プログラマの思索

チケット駆動開発にEVMの概念を導入できるか考えた事をメモ。
#間違っているかもしれないので、あくまでもイメージを書く。

【元ネタ】
[ThinkIT] 第2回：EVMの基本値から導出される値の説明と練習問題 (1/4)

チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索

Redmineの集計プラグイン、statSVN諸々: プログラマの思索

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

プロジェクト実績の測定とコントロール

【1】以前のように、システムの検収が終わった後に丼勘定で収支のつじつまを合わせる工事完成基準は、もはやできない。
2009/4から、SW開発も他業界と同様に工事進行基準で会計報告が必須になったため、四苦八苦しているプロジェクトは多いだろう。

EVMは、SW開発のプロジェクト管理における工事進行基準の仕組みと言ってもいい。
EVMで出てくる概念は、次の3つと言っていい。

・出来高計画値(PV)→該当期間の作業の総予定工数
・投入実績値(AC)→該当期間の実質の総実績工数
・出来高実績値(EV)→該当期間の完了した作業の総予定工数

PV(Planned Value)は計画価値であり、ベースラインに相当する。
AC(Actual Cost)は実コストであり、実績値そのもの。
EV(Earned Value)はいわゆる達成価値。

EVMの利点は、完了時総見積(EAC)を予測できること、そして、CPIやSPIから進捗やコストのリスク管理に使えることだ。

【2】この概念をチケット駆動開発では下記で置き換えられる。

・出来高計画値(PV)→該当バージョンのチケットの総予定工数
・投入実績値(AC)→該当バージョンのチケットの進捗率も加算した総実績工数(薄緑色の進捗)
・出来高実績値(EV)→該当バージョンの終了チケットの総予定工数(濃緑色の進捗)

即ち、Redmineのロードマップ画面では、ACは見かけ上の進捗、EVは実質の進捗に置き換えられる。

実際に下記のプロジェクトに当てはめた場合、チケット駆動開発で考えてみよう。

2-1.スケジュールも遅延し、コストもオーバーした場合
2-2.コストはオーバーしたが、納期までに納品できた場合
2-3.コストも予算内に収まり、納期までに納品できた場合

2-1.では、SV(スケジュール差異)＜0、CV(コスト差異)＜0になるので、EV＜PV、EV＜ACになる。
つまり、終了チケットの消化具合は予定よりも少ないため、EV(システムの実質の価値)は予定よりも低い。
又、終了チケットの総予定工数よりも総実績工数が多いため、コストオーバーでタスクを完了させたことになる。

Redmineのロードマップ画面では、該当バージョンの進捗バーは緑色が少なくて白色の部分が多く、殆ど進んでいない状況だろう。

即ち、タスクをこなす進捗速度は予定よりも遅いから、コストも増大しているのだ。
いわゆるデスマーチ、あるいは、要件定義から不穏な雰囲気のあるプロジェクトが相当するだろう。

原因としては、元々の見積もりが甘かった事もあるだろう。
だから、WBSを洗い出した時に、WBSをチケットに当てはめてBTS上で進捗のシミュレーションをあらかじめできれば、既に請け負った段階で、どうやっても納期はオーバーしたり、コストも予定よりもオーバーする事実を説明できるだろう。
つまり、チケット数と言うスコープを調整するしかありません、とユーザに言う事ができるだろう。

2-2.では、SV(スケジュール差異)≧0、CV(コスト差異)＜0になるので、EV≧PV、EV＜ACになる。
つまり、終了チケットの消化具合は予定通りに進んだものの、当初の予定工数よりも実績工数が大きいので、それぞれのチケットの工数を見れば、殆どが工数オーバーだったことになる。

Redmineのロードマップ画面では、該当バージョンの進捗バーは薄緑色の部分は多いものの、濃緑色が少ない状況だろう。
つまり、見かけ上の進捗は予定通り進んでいるが、実質の進捗(＝終了チケット数)は遅延している状況だろう。
よくある状況は、設計や開発は進んでいるものの、色んな理由でレビュー待ちになっている場合。

即ち、タスクをこなす進捗速度は予定通りだが、コストは増大している。
このパターンがSW開発ではとても多いだろうと思う。
要件漏れ、仕様変更による手戻り作業、重大なバグをリリース間際に発見して何とか修正した、など、当初の予定になかったタスクが発生して、その分コストオーバーになった例が多いだろう。

SW開発では、当初の計画にない突発的なタスクの管理が重要になってくる。
チケット駆動開発をアジャイル開発として扱えば、変更を受け入れる余地があるため、突発的に生じたタスクをチケットに登録して管理できる。
しかも、そのチケットをどのイテレーションでこなすか、というイテレーション計画の発想によって、変化を吸収できる。
いわゆる小規模リリースによって、予期しない変化を取り込む余裕を作っているのだ。

2-3.では、SV(スケジュール差異)≧0、CV(コスト差異)≧0になるので、EV≧PV、EV≧ACになる。
つまり、終了チケットの消化具合は予定通りに進み、当初の予定工数よりも実績工数が少なかったので、コストもオーバーしなかったことになる。

Redmineのロードマップ画面では、該当バージョンの進捗バーは濃緑色の部分が多く、もう少しでリリースできる状況だろう。

即ち、チケットをこなす速度も予定よりも早く進み、そのおかげで納期も短くなったことになる。
このパターンは、プロジェクトの理想的な展開だといえるだろう。

実際は、アジャイル開発で小規模リリースを実施すると、初期のイテレーションは非常に苦労するが、後期のイテレーションではこのパターンに当てはまる。
最初は、要件や仕様の理解に苦しんだり、新しい技術の習得に時間がかかったり、メンバーの役割分担が不十分だったりして、何とかイテレーションをこなすのが精一杯。
しかし、イテレーションと言うリズムに慣れると、イテレーションに収まりきらないチケットは後回しにしたり、優先順位を付けてチケットを入れ替えるなどのマネジメントがスムーズになるので、結果的にバグが生じにくくなり、手戻り作業も減る。

SW開発では、学習速度と言う概念が重要だと思う。
3ヶ月経てば、新人であろうとも、仕様も技術も慣れてくる。
その分、タスクをこなす速度は上がってくる。
つまり、開発チームのベロシティ(進捗速度)はほぼ一定になるので、見積もりの精度が高くなり、手戻り作業などのリスク管理も上手に制御できるようになるだろう。

【3】つまり、Redmineでは、EVMの対象範囲をバージョンという複数のイテレーションに分割しており、各バージョンの進捗管理をロードマップ画面で一覧していることになる。

特に、Redmineのロードマップ画面がTracやMantisよりも優れているのは、上記3種類の進捗を表示している事だ。
TracやMantisでは、出来高計画値(PV)と出来高実績値(EV)しか表示しておらず、実質の実績工数から得られる進捗を表示しない為、現在の作業の遅延がどんな状況なのか、具体的に把握しづらい。

Redmineではサマリという画面で、チケットの作業状態をステータスごとに集計してくれるので、未完了の作業の内訳を見れば、レビュー待ちで遅れているのか、テスト中で遅れているのか、を探る事ができる。

TiDD(チケット駆動開発)は上記の関係によって、EVMが計算可能な点もある。
つまり、工事進行基準に対応可能だ。
この理由は、進捗情報・工数情報・WBS情報が全てDBにあるから、SQLやプログラムさえ作れば、いくらでも色んな観点で集計可能だからだ。

更に、TiDDの更なる利点は、WBSが頻繁に変わっても、TiDDならリアルタイムにEVM出力が可能なことだ。
実際のSW開発では仕様変更や手戻り作業が頻繁に発生し、その都度、最新状況を反映しなくてはならない。
TiDDでは、チケットを新たに登録すればいいから、スコープの変化に対応しやすい。

結局、現代のSW開発のプロジェクト管理は、高度な管理システムが必須だ。
現代のSW開発のビジネスは、プロジェクト管理がIT化されていなければやってゆけない。

工事進行基準に対応するには、Excelは到底無理なはず。
EVMを計算するには、マクロを駆使するしかない。
マクロを作ると言う事は、Excelが一つのシステムであること。
しかし、Excelは壊れやすく、保守しにくい。

更に、MSProjectも最終的には難しいだろう。
MSProjectには資源平準化の機能もあるし、EVMも計算できる。
しかし、WBSの変化や実績工数をの履歴を残せば、ファイルサイズがどんどん膨らむ。
結局、Excelのファイルバックアップのように、「XXシステムの進捗_yyMMdd.mpp」というファイル管理をせざるを得ない。

チケット駆動開発を単なるアジャイル開発のプロジェクト管理から、SW開発のプロジェクト管理ツールへ拡張できるか、模索してみたい。