ホソカワです。コメントありがとうございます。
on 2000/04/17 1:56 PM, Yutaka Kamite at y-kamite@....jp wrote:
> 上手です。
> 若干、コメントさせて下さい。
>
> 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 探検
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 の「精密、正確」という
> 意味で、
> 精密（厳密）に見積もられている・・位の方が良いのでは。
>
「(1) those that they can estimate 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」はどう解釈すればいいんでしょうか。下の解釈でいいのでしょうか
> ？
>
> ２，３日経ってもタスクの評価が出来ない時は、分割する
>
「If you can't estimate a task at a few days, break it down into smaller
tasks.」「*at* a few days」の部分の訳ですが、「*as* a few days」の間違いじゃ
ないかと思っています。ですから、「数日間のタスクとして見積もれないのであれば、
分割しましょう。」と考えました。続きの文（「If several tasks each take an
hour, combine them to form a larger task.」）は、「複数のタスクがそれぞれ１
時間として見積もれるのであれば、統合しましょう。」と、逆を説明しているので、
このように解釈しました。「*in* a few days」であれば、上手さんが言っていると
おり、「２、３日経っても…」でいいと思います。
>> <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
>>
>
> ＃私の担当分は来週までに最新版に差し替えるつもりです、少々お待ち下さい。
>
> （では）
ゆっくり、やりましょう。よろしくお願いします。
--
Kaoru Hosokawa
khosokawa@....com