RedmineからPMBOKのEVMを計測する方法
RedmineからPMBOKのEVMを計測する方法についてアイデアをメモ。
【元ネタ】
チケット駆動開発にEVMの概念を導入してみる: プログラマの思索
RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索
チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索
【1】PMBOKのEVM(Earned Value Management)とは、工事進行基準による進捗管理と実質的に同義だ。
昨今のITプロジェクトでは、大規模案件ほど、成果物の進捗ベースで売上が計上される仕組みが多いだろう。
すると、メンバーに毎日の進捗報告を義務付けて、マネージャが週1回集計して、売上を計上して会社に報告する流れになるだろう。
以前は、工事終了基準だったから、システムの検収後に一括して売上を計上すれば良かったが、J-SOXがあるために実質的に不可能。
実際に工事進行基準でプロジェクト管理を始めると、実績工数を含めた進捗報告と集計作業がとても大変で、実際の仕事に関係ない所でロスが発生する。
運用ルールが決められていないと、進捗率が90%のまま1週間以上も未完了だったり、各メンバーの進捗報告のレイアウトがバラバラで集計しにくかったりする。
そもそも、実プロジェクトの進捗管理そのものがルーズだったりすれば、すぐにデスマーチに陥る。
【2】PMBOKのEVMは、成果物の進捗ベースからスケジュールやコストを予測できる優れた仕組みだが、正直分かりづらい。
僕は、Redmineによるチケット駆動開発でEVMの概念が腑に落ちた。
EVMの概念は下記でRedmineへマッピングできる。
(1) PV=sum(該当期間のチケットの予定工数)
(2) AC=sum(該当期間のチケットの実績工数)
(3) EV=sum(該当期間の終了チケットの予定工数)
又は
EV=sum(該当期間のチケットの予定工数×進捗率)
ここで、EVの概念がAgile開発と従来のWF型開発の場合、2通りの定義が出ることに注意して欲しい。
EVは獲得価値(出来高)であるから、実際の成果物(出来高)に相当する。
Agile開発では、作業の終了条件(Done)がリリースできることだから、進捗率は0%か100%のどちらかしかない。
ソースをコミットしてビルドして動くのが確認できるまで、未着手でも作業中でも0%だ。
何故なら、Doneの条件が動くシステム=リリース完了だからだ。
Agile開発が定義するEVはとても厳格で、うまくプロジェクト管理できなければ、顧客から見れば、殆ど作業がはかどっていないように見えるだろう。
従来のWF型開発では、メンバーが自分の判断で進捗率を入れる場合が多いだろう。
すると、進捗率の基準があいまいなため、90%シンドローム(進捗率が90%のまま停滞する)が起きやすく、EVの値が正しくないケースが出てきがちだ。
だから、普通は作業ステータスごとに進捗率が設定されるだろう。
未着手=0%、作業中=50%、レビュー中=90%、完了=100%みたいになるだろう。
Redmineの場合、管理画面でステータスごとに進捗率を設定できるので、この機能を使えばいいだろう。
又、実績工数の入力ではWorkTimeプラグインがとても使いやすいのでお勧めだ。
プラグイン作者は、このプラグインから出力された前日の実績データを朝会で使っていると聞いたことがある。
RedmineのWorkTimeプラグイン: プログラマの思索
【3】PV、AC、EVの値は、Redmineからすぐに取り出せる仕組みはないようだ。
直接MySQLにアクセスして、SQLでデータをダウンロードしなくてはいけないようだ。
その場合、下記のようなデータのフォーマットがあれば、EVMは計算可能。
チケットNo,開始日,終了日,予定工数,実績工数,進捗率
現在日付から該当の期間を初期設定しておけば、ExcelマクロでPV、AC、EVの値は集計可能。
Excelの集計のアイデアは下記に書いた。
本来は、Redmineの画面上でEVMをグラフ化してくれるのが良いのだが、今の所、そういうプラグインは存在しないようだ。
【4】EVMを使う場合、ベースラインが重要で、最初に決めた計画のベースラインを修正することはない。
修正してしまったら、予定と実績の差がなくなるので、差異分析ができなくなるからだ。
だが、実プロジェクトでは、マイルストーンごとに見直し作業や作業漏れのタスクを反映してリスケする時がとても多い。
そうしなければ、ベースラインは実プロジェクトからかけ離れた与太話に過ぎなくなり、差異分析する意味もなくなる。
EVMのグラフを見ると、Agile開発で出てくるバーンダウンチャートに似ているように見える。
バーンダウンチャートは、PVとEVを右肩下がりで描いたグラフと言える。
実際、バーンダウンチャートの残作業の予定量はBAC-PV、残作業の実績量はBAC-EVから求められる。
ベースラインを使うEVMよりもバーンダウンチャートの方が開発チームにとって有効である理由の一つは、ゴールが見えやすいことだろう。
無理な予定に実作業を合わせるのではなく、顧客に価値あるソフトウェアを作るために、決められた納期までに作業を進める方が現実的だからだ。
PMBOKのEVMをITプロジェクトへ適用する場合、建設業やプラント業界とは違ったノウハウが必要とされるように思う。
もう少し考えてみる。
| 固定リンク
« Shibuya.trac第12回勉強会でチケット管理システム大決戦第2弾が開かれるようです #tidd | トップページ | Redmineが使いづらいと言う質問~開発業務をRedmineへマッピングできていない »
「プロジェクトマネジメント」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
「Redmine」カテゴリの記事
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント