EVMとバーンダウンチャートは本質的に違う
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で実際に運用するのは、結構面倒だ。
チケットに開始日、終了日、予定工数、実績工数を毎日正確に入力してもらわないとチームの実情にあったグラフにならないからだ。
この辺りの運用はまだまだ改善の余地はある。
| 固定リンク
「Agile」カテゴリの記事
- 法律のケース問題をモデル化するアイデア(2019.02.11)
- Coplienの開発工程の生成的パターン言語を読むpart1(2012.10.11)
- ユーザ機能駆動開発FDDを再考(2011.05.28)
- Redmineプロジェクトの構造とConwayの法則(2011.05.18)
- Conwayの法則~アーキテクチャは組織にしたがう(2011.04.17)
「Redmine」カテゴリの記事
- Redmineインスタンスはチームの組織文化や慣習を表す(2016.06.04)
- RedmineユーザはRedminersと呼ぼう~We are Redminers!(2019.02.11)
- 日本の大企業におけるRedmineの利用事例の資料のリンク(2017.03.22)
- 第14回東京Redmine勉強会の感想 #redmineT(2018.05.27)
- RedmineのGit連携機能に関する議論(2019.01.31)
「ソフトウェア工学」カテゴリの記事
- ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか(2015.07.18)
- 【告知】2019/2/16にSEA関西でIPAの方の講演「IoT時代のシステム開発アプローチ」の見所 #seakansai(2019.01.11)
- 【告知】2019/3/2にSEA関西で「気象予報システムを支える技術」の見所 #seakansai(2019.01.11)
- 大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響(2016.06.19)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
「プロジェクトマネジメント」カテゴリの記事
- クラウド(対立解消図)の考え方(2019.02.03)
- 大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響(2016.06.19)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
- Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う(2015.07.15)
- Coplienの開発工程の生成的パターン言語を読むpart1(2012.10.11)
コメント