よい「進捗報告」
われらがケントベック様のお言葉では
http://blogs.itmedia.co.jp/hiranabe/2006/06/post_2ffc.html
- Honest - 正直であること。事実をまげないこと。
- Effective - うまく伝わること。
- Responsive - 反応的であること。プロジェクトのフィードバックループに組み込まれていること。
何のための進捗かですね。Honestであってもうまく伝えられなければ意味がない。だめな進捗報告の例で有名な話は、毎週80%の状態が続く進捗報告ですね。報告している本人にとっては、確かに毎週80%なんですよね、その時点でゴールが不明確だから正直にそう思ってしまうのですよね。そのこと自体は攻められないけど、もっと現実をうまく伝える方法があるはずですよね。単体試験のテスト項目消化件数とか、仕様書ページ数とか少しでも計測可能な数値が欲しいですね。
また、進捗報告で難しいのは、検討項目とタスクの混在があります。検討項目をタスクとして取り扱うと制御困難になりがちです。だって、ゴールが見えないから検討事項なんでもの。もっと具体的なタスク(作業)のレベルに分解して進捗を管理すべきです。
アジャイルPMBOKドラフト版より、アジャイル進捗報告の原則
原則
http://www.metabolics.co.jp/SoftwareProcess/APMBOK2004.pdf
- 進捗報告にストレス / コストを掛けない.
- できる限り自動化ツールを使う.
- 進捗報告はメンバの能力を測定するためのものではない.
- 公表するときにはプロジェクト全体の値として公表する.
- 進捗はときどき測るものではなく, 常に測定する.
- 週1回, 月1回の報告ではそれに基づいてプロジェクトの舵をきることができない.
- 進捗の尺度は客観的で, 直接的で, 計測可能でなければならない.
- 「だいたい1/3くらい終了」は進捗ではない, 思い込み.
- 90%完了シンドローム
- ソフトウェアの価値とは直接関係のないコード行数を測っても意味はない.
- 検証規準をパスしていないものは進捗ゼロと測る.
- バイナリ・トラッキング (二値追跡)
- 基本的にはスコープの達成度合いを, スコープの検証基準に基づいて測定する.
- 報告された結果はちゃんとフィードバックする.
- 管理者が隠し持っていても意味はないし, 報告者のモチベーションにならない.
- 全員がいつでも気にしていられるように.
これらは、いわゆるプロジェクト管理のための進捗ですが、PSP的とでも言うのでしょうか、個人の成長のための進捗管理(じゃ報告の必要ないじゃん)というものも存在します。自分の作業に対して、いつも制御可能な範囲で制御し続ける訓練ですね。自分の作業見積が正確にできるようになると、その集合体であるプロジェクトの見積も正確になって最後みんな幸せになれる、かな？
