原則とは？
- どう振る舞うかの指針
- ドキュメントと会話、どちらが優先されるかはすべての条件が同じであれば、原則会話とされる
- XPのValue とXPのプラクティス を結びつける
- Valueは普遍的だが、プラクティスは状況によって変わる
XPの原則
人間性
- ビジネスだけでなく、開発者個人の要求も満たされるようにする
- 身体的危害や失業の不安がない
- 開発者が社会に貢献する機会がある
- 会社に属していることを実感でき、評価と責任を受けられる
- 開発者としての技術を発展する機会がある
- 他人を理解し、他人から理解される
経済性
相互利益
- すべての活動が、関係者全員の利益になるようにする
- 「膨大なドキュメント」はこの原則に反するプラクティスである
- 将来関与する人には利益だが、開発速度を落とすため現在の関係者には不利益になる
- 「自動テスト」「リファクタリング」「一貫性がある命名」などは、将来関与する人と相互有益な方法である
自己相似性
- ある解決策を、別の状況でも使ってみる
- 「失敗するテストを作成し、そのテストを動作させる」というTDDのリズムを他の状況にも当てはめる
- 四半期単位では、取り組みたいテーマを一覧にして、ストーリーを出してテーマを網羅する
- 週単位では、取り組みたいストーリーを一覧にして、これらのストーリーを表現するテストを作成・動作させる
- 数時間単位では、作成する必要のあるテストを一覧にして、テストを作成・動作させ、一覧が終了するまで繰り返す
- ある解決策が別の状況で機能するとは限らないが、よい出発点にはなる
- 参考: フラクタル
多様性
- チームは様々なスキル・姿勢・物事の見方を結集して、問題に取り組む
- 多様性に衝突は付き物
- 衝突は「機会」であり、プログラマ両方の意見を重視すべきである
- 他人を敬い、自分自身を維持することが大事
反省
- 作業を行う際には、作業方法と作業理由も考える
- 四半期やイテレーションごとにとらわれず、会話や読書といった普段の活動からも反省することができる。
フロー
- 開発のすべての活動（コーディング・自動テスト・ビルド・デプロイ…）を個別のフェーズではなく、連続的な活動として行う
機会
- 問題が起きた際には、「変更の機会」だと考える
- 「存続させる」ではなく、「向上させる」
- 各問題を機会へと意識的に変換することがエクストリームであることに含まれる
冗長性
- 冗長性をもたせることで最悪の事態を避けるようにする
- XPでは、バグに対して冗長性のあるプラクティスで対処する
- ペアプログラミングで、パートナーがバグを見つけてくれる
- 全員同席で、誰かが欠陥を見つけてくれる
失敗
- 成功が難しい場合には、失敗してみる
- 3つの方法のうちどれが正しいかわからない場合は3つすべての方法を試す
- 知識を与える失敗は無駄ではない
品質
- 品質を決して犠牲にしない
- 品質を下げてもプロジェクトは早く進まず、むしろ遅延する
- 品質を向上させると納品も早くなる
- 経済的要因以外でも、「人は誇りに思える仕事をすべきである」という観点からも品質を犠牲にしてはいけない。
- プロジェクト管理には品質の代わりにスコープを使う
小さなステップ
- 重要な変更を1度に行わない
- 小さなステップでは、失敗を捨てるときのオーバーヘッドが少ない
責任の受け入れ
- 責任は割り当てるものではなく、受け入れるものである
- 責任があるかどうかを判断できるのは、当のプラグラマだけ