上手＠データ通信システム です。
１１章のまとめです。コメントよろしくお願い致します。
この章の各パラグラフの構造は以下の例のようになっています。
（例）
テスティング
１ たぶん全部のテストケースは書けないかもしれない
（プラクティスが守れない）
２ Unless:（前提条件や、実行内容を書く）
・こういうことをする
・ああいうことをする
３ そうするとプログラマはテストケースを書くね（プラクティスが守れる）
１はあまり意味が無いので、２と３の内容だけ紹介します。
----------------------------
１１章 How Could This Work?
（どうやればこれは機能するのか）
いままで述べて来たプラクティスは全て、ユニークでもオリジナルでもない。
プログラムが出来た時からずっとある。またこれらのプラクティスの大部分
は捨てられ、より複雑な、オーバヘッドの高いプラクティスに置き換わった。
原因は、プラクティスの弱点が明白になったからだ。では何故XPはこのシ
ンプルなアプローチを採用するのか？先に進む前に、シンプルプラクティス
は一昔前にプロジェクトを崩壊させたが、今はそんなことはないのを確信し
ておこう。
指数変更コスト曲線の崩壊はこれら全てのプラクティスを復活させた。それ
ぞれのプラクティスは前と同じ弱点を持っているが、これらの弱点は他のプ
ラクティスの強さにより補われる。
この章は何がプラクティスを守れなくし、また他のプラクティスがそれぞれの
悪い効果をもちながら、どうやってプロジェクト全体の崩壊から守るかを述べ
る。また、XPのストーリー全体がどのようにして機能できるのかを示す。
◇計画ゲーム(The Plannig Game)
・プログラマが提供した見積りに基づいて顧客が自分自身で計画を更新した
・あなたが最初から十分なプランを持っていた。これからの何年かの間、何
が可能かのラフなアイデアを顧客に提供できる。
・short releases をやっているので計画の中のどんなミスもせいぜい２，３週
間か月の影響しかない。
・顧客がチームの中にいるので、彼らが潜在的な変化や改良のチャンスに素
早く気づく
シンプルな計画で開発を開始することが出来、進行するにつれてそれを継続
的に磨いていくことができる。
◇ショートリリースズ(Short Releases)
＃前の章では、Small Releases となっているが、この章は Short Releases
＃となっている。他の章はどうでしょうか？
・計画ゲームにより一番価値のあるストーリーから始めているので、小さなシ
ステムでビジネス上の価値がある。
・継続的に integrate しているのでリリースコストは最小だ
・テスティングで欠陥率が減っているので、legathyテストサイクルを採る必要
が無い
・このリリースのためだけのsimple designをすればいい
開発が始まってすぐ、small releases ができる。
◇メタファー（例）
・プラクティスの中でmataphorが効いているか実コード、実テストで実際にフィ
ーバックされる。
・顧客は、metaphorの用語で会話するのを好む。
・metaphorの意味の理解をリファクターする。
metaphorにより開発を始められる。
◇シンプルデザイン
・リファクタリングに慣れているので、変更をするのに迷いは無い
・全体に対する明確なmataphorがあるので、先にいって、吸収されることが解
っている。
・パートナーと一緒なので、シンプルデザインをやっていることに自信が持てる
今日、シンプルデザインで仕事を始められる。
◇テスティング
・デザインがシンプルなのでテストを書くのも簡単。
・パートナーと一緒なので、他のテストは書いてくれる。パートナーがテストを軽
視していたら、自分が書く。
・テストが全部通る（こと自身が）気持ちいい。
・顧客も自分が書いたテストが全部通ると気持ちいい。
そうすると、プログラマも顧客もテストを書く。おまけに、一人が自動化テストを
書かないと、XP全部が動かなくなる。
◇リファクタリング
・collective ownership に慣れているので、必要な時にはためらわず修正する。
・coding standardsがあるので、 リファクタリングの際に再フォーマット不要。
・ペアでプログラミングするので、面倒なリファクタリングに取り組める。
・simple designしているので、リファクタリングは容易。
・testsがあるから、知らずに何かを壊してしまうことは少ない
・継続インテグレーションをしているので、デグレードがあれば、何時間かの間
に判明する。
・十分休息しているので、意欲もある、ミスも犯さない。
システムをsimpleにする、duplcationを減らす、より明確にcommunicateする
チャンスを見つけた時には、すぐリファクタする。
◇ペアプログラミング
・coding standardsがあるので、無駄な論争が減る
・みんなフレッシュで休息しているので、無内容な討論が減る。
・テストを一緒に書くので、実装に入る前に理解を共通か出来る。
・metaphorがあるので、ネーミングやbasic designで勝手なことをしない。
・simple designに従って仕事をしているので、共に進行を確認している。
これでペアでコードを書ける。
◇集合的所有権(Collectiv Ownership)
・ごく短い時間の後にintegrateするので、conflictsの発生は減る。
・testsを書き、走らすので、他の部分を壊してしまう危険は減る。
・ペアでプログラムするので、コードを壊す可能制覇減るし、うまい変更の方法を
早く学ぶ
集合的所有権が無いと、デザインの改良スピードは劇的に低下する。
◇継続的インテグレーション
・testsをquicklyに走らすので、何も壊していないことが判る。
・リファクタするので、作業対象はより小さな部分になり conflictの可能性が減る
quicklyに integrate しないと、conflicts の可能性と、integration コストは急激に
上昇する。
◇週４０時間
・The Planning Game により一番重要な仕事が判る。
・The Planning Gameと testing の組み合わせで、やるべきことを見逃さない。
・The practicesによりトップスピードでプログラムできる。
と言うわけで週４０時間で十分ビジネス上、価値のある仕事が出来る。
もし、（それ以上働いて）fresh で energetic で無くなると、残りのThe practices
を実行できなくなる。
◇オンサイト顧客
・オンサイト顧客は機能テストを書いてくれる
・オンサイト顧客はプログラマのために、小規模の優先順位付けをし、開発対象
(scope)を決定してくれる。
プロジェクトに貢献することで、会社にとってより大きな価値が産み出される。
◇コーディング基準
・XPの全てが、winning team のメンバになる可能性を高める。
coding standardsが無いと、ペアプログラミングとリファクタリングのスピードは
ひどく遅くなる。
結論
どのプラクティスも自分だけでは自立できない（テスティングを除く）。他のプラ
クティスがバランスをとることが必要だ。
図４．（プラクティスは相互にサポートする）はプラクティスを要約する。
２つのプラクティスの間の線は２つのプラクティスが相互に強化しあっていることを
示す。
個々の部分はシンプルだ。豊かさは部品同士の相互作用からもたらされる。
（ここまで）