アジャイルな見積りと計画づくり　価値あるソフトウェアを育てる概念と技法

• 

  レビューネーム未設定

  しばらくチーム開発から離れていたのでとても為になりました。（PivotalTrackerを導入する前にその方法論を学ばねばと慌てて読みました。）
  
  規模の見積りと期間の見積りを明確に分けるのは目から鱗…。
  
  ただ、受託開発の時にどういった契約書（請求書）出すのかがイメージ出来なかった。他にも参考になりそうな書籍を当たってみたい。続きを読む

  投稿日：2012.03.16

• 

  japapizza

  まえがき
  　まず、アジャイルチームは頻繁に計画づくりをおこなうが、プロジェクト全体の期間に均等に分散させておこなう。次に、アジャイルチームは、アジャイルでないチームが無視しがちな重大な要素に正面から取…り組む。それは、不確実性だ。計画づくりは重要か?もちろん。知識を獲得したり不確実性が軽減したら計画を見直すことは重要か?もちろん。私が見てきた多くの組織では、あまりに早期に無茶なコミットメントをしてそれを結果的に守れないことが許される一方で、不確実性を考慮した現実的な計画を立てると「ルールに則っていない」「チームに馴染まない」とレッテルを貼られてしまう。こうした組織では、ソフトウェアを提供できないことは許容されるが、コミットしないこと(無茶な目標であっても)は論外なのだ。マイクが説明しているアジャイルなアプローチでは、価値を提供することに注力し、壮大だが実現不可能な計画やコミットメントのことは考えない。アジャイル開発者たちの言いたいことは、シンプルにすればこういうことだ。「私たちは、いまここでわかっていることを元に計画を立てます。あなたにとっていちばん大事な目標を達成できるように、私たちは計画を変更します。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させます。私たちからあなたへのお願いは、ビジネスの変化へ柔軟に適応することと、当初の計画を死守することとは矛盾した要求だと、きちんと理解しておいてほしいということです」。「アジャイルな見積りと計画づくり」では、いま述べたことのひとつひとつが取り上げられている。
  　不確実性にうまく対処することの難しさに立ち返って、アジャイル開発プロセスがいかにし て目標の不確実性(本当に作りたいものは何なのか)と方法の不確実性(どうやって作ればいいのか)の両方を軽減させるのかを、マイクは見事に整理してみせた。多くの従来型の計画立案手法は重要なことを見落としている―不確実性を踏まえていないものは計画ではないのだ。計画とは、いまこの時点で私たちが知っていることを元に立てられている。不確実性とは、目標と方法のそれぞれについて私たちがまだわかっていないことを別の言い方であらわしたものだ。ほとんどの不確実性(知識の欠落)は、具体的に何かしてみる―実践したり、開発したり、シミュレーションしたり―ことでフィードバックと知識を得なくては解消できない。多くのプロジェクトマネジメント手法は「計画-計画-計画実行」のように見える。アジャイル手法は「計画実行-適応」「計画実行-適応」の繰り返しだ。プロジェクトの不確実性が多ければ多いほど、成功するためにはアジャイル手法が必要となる。
  
  
  １章　計画の目的
  ■フィーチャ：ユーザーにとってのソフトウェアの価値を表現したものであり、ユーザーに直接価値を提供するもの。性能目標やセキュリティといったいわゆる非機能要件も含まれる。プリンターに赤インクを装填できることは機能であって、フィーチャではない。この場合は「フルカラーで印刷できること」がフィーチャである。オンラインショッピングのサイトに商品選択画面、注文確認画面、支払画面、注文完了画面があった場合、各画面はそれぞれ機能であるがフィーチャではない。ショッピングサイトのフィーチャは「欲しい商品を注文できること」である。ソフトウェアを使う側の視点から記述している、という点が重要である。
  
  ■よい計画づくり
  ・リスクを軽減する
  ・不確実性を減らす
  ・意思決定を支援する
  ・信頼を確立する
  ・情報を伝達する
  
  ■まとめ
  　見積りも計画づくりも極めて重要なのだが、難しく、そして誤りやすい。見積りや計画づくりが難しいからといって避けて通ることは許されない。プロジェクトの初期段階では不正確な見積りしかできないが、プロジェクトが進むにつれてより正確に見積もれるようになる。こうして見積りが徐々に調整されていく様子を示しているのが、不確実性コーンである。
  　計画づくりの目的は、プロダクトの開発においてもっとも重要な質問、すなわち「なにをつくるべきか?」という問いに答えることだ。この質問への回答には、フィーチャ、リソース、スケジュールが盛り込まれる。この回答に説得力を持たせるのが計画づくりである。そのような計画づくりはリスクと不確実性を低減させ、信頼のおける意思決定を導き、信頼関係を確立し、情報を伝達する。
  　よい計画とは、プロダクトとプロジェクトについての意思決定をおこなう根拠として信頼できるものである。アジャイルな計画づくりで大事なのはでき上がった計画よりも、計画を立てるという活動そのものだ。アジャイルな計画づくりは変化を促進する。アジャイルな計画づくりでは、立てた計画を容易に変更できる。アジャイルな計画づくりはプロジェクトのはじめから終わりまで何度も繰り返される。
  
  ２章　なぜ計画づくりに失敗するのか
  ・プロジェクトの３分の２近くは、コスト見積りを大幅に超過する
  ・プロジェクトのフィーチャの64％は、めったに、あるいはまったく利用されない
  ・平均的なプロジェクトは予定スケジュールの２倍以上かかる
  
  ■作業を基準にしたスケジュールが遅れる理由
  ・作業は早く終わらない
  ・スケジュールの遅れは先へと伝わる
  ・作業は独立していない
  
  「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」
  
  ■まとめ
  　2章では、従来型の計画づくりに内在するいくつもの問題を見てきた。数多くのプロジェクトが失敗してしまうのも、まったく不思議ではない。作業を基準にした計画はフィーチャを軽視することにつながるが、フィーチャこそが顧客にとっての価値なのだ。作業を基準にした計画が問題を引き起こしてしまい、スケジュールを守れなくなることも多い。良かれと思って、プロジェクトのメンバーはマルチタスク化によって状況を打開しようとするが、マルチタスク化に潜むコストのせいで、結果的にプロジェクトはさらに遅延することになる。そしてプロジェクトがスケジュールを超過しそうになると、提供予定だったフィーチャが削除される。ところが、フィーチャを開発する順番は開発側の都合だけで決めているので、ユーザーにとって価値の高いフィーチャが削除されてしまうこともある。
  　ユーザーが最終的に何を求めるのかには不確実性があり、はっきりとはわからない。この事実を無視すると、プロジェクトとしては期日を守れたとしても、ユーザーにとって本当に重要なフィーチャを取りこぼしてしまいかねない。というのも、計画を立てた後で明らかになった重要なフィーチャを反映させられないからだ。また、プロダクトを開発する方法にも不確実性があることを無視すると、プロジェクト計画から必要な作業が漏れてしまう。その結果、プロジェ クトが遅れたり、土壇場になってフィーチャを削除することになったり、許容できない品質の低下が起きたりする。
  　多くの組織が見積りとコミットメントを混同している。チームは見積りを出したら、それをコ ミットメントとするよう強いられてしまうのだ。
  
  
  ３章　アジャイル手法
  ■まとめ
  　アジャイルチームはチームとして一丸となって仕事をするが、チームの一人一人には役割がある。プロダクトオーナーとは、プロダクトのビジョンを提供し、チームが開発するフィーチャの優先順位づけに責任を持つ役割である。顧客とは、プロジェクトへ資金を提供したり、完成したソフトウェアを購入する役割のことである。アジャイルプロジェクトには他にも、ユーザー、開発者、マネージャといった役割がある。
  　アジャイルチームは、短くタイムボックス化されたイテレーションで作業する。各イテレーションの終わりには、稼働するプロダクトを提供する。イテレーションで開発するフィーチャはビジネスの観点から選択する。これにより、もっとも重要なフィーチャから順番に開発する。ユーザーストーリーはユーザーの要求を記述する手法で、アジャイルチームでよく使われている。アジャイルチームは、計画が立てたそばから実態と乖離し始めるものだと承知している。これに適応するために、アジャイルチームでは計画を頻繁に見直す。プロジェクトというものは、迅速かつ一定して、新たな機能と知識とを生み出し続ける活動だと考えるべきである。単に定められた手順を実行するだけではないのだ。プロジェクトから生み出される知識には2種類ある。それはプロダクトナレッジとプロジェクトナレッジである。計画を洗練し、組織にとっての価値を最大にするためには、どちらの知識も重要である。アジャイルチームは3つのレベルで計画づくりをする。それは、リリースプランニング、イテレーションプランニング、「今日」のプランニングの3つだ。リリース計画はリリース全体についての計画であり、3ヶ月から6ヶ月という期間がよく使われる。イテレーション計画は1イテレーション分の計画で、2週間から4週間である。「今日」のプランとは、日々のスタンドアップミーティングでメンバーがその日になにをするか決めた1日単位の計画のことである。
  　プロダクトオーナーの満足条件を理解することなしに、リリースプランニングとイテレーションプランニングはできない。リリースプランニングでは、リリースでどうやってすべての満足条件を満たすかをチーム全員で決定する。ここでの満足条件には、スコープ、スケジュール、リソースも含まれる。すべての満足条件を満たすために、プロダクトオーナーは一部の満足条件を緩めなければならないこともある。同様のプロセスをイテレーションプランニングでも繰り返す。イテレーションプランニングでの満足条件は、実現すべきフィーチャと、フィーチャが期待通りに実装されたことを確認する概要レベルのテストとして表現される。
  
  
  ４章　ストーリーポイントによる規模の見積り
  ■まとめ
  　ストーリーポイントは、ユーザーストーリーの相対的な大きさを測る単位である。見積りが10ポイントのユーザーストーリーは、5ポイントのユーザーストーリーの2倍くらい大きいか、複雑か、リスクがあることを示す。同様に、10ポイントのストーリーは20ポイントのストーリーの半分の大きさか、複雑さか、リスクだということだ。ここで重要なのは、ストーリーに割り当てたポイントを比べたときの比率なのだ。
  　ベロシティはチームが1回のイテレーションでどれだけ進めるか、すなわち速度を示す。イテレーションを終えるたびに、チームがそのイテレーションでこなしたストーリーのストーリーポイントを合計して、ベロシティを算出する。
  　ストーリーポイントは、作業の規模だけを見積もったものである。プロジェクトの期間は見積もるのではなく、ストーリーポイントの合計をチームのベロシティで割ることで導出される。
  
  
  ５章　理想日による見積り
  ■まとめ
  　理想時間と現実時間は異なる。アメフトの理想時間は60分(15分のクォーターが4回)である。
  　しかし、理想時間で60分の試合が実際に終了するまでには現実時間で3時間以上かかる。理想時間と現実時間とが異なるのは、試合中には当然のように割り込みが発生するからだ。ユーザーストーリーの開発にかかる時間は、現実日で見積もるよりも理想日で見積もるほうが簡単である。現実日による見積りでは、ストーリーの完了までに起こりうる、あらゆる割り込みを考慮しなくてはならない。理想日による見積りなら、ストーリーに必要な時間だけを検討すればよい。つまり、理想日は規模の見積りなのだ。ただし、ストーリーポイントほどには厳格に規模だけを考慮したものではない。
  　理想日による見積りでは、1つのユーザーストーリーの見積りは1つの値にするのが望ましい。あるユーザーストーリーの見積りを、プログラマの4理想日、テスターの2理想日、プロダクトオーナーの3理想日と表現することは避けるべきだ。それよりも、合計した数字を使って「このストーリーには9理想日かかる」と表現したほうがよい。
  
  
  ６章　見積りの技法
  ■まとめ
  　時間と労力を費やして見積りを出したからといって、必ずしも見積りが正確になるとは限ら ない。見積りに費やすべき労力は、見積りの目的に応じて決めなくてはならない。見積りは実 際の作業担当者がおこなうことが最適だとよく知られている。しかし、アジャイルチームでは 誰が実際に作業を担当するのかが事前にはわからない。よって、見積りはチームの協調的な作 業とするべきだ。 見積りには事前に定義されたスケールを使っておこなうべきだ。近い将来に必要とされる フィーチャは信頼性の高い見積りが必要になるので、非線形のスケールを使って細かい単位 で見積もるべきだ。このときのスケールは、1から始まって10を越えない範囲の非線形の値 にするのがよい。たとえば「1、2、3、5、8」 や 「1、2、4、8」といった数列を採用する。相対 的に大きなフィーチャがあっても、今後の数イテレーションの間には実装しない見込みであ れば、見積りの値は大きいままにしておいてよい。この場合は、たとえば「13、20、40、1001 といったサイズを見積り単位とする。「ゼロ (0)」を含めるチームもいる。
  　見積りを出すための技法には、専門家の意見、対比、分割といった技法がある。これらの技法 を組み合わせた、楽しくて効果的な見積り手法がプランニングポーカーだ。プランニングボー カーでは、参加する見積り担当者に、見積りに使用できるポイントが記入された一揃いのカー ドを配る。フィーチャについて話し合った後、見積り担当者は手元のカードから自分の見積 りをあらわすポイントのカードを選ぶ。見積り担当者のカードは一斉にオープンする。参加者 全員が合意できる見積りポイントに達するまで、見積り担当者間での話し合いと、カードの選 択を繰り返す。
  
  
  ７章　再見積り
  ■まとめ
  　ストーリーポイントや理想日がフィーチャの規模の見積りだと理解していれば、再見積りのタイミングもわかりやすい。再見積りすべき時とは、ストーリーの相対サイズについての考え方が変わったときだ。進捗が想定どおりではないという理由だけで再見積りしてはならない。ペロシティを補正装置として使うことで、見積りの不正確さは解決されていく。
  　イテレーションの終了時点で途中までしか完了できなかったストーリーは、ベロシティの算出に加えないことを私は勧める。私の好みは、ストーリーの全ポイントをベロシティに加える(ストーリーの実装とテストが完了して、プロダクトオーナーが受け入れた場合)か、さもなければ達成ポイントはゼロとみなし、ベロシティに加えないというものだ。とはいえ、部分的に完了させたストーリーのポイントを加えたい場合もある。よくある対処法は、ストーリーのうちでイテレーション中に完了させた部分をポイントとして見積もってペロシティに加算し、残った部分は別のストーリーとして書き直すというものだ。このとき、完了分のストーリーポイントと残作業分のストーリーポイント合計は、元々のストーリーのポイントと一致しなくてよい。
  
  
  ８章　ストーリーポイントと理想日
  ■まとめ
  　見積りをするにあたって、チームはストーリーポイントと理想日のどちらを採用してもよい。それぞれに利点がある。ストーリーポイントにはチームの職能横断的な働きを促進する利点がある。また、ストーリーポイントは純粋な規模の見積りなので、チームが対象とする技術や業務分野に詳しくなっても再見積りの必要がない。多くの場合、理想日よりもストーリーポイントのほうが早く見積もれる。そして、ストーリーポイントは理想日と違って、チームメンバー間で比較できる。理想目による見積りでは、あるメンバーが4理想日と見積もったストーリーを、他のメンバーは1理想日と見積もることもありうる。この2人の見積りはそれぞれに正しいのだが、唯一の見積り値として合意する基準がない。理想日の利点は、チームの部外者に説明しやすいということと、最初に導入するのが簡単ということである。
  　私はストーリーポイントのほうが好みだ。ストーリーポイントで見積もる利点には、採用の根拠になるだけの説得力がある。チームが純粋な規模の見積りに苦労しているなら、私なら、まず理想日による見積りで始めて、そのうちストーリーポイントに切り替えていく。このときの私のやり方は、見積りの際に「このストーリーには何理想日かかるか?」ではなく「このストーリーは、さっき見積もったストーリーに比べてどのくらいの大きさか?」といった質問をすることだ。変化は徐々に起こるので、多くのチームは気づかない。チームが気づく頃には、理想日ではなくストーリーポイントで考えるようになっているのだ。
  
  
  ９章　テーマの優先順位づけ
  ■まとめ
  　すべてのことをやれるだけの時間があることは稀なので、優先順位づけをして、どこから手をつけるのかを決めねばならない。優先順位づけにあたっては、重要なことが4つある。
  1.金銭価値
  2.必要となるコスト(おそらくはサポート等も含む)
  3.得られる知識の量とその意義
  4.低減できるリスク
  　4つの要素を検討する際には、まず価値とコストの面から暫定的な優先順位づけをおこなう。それから他の要素を加味して、それぞれのテーマの優先順位を調整する。
  
  
  10章　金銭価値による優先順位づけ
  ■まとめ
  　テーマを財務的に分析することは優先順位づけに役立つ。ほとんどの組織において最終的な評価とはどれだけの金額を得たり節約したりできるかで決まるためだ。利益と業務改善の効果を予想するのは、2年間先まであれば大抵は十分である。もし必要であれば、もっと先まで予想してもかまわない。テーマから得られる収益をモデル化する場合には、4つに分類するとよい。新しい顧客から得られる利益、既存の顧客が追加で購入したり新たにサービスを利用することで得られる利益、既存の顧客が競合プロダクトに乗り換えなかったことで維持できる利益、業務の効率化による利益だ。今日稼いだり使ったりしたお金には、将来に稼いだり使ったりするよりも高い価値がある。現在の金額と未来の金額を比較するためには、現在の金額を割り引く。現在価値とは、銀行に代表される比較的安全な投資によって、将来のある時点での金額を得るために現在必要となる投資額のことだ。
  　キャッシュフローを評価するのに役立つ指標が4つある。正味現在価値、内部収益率(または投資収益率),回収期間、割引回収期間だ。それぞれのテーマについてこれらの値を算出すれば、テーマ間の比較ができるので、プロダクトオーナーとチームとが協力して賢明な意思決定ができる。
  
  
  11章　「望ましさ」による優先順位づけ
  ■まとめ
  　ここで一歩退いて、なんのために優先順位をつけているのかを思い出そう。9章ではフィーチャ に優先順位づけする際に重要な4つの要素を検討した。
  1.金銭価値
  2. 必要となるコスト(おそらくサポート等も含む)
  3. 得られる知識の量とその意義
  4. 低減できるリスク
  　10章では、フィーチャの優先順位づけにあたっては学習とリスク軽減とを考慮して全体的に評価することの重要性を説明した。 11章では、フィーチャの望ましさに優先順位を付けるための手法を2つ紹介した。狩野モデルと、相対的重み付け手法である。
  　狩野の分析では、フィーチャは3つのカテゴリに分類できる。当たり前のフィーチャ、線形の フィーチャ、魅力的なフィーチャである。見込みユーザーに対してアンケートをとることで、 フィーチャは分類できる。アンケートでは各フィーチャについて2つの質問を用意する。それは 「このフィーチャがあったらどう思うか」と「このフィーチャがなかったらどう思うか」である。 相対的重み付けでは、あるフィーチャについての利点、フィーチャがないことの悪影響、開 発するためのコストの3つをもとに、フィーチャの優先度をあらわす数値を算出する。
  
  
  12章　ユーザーストーリーの分割
  ■まとめ
  　ストーリーが1回のイテレーションに収まらないのであれば、分割すればよい。そもそも1回のイテレーションでは完了できない場合だけでなく、計画しているイテレーションには組み入れる余地がない場合にも、分割を検討する。また、1つの大きなストーリーを見積もるよりも、分割して見積もったほうが正確な見積りになる。より正確な見積りが必要な場合にもストーリーの分割は有効である。ストーリーの分割にはさまざまな手法がある。扱うデータに沿って分割することもできるし、ストーリーを実現するための操作に沿って分割することもできる。いわゆるCRUD(作成、読み出し、更新、削除)に沿った分割するというのはよくおこなわれているし、横断的な機能を個別のストーリーとして括り出すこともできる。横断的な機能とは、セキュリティ、ロギング、エラーハンドリングなどだ。また、最初はパフォーマンス目標を考慮せず、イテレーション内ではストーリーの機能要求を実現させることでストーリーを小さくすることもできる。パフォーマンス目標はそれ自体を個別のストーリーとして、後のイテレーションで実現するのだ。また、ストーリーには複数の要求が含まれていることも多い。これらの優先度が異なる場合には、それぞれを別のストーリーへと分割できる。
  　それから、ストーリーをフィーチャの実装に必要な開発タスクへと分解してはならない。機能を必要なタスクへと分解するのは誰にとっても馴染みのあるやり方なので、ついストーリーもタスクに分解してしまいそうになる。大きなストーリーに、そのストーリーをリリースするのには直接関係ないが関連する変更を追加する誘惑を断つこと。大きなストーリーをさらに大きくしてしまっては意味がない。
  　最後に、複数のユーザーストーリーを1つにまとめたほうが適切な場合もあることに注意。これは、バグ修正のようにひとつひとつはストーリーとしては小さすぎる場合に有効である。
  
  
  13章　リリース計画づくりの基本
  ■まとめ
  　リリース計画は抽象度の高い計画であり、1回のイテレーションよりも長い期間を対象とする。 ほとんどのチームで、リリースは3ヶ月から6ヶ月の周期で繰り返される。ソフトウェアの種類 によっては、リリース周期がもっと長くなることもあれば、短くなることもある。状況が極め て単純であれば、リリースプランニングも簡単だ。想定されるベロシティを予定しているイテ レーションの数と掛けて、その結果を越えない範囲でユーザーストーリーを選択すればよい。
  　リリースプランニングの段階では、個々のイテレーションで何をするかまで詳細に決める必要 はない。実際、そこまでの詳細が必要になることはめったにない。ほとんどのプロジェクトで は、最初の数イテレーションにストーリーを割り振っておけば十分である。残ったストーリー のイテレーションへの割り振りは、イテレーション計画を立てる際におこなえばよい。 リリースプランニングは繰り返し実施される、イテレーティブなプロセスである。まずはプロダ クトオーナーの満足条件を求める。この条件には通常、目標とするスケジュール、スコープ、リソースが含まれている。立てた計画がプロダクトオーナーの満足条件を満たせなかった場合は、計画が条件を満たせるようになるまで、繰り返しながら条件の基準を調整する。たとえばフィーチャを削らないのであればリリースを少し遅らせるとか、チームの人数を増やしてみる、といったようにだ。
  　立てたリリース計画を壁に飾ったままにしてはならない。各イテレーションの開始時点で計画 を見直して、必要に応じて更新すること。
  
  
  14章　イテレーション計画づくり
  ■まとめ
  　リリース計画とは異なり、イテレーション計画は1回のイテレーションでの具体的な作業を扱う。リリース計画が3ヶ月から6ヶ月の期間を対象とするのに対し、イテレーション計画は1回のイテレーションだけを対象とする。リリース計画で扱う比較的大きなユーザーストーリーを、イテレーション計画ではタスクに分解する。ストーリーを分解したタスクは完了までにかかる理想時間を単位として見積もる。
  　イテレーションプランニングの進め方は大きく分けて2つある。ベロシティ駆動とコミットメント駆動だ。どちらのやり方も手順の多くは共通しているので、できあがったイテレーション計画が似たようなものになることもよくある。
  
  
  15章　イテレーションの長さを決める
  ■まとめ
  　ほとんどのアジャイルチームでは2週間から4週間のイテレーションを採用している。いつでもどこでも、どんなチームにも適用できるイテレーションの長さというものは存在しない。イテレーションの長さは、それぞれのチームが自分たちの状況を踏まえて、自分たちに最適な長さを選ばねばならない。そのために考慮すべき要素は以下の通りである。
  ・リリースまでの期間
  ・不確定要素の高さ
  ・フィードバックの得やすさ
  ・優先順位が安定している期間
  ・外部からのフィードバックの必要性
  ・イテレーションのオーバーヘッド
  ・切迫感を感じ始めるまでの時間
  
  
  16章　ベロシティの見積り
  ■まとめ
  　ベロシティを見積もるには3つ方法がある。1つ目は、過去の実績値があれば、それを平均して使うというもの。ただし、この方法を使うにあたっては、チームやプロジェクトの性質、採用している技術などに大きな変化がないことを確認しなければならない。2つ目は、実際にイテレーションを実施するというものだ。これが最善の選択肢である。3つ目は、ベロシティを予想するというものだ。予想するためには、代表的なストーリーをいくつか選んでタスクに分解し、イテレーションの作業可能時間内に収まるかを調べる。この方法はイテレーションプランニングによく似ている。いずれの方法を採用するにせよ、ベロシティの見積りには幅を持たせる。見積り幅には見積りの不確実性を反映させること。見積りに持たせる幅をどれぐらいにするかを決めるには、不確実性コーンが役に立つ。
  
  
  17章　不確実性に備えるバッファの計画
  ■まとめ
  　プロジェクトというものは非常にたくさんの不確実性を抱えている。しかし、この不確実性をきちんと反映したスケジュールが作成されることは稀である。不確実性が大きすぎる場合や、問題が起きた場合の影響が深刻な場合には、プロジェクト期間を見積もるのに工夫が必要になる。実際の開始よりもかなり前の時点でプロジェクト計画を立てねばならない場合や、スコープがまま固定で厳格な納期が設定されている場合、プロジェクトをアウトソースする場合、要求がごく表面的にしかわかっていない場合、納期を守れなかったときの(財務上、あるいはその他の影響が甚大である場合などがそうだ。
  　バッファの持たせ方でよく使われる方法は、フィーチャバッファとスケジュールバッファの2つである。フィーチャバッファは、プロダクトに対する要求が優先順位づけされていて、そのすべてが必ず提供されるわけではないと合意できている場合に用意するバッファである。たとえば、アジャイルプロセスの1つであるDSDMでは、提供されるフィーチャの30%はオプションと見なすことを提案している。この30%がプロジェクトのフィーチャパッファである。時間が足りなくなったときには、フィーチャパッファにあるフィーチャを削ることでスケジュールを守るのだ。
  　いっぽうスケジュールバッファは、スケジュールに適用するバッファである。スケジュールパッファはユーザーストーリーそれぞれの50%見積りと90%見積りから導き出される。各ユーザーストーリーについて50%見積りと90%見積りの差の平方を求め、その値の合計の平方根を算出することで、適切なスケジュールバッファを見積もれる。
  　プロジェクトを機能面での不確実性から守るにはフィーチャバッファを用意し、スケジュール面での不確実性から守るにはスケジュールバッファを用意することだ。フィーチャバッファとスケジュールバッファを組み合わせて使うこともできる。むしろ、バッファは組み合わせるほうが望ましい。そのほうが、それぞれのバッファを小さくできるからだ。
  
  
  18章　複数チーム編成プロジェクトの計画づくり
  ■まとめ
  　アジャイルプロジェクトは、大規模なプロジェクトに対しては、1つのチームを大きくするのではなく、複数の少人数チームを編成することが多い。1つのプロジェクトに複数のチームが関わっていると、互いの作業を連携させる必要が出てくる。この章では1つのプロジェクトに複数のチームが関わっている場合に役立つ4つのテクニックを紹介した。
  　1つ目は、チーム間で共有できる見積り基準の確立だ。そのためにはまず、すべてのチームが同じ見積り單位を採用すること。見積り単位はストーリーポイントか理想日のどちらかだ。それから、見積り基準についての認識を合わせるために、いくつかのストーリーを見積もって、その結果に合意できるようにしておくこと。
  　2つ目は、複数のチームが同じプロジェクトで作業する場合には、ユーザーストーリーは早い段用で詳細化しておくことだ。これについては、ストーリーに対するプロダクトオーナーの満足条件を明確にするのが最も効果的だ。プロダクトオーナーの満足条件を把握できれば、ストーリーがきちんと期待通りに実装できていることを、実際に動かして確認できる。
  　3つ目は複数チームによるプロジェクトでは、リリース計画に「移動する先読み範囲」を取り入れると効果的だ。計画における「移動する先読み範囲」とは、今後予定されているイテレーションのいくつか(通常2つか3つ)までの先を見越して計画を立てるということだ。これがあると、近いうちに各チーム間でどういった連携が必要になるかを、情報交換しながら調整できる。
  　最後となる4つ目は、チーム間の依存関係が多くて非常に複雑なプロジェクトでは、合流パッファを計画に組み入れると役に立つというものだ。合流バッファは、あるチームの作業の遅れが他のチームの作業開始に影響が及ばないように、プロジェクトに用意する時間的な余裕である。
  以上の4つのテクニックは、一般的には紹介した額にプロジェクトに導入するのがよいが、必ずしも順番通りである必要はない。
  
  
  19章　リリース計画のモニタリング
  ■まとめ
  　ベロシティはチームが1回のイテレーションで完了させた仕事量を測定したものだ。ベロシティの算出は、オール・オア・ナッシングだ。すなわち、イテレーション終了時点でストーリーが完了していれば、見積りポイント分すべてをベロシティに加算する。ストーリーに一部でも完了していないところがあれば、その見積りの数字は一切ベロシティに加算してはならない。
  　リリースバーンダウンチャートは、各イテレーションの開始時点で、プロジェクト全体としてストーリーポイント(または理想日)がどれだけ残っているのかを把握するためのものだ。チームの残作業のバーンダウンが終始一貫して安定していることはない。見積りは不正確だったり、途中で変わることがあるし、そもそもリリースのスコープ自体が変化するからだ。イテレーションの途中でバーンダウンチャートがパーンアップすることもある。ある程度は作業を完了させていたとしても、未着手のストーリーのなかに過小見積りのストーリーがあることに気づくかもしれない。また、プロジェクトのスコープが広がった場合もプロジェクトはバーンアップする。リリースバーンダウンチャートを解釈するうえでのポイントは、チームの総合的な進み具合(正味進捗)が表現されているということだ。正味進捗とは、実際に完了させた作業量から、リリースに向けて増加した作業量を引いたものである。
  　リリースバーンダウンチャートには、スタンダードな折れ線グラフ販の他にも、(場合によっては)より便利な棒グラフ版が存在する。棒グラフ版では、チームの選抜と、リリースに向けたスコープの変動とを別々に表現できるのが特徴だ。棒グラフ版では、縦棒の下端を伸び縮みさせることで、スコープの増減をあらわす。こうすることで、棒グラフ販のバーンダウンチャートは折れ線グラフ版よりも表現力を増すが、使うにあたっては注意が必要になる。組織によっては、スコープの変動を縦棒の上端(チームの進捗)に反映すべきか、それとも下端(スコープの増減)に反映すべきかで揉めることがあるからだ。
  　パーキングロットチャートも、プロジェクト全体に対するチームの状況を概観するのに役立つ。このチャートでは1枚の紙で、実装予定のテーマ単位ごとに進持状況を表現できる。
  
  
  20章　イテレーション計画のモニタリング
  ■まとめ
  　タスクボードは、チームの作業を整理し、可視化する。タスクボードにはホワイトボードやコルクボードを使うことが多いが、壁の片隅でも構わない。タスクボードの列にはそれぞれラベルをつけておき、作業の進行に応じて、対応するタスクカードないしはタスクかんばんをチームメンバー自身が順番に右側の列へと動かしてく。
  　イテレーションバーンダウンチャートはリリースバーンダウンチャートとよく似ているが、現在のイテレーションの作業をトラッキングするのに使う点が異なる。イテレーションバーンダウンチャートは、縦軸に残作業の合計時間を、横軸にイテレーションの何日目かを取る折れ線グラフである。
  　タスクの所要時間の見積りと実績との比較はしないほうがよい。大抵の場合、予実を追跡することによるリスクと手間が利点を上回ってしまうからだ。
  　個人単位でベロシティを測定したりトラッキングしてはならない。
  
  
  21章　計画とコミュニケーション
  ■まとめ
  　見積りと計画にまつわるコミュニケーションは、正直で頻繁な、双方向のコミュニケーションでありたい。実は、ガントチャートは計画を伝えるのに役立つツールである。しかし、フィーチャより細かく分解したタスクレベルには使うべきではないし、ガントチャート上でフィーチャを割り当てる期間の長さは実装予定のイテレーション全体の期間にすべきだ。
  　バーンダウンチャートは最も重要な進捗報告ツールだが、バーンダウンチャート以外にも、過去のイテレーションのベロシティをまとめたグラフを用意することが多い。今後のチームのべロシティを予測する場合は、ベロシティを1つの値であらわすのではなく、幅を持たせたほうがよい。そのためにはベロシティを3つ用意するとよい。すなわち、直近のイテレーション、過去8イテレーションの平均、過去8イテレーションのワースト3の平均、の3つだ。これらの値は、それぞれに対応する状況をあらわしている。つまり、最近の状況、「長期的」平均、起こりうる最悪の事態の3つである。
  　プロジェクトによっては「イテレーション終了報告書」があると便利だ。イテレーション終了報告書があれば、最新情報を報告できる。また、後から過去のイテレーションの記録として参照するために保存しておくこともできる。
  
  
  22章　なぜアジャイルな計画づくりがうまくいくのか
  ■アジャイルな見積りと計画づくりのための12のガイドライン
  1.チーム全体を巻き込む
  2.複数レベルの計画を立てる
  3.大きさの見積りと期間の見積りを区別するために別々の見積り単位を使う
  4.不確実性はフィーチャか日付のいずれかで表現する
  5.頻繁に計画を見直す
  6.進捗をトラッキングして情報を共有する
  7.学習することの大切さを受け入れる
  8.フィーチャは適切な大きさで計画する
  9.フィーチャを優先順位づけする
  10.現実に即した見積りと計画を立てる
  11.ゆとりを残す
  12.複数チームの連携には「移動する先読み範囲」を使う
  
  
  訳者あとがき
  　スコープとスケジュールのいずれか(できれば両方)を調整可能にしてはじめて、ほんとうにアジャイルな開発――価値のあるソフトウェアを育て、リリースし続ける開発は実現できるのです。では「見積りと計画づくりをアジャイルに」しさえすれば、プロジェクトはアジャイルになるのでしょうか?残念ながらその答えは「いいえ」です。このことはすでに、空前のアジャイルブームを迎えた北米では(図らずも)実証されているようです。ジェームズ・ショアは「アジャイルの衰退と凋落」と題した記事で、ビジネスの要請だけにもとづいて短いイテレーションと頻繁な計画づくりを導入しても、プロジェクトを疲弊させてしまうだけだと警鐘を鳴らしています。
  　重要なのは、技術とビジネスの調和です。開発者には自分たちで見積りを出す権利があります。しかし同時に、見積りの説明責任を果たすために、誠実で透明性のある進捗を報告する義務があります。顧客やプロダクトオーナーには要求を出す権利がありますが、要求がリリースやイテレーションに収まらない場合には優先順位の決断を下す義務もあります。続きを読む

  投稿日：2024.02.03

すべてのレビューを見る