プログラマの思索

EVMとバーンダウンチャートは本質的に違うことを指摘している記事を見つけたのでメモ。
ラフなメモ書き。

【元ネタ】
バーンダウンチャート / バックロググラフっていいね。 - 遅れなんか見たくない。いつ終わるかを見たいんだ。: 円山貫’s EYE on high-tech development

【1】
(引用開始)
■ 縦軸に見積もり工数を取った場合、工数ベースのEVMS(*)をひっくり返した形に近い。
(中略)
※(バーンダウンチャートでは)プロット毎に残作業を見積もるということは、過去作業の作業効率から完成時コストを延長推定する(簡易)EVMSよりも本質的には厳密なもの。アジャイル精神、開発チームが作業をコントロールするためのツールとして使うのは楽しいが、超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある。(※追記：2005.7.26)
(引用終了)

バーンダウンチャートはEVMの工数を残工数へひっくり返した形である指摘は、僕も同じ意見だ。
アジャイル開発の方が管理作業は第三者から見れば楽そうに見えるが、アジャイル開発の方が作業の終了基準が厳しいため、「超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある」。

(引用開始)
■そもそも、EVMSとバックロググラフ(バーンダウンチャート)では、根本的な発想が違う。
EVMSは、計画(WBS)を絶対視したうえで期間と費用の計画偏差を是正しようとする。ベースライン計画に如何に収束させるか、という発想で、予算化した計画を動かすことはほとんど拒否する。
バックロググラフでは、期間固定で、計画(WBS)が流動するものとする。一定期間内に出来ることでとにかく切りをつけよう、という発想になる。
(引用終了)

EVMSとバーンダウンチャートは根本的に発想が違う指摘は全く同意。
PMBOKにせよ、WF型開発にせよ、最初に立てた計画から実績がどれだけずれているかを追跡して、いかにその変化を抑えこむか、という発想でコントロールする。
しかし、アジャイル開発はその発想がそもそも無い。
イテレーション計画は当然作るが、イテレーション実施中に、イテレーション計画の作業順序は頻繁に変わるし、流動的だ。
2～4週間という短い期間で全ての作業を終了させるには、計画にしがみつくよりも、その実績に応じてやり方を変えていく。

計画を立てて実績のズレを検証し、その内容をフィードバックしていくという仮説検証スタイルはアジャイル開発だけでなく、WF型開発でもよく言われている。
検証した結果、計画が間違っていたら計画を修正ないし、新しく作りなおせばいい。
しかし、計画を変更してしまうとWF型開発では当初の予算も変わってしまうため、修正することがとても難しい。

そんなことを考えながら、「アジャイルな見積りと計画づくり」や「ソフトウェア見積り―人月の暗黙知を解き明かす」を読み直すと、計画と見積りは密接に関わっている事実、更にそこにはもっと深い考えがあるような気がしている。

【2】@daipresentsさんのredmine_version_burndown_charts画面では、Scrumの考え方をさらに注入して、面白いメトリクスを表示してくれる。

理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索

(1)「予想ライン」が予定工数から計算される残工数、「実績ライン」が実績工数と進捗率から計算される残工数。
(2)理想ラインは、該当バージョンの開始日から期日に向けて残工数がまっすぐ下がっていく残工数。
(3)上限ライン・下限ラインは、予定工数の±20%という設定から計算される理想ライン。管理図のようなもの。
(4) 本来のバーンダウンチャートは、理想ラインの付近で表示されるのが望ましい。理想ラインから離れるほどタスクがあふれていることを示している。

また、バーンダウンチャートの下がり具合を調べると、チームの成熟度や能力を予想することもできる。

バーンダウンチャートのパターン集: プログラマの思索

上記の「上限ライン・下限ライン」枠内にバーンダウンチャートが収まっているならば、そのチームはそのイテレーションを完全にコントロールできていると言えるだろう。
でも実際のプロジェクトでは、「上限ライン・下限ライン」枠外に残作業が残ってしまって、アップアップになってしまう状況も多い。

また、バーンダウンチャートをRedmineで実際に運用するのは、結構面倒だ。
チケットに開始日、終了日、予定工数、実績工数を毎日正確に入力してもらわないとチームの実情にあったグラフにならないからだ。
この辺りの運用はまだまだ改善の余地はある。