上手＠データ通信システムです。
第21章 の要約です。
コメントお願いいたします。
意訳してあります。
-----------------------------
XP Chapter21
Lifecycle of an Ideal XP Project
理想的なプロジェクトのライフサイクル
この章は、理想化されたＸＰのプロジェクトをもとに、プロジェクトのライフサ
イクルの全体的な流れを記述している。
＜探索＞
ＸＰ流にいうと、生産にいないということはお金を稼がず、費やしているだけと
いうことになる。これは居心地が悪い。
しかし、生産を始める前に生産に行けるということを確認する必要がある。これ
が探索フェーズでやることだ。
ポイントだけ紹介します。
良い最初のリリースをするために十分なストーリーカードがあり、顧客が満足し
ている。プログラマは実装する前としては一番良い見積を持って満足している。
この時、探索は終わる。
プログラマは使用するテクノロジの一部を使ってみる。１、２週間かけて開発す
るシステムに似たものをつくる。これを３，４回、別チームで行い、結果を比較
する。
一週間で評価出来ない場合は、それをリスクのある技術に分類する。慎重にその
技術を取り扱い、代替を探す。
新しい技術の専門家を呼んで来る場合は、言うことを鵜呑みにしてはいけない。
技術の性能限界を実験する。可能なら実負荷をシミュレートする、ただし簡単に。
顧客はストーリーカードを書くが、最初はうまくいかない。キーは、最初の少し
のストーリーに対して、素早く多くのフィードバックをすることだ。そうすると
顧客は、プログラマが必要としていることを明記し、必要ないことは書かないこ
とをすぐ学ぶ。キーの質問は、”プログラマは自信をもってストーリにかかる
努力を見積もれるか”だ。時にはストーリーは書き直さないといけないかもしれ
ない。時にはプログラマはちょっと実験をする必要があるかもしれない。
使う技術とメンバを既によく知っているチームなら、探索フェーズは２，３週間
でいいだろう。ある技術やドメインに対して全く初めてならば、２，３ヶ月はか
かる。もし探索がこれより長くなったら、プロセスを急がせるために小さな実プ
ロジェクトを作るかも知れない。
＜計画＞
計画フェーズの目的は、顧客とプログラマが、開発する最も小さく最も重要なス
トーリーのセットの開発期限について、自信をもって合意することだ。やり方は
プランニングゲームの章を見ること。探索で準備をしていれば、計画（コミット
メントスケジュールの作成）は１日か２日で出来るだろう。
最初のリリースは２から６ヶ月の間に計画すべきだ。それより前だとたぶん重要
なビジネス問題を解決することは不可能だ。長すぎるとリスクが大きくなる。
＜初回リリースへのイテレーション＞
コミットメントスケジュールは１から４週間のイテレーションに分割される。各
イテレーションでは予定されたストーリーのための機能テストケースのセットが
作られる。
最初のイテレーションによりアーキテクチャが表に出る。最初のイテレーション
のためのストーリーは、それが骨格のような形だったたとしても”全てのシステ
ム”を創ることを強制するものを選びなさい。
その後のイテレーションのストーリーの選択は顧客にかかっている。自分に聞く
こと。”我々にとってこのイテレーションで動かすべき最も価値のあることは何
だろう”
イテレーションを進めていって計画とのずれが発生したら、計画やプロセスや技
術を変更して対処する。
理想的には、各イテレーションの最後には顧客が機能テストを完成しており、そ
れが全部通る。各イテレーションの最後にはセレモニーをしよう−ピザを買い、
爆竹を鳴らし、顧客に完了したストーリーカードにサインしてもらおう。品質の
良いソフトを予定通り出荷したんだ。それはたった３週間だったけど、お祝いの
価値があるのさ。
最後のイテレーションが終わると、生産にはいる準備が整う。
＜生産化＞
＃productionizing を生産化として訳してみます。
リリースの最後になると（”生産化”）フィードバックサイクルは短くなる。イ
テレーションは一週間になる。毎日立ちながらのミーティングがあるので誰もが
互いのやっていることを知っている。
通常、ソフトウェアが生産にはいる準備が出来ていることを証明するために幾つ
かのプロセスがある。生産への適合性を証明する新しいテストを実装する。この
ステージではパラレルテストがよく用いられる。
このフェーズではシステムの性能をチューニングする必要がある。私は次のモッ
トーを強く信じている。”走らせろ、正しくしろ、早くしろ”。システムのデザ
インの知識もあり、負荷の見積もできるし、ハードウェアも使えるので、チュー
ニングには完璧な時期だ。
生産化の間は、ソフトウェアの改良のペースを落とすだろう。ソフトウェアの改
良を止めるのではなく、リスクをより重要視して、変更をこのリリースに含める
か判定する。しかし、経験を積めば設計がどうあるべきか良く知るのだから、現
在のリリースでおかしいところがあれば、それをリストにして、生産に移行した
後に皆が見れるようにしておこう。
実際にソフトウェアが生産に移行したら、ビッグパーティをやろう。多くのプロ
ジェクトは生産まで行かないんだから、命を持っただけでお祝いする理由がある。
＜保守＞
保守はＸＰプロジェクトの正常な状態だ。
それぞれのリリースは探索フェーズから始まる。前のリリースの最後では恐れた
大きなリファクタリングにトライするかもしれない。次回のリリースには使おう
と思っていた新技術にトライするかもしれない、もう使っている技術の新バージ
ョンへの移行をするかもしれない。新しいアーキテクチャのアイデアを実験する
かもしれない。顧客がビジネスのビッグ勝者になろうとして、突飛なストーリー
を書こうとするかもしれない。
生産にいると開発のスピードは変わる。新しい見積には保守的になること。探索
の間に、開発に占める生産サポートの影響を計測すること。生産に移行すると理
想的なエンジニアリング時間の比率はカレンダー時間の５０％に増加すると思う。
（カレンダー時間は２〜３日／１エンジニアリング日）
＃注：２〜３日のうちの１日は、生産サポートをしている比率になる。
想像しないこと、代わりに、計測すること。
チームの構造を生産に対応して変更する準備をしよう。ヘルプデスクをつくって
大半のプログラマが生産からの（問い合わせによる）割り込みに常時さらされな
いようにしようとするかもしれない。全部のプログラマをローテーションにいれ
てそれを担当させるようにしなさい−生産サポートでしか学べないことがある。
もっとも開発ほど面白くはないが。
新規に開発したソフトを生産にいれると一部が動かないことがある。いずれにせ
よ生産システムにいれること。このサイクルが日か週であるプロジェクトにいる
が、どのケースでもコードを１イテレーション放置して置いてはいけない。タイ
ミングは妥当性確認(verify）と移行のコストによる。リリースの最後にやらな
いといけないのはコードの大きな固まり、たぶん何も壊さない、を統合すること
だ。生産コードベースと開発コードベースがだいたい同期しているなら、統合の
問題はより早く警告されるだろう。
新しいメンバーがチームに来たら２、３イテレーションの時間を与え、質問をさ
せ、ペアプログラミングをさせ、多くのテストとコードを読ませよう。彼らが準
備ができたと感じたら、２，３のプログラミングのタスクに、負荷率を減らして、
責任を持たせよう。彼らが納入できることを実際に示したら、負荷率を増やそう。
チームが徐々に変化していくと、一年経たない内にオリジナル開発チームは、生
産サポートや進行している開発を中断することなく、全員あたらしいメンバーに
替わることが出来る。これは普通の”それとこの紙の束に必要な情報は全部はい
ってます”という引継よりは遙かにリスクが少ない。実際、プロジェクトの周り
のカルチャーを共有（＃communicate：佃さんの解釈が正しいようです。情報共
有）することは、設計や実装の詳細と同じく重要であり、それは個人的な接触を
通じてのみ達成されます。
＜死＞
うまく死ぬことは、うまく生きることと同じく重要だ。これはプロジェクトにも
あてはまる。
顧客がもう新しいストーリーを提供しないなら、システムをモスボールに入れる
時だ。５から１０ページのシステム記述書を書いて、５年間の仕事にけりをつけ
よう。
それは死ぬべきよい理由である−顧客はシステムにハッピーで、予見できる未来
においても追加機能は全く考えられない。
死ぬべきそんなに良くない理由もある−システムはまだ納入されない。顧客が要
求する機能を経済的に追加できない。欠陥率がじりじり上がり許容範囲を超えた。
これはあなたが長い間戦って来たエントロピーの死だ。ＸＰも例外ではない。
どのケースでも、継続は不可能だと断定したのだから、プロジェクトは死ぬ。後
は皆の前でオープンにやるべきだ。チームはその状況の経済学を知るべきだ。顧
客もマネージャも、チームとシステムが必要なものを納入できなかったことに合
意することが出来るべきだ。
それからやさしいお別れをしよう。パーティを開こう。システムに関係した人を
皆招こう。システムの失敗のシーズを探す機会を作ろう。次はどうやるか考えよ
う。
（以上）