eXtreme Programming - 変化ヲ抱擁セヨ

• Preface
• Section 1 問題
  • Chapter 1 リスク: 基本的な問題
  • Chapter 2 ある開発風景
  • Chapter 3 ソフトウェア開発の経済学
  • Chapter 4 四つの変数
  • Chapter 5 Cost of Change
  • Chapter 6 Learning to Drive
  • Chapter 7 Four Values
  • Chapter 8 Basic Principles
  • Chapter 9 Back to Basics
• Section2 解決方法
  • Chapter 10 クイックオーバービュー
  • Chapter 11 これはどういう風に機能するのか
  • Chapter 12 管理戦略
  • Chapter 13 設備・機器戦略
  • Chapter 14 ビジネスおよび技術の責任を分割する
  • Chapter 15 Planning Strategy
  • Chapter 16 Development Strategy
  • Chapter 17 Design Strategy
  • Chapter 18 Testing Strategy
• Section3 XP の実装
  • Chapter 19 XP を採用する
  • Chapter 20 XP へ模様替えする
  • Chapter 21 理想的なプロジェクトのライフサイクル
  • Chapter 22 人々の役割
  • Chapter 23 20-80 Rule
  • Chapter 24 What Makes XP Hard
  • Chapter 25 When You Shouldn't Try XP
  • Chapter 26 XP at Work
  • Chapter 27 Conclusion
• Glossary

Preface

• ペアプログラミングによるコードレビュー
• テストツールによる徹底的なテスト
• リファクタリングによるきれいな設計
• 必要な機能しか実装しないシンプルなシステム
• アーキテクチャを表現するためのメタファ
• 頻繁なコードの統合とテスト
• 短い開発サイクル

Chapter 1 リスク: 基本的な問題

• スケジュールの遅延、不必要な機能、プロジェクトの中止、状況の変化

  XP では、重要な機能から順番に非常に短いサイクル(最長でも数カ月) でシステムをリリースします。したがって、スケジュールに間にあわない 可能性のあるのは、それほど重要でない機能のはずですし、システムには 今必要な機能だけが実装されているはずです。このようなシステムは、 リリース毎に最大の価値をもつので、プロジェクトが中止になる可能性は 非常に低くなります。また、開発サイクルが短いため、状況の変化にすば やく追従できます。

• 仕様の勘違い

  ユーザーはチームの一員として開発をおこないます。したがって、間違った 仕様はすぐにシステムに反映されます。

• コードの腐敗

  テストツールにささえられたリファクタリングのおかげで、常に一定レベル 以上の品質がたもたれます。

• バグ

  単体テストツールとユーザーをまじえた機能テストのおかげで不具合が発生 する可能性は低くなります。

• 転職

  プログラマは責任をもって見積もりと作業をおこないます。したがって、非 現実的なスケジュールに悩んだすえ転職するようなことはありません。

Chapter 2 ある開発風景

• ペアプログラミング
• まず単体テストを書きそれからコードを書く。すべてのテストに合格し、 これ以外のテストを考えつかなくなるまでこれを続ける。
• 必要ならリファクタリングをおこなう。
• 単体テストが完了したら、すぐにコーディング統合と統合テストをおこなう。

Chapter 3 ソフトウェア開発の経済学

• プロジェクトをキャンセルするオプション
• プロジェクトの方向性を変更するオプション
• プロジェクトを延期するオプション
• プロジェクトを継続するオプション

• オプションを得るために必要な投資
• オプションを実行することによって得られる報酬
• 報酬の現在価値
• オプションの行使にかかる時間
• 報酬の最終価値の不確実性

• 正確かつ頻繁なフィードバック
• 頻繁な要求の変更
• 小額の初期投資
• より速く進む機会

Chapter 4 四つの変数

• コスト
• 時間
• 品質
• スコープ

このうち、開発チームが決定する事ができるのは4番目のスコープだけです。 残りの三つは顧客やマネージャが決めます。

四つの変数の中で、コストを変更する事が一番困難でしょう。しかし、より 多くのコストをかければ、スコープの拡大、納期の短縮、品質の向上が可能 です。

時間は、ほとんどの場合外的な制約です。Y2K 問題を思いだしてください:-) したがって、この変数は顧客によって決定されます。

品質は奇妙な変数です。品質の向上により、納期を短縮したり、より多くの仕事 をおこなうことができます。しかし、逆に範囲で品質を犠牲にすることにより、 はやく仕事を終らせることもできます。

開発者にとって一番重要なのはスコープです。これを管理できれば、他の変数 についてはマネージャや顧客の決定に従うことができます。

スコープは頻繁に変化します。顧客は最初から自分が欲しいものを正確に 認識できません。顧客はソフトウェアがリリースされて、初めて自分が欲しい ものが何だったのかを知るのです。頻繁な要求の変化を受けいれるには、 スコープの柔軟な変更が必要です。

以上の事からわかるのは、まず時間と質とコストを決定するべきだという事です。 この三つの変数がきまれば、要求の変化にあわせて簡単にスコープを変更する 事ができます。

Chapter 10 クイックオーバービュー

• 計画ゲーム

  顧客(ユーザ)はビジネス上の優先度をつけ、プログラマは技術見積をし、 次回リリースの範囲を決める。

• 小規模リリース

  小さなシステムを最短で稼働させ、その後、新バージョンを非常に短い サイクルでリリースしていく。

• メタファー(たとえ)

  システム全体の機能を解りやすく説明する喩え（たとえ）を使用し、 メンバ全員が共通のイメージを持つ。

• シンプルデザイン

  できる限り単純にシステムを設計し、無駄な複雑さは見つけ次第取り除く。

• テスティング

  プログラマはコードを書く前に単体テストを書く。顧客は、開発終了判定 となる機能テストを書く。

• リファクタリング

  プログラマは正常稼働しているシステムでも、積極的にコードを改良する。

• ペアプログラミング

  二人のプログラマがペアを組んで、一台のマシンでプログラミングする。 ペアは一日に何度も変わる。

• 共同所有権

  プログラムはプログラマ全員の共同所有で、おかしい所をみつけたら、 いつでも、誰でもリファクタリングできる。

• 継続的インテグレーション

  システムを一日に何回も統合する。インテグレードしビルドし、毎回タスク は完了する。

• 週40時間

  週40時間以上仕事をしてはいけない。

• オンサイト顧客

  実際のユーザをチームに加えて、いつでもプログラマの質問に答えられる ようにする。

• コーディング基準

  プログラマはコーディング基準に従ってプログラミングし、コードを 通じて情報を共有する。

10章では、全てのプラクティスの要約をしており、11章でそれがどう機能するかを 説明している。この章だけ読めば、XPの概要は解る。

Chapter 11 これはどういう風に機能するのか

11章は個別のプラクティスの説明と共に、XPが全体としてどう機能するのかを 説明している。

まず、これらのプラクティスはオリジナルなものでなく、ずっと前からあり、 大部分は捨てられ、より複雑なプラクティスに置き換わった、と述べている。 しかし、変更コストの指数曲線の前提が崩れたため復活した、また、それぞれ のプラクティスは前と同じ弱点を持っているが、他のプラクティスの強さにより 補われる、としている。

結論でも、テスティングを除き、どのプラクティスも自分だけでは自立できない。 他のプラクティスがバランスをとることが必要だ、としている。

図「プラクティスは相互にサポートする」に、プラクティスの要約がある。 ２つのプラクティスの間の線は、相互に強化しあっていることを示している。

この章の各パラグラフの構造は以下の例のようになっている。

(例)テスティング

1. たぶん全部のテストケースは書けないかもしれない

   (プラクティスが守れない)

2. Unless:(前提条件や、実行内容を書く)
   　　
   • こういうことをする
   　　　
   • ああいうことをする
3. そうするとプログラマはテストケースを書くね(プラクティスが守れる)

Chapter 12 管理戦略

Chapter 13 設備・機器戦略

この章では、部屋の中の機器の配置、使い方などを説明しています。

• 働くのに合理的な場所でなければ、プロジェクトはうまくいかない。 良い場所と悪い場所の差は、直接的かつ劇的だ。
• オブジェクト指向のコンサルにいったら、上級プログラマが大きな フロアの角のオフィスにばらばらにいたので、配置換えから始めた。
• XPはかなり多くの共有スペースを必要とする開発手法だ。XPは、 コミュニケーションをベースにしており、相互に見、聞き、質問し、 自分に関係する会話を聞く。
• 横に並べないテーブルは駄目、４角い壁（の部屋）も駄目、でもチームは 離れていないと駄目。

という訳で、最初の写真のような配置になります。

• 中央に大きな机を置き、開発マシンを乗せる。
• 周りには、私物や電話を置くちょっとしたスペースを用意。ここに居る時 の仮想プライバシは大事に守る。
• コミュニケーションスペースを一番快適な場所として用意し、コーヒー メーカー、カウチソファ、オモチャ少々、お絵かき道具を置く。
• 組織が開発すべき環境を整えられないなら、そこで働くことはできない。
• 物理環境の制御権を取ることは、チームに協力なメッセージを送ること になる。仕事の全てに関する制御権をとる第一歩だ。

物理環境はとても大事な要素だ。物理環境の確保に対する組織の姿勢を見れば、 開発に対する本音がわかる、という話のようです。

最初にダイムラー・クライスラー社のＣ３プロジェクトの開発風景の写真があり、 Ron Jeffriesの説明が紹介されています。大変興味深く読みました。

• ２つの大きなテーブルがあり、各６台のマシンが乗っている
• プログラマは２人ずつ、使えるマシンの前に陣取る 確かに、２人ずつ座って、一緒に画面を眺めています。
• 壁には注意すべき機能テスト、CRCセッションの予定、イテレーションの 計画などが貼ってある。壁の上には、XPのルールが掲示されている。
• 右側の壁には電話と物書きの出来るちょっとしたスペースが並んでいる。
• 一番奥には、ミーティングやCRCセッションをするテーブルがある。 このテーブルはいつもCRCカードと食べ物で一杯。チームのルールの ひとつは”いつも食べ物を”。

部屋はチームがデザインしたそうで、

• みんな静かに話すので、騒音レベルはとても低い
• フロアにカーペットがないで、椅子を滑らせることが出来る

Chapter 14 ビジネスおよび技術の責任を分割する

What to Do?(何をすべきか)

ビジネスもプログラマも、分担を明確にし、何事も自分たちだけで勝手に 決めないようにする。

ビジネスは以下を選択する

• スコープとリリースのタイミング
• 提案された機能の相対的な重要度
• 提案された機能の正確なスコープ（実現範囲）

この決定のために、開発は以下を支援する

• 機能を実装するのにかかる時間を見積もる
• 技術的な選択肢の検討結果の見積り
• 人的資源、ビジネス環境、会社の文化を考慮した最適な開発プロセス
• 最初に使うプラクティスのセット。プラクティスの効果をレビューし、 プラクティスを変更する方法。

ビジネス決定はプロジェクトの続く限り発生するので、顧客はプログラマ の一員となり、更に、チームに加わってフルタイムで質問に答えられれば一番 良い結果を生む、と述べています。

テクノロジの選択

テクノロジの選択は純粋に技術的な決定の様に見えるかもしれないが、 インプットが開発からされるだけで、実際はビジネス決定だ、としている。 開発が技術的なコメントを述べ、ビジネスが決定する例が挙げられている。 一方で、開発の決定としてメンテナンスコストを計算に入れることが強調 されている。

Chapter 19 XPを採用する

1. 最悪の問題を取り上げる
2. それをXP流に解決する
3. それがもう最悪の問題でなくなったら、(1、2を)繰り返す。

最初にやるのは明らかにテスティングと計画ゲームだろう。多くの プロジェクトは品質問題と、ビジネスと開発の力関係に悩まされている。

このアプローチの利点

• 非常にシンプル
• 一度に一つのプラクティスを学ぶのでよくわかる
• 今一番緊急の問題に対処しているので、変更に対する自分の動機も沢山 あるし、自分の努力に対して、ポジティブなフィードバックを即座に得られる。

今一番緊急の問題を解決することで”XPはお仕着せだ”という反対意見にも 対応できる。各プラクティス採用する時に、状況に合わせれば良い。

物理環境の重要性を過小評価するな。私はいつもドライバーとレンチで始める。

• 机などを再配置して、ペアプログラミングができるように、顧客も一緒 に座れるようにする。
• お菓子を少々買う。

この章は、13章（機器・設備戦略）と併せて読んで下さい。 XPには、いつも「お菓子」が出てきます。太らないかな？

Chapter 20 XP へ模様替えする

20章では、稼働しているソフトウェアを開発している既存のチームで どうやって XP を採用するかを、各分野について述べています。

既存コードから XP にシフトする時、既存の全てのコードについてテスト を書きたくなる。しかし、これをやってはいけない。代わりに、必要により テストを書く。

• テストされていないコードに機能を追加する時に、現在ある機能について のテストを先に書く。
• バグをフィックスする必要がある時に、テストを一つ先に書く。
• リファクタが必要な時に、テストを先に書く。

最初は開発が遅くなったと思うだろう。通常の XP と比べてより多くの時間 をテストを書くのに費やすので、新しい機能を開発するのも前より遅くなった ように感じる。しかし、システムのいつも使う機能、注意が必要な機能や新しい 機能はすぐに徹底的にテストされる。まもなく、システムの良く使われる部分は XP で書かれているかのように感じるようになる。

XP への設計の移行は XP へのテストの移行とよく似ている。新しいコードが 古いコードとは全く違っていると気づくだろう。一度に全部フィックスしたくなる だろう。でも、駄目。一度に少しだけ。新しい機能を追加する時に、先にリファクタ しよう。XP 開発の実装ではいつもリファクタを先にする準備が出来ているものだが、 XP の移行に際しては、これをより頻繁に行わなければならない。

プロセスの最初に、チームに大規模なリファクタリングのゴールを認識させよう。 特に絡み合った継承関係があるかもしれない、統一したい機能のかけらがシステム 中に散らばって居るかも知れない。ゴールをセットして、それをカードに書き、 沢山掲示しよう。

既存の要求情報はストーリーカードに変換しなければならない。顧客にはゲーム のルールを教育しなければならない。顧客は次回のリリースの内容を決めなければ ならない。XP 計画にスイッチすることの最も大きな挑戦(であり機会)は顧客に、 チームからどれだけより多くを引き出せるかを教えることだ。彼らはたぶん今まで 要件変更を歓迎する開発チームなんてお目にかかったことが無いだろう。

XP の管理は、間接的で影響を与えるというゲームだ。マネージャーは自分 で意志決定はしない。しかるべき人に、意志決定をし、その決定を伝えてくれ と頼む。

• XP をやっていなかった時の状況が発生したら、ステップバックして、 チームにルール、価値、基準を思い出させ、それから何をすべきか決める。
• XP に高速でシフトするためには、チームメンバを消耗(疲れ切る)させない ことだ。

トラブルを抱えてソフトウェアが使われるまで至っていないプロジェクトを、 XP に移行することで打開しようとしても成算は無いから止めるように、と繰り 返し述べています。

現在のコードベースを慎重に評価しなさい。それが無くてもやっていけますか? もしそうなら、それを消しちゃいましょう。全部。大きなたき火でテープを燃やそう。 一週間休暇を取ろう。フレッシュでやり直そう。

この本は読みにくいなとずっと感じていましたが、下にあるような修辞的な 構成が沢山あり、またメタファーが多用されているからでしょう。教養が有り すぎる、というところでしょうか。

古いコード　->夜(night) 　-> bug は暗闇(dark)で育つ　->解決は明るいところに出す
XP コード　 ->昼(day)   　->

Chapter 21 理想的なプロジェクトのライフサイクル

21章は、理想化された XP のプロジェクトをもとに、プロジェクトのライフ サイクルの全体的な流れを記述している。

良い最初のリリースをするために十分なストーリーカードがあり、顧客が 満足している。プログラマは実装する前としては一番良い見積を持って満足 している。この時、探求は終わる。プログラマは使用するテクノロジの一部 を使ってみる。1、2週間かけて開発するシステムに似たものをつくる。 これを3、4回、別チームで行い、結果を比較する。

使う技術とメンバを既によく知っているチームなら、探索フェーズは2、3 週間でいいだろう。ある技術やドメインに対して全く初めてならば、2、3ヶ月 はかかる。もし探求がこれより長くなったら、プロセスを急がせるために小さな 実プロジェクトを作るかも知れない。

計画フェーズの目的は、顧客とプログラマが、開発する最も小さく最も 重要なストーリーのセットの開発期限について、自信をもって合意することだ。 やり方はプランニングゲームの章を見ること。探求で準備をしていれば、計画 (コミットメントスケジュールの作成)は1日か2日で出来るだろう。最初のリリース は2から6ヶ月の間に計画すべきだ。それより前だとたぶん重要なビジネス問題 を解決することは不可能だ。長すぎるとリスクが大きくなる。

コミットメントスケジュールは1から4週間のイテレーションに分割される。 各イテレーションでは予定されたストーリーのための機能テストケースのセット が作られる。理想的には、各イテレーションの最後には顧客が機能テストを完成 しており、それが全部通る。最後のイテレーションが終わると、生産にはいる 準備が整う。

リリースの最後になるとフィードバックサイクルは短くなる。イテレーション は一週間になる。毎日立ちながらのミーティングがあるので誰もが互いのやって いることを知っている。このフェーズではシステムの性能をチューニングする 必要がある。モットーは「走らせろ、正しくしろ、早くしろ」。

保守は XP プロジェクトの正常な状態だ。

新しいメンバーがチームに来たら2、3イテレーションの時間を与え、質問を させ、ペアプログラミングをさせ、多くのテストとコードを読ませる。彼らが 準備ができたと感じたら、2、3のプログラミングのタスクに、負荷率を減らして、 責任を持たせる。彼らが納入までいったら、負荷率を増やす。

チームが徐々に変化していくと、一年経たない内にオリジナル開発チームは、 生産サポートや進行している開発を中断することなく、全員あたらしいメンバー に替わることが出来る。これは普通の「それとこの紙の山に必要な情報は全部 はいってます」という引継よりは遙かにリスクが少ない。実際、プロジェクト の周りのカルチャーを共有有)することは、設計や実装の詳細と同じく重要であり、 それは個人的な接触を通じてのみ達成される。

Chapter 22 人々の役割

XPプログラマは他のプログラマと表面的には同じに見えるが、実際は全く違う。

• 知識の共有

  テストを先に書く/ペアプログラミング

• 単純性の習慣デザインパターンに熟達していても駄目、ツールをいっぱい 持っていても駄目。
• 技術的なスキル

  リファクタリング/単体テスト

• ソースの共同所有権
• 自分の怖れを認識すること 　

  誰もが怖れる: ばかに見られること/技術の 陳腐化

勇気なしにはXPは機能しない。失敗しないことに時間を使うのではなく、 チームの助けを受けて怖れを認識する。素晴らしいソフトウェアを書くこと に喜びを見出すチームに属し、ビジネスとうまくやっていこう。

プロジェクトに影響する、しかしコントロールはできない。意志決定をする。 ストーリーを書く。機能テストを書く。

顧客が機能テストを書くのを助ける。全てのテストを定期的に走らせ、結果を 皆に伝え、テストツールがうまく動くようにする。

見積もりのフィードバックのループを閉じる。全体的な進捗も監視していて、 チームに報告する必要がある。チームの歴史家でもある。

• 機能テストのスコアのログ
• 報告された欠陥について

  ログ/誰が欠陥に対する責任を了承したか/各欠陥に対してどのテスト ケースが追加されたか

プロセス全般に責任を持つ。最も難しいのは、間接的に働くことが、一番効果 があるということ。直接指示を出さず、自分で解決するように持っていく。コーチ に必要なスキル

シンプルデザイン/リファクタリング/テスト

しかし、チームがこの能力を持っているなら、必ずしも必要ではない。また、 チームが成熟するに連れ、コーチの役割は小さくなる。

チームが深い技術的知識を必要とする時が、コンサルタントの出番。

彼らのすることを見ていて、何かおかしいことがあれば質問する。答が おかしければ、止めさせる。必要な時に的確に動き、必要でない時は口を 出さない。

プログラマと顧客といった、重複した役割は問題が起きた時に解決しにく いから駄目、といっています。

顧客のところに、面白い表現がありました。

顧客は、約束したことの半分しか納入されず、納入された残りも半分も駄目 というITに慣れていた。どっちにしろ失望するんだから、ITに一インチも譲ら ないようになった。XPはこういう顧客にはうまく機能しない。