ホソカワです。
第１５章のアップデートです。「Release Planning と Iteration Planning の違い」
と「Planning in a Week」を追加しました。
----
Chapter 15 Planning Strategy
============================
The Planning Game (Release Planning Game)
-----------------------------------------
XP では、開発計画をゲームとして扱っています。このゲームを「Planning Game」と
言っています。
プラニングゲームのゴールは、開発するソフトウェアの価値を最大にすることです。
戦略は、最少の投資、最短の期間で、最大限の価値を生むことです。ビジネスは、出
来上がったシステムから学習したことをベースに次のシステムへの要求を決め、開発
はすぐにそれを実装します。この繰り返しです。ゲームのコマは、ストーリーカード
で、選手はビジネスと開発です。ゲームには、３つのフェースがあり、それらは、探
検（Exploration）、約束（Commitment）、運営（Steer） と言います。これらのフェー
スは循環するので、運営フェーズの後に探検フェーズに戻ることもあります。
<探検フェーズ>
このフェーズでは、選手たち（ビジネスと開発）にシステムの最終型を認識させます。
３つの進め方があります。
・ストーリーの記述 - ビジネスはシステムの仕様を説明しているストーリーを書き
ます。
・ストーリーを見積もる - 開発は story の見積もりを出します。この見積もりは、
「理想の作業時間（Ideal Engineering Time）」で表され、中断や会議なしで、実装
にかかる期間のことを言います。
・ストーリーの分割 - 開発がストーリーの見積もりをできない時やビジネスがストー
リーの一部分が重要とわかった時は、ストーリーを分割します。
<約束フェーズ>
このフェーズでは、ビジネスがスコープと納期を決定し、開発がその条件下の開発を
引き受けます。ここでは、４つの進め方があります。
・価値で整列 - ビジネスはストーリーを「必須機能」、「あればビジネスに貢献で
きる機能」と「あればうれしい機能（Nice To Have）」に分けます。
・リスクで整列 - 開発は story を「正確に見積もられている機能」、「まあまあの
見積もりの機能」と「見積もりができない機能」に分けます。
・速度の設定 - 開発はプログラミング速度（velocity）を宣言します。
プログラミング速度＝理想的な作業時間／月
（velocity = Ideal Engineering Time / calendar month）
・スコープの選択 - ビジネスはこのリリースのためにどのストーリーを実装するか
決定します。
<運営フェーズ>
このフェーズでは、プランのアップデートを行います。４つの進め方があります。
・ひとサイクル（Iteration） - ビジネスは、ひとサイクルごとに、もっとも重要な
ストーリーを決定します。
・修復 - 開発が速度を過大に評価したと発見した時、ビジネスに対して、今回のリ
リースで重要なストーリーを新しい速度と見積もりで再度選択してもら
います。
・新しいストーリー - ビジネスが新しいストーリーを発見した時、そのストーリー
を作成し、開発は、見積もりを行います。重要度によっては、新しいストーリーを入
れ、重要度の低いストーリーを外します。
・見積もり直し - 開発は、見積もりを再度行い、プログラミング速度を再設定する
こともできます。
Iteration Planning
------------------
今度は、Iteration Planning Game です。Planning Game に似ていますが、
Iteration Planning Game のプレイヤーは、プログラマー、コマは、タスクカードで
す。また、期間も短く、１から4週間です。似たような、フェーズと進め方で構成さ
れています。
<探検フェーズ>
・タスクの記述 - ストーリーを実装するために必要なタスクを書きます。
・タスクの分割/タスクの結合 - 大きいタスクが分割して、短いタスクは統合しま
す。
<約束フェース>
・タスクの受け入れ - Practice にもありますが、タスクを買って出ます。
・タスクの見積もり - タスクを見積もります。
・作業負担（load factor）の設定 - 作業負担を決定します。
作業負担＝理想の作業時間／時間
（load factor = ideal engineering time / calendar time）
・均等化 - あるプログラマの持ち分が大きすぎる時は、他のプログラマにタスク
を分けます。
<運営フェース>
・タスクの実装 - タスクを実装します。
・進捗の記録 - 進捗状況を記録します。
・修復 - あるプログラマが手一杯になった時は、例えば、タスクのスコープを
縮小したり、顧客にストーリーのスコープを縮小してもらいます。
・ストーリーの実証 - タスクをすべて作成した時、ストーリーが完成したかチェッ
クします。
Release Planning と Iteration Planning の違い
---------------------------------------------
・Iteration Planning のスケジュール変更のほうが Release Planning のスケジュー
ルの変更より耐えられます。開発メンバー全員で主要な refactoring に時間をさく
ことができますが、顧客にそんな状況を頻繁に見せられるものではありません。嘘を
ついているように感じるかもしれませんが、これは「ビジネスとテクニカルの判断の
分割」practice の延長です。
・Release Planning では、ビジネスからストーリーが与えられ、チーム全体でストー
リーの責任を持ちますが、Iteration Planning では、プログラマーが自らタスクを
選択し、個人で責任を持ちます。
・Iteration Planning のタスクの中には、ストーリーと直接関係しない場合もあり
ます。例えば、ツールの強化などが考えられます。
Planning in a Week
------------------
一週間で計画を立てなくてはならない時は、プラニングゲームを行っている余裕など
ありません。この場合は、リスクをある程度背負って大きめのストーリーを作成し、
理想の作業月（ideal engineering month）で見積もりを出します。顧客にこの大き
さのストーリーでトレードオフを検討してもらいます。もともと経験で見積もりを出
すべきで、経験がない場合は、入札に参加するべきではありません。
--
Kaoru Hosokawa
khosokawa@....com