ホソカワです。
第15章 Planning Strategy の解説です。最後にコメントあります。
----
Chapter 15 Planning Strategy
============================
The Planning Game (Release Planning Game)
-----------------------------------------
XP では、開発計画をゲームとして扱っています。このゲームを「Planning Game」と
言っています。
プラニングゲームのゴールは、開発するソフトウェアの価値を最大にすることです。
戦略は、最少の投資、最短の期間で、最大限の価値を生むことです。ビジネスは、出
来上がったシステムから学習したことをベースに次のシステムへの要求を決め、開発
はすぐにそれを実装します。この繰り返しです。ゲームのコマは、story cards で、
選手はビジネスと開発です。ゲームには、３つのフェースがあり、それらは、
Exploration、Commitment、Steer と言います。これらのフェースは循環するので、
steering の後に exploration に戻ることもあります。
<Exploration フェーズ>
このフェーズでは、選手たち（ビジネスと開発）にシステムの最終型を認識させます。
３つの進め方があります。
・Write a story - ビジネスはシステムの仕様を説明している story を書きます。
・Estimate a story - 開発は story の見積もりを出します。この見積もりは、
「Ideal Engineering Time」で表され、中断や会議なしで、実装にかかる期間のこと
を言います。
・Split a story - 開発が story の見積もりをできない時やビジネスが story の一
部分が重要とわかった時は、story を分割します。
<Commitment フェーズ>
このフェーズでは、ビジネスがスコープと納期を決定し、開発がその条件下の開発を
引き受けます。ここでは、４つの進め方があります。
・Sort by value - ビジネスは story を「必須機能」、「あればビジネスに貢献で
きる機能」と「あればうれしい機能（Nice To Have）」に分けます。
・Sort by risk - 開発は story を「見積もりに自信がある機能」、「まあまあの見
積もりの機能」と「見積もりができない機能」に分けます。
・Set velocity - 開発は velocity（プログラミング速度）を宣言します。
velocity = Ideal Engineering Time / calendar month
・Choose Scope - ビジネスはこのリリースのためにどの story を実装するか決定し
ます。
<Steering フェーズ>
このフェーズでは、プランのアップデートを行います。４つの進め方があります。
・Iteration - ビジネスは、iteration ごとに、もっとも重要な story を決定しま
す。
・Recovery - 開発が velocity を過大に評価したと発見した時、ビジネスに対して、
今回のリリースで重要な story を新しい velocity と見積もりで再度選択してもら
います。
・New story - ビジネスが新しい story を発見した時、その story を作成し、開発
は、見積もりを行います。重要度によっては、新しい story を入れ、重要度の低い
story を外します。
・Reestimate - 開発は、見積もりを再度行い、velocity を再設定することもできま
す。
Iteration Planning
------------------
今度は、Iteration Planning Game （IPG?です。Planning Game に似ていますが、
IPGのプレイヤーは、プログラマー、コマは、task card です。また、期間も短く、
１から３週間です。似たような、フェーズと進め方で構成されています。
<Exploration フェーズ>
・Write a task - story を実装するために必要なタスクを書きます。
・Split a task/combine tasks - 大きいタスクが分割して、短いタスクは統合しま
す。
<Commitment フェース>
・Accept a task - Practice にもありますが、タスクを買って出ます。
・Estimate a task - タスクを見積もります。
・Set load factor - load factor を決定します。
load factor = ideal engineering time / calendar time
・Balancing - あるプログラマの持ち分が大きすぎる時は、他のプログラマにタスク
を分けます。
<Steering フェース>
・Implement a task - タスクを実装します。
・Record progress - 進捗状況を記録します。
・Recovery - あるプログラマが手一杯になった時は、例えば、タスクのスコープを
縮小したり、顧客に story のスコープを縮小してもらいます。
・Verify story - タスクをすべて作成した時、story が完成したかチェックします。
[コメント：
story は、曖昧なものが多いと思います。iteration をくり返すうちにだんだんと固
まって行くのでしょうが、その story からタスクを作るのは大変でしょうね。また、
初期のiterationでは、捨てられる story、タスクが多いでしょうね。プログラマー
のモラルは大丈夫なのでしょうか？「せっかくタスクを作ったのにもういらないの？」
]
--
Kaoru Hosokawa
khosokawa@....com