進捗管理について思うこと

進捗状況は自動的に収集する

手動で進捗状況を記入させている場合、頻繁に進捗を入力させると観察者効果により、余計に進捗が進まなくなる。
頻繁に進捗状況を報告させると、進捗状況が改善するどころか、悪化する。
だから、進捗状況は自動的に集まるようにしておかなければならない。
だるまさんがころんだ方式の進捗管理 - Sacrificed & Exploited

進捗状況は客観的でなければならない

主観的にソースコードをここまで書いたから、50%とか100%とか記入しているようでは真の進捗状況を知ることはできない。

10/28追記

大事なことを忘れていた。客観的であれば何でもいいわけではない。
ステップ数の非常識2.ステップ数で進捗を管理する - Sacrificed & Exploitedで述べているように、ソースコードの行数、ステップ数などは当てにならん。

例えば、見積もりのステップ数に達していても、テストしてみたらぼろぼろだったとか、
無駄に行数を稼ぐことができたりとか、ソフトウェアが完成したかどうかの進捗の実態とは乖離しており、指標としては不適切だ。

本当に管理しなければならないのは、開発工程上どこまで進んでいるのかではなく、ソフトウェアの完成までどこまで進んでいるのかという事だ。

私はソフトウェアが完成したかどうかの基準は、そのソフトウェアが満たさなければならないテストを全て通過したかどうかだと考える。
テストしてもいないコードを進捗として計上するのは、プロジェクト進捗率の架空計上なのではないか。

進捗状況が遅いからといってペナルティを課したり、怒ったり、責めたりしてはならない。

それこそ正直ものがバカを見るような状況では、誰も本当のことを言わなくなる。
あとでひどいことになるとしてもだ。
「正直ベースの進捗率」とか言ってる時点で、 もう進捗管理としては破綻していると思ってよい。

本当の進捗状況を知るには、ゴールが動かない事が前提。

毎週仕様書に改訂が入るような場合、改訂の度にゴールが遠ざかっている。
そのような状況で本当の進捗状況を知ることは出来ない。
50%までできたと思ったら、ゴールの方が動いてたでは話にならん。