第8回チームの開発速度を計測してリリース・プランニングに役立てる

2006.04.28

　引き続きアジャイル型開発の進め方をTRICHORDの開発を例にとって解説する。前回はストーリを効率よく見積もる方法について紹介した。ストーリを見積もった後は，リリース・プランニングを実施することになる。リリース・プランニングは，リリースまでに実現しなければならないストーリを，リリースまでのタイム・ボックス，つまり各イテレーションに，優先度や依存関係を考慮して割り当てていく作業だ。

　リリース・プランニングの進め方は，以下のようなイメージでとらえると分かりやすい（図1[拡大表示]）。

(1)各イテレーションのサイズを表す箱を用意する
(2)ストーリ・サイズを表現したブロックをストーリぶん用意する
(3)優先度順にブロックを箱に入れていく
(4)箱に収まらなくなった場合は次の箱に移すか，箱に入るようにブロックの大きさを調整する。

図1 リソース・プランニングの進め方
様々なサイズのストーリを，優先度や依存関係を考慮してタイム・ボックスに収めていく。タイム・ボックスに収まらない場合には，次のボックスに入れるか，ストーリを分割する。
[画像のクリックで拡大表示]

　イテレーションはタイム・ボックス，つまり箱なので，入るものは限られている。箱に入り切らない場合は当然，別の箱に入れるか，極端に言うと捨ててしまうことになる。前回も指摘したが，「全部やらないといけない」ではなく「ここまでは含める」という線を明確にするのだ。

　開発を開始した時点では，1つのタイム・ボックスの中にどのサイズのストーリが収まるかは分からない。そのため，最初は「とりあえず」タイム・ボックスにストーリを割り当てておく。

　ここで注意したいのは，最初の数イテレーションは「まずやってみる」ことを目的としてイテレーションを実施することだ。チームが1つのタイム・ボックスで消化できるストーリのサイズをチームの「ベロシティ」（velocity：速度）と呼ぶ。最初の数イテレーションは，チームのベロシティを測定して，チームの開発速度がどのくらいなのか，つまり1イテレーションでどのくらいのサイズのストーリをこなすことができるか，をまず見極める必要があるのだ。

　最初の数イテレーションで得られたベロシティの計測値は，以降のリリース・プランニングの基準値となる。つまり，リリース・プランニングを終えたら一直線にゴールまで突き進むのではなく，ベロシティの目安が出た時点で，最初のリリース・プランを見直すという意味だ。ここであえて「プランニング」という用語を用いているのは，「計画は常に見直す必要がある」という意味を込めているからだ。ベロシティは，チームのドメインに対する知識，利用している技術，開発スタイルについての習熟曲線が上るにつれて高まっていく。

　ベロシティは平均値ではなく，範囲（下限と上限）として扱うのがポイントだ。例えば最初の3回のイテレーションにおけるチームのベロシティが5，7，6だった場合，「ベロシティ：6」ではなく，「ベロシティ：5～7」とする。こうしておくと，10イテレーションぶんのリリース・プランニングの際に，合計60ポイントのストーリは平均サイズではあるが，全イテレーションをベロシティ：5で進んだ場合には終わらない可能性があることが分かる。つまり，「順調に行けば無事終わるが，最悪の場合10ポイントぶん終わらないかもしれない」というリスクが顕在化するのである。この時点で，最後の10ポイントぶんは最悪落ちても問題がないストーリ，言い換えれば「あったらうれしい」「無くても困らない」ストーリを選択することになる。

　TRICHORDチームのリリース・プランニングの例で言うと，3回ほどイテレーションを実施してベロシティを測定した後に，4月3日のリリースに含めたいすべてのストーリが出そろった。この時点でリリース・プランニングを実施して各ストーリのサイズを見積もると，今までのチーム・ベロシティでは2カ月先のリリース日に全く間に合わないことが判明した。2カ月前にたった数時間のセッションで，確実に「終わらない」ことが分かったのだ。この後，各ストーリの優先度を基に，2カ月で収まる範囲にストーリを選択・分割し，最低限の機能まで絞り込んで実装したのが4月3日にリリースしたTRICHORDである。

　要求が変化したために，新しいストーリの追加や既存のストーリの削除が発生することもある。これに対処するには，イテレーション終了後にストーリの変更を反映し，新規ストーリについてはまた優先度を付けてサイズを見積もる必要がある。そのうえで，チームのベロシティを基準にして，リリース・プランを見直していくことになる。

　コンセプト・アウト/デマンド・イン型のソフトウエア開発では，こうした細かい軌道修正に基づく素早い対応が不可欠だ。筆者はストーリをベースにしたリリース・プランニングが，細かい軌道修正をするのに大変有用なことを実感している。

　開発が当初の計画よりも進んでいる場合は，イテレーションの終了を待たずに予定しているストーリの作業が完了してしまう。このような場合はあまった時間で追加のストーリの作業を実施する。TRICHORDチームではこれを「おかわり」と呼んでいる。

　「おかわり」するストーリには2種類ある。1つは，次のイテレーションで予定していたストーリの作業を前倒しで進めるというものだ。このケースは，イテレーションの残り時間が追加するぶんのストーリを含めることができるサイズだった場合に限る。残り時間で収まりきらないサイズのストーリを選択してはいけない。

　もう1つは課題項目をストーリ化して，課題をつぶしていくというものだ。プロジェクト進行中には様々な課題が顕在化する。顕在化するたびに対応してしまうと，モグラ叩きのようになってしまう。さらに言うと，リリース・プランニングしたストーリ以外の作業が発生するため，チームのベロシティが正確に計測できなくなる。チームがどの位の速度で進んでいるかがわからなくなってしまうと精度の高いプランニングは実施できなくなる。そのため課題に対応する場合には，課題をストーリにしたうえでプランニングすることになる。課題をストーリにするコツは，前回の連載を参照していただきたい。