とりあえず実物を見ていただいたほうが話が早いので、さっそく以下の図をご覧ください。
あれだけガントチャートを批判しておいて、どんな凄い物が出てくるんだと期待した方には拍子抜けするかもしれませんが、至ってシンプルなグラフです。
しかしこの単純なグラフこそ、ソフトウェア開発者にとってガントチャートよりも実践的な、現実に即した進捗管理ツールなのです。
バーンダウンチャートでは縦軸に残タスクの量、横軸に時間を取ります。上記の例では縦軸に残タスクの見積もり所要時間合計、横軸に日付を取っています。
横軸の範囲はプロジェクトの進め方に応じて決めればよいのですが、上の例では次のバージョン（公式リリース用ではなく内部管理用のバージョン）の完成予定日までにしています。
毎日帰る前に、残タスクの見積り時間の合計をグラフに記録していきます。
残り時間合計が減っていき、グラフが一番下まで行って横軸と交わったら完了です。
このバーンダウンチャートを使うと、次のように前回挙げたガントチャートの欠点を回避できます。
- 順番を意識しないでいい
ガントチャートは作業の順番に依存した描き方でしたが、バーンダウンチャートは残り時間の合計を記録していくので、途中で作業の順番を入れ替えようが関係ありません。 - 見積りの変更に強い
仕様変更や作業時間の見積もりが間違っていて工数を変更した場合でも、グラフを変更したあとの数値で続けて書いていけばいいだけです。書き直しは発生しません。 - 開発スピードが分かる
これが一番のメリットでしょう。グラフの傾きで一目で分かります。しかも結構初期の段階で分かります。
そして突発的トラブルで遅れているのか、開発スピード自体に問題があるのかも判別をつけやすいです。突発的トラブルなら、グラフの傾きが突然鈍くなるはずですが、そもそも開発スピード自体が遅いなら、グラフの傾きは最初から鈍いはずです。
グラフの傾きを見ることで、頑張れば挽回できるのか、それとも無理なのかの判断材料にすることが出来るのです。
ちなみに上記のグラフは実際に僕が仕事で記録したデータそのものです。推移を見ていくと、
・1/16(水)～1/18(金)辺りで何らかの事情によりペースが落ち、
・遅れを取り戻すため、やむなく土日出勤し、
・次の週、頑張って追い込みをかけ、
・スパートかけた甲斐あって最後の１日は余裕を持って終了
といった生々しい状況（笑）を読み取ることができます。このような状況をあとから時系列に沿って振り返ることも、ガントチャートでは不可能ですがバーンダウンチャートなら可能です。
また、バーンダウンチャートはExcelで簡単に作れます。こんな感じで表を作ってグラフにしていました。
なお、表とグラフ横軸の土日はもともと存在せず、あとから足しました(もちろんです)。単純に表の行を足せば自動的にグラフに反映されるので変更は簡単でした（Excelグラフのいいところですね）。開発状況の方は大変でしたが（苦笑）。
ちなみにこの「残り時間合計」をどうやって計算するのかというと、実はバーンダウンチャートと組になるもう一つのツール「タスクボード」を使うのです。タスクボードについては別の記事で改めて取り上げます。（→こちら）
さて、色々とメリットがあるバーンダウンチャートですが、もちろん万能ではありません。
- 横軸が一定以上長くなると使いづらい
例えば横軸を1目盛1日に取る場合、1週間～4週間くらいまでが使いやすい範囲といえるでしょう。それ以上になるとかえって見にくくなってきます。
その意味でバーンダウンチャートはアジャイル開発手法には最適です。アジャイルでは繰り返しの単位を1週間～4週間で設定することが多いからです。そもそも僕はアジャイル開発の書籍でバーンダウンチャートを知りました。
反復型開発やウォーターフォールモデルなどでバーンダウンチャートを使う場合、設計・実装・テストの各工程ごとに別々のグラフを描くと良いでしょう。それでも期間が長いようなら、更に各工程内部で幾つかに分割するなどの工夫が考えられます。 - タスク総量が増加したことと開発が滞っていることの区別がつかない
前述のように突発的トラブルが発生したこと自体は、グラフの傾きが急に鈍くなることから分かります。しかし、そのトラブルの内容が「開発が進んでいない」のか、「開発は進んでいるがタスクの総量が増えてタスク残量が減らなくなった」のかの区別はつきません。
0 件のコメント:
コメントを投稿