2013年3月20日水曜日

ガントチャートを捨てろ(4) タスクボードとバーンダウンチャート

前回(→こちら)はバーンダウンチャートとバーンアップチャートの併記によるメリットについて述べました。じゃあそのバーンダウンチャートとバーンアップチャートはどうやって作ればいいの?ということで、今回はタスクボードについて紹介したいと思います。

ということで早速、実物を見ていただこうと思います。


これがタスクボードです。一部を伏字にしていますが、実際に仕事で使ったものです。

このプロジェクトでは、Redmineのチケットを一つの単位として管理していました。チケット番号を左端に記入し、チケット題名を記入します。このチケット題名ですが、なるべく主語を明確にします。例えば、「サイト訪問者として○○を選択できるようにする」などです。このように主語を明確にして利用者の立場から機能要件を表現したものを「ユーザーストーリー」と呼びます。つまり上の図ではRedmineとの連携を意識して「チケット題名」と書いていますが、ここは「ユーザーストーリー」と書いてもいいのです。

その横の「SP」は「ストーリーポイント」です。「ストーリポイント」とは、ストーリーの大きさを表す相対値です。相対値なので、あるストーリーを5と決めたら、その2倍の大きさのストーリーは10となります。別にこれを10と20にしてもいいわけです。

そして、各チケット(のストーリー)をタスクに分解し、各タスクの時間を見積ります。
上の図では、細かく分解してありますが、実際には最初から詳細にタスク分解する必要はありません。例えば、最初の時点では

・ 仕様・タスクを定義する
・ 実装
・ 調整
・ テスト実施、バグ修正を行う

の4つのみに分解しておき、タスクをこなしながら実装方式検討や実装の細かい分類のタスクなどに細かく分解していけばいいのです。その際、ストーリーごとの見積時間の合計が変わらないようにしておけば、全体として整合性が保たれます。

ここで、ストーリーポイントとそのストーリー中のタスクの見積り時間の合計がほぼ対応するようにします。例えば上の図では、各チケット(のストーリー)のタスクについての見積時間の合計は、「ストーリーポイント×4」になっています。厳密に合わせなければいけないわけではないですが、だいたい合わせるようにします。

例えば上の図でチケット#30は「実装(処理)」が5時間、「実装(権限制御)」が5時間となっていますがもともとは「実装」の1つで10時間と見積もっていたものです。これを作業をしながら前述の2つに分けたのです。

各タスクについて、現在の状態に応じて「未着手」「作業中」「完了」の欄のどれかに印をマークします。また、着手した際には「着手日」に、完了した際には「完了日」に日付を記録します。

「残り時間」「完了時間」「進捗率」はExcelの機能で自動計算することができます(「完了」列にマークされているかどうかを判断して計算します)。

タスクボードの下部には「見積時間」「残り時間」「完了時間」「進捗率」の合計値がExcelの機能で自動的に算出されるようになっています。

タスクボードからのバーンアップ・バーンダウンチャートの作成は簡単です。
1日ごとに「残り時間」の合計を記録すればバーンダウンチャートになります。
また、「見積時間」の合計と「完了時間」の合計を記録すればバーンアップチャートになります。

このタスクボードは、ガントチャートとセットで使われるWBSと以下の点で違いがあります。
  • 最初から全てを分解する必要がない
    WBSの場合は、作業を分解すること自体が目的でした。それに対してタスクボードは進捗把握が目的です。分解の粒度は進捗を把握するのに必要なだけなので、作業にとりかかる直前でも構わないのです。
  • 順番を意識しなくてよい
    WBSの本来の定義では順番は関係ないのですが、WBSは殆どの場合ガントチャートとセットになるため順番を意識せざるを得ません。タスクボードは残り時間と完了時間の合計値さえ計算出来れば良いので順番は関係ありません。
  • 同時並行作業もタスクとして書ける
    WBSの場合、やはりガントチャートに対応させる関係上、分解したタスク同士は同時並行で作業を進める前提にはできません。タスクボードの場合は残り時間と完了時間の合計値が計算できればいいだけなのでタスクを同時並行して進めても一向に構いません。
ということで、4回にわたってお伝えして参りました「ガントチャートを捨てろ」シリーズですがいかがでしたでしょうか。これをお読みの皆様の中で1人でもお役に立てましたら幸いです。

2013年3月2日土曜日

ガントチャートを捨てろ(3) バーンダウンチャートとバーンアップチャートを併記する

前回(→こちら)はガントチャートを捨てて、代わりに「バーンダウンチャート」を使うことを提案しました。その具体的メリットと、どんなプロジェクトに向いているかもまとめました。

そこで、バーンダウンチャートの弱点としてグラフの傾きが鈍くなった際に「開発が進んでいない」のか、「開発は進んでいるがタスクの総量が増えてタスク残量が減らなくなった」のかの区別がつかないことを挙げ、それは「バーンアップチャート」を併用することにより克服できると書きました。

ではその「バーンアップチャート」とは何なのか、さっそく以下の図をご覧ください。


これが「バーンアップチャート」です。バーンダウンチャートと同じく横軸に時間を取りますが、縦軸はタスクの量として見積時間合計と完了時間合計の2つのグラフを書きます。

上記の例では赤い線が見積時間合計、すなわち期限までにこなすべきタスク全体の合計量を表しています。青い線は完了時間合計、すなわちその時点までに完了したタスクの合計量を表しています。赤い線青い線交わったら完了です。

ちなみに、この赤い線青い線距離は残タスクの合計、すなわちバーンダウンチャートになるのですね。

このバーンアップチャートがバーンダウンチャートと違う点は、タスク総量の変化を表現できることです。タスク総量が変化するのは、例えば急な仕様変更が入った場合や、タスクに要する時間の見積りを間違えていて修正した場合などが考えられます。なお、そういうことがなければ見積時間合計の線は横一直線になります。

例えば上記の例は前回用いたの同じく私が実際に仕事で記録した例ですが、1/19に見積時間合計が増加しています。これは、実際に開発を進めたところ、当初のタスク見積よりもタスクが多かったため、見積時間を多く修正したのです。

そして、純粋な開発速度そのものを表現できるのも強みです。完了時間合計の線の傾きを見れば、タスクをこなすスピード自体がわかります。この傾きが一定であれば、同じペースで仕事をこなせているということです。

さて、ここまでお読みになると「バーンダウンチャートとバーンアップチャートを状況に応じて使い分ければいいのかな」と思われるかもしれません。しかし使い分けるよりも、バーンダウンチャートとバーンアップチャートを併記すると面白くなります。例えば以下の図をご覧ください。



左右の図は別の角度から同じ状況を表現したものです。しかしここから、バーンダウンチャートだけではわからなかった事実を次のように読み取ることができます。

  • バーンダウンチャートを見ると、1/16~1/19にかけて傾きが鈍くなり、開発スピードが落ちているように見える。特に、1/19は全く開発が進んでいないように見える
  • 一方バーンアップチャートを見ると、1/19には完了時間合計はむしろ急に増えており、開発は進んでいないどころか、頑張ってかなり進めたことが分かる。そしてこの日に見積時間合計がこなしたタスクと同じくらい増えていた。これは甘かった見積りの修正であった。
  • つまり途中でつまづいていたわけではなく、この部分で取り掛かっていたタスクの見積りが甘かったことが原因だった、ということが読み取れる。
いかがでしょうか?このようにバーンダウンチャートとバーンアップチャートを併記すれば、後から振り返った場合に、どういう状況だったのか分析しやすくなります。次の開発に向けて反省点を見つけやすくなるのです。

上記で挙げた例は見積りが甘かった例ですが、これがもし仮に仕様変更によるタスク増加だった場合、仕様変更が原因で開発が苦しくなることを明確に説明できるツールになります。なぜなら、バーンダウンチャートの傾きが鈍くなったとき、バーンアップチャートの完了時間合計の傾きが一定で見積時間合計が増えているならば、開発速度は本来落ちていないのに、仕様変更により遅れが発生したことが明確にわかるからです。これは仕様変更に対抗する武器になりえます。

前回と今回にわたってバーンダウンチャートとバーンアップチャートの説明をしたわけですが、これらのグラフを描くには、残タスクの量あるいは完了タスクの量を計測することが必要です。それを計測するためのツール、すなわちバーンダウンチャートとバーンアップチャートを描くためのツールに「タスクボード」があります。タスクボードについての詳細は記事を改めて書こうと思います。(→こちら