上手です。
若干、コメントさせて下さい。
At 17:11 00/04/15 +0900, you wrote:
> ホソカワです。
>
> 第15章 Planning Strategy の解説です。最後にコメントあります。
>
> ----
>
> Chapter 15 Planning Strategy
> ============================
>
> The Planning Game (Release Planning Game)
> -----------------------------------------
>
> XP では、開発計画をゲームとして扱っています。このゲームを「Planning Game」と
> 言っています。
>
> プラニングゲームのゴールは、開発するソフトウェアの価値を最大にすることです。
> 戦略は、最少の投資、最短の期間で、最大限の価値を生むことです。ビジネスは、出
> 来上がったシステムから学習したことをベースに次のシステムへの要求を決め、開発
> はすぐにそれを実装します。この繰り返しです。ゲームのコマは、story cards で、
> 選手はビジネスと開発です。ゲームには、３つのフェースがあり、それらは、
> Exploration、Commitment、Steer と言います。これらのフェースは循環するので、
> steering の後に exploration に戻ることもあります。
ちょっと馴染みの薄い単語なので、exploration(探索)、commitment(約束)、steer
(運転？)とか、適当な訳を入れた方が解りやすいのでは。
>
> <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 を「見積もりに自信がある機能」、「まあまあの見
この「見積もりに自信がある機能」なんですが、precisely の「精密、正確」という
意味で、
精密（厳密）に見積もられている・・位の方が良いのでは。
> 積もりの機能」と「見積もりができない機能」に分けます。
>
> ・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 です。また、期間も短く、
> １から３週間です。似たような、フェーズと進め方で構成されています。
>
エーと、原文だと「一つのイテレーション（１〜４週間）」となっています。
３週間というのは最初の文の、「Planning Gameにより３週間毎の開発をコントロー
ル(steering)できる」の方だと思います。
> <Exploration フェーズ>
>
> ・Write a task - story を実装するために必要なタスクを書きます。
>
> ・Split a task/combine tasks - 大きいタスクが分割して、短いタスクは統合しま
> す。
ここは質問なんですが、「If you can7t estimate a task at a few days, break
ti down
into small 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
>
＃私の担当分は来週までに最新版に差し替えるつもりです、少々お待ち下さい。
（では）