« ビジネスモデルキャンパスの感想 | トップページ | レガシーマイグレーションという名のシステム移行はデスマーチになりやすい »

2013/07/15

EVMはアジャイル開発に適用できるか

InfoQの記事で、EVMはアジャイル開発に適用できるか、という課題について書かれた記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるか

AgileEVM: 製品ライフサイクル全体で費用対効果を計測する

アジャイル開発は工事進行基準と相性が良いという仮説: プログラマの思索

RedmineのEVMプラグイン: プログラマの思索

【公開】未発表資料「チケット駆動開発における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を測定すれば、開発チームの開発ペースが分かるから、総コストも予測できるだろう。

このあたりのアイデアはもう少しまとめてみたい。

|

« ビジネスモデルキャンパスの感想 | トップページ | レガシーマイグレーションという名のシステム移行はデスマーチになりやすい »

プロジェクトマネジメント」カテゴリの記事

ソフトウェア工学」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« ビジネスモデルキャンパスの感想 | トップページ | レガシーマイグレーションという名のシステム移行はデスマーチになりやすい »