EVMはアジャイル開発に適用できるか
InfoQの記事で、EVMはアジャイル開発に適用できるか、という課題について書かれた記事があったのでメモ。
ラフなメモ書き。
【元ネタ】
アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるか
AgileEVM: 製品ライフサイクル全体で費用対効果を計測する
アジャイル開発は工事進行基準と相性が良いという仮説: プログラマの思索
【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索
EVMとバーンダウンチャートは本質的に違う: プログラマの思索
EVMの考え方は、計画と実績の差異を追跡して、変化を抑え込む点にある。
計画通りに進まないのは悪い、計画通りに作業させる、という発想。
つまり、ウォーターフォール型開発と相性が良い。
でも、ソフトウェア開発の場合、WF型開発でうまくいった試しがない。
EVMを繰り返し型開発やアジャイル開発に適用する場合、そもそも計画に合わせて作業するという発想よりも、納期と費用の差異を現状に合わせて是正しながら作業する発想のため、そのままでは適用できない。
当初の計画があっても、その計画はすぐに現実に合わなくなるからだ。
途中でたくさんの仕様変更や仕様追加、障害修正が入って、それらを混ぜ込んで、小刻みにリリースしていくスタイルゆえに、計画をガチガチに守るよりも、スコープを調整する方を重視する。
だから、EVMをアジャイル開発に適用する場合、PV・AC・EVを再定義する必要がある。
アジャイル開発でももちろん見積もり作業はある。
その見積もり(PV)は開発規模(ストーリーポイント)が普通だろうが、EVMの場合は理想日という工数を使えばいい。
実績(AC)は文字通り実績工数。
出来高(EV)は、Doneの定義で評価されたアウトプット。基本は、0または100%のいずれか。
つまり、出来高は、出荷可能な製品の一部であるかどうかで判断できる。
アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるかでは、「EV は資金提供者にとって意味のある単位,すなわち金額で完成予測を行う」ことに使おうとしている。
バーンダウンチャートとEVMの違いは、出来高という概念を残工数でみるか、完成した出来高の累積値として捉えるか、の違いだ。
つまり、バーンダウンチャートは、イテレーション単位にEVMのグラフからPV-EVの数値だけを時系列に抜き出したものと見なすことができる。
この観点の違いは重要だ。
バーンダウンチャートでは、PVは変動する値と見なすのに対し、WF型開発のEVMではPVは固定値と見なす。
そして、EVの考え方も、WF型開発では進捗率で測定するのに対し、アジャイル開発では未完了か完了のどちらかで測定する。
したがって、アジャイル開発の方がEVの定義が厳しいために、担当する作業の粒度を小さくしてどんどん完了していくペースでなければ、プロジェクトの進捗は遅延しているように見えるだろう。
つまり、アジャイル開発では、イテレーションというタイムボックスで管理したり、作業の粒度を小さくするなどの工夫をしなければ、EVMで測定しても変化がほとんどないから意味がない。
EVMをアジャイル開発に適用できると、EVMの公式を使って、プロジェクトの進捗やコストを予測したり評価する手法を使える。
AgileEVM: 製品ライフサイクル全体で費用対効果を計測するでは、SPIを使って進捗度合いをグラフ化して見える化している。
CPIを測定すれば、開発チームの開発ペースが分かるから、総コストも予測できるだろう。
このあたりのアイデアはもう少しまとめてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント