# イテレーション計画づくり ## 定義 ### イテレーション計画づくりとは イテレーション計画づくり(イテレーションプランニング)は、目前のイテレーション1回分(2〜4週間)を対象に、そのイテレーションで実装するタスクを定める活動である。参加者はプロダクトオーナー、アナリスト、プログラマ、テスト担当者、データベースエンジニアなどプロダクトに関わる全員であり、成果物はタスクをまとめた集計表(表14.1)またはカードの束(図14.1)でよい。リリース計画がユーザーストーリーをストーリーポイントまたは理想日で見積もるのに対し、イテレーション計画はユーザーストーリーをタスクに分解し、タスクを理想時間で見積もる(表14.2)。タスクを理想時間で見積もれるのは、イテレーションプランニングでは確実に理解したと言えるまで議論を重ねるため、見積りの粒度を細かくしても信頼できるからである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §2) イテレーションプランニングではタスクに担当者を割り当てない。担当者がタスクに「サインアップ」する(自分で担当タスクを選びカードに名前を書き入れる)のはイテレーションが始まってからであり、一度に1つ、多くて関連する2つまでである。事前にすべてのタスクへ担当者を決めてしまうと、「全員が一丸となって取り組む」という参加意欲を損なう。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §1) ### 進め方: ベロシティ駆動とコミットメント駆動 イテレーションプランニングの進め方は「ベロシティ駆動」と「コミットメント駆動」の2つに大別される。どちらもうまくいく手法であり、自由に取り混ぜることもできる。 **ベロシティ駆動**は、(1)優先順位を調整する、(2)目標ベロシティを決める、(3)イテレーションのゴールを決める、(4)ユーザーストーリーを選ぶ、(5)ストーリーをタスクに分解する、(6)タスクを見積もる、という手順を踏む。目標ベロシティに達するまでストーリーをまとめて選んでから、まとめてタスクに分解する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §3) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch14-fig14.2-velocity-driven-steps.png]] (図14.2 ベロシティ駆動のイテレーションプランニングの手順。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §3) **コミットメント駆動**は、最初の2手順(優先順位の調整、ゴールの決定)はベロシティ駆動と同じだが、そのあとはストーリーを1つずつ選んでタスクに分解・見積もりをおこない、そのつど「チームにコミットできるか」を尋ねる。確約できればさらにストーリーを追加し、確約できなくなったらストーリーを減らして完了する。著者はこちらを好むと明言している。理由は、ベロシティ(ストーリーポイントや理想日)が粒度の粗い見積りであり短期間のイテレーション内の個別作業の見積りにそのまま使えるほど正確ではないこと、また見積り誤差をならすには1イテレーションで20〜30ものストーリーをこなす必要があるが実際には3〜10程度しか選べずならされにくいことの2点である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §4, §5) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch14-fig14.3-commitment-driven-steps.png]] (図14.3 コミットメント駆動のイテレーションプランニングの手順。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §4) チームに投げかける質問は「いま話し合ったこのフィーチャをリリースできると確約しますか?」であって、「洗い出したタスクの完了を確約しますか?」ではない。前者はフィーチャの提供そのものを確約させ、イテレーション中に新しいタスクが見つかっても最後までやり遂げようとする動機になるが、後者のコミットメントは弱い。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §4-1) ### ストーリーからタスクへの分解 ユーザーストーリーは、プロダクトに統合して動作させるために必要なすべてのタスク(分析・設計・コーディング・テスト・ドキュメントなど)に分解する。イテレーション計画に含めるタスクは現在のプロジェクトに直接価値を与えるものだけに限り、メールの返信や無関係な打ち合わせは含めない。ストーリーの実装順序が見積り時に想定した「自然な順序」と異なる場合は、それに伴って必要になる追加タスクを計画に加える。タスクへの分解がとりわけ難しいフィーチャは、影響範囲を調べる「スパイク」(知見を得たり疑問を解消することを目的とするタスク)と、大雑把な見積りのプレースホルダー的なタスクの2つに分けるとよい。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §3-5, §3-5-1, §3-5-5, §3-5-6) ### タスクの見積り(理想時間) タスクの見積り単位は理想時間であり、担当者個人ではなくグループで見積もる。理由は4つ。(1)イテレーションプランニングの段階ではタスクに担当者を割り当てないため個人による見積りがそもそも不可能、(2)他のメンバーの見積りへの貢献(過去の実績を踏まえた指摘など)には価値がある、(3)見積りが予想外に大きければ詳細化しすぎに気づける、(4)協調作業の結果である見積りは誤りを認めやすい。タスクの適切なサイズは、開発者が平均して1営業日に1つ完了できる程度である。これより大きいと1〜2人の開発者に負荷が集中し、他のメンバーは待ちになりがちである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §3-6, §3-8) ### チームがコミットできる作業量の判断 コミットメント駆動でチームがコミットできるかを判断する目安は、タスク見積りの合計を1日あたりに換算した量である。7人編成・イテレーション長2週間のチームの持ち時間は合計560時間(7人×10日×8時間)になるが、タスクカードに現れない作業(メール対応やミーティングなど)や見積り誤差があるため、560時間丸ごとをサインアップできることは期待できない。多くのチームで一番うまくいくのは、計画した作業(タスクカードの合計)が1日あたり4〜6時間になっているときであり、この例では2週間のイテレーションで280〜420時間の作業を計画するのがよい。この作業量に、他システムのサポートや保守など事前に予測できないが不可避な作業負荷も考慮する必要がある。著者はイテレーションを空のグラスにたとえ、まず変えられないコミットメント(サポート・保守)が注がれ、残りの空きにイテレーションの作業を注げると説明する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §4-1-1, §4-1-2) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch14-fig14.4-commitment-capacity.png]] (図14.4 イテレーションでコミットできる作業量は、他のコミットメントの量による。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] §4-1-2) ## 横断的知見 - 14章はイテレーション計画づくりの手順(ベロシティ駆動/コミットメント駆動)を扱う一方、イテレーションの長さそのものをどう決めるかには立ち入らない。[[イテレーションの長さ]]で扱う15章の7要因のうち「優先順位が安定している期間」(§1-4)は、14章のコミットメント駆動が前提とする「イテレーション中にプロダクトオーナーが優先順位を変えない」という制約(§1、§4-1)の裏付けになっている。15章は、優先順位を安定させたいならイテレーションを短くしすぎず、かつ大抵の組織では2週間程度なら優先順位を固定できると具体的な長さの目安まで踏み込んでおり、14章が前提とするだけの制約に、どの長さなら現実に守れるかという回答を与えている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]]) - 14章のコミットメント駆動でチームが確約できる作業量は「1日あたり4〜6時間」という経験則(§4-1-1)で決まり、この換算は2週間のイテレーションを暗黙の前提に置いている(7人×10日×8時間=560時間からの逆算)。15章§2が2週間を著者の推奨する長さとして独立に導いていることと突き合わせると、14章の経験則が特定の長さに依存した数値であり、イテレーションが4週間や1週間なら同じ「1日あたり4〜6時間」がそのまま妥当するとは限らないことが見えてくる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]]) - リリース計画([[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]])では期待ベロシティを使ってリリースに含められるストーリーポイントの合計や必要イテレーション数を算出し、ベロシティは有効な指標として扱われる。ところがイテレーション計画([[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]])では、著者はベロシティ駆動よりもコミットメント駆動を好み、その理由としてベロシティの粒度の粗さと、1イテレーションあたりのストーリー数の少なさ(3〜10程度)ゆえに見積り誤差がならされにくいことを挙げる。2つの章を並べると、同じベロシティという指標でも、リリースという長い時間軸(3〜6ヶ月、多数のストーリー)では誤差が平均化されて有効に機能する一方、イテレーションという短い時間軸(2〜4週間、少数のストーリー)では個別作業の見積りに使うには粗すぎるという、「時間軸の長さによって指標の有効性が変わる」構造が見えてくる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]]) - リリース計画の標準手順(図13.1、6ステップ)とイテレーション計画の手順(図14.2・図14.3)を比較すると、両者とも「優先順位づけ→対象の選択→見積り」という骨格を共有しつつ、計画対象の水平線が狭まるにつれて確認の粒度が細かくなっていく。リリース計画は「ストーリーを選択し、リリース日を決める」で完結するのに対し、イテレーション計画のコミットメント駆動はストーリーを1つ追加するたびに「チームにコミットできるか」を繰り返し確認するループを持つ。荒削りな計画から詳細な計画へ段階を追うほど、チームへの確認頻度も上がるという設計だといえる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]]) - 14章はイテレーション計画づくりの手順(タスクへの分解、理想時間での見積り)を扱うが、分解したタスクをイテレーション中どう追跡するかには立ち入らない。20章は、14章が定めたタスクの粒度(§3-6、開発者が平均1営業日で1つ完了できる程度)を[[タスクボード]]という具体的な運用に落とし込み、各タスクカードの残り見積り時間を毎朝集計することで、14章のタスク分解を「日次で追跡可能な単位」として機能させている。すなわち14章が定めるタスク粒度の基準は、20章の日次集計運用と組み合わさって初めてイテレーション全体の進捗の可視化に結びつく。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]]) - 14章のコミットメント駆動は、チームが確約できる作業量を「1日あたり4〜6時間」という経験則(§4-1-1)で見積もり、コミットの是非をイテレーション計画づくりの時点で1回だけ判断する。20章はこの確約後、イテレーション進行中に投入済みの実績時間を見積りと比較する運用には否定的な立場を取り、比較が見積り担当者に「評価への不安」を招き、直感的で不正確な見積りに陥らせると警告する(§3)。両章を並べると、14章のコミットメントは「事前に引き受けられる量を判断する道具」であって「事後に見積り精度を検証し責任を問う道具」ではなく、20章はこの2つの用途を混同することに明確に反対していることがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]]) ## 未解決の問い - ベロシティ駆動とコミットメント駆動は「自由に取り混ぜられる」とされるが、どちらを主軸に据えるべきかの判断基準(チームの習熟度、保守業務の有無など)は本章では明示されていない。 - イテレーションの長さ(2週間か4週間かなど)をどう決めるかは、[[イテレーションの長さ]](15章)を参照。7つの決定要因が互いに矛盾する場合の優先順位づけ基準は15章でも明示されておらず、未解決のまま残る。 - 保守・サポート業務の負荷が大きく変動するチームで、コミットメント駆動の「確約」の信頼性をどう担保するか(図14.4が示す空きの見積り自体の不確実性)は、本章の範囲では十分に論じられていない。 - 20章のイテレーションバーンダウンチャート([[バーンダウンチャート]]参照)は「イテレーション長が2週間より長い場合に非常に便利」と留保しており、15章が推奨する2週間のイテレーションでは効果が薄い可能性がある。14章のコミットメント駆動が前提とする標準的なイテレーション長(2週間、§4-1-1)と、20章が有用と見なすイテレーション長(2週間超)がずれていることをどう解釈すべきかは、原本に明示的な答えがない。 ## 関連 - 概念: [[リリース計画づくり]] / [[アジャイルな計画づくり]] / [[イテレーションの長さ]] / [[タスクボード]] / [[バーンダウンチャート]] - 実体: [[SwimStats]] - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 14章・15章・20章。