ホソカワさん、上手です。
ちょっとコメントさせて下さい。
On Sat, 1 Jul 2000 13:07:51 +0900
Kaoru Hosokawa <khosokawa@....com> wrote:
> ホソカワです。
>
> 遅くなりました。２６章の解説です。最後にコメントあります。
>
> Chapter 26 XP at Work
> =====================
>
> Fixed Price (固定価格)
> ----------------------
>
> 固定価格契約をextremeで行う事が難しいようです。結局、固定価格、固定納期、少々
> の変動が許されたスコープになってしまいます。
>
> XPは、固定価格、固定納期、固定スコープではなく、どちらかと言うと「定期購読」
> を提供します。iterationごとに顧客は、方向転換をする事が許され、新しいストー
> リーを導入する事ができます。
>
> XPは、小刻みにリリースを出荷することから違う側面を提供します。リリースを出荷
> しないで、１２から１８ヶ月もXPを行いません。１２ヶ月の契約の場合、２から３ヶ
> 月で出荷を開始します。そこから、１、２ヶ月単位で出荷を続けます。徐々に出荷さ
> れる事で、進捗状況などによって顧客は契約を破棄することができたり、方向をかえ
> る事が出来ます。
ここは、やまの さんが指摘されています。
>
> Outsourcing
> -----------
>
> 通常、アウトソーシングすると顧客は、最終的に保守できないコードを請け負う事に
> なります。
>
> XPで、アウトソーシングした場合は、顧客が開発チームのところに行き、作業を行う
> か、灰初チームが顧客のところに行き、作業します。契約が終了した時、顧客は（一
＊開発＊
> 緒に作業する事によって内容をちゃんと把握している）コードをもらいます。
>
> 顧客は、単体テストや機能テストがあるので、変更を加えてもシステムを壊す事はあ
> りません。顧客は、プログラマの管理者を任命しますので、システムの中身も理解す
> る事が出来ます。顧客は、開発のかじとりもできます。
>
> Insourcing
> ----------
>
> Beck氏は、アウトソーシングをよく思っていません。ちょっと思考を変えて、例えば、
> 徐々に顧客の技術者と開発チームのメンバーを入れ替えていくとどうでしょう？これ
> を、「insouring (インソーシング)」と言います。
>
この部分は、「アウトソーシングにXP流の変更を加える」ことを明確に示す必要
があると思います。例えば、
アウトソーシングのビッグサム納入は（XPの）インクリメンタル納入ルールに違
反する。アウトソーシングにXP流のちょっとした変更を加える。例えば徐々に・
> これには、たくさんのメリットがあります。例えば、ベンダーは、詳細な技術情報を
> 顧客に提供することが出来ます。徐々に責任を顧客に移す事によって、顧客は、手に
> 終えないプログラムを納品されるリスクがありません。
＊負＊
下の結論にいきなり行くのは無理でしょう。本文に説明のある、インクメンタル
納入の説明が無いと、意味が通じないと思います。
サンプルのインソーシングとして10名のチームを考える。契約は12ヶ月。最初の
開発は３ヶ月で、月に１回の納入を９回行う。顧客は最初は一人の技術者をチー
ムにいれ、毎月一人ずつ増やす。供給者は毎月一人ずつメンバーを減らす。
>
> チームメンバーが入れ代わるので、開発期間はアウトソーシングよりかかるでしょう
> が、リスクの軽減が大事でしょう。
>
> XPでは、チームの生産性を常にモニターしますので、iterationのストーリーを調整
> する事によって、納期を守る事ができます。
>
> Time and Materials
> ------------------
>
> 「Time and materials（期間と納品物??）」契約の場合は、チームが作業を行った時
materials は人のことと思います。私の会社の用語だと、「期間契約」「派遣」
になります。ある人をある期間派遣でサービス提供し、精算は実働時間で計算す
る場合です。
> 間を請求します。問題は、ベンダーと顧客のゴールが違う事です。ベンダーは、でき
> るだけたくさんの人員を投入して、利益をあげようとします。また、残業も増やそう
revenue の訳は収益か収入の方が良いと思います。
> とします。顧客は、短期間で、少人数で、より多くの機能を作成させようとします。
>
> ベンダーと顧客との関係がT＆M契約を左右するでしょう。
>
> Completion Bonus
> ----------------
>
> 固定価格やT＆M契約でボーナス制度を設けることいいでしょう。XPチームは、
> Planning Gameで、実現できる達成目標を決めているので、ボーナスをもらう確率が
> 高いでしょう。
>
> ボーナス制度の逆で、納品が遅れた場合のペナルティもあります。この場合でも、
> Planning Gameで、達成可能が目標を立てているので、大丈夫でしょう。
>
> 問題は、Planning Game で、スコープを変えた場合ですが、一般的に問題ないでしょ
> う。クリスマスに、クリスマスツリーの下にプレゼントの数がサンタに頼んだ数と合っ
> ているかどうかなど考えません。特に変更をしたのは、顧客の場合。
>
> もし、ストーリーの数にこだわる顧客ならば、契約を結ばないでしょう。
>
> Early Termination
> -----------------
>
> XPで、顧客は、開発経過を完全に把握できるので、いつでも、開発を止めるができま
> す。契約書に、プロジェクトを中止した場合の、チームに対する賠償などを追加する
> ことはどうでしょう。
ここは正確に訳した方が良いと思います。
顧客がプロジェクトを中止しトータルコストの比例分と、たぶん供給者が新しい
契約を短期間で見つけないといけないことを償う割り増し分、を支払うという条
項を盛り込むことを考えよう。
>
> Frameworks
> ----------
>
> 使われていない機能は削ると言う方針で開発を行うのであれば、フレームワークは消
> えてしまうのではないでしょうか？XPでは、アプリケーションを作り、その中から、
> 使えそうな機能を抽出して、汎用的にできるか考えます。
>
> XPを使って、フレームワークを開発する場合、Planning Gameのビジネスはフレーム
＊外部使用のフレームワーク＊
> ワークを使うプログラマになります。彼等の期待している機能がストーリーになりま
> す。
ここでは、フレームワークを １内部使用する場合 ２外部使用する場合 の２
つの話があるので、内部、外部の区別は明確にした方がいいと思います。
>
> Shrinkwrap Products
> -------------------
>
> 「Shrinkwrap Products (店頭販売製品)」でも、XPを適用できます。ここでビジネス
Shrinkwrap Products は通常、「パッケージソフト」と訳していると思います。
> は、マーケティングになります。また、エキスパートをビジネスとしてむかえる事も
マーケティング部門 エキスパートユーザー
この方が良いと思います。
（以上）
> できます。
>
> ----
>
> [コメント： いろいろなコントラクトにXPが対応できるように書かれています。た
> だ、Fixed Price と Time & Material コントラクトにはむいていないようにおもい
> ます。スコープを途中で変更（たいていの場合、縮小の方向）されて、顧客は満足す
> るのでしょうか？逆にInsourcing, Frameworks, Shrinkwrapには、使えますね。
> ]
>
> --
> Kaoru Hosokawa
> khosokawa@....com
>
>