nDiki : KPT

スポンサードリンク

2005年10月7日 (金)

■ すごいKPT事後評価セッション

スポンサードリンク

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

*1 @IT: 初めてのプロジェクトリーダー(6) 「ふりかえり」でプロジェクトを改善する

@ 招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
- スコープ、スケジュール、リソース、欠陥レベル
- プロジェクト運営
- コラボレーション (スタッフ間)
- 個人・チームとして学習した点
- その他 (開発手法など)
問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
問題点は Problem です。(KPT法流)
問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
注意点 (「適応型ソフトウェア開発流」)
- 良かった点を必ず書いてください。(すごい会議にも通じる)
- 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
- 特定の個人を批評はいけません。
事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

@ セッション

メンバは4人。ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出ればホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。「担当」と「期日」を明確に設定 (すごい会議流)。

@ 完了

合計90分。ほぼ予定時間とぴったり。事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

◇ Twitter やってます。この記事が気にいったらぜひ twitter.com/Naney の follower になってください。

[ permalink ]

すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
すごい会議はじめての全手順(1/2) (2005-06-30)
今日のさえずり - 壊れた金具の代わりに南京錠 (2009-04-14)
「すごい会議」2度目 (2005-06-03)
ソフトウェアかんばん「見えない化」 (2006-04-10)

[ 10月7日全て ]

2005年10月28日 (金)

■ ソフトウェアかんばん

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

B6 情報カードを使う。
- この大きさだと書くにはちょうど良さそうだが広い壁が必要になりそうだ。
エクストリーム・プログラミングのように、まずはストーリーカードを作成する。
- 今回はベースとなる仕様書の機能を実装する形。ビジネスサイドがストーリーカードを作るという体制にはできないので、開発チームでストーリーカードをおこす。
ストーリーカードからのタスクカードおこし。
- 時間の関係から、まずは優先度の高いストーリーカードを選んでこれをタスク化する。
- タスク化済みのストーリーカードは(tなどの)マークをつける。
タスクカードのカテゴリは「TODO」「DOING」「CHECKING」「DONE」の4つとする。
開発者は TODO タスクカードから1枚カードを選んで署名して DOING へ移す。
タスク作業完了後「DONE」あるいは「CHECKING」へ移す。
- 「CHECKING」はチームはタスクを受け持った人が作業完了後、チームでチェックをして欲しい時に入れられるカテゴリ。
- カテゴリ名はこれでいいかな?

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

イテレーションの設定
タスクの見積もり
ストーリーの見積もり
全体の見積もり
定期的チェックタイムの設定
貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]

[ permalink ]

[ 10月28日全て ]

2005年12月6日 (火)

■ 乱入OK! コラボレーションタイム

11月末にモノを発送できたプロジェクトの事後評価セッション。手法は前回と同じくKPT法をとりいれた方法で。

セッションでは「質問したい時に、忙しそうにしていると話かけづらい時がある」という課題があがった。あ、自分のことね。忙しいと集中して(あるいは集中しているフリをして)そういう雰囲気を醸し出しているな。

こちらは案外好きな時間に声をかけているのだが、立場というダイオードが入っているのかもしれない。

集中とコラボレーション、どちらも大切。

ということでアイデアとして、時間を決めてその間はアポがはいっていたり極限状況にあったりない限り、チームメンバで御互いに話しかけたら誠実に対応するというルールを作ってみた。 15:00 - 16:00 をその時間に。その日にある程度作業をした後問題が発生した頃で、かつコラボレーション後実行してみる時間を残っている時間はこの時間帯かなと。

トリンプ・インターナショナル・ジャパンの「がんばるタイム」のように、各個人業務の集中時間を設けるという事例は聞いたころがあるが、こういうコラブレーション推奨時間を設けている話はまだ見かけたことがない。多分いろんなところでやられていると思うのだけれども。

p.s.

基本的にそれ以外の時間には話かけるなということではないので、お間違いなく。

[ permalink ]

[ 12月6日全て ]