第5章 原則
#エクストリームプログラミング
XPのおける原則には以下のものがある
人間性（Humanity）
ソフトウェア開発を軽視することによって、エンジニアのコスト大きくなり、離職率や組織の崩壊につながる
優れた開発者になるためには
基本的な安全性
空腹、身体的な危害、愛する人を危険にさらすものが存在しないこと。失業の不安はこうした要求を脅かす
達成感
自分が所属する社会に貢献する機会や能力
帰属意識
グループに所属して、承認や説明石責任を受け取ったり、共通の目標を貢献したりすること
成長
スキルや視野を広げる機会
親密な関係
他人を理解して、他人から深く理解されること
XPのプラクティスにはビジネスニーズと個人の要求の両方を満たすものもの選んでいる。しかし、人間的な要求（休息・運動・社会化）などは現場で満たされることはない。
チームのソフトウェア開発で個人の要求とチームのニーズの両方をバランスよく得ることは難しい
個人の要求とチームのニーズがバランスがあれば問題ないが、個人の要求よりチームにニーズを優先しまうと、うまくいかなくなる
優れたチームがすばらしいのは、メンバーの信頼関係のもと、それぞれが自分らしくいられることによって、個人の要求のバランスを取れているから
親密な関係になるのは、プライベートの話を仕事場に持っていくことはあまりよくない。チームのコミュニケーションの弊害につながる。
プライベートの話は、本当に親密な関係（身内や距離の近い同僚など）だけに絞り、区別することで仕事上のコミュニケーションが効果的になる
経済性（Economics）
ソフトウェア開発をする上では、誰がお金を支払っているのか、ビジネスのゴールをなのかを理解する必要がある
ソフトウェア開発の経済面には二つの側面がある
貨幣のタイムバリュー
早めにお金を稼いで、将来に使うほうが価値を高い
インクリメンタルな設計にすれば、設計の投資を後回しできるため、後でお金を使うことができる
システムやチームのオプションバリュー
特定の課題をプログラムが、別の課題にも解決するプログラムであった場合、価値が高いとみなすことができる
貨幣のタイムバリューを気にかけながら、オプションバリューを高めるプラクティスが準備されている
相互利益（Mutual Benefit）
XPのおいて最も難しい原則
問題が起きた時に解決した場合、ある人によっては利益になるが、ある人によって損失が生じてしまうことがある。そこから人間関係に亀裂が入ることがある
ドキュメント管理は一例。将来のためにドキュメントを充実させるという試みがある場合、将来そのドキュメントをみる人はメリットはあるが、現在管理している実装する時間を短くなるというデメリットが存在する
XPではこのような相互利益の問題を以下のように解決する
現時点で設計や実装の自動テストを書いておく。現在の自分と将来担当者にメリットにつながる
複雑性を排除するリファクタリングを行う。現在の自分の満足感も得ることができ、将来担当者に可読性にも期待できる
統一した命名を使用する。現在の開発速度もあがるし、コードが明確になる
自己相似性（Self-Similarity）
XPの原則はどの粒度でも同じように作用する
コードを書くとき、1つのユーザーストーリーの実装、リリース計画も基本的にXPと考え方がどこでも作用することができる
改善(Improvement)
改善を繰り返すことでソフトウェアの高みを目指すことが大事
完璧を目指すのではなくて、改善を繰り返していくことの方が大事
多様性（Diversity）
開発メンバーが全員に考え方が似たようなプロジェクトであればそれは機能的ではない。さまざまなスキル・考え方のメンバーがいて、意思決定の選択肢が多いプロジェクトのほうがより機能的になる。そこで多様性が重要になってくる。
意思決定が複数あると衝突することがあるが、お互いにリスペクトしそれぞれ主張をできるのであれば、多少ストレスがあっても円滑にすすむはず。
ふりかえり（Reflection）
優れたチームはどうやって仕事をしているのか、なぜ仕事をしているのかを考えており、ふりかえりで分析して得ている。
ふりかえりは知力だけが必要な作業ではなく、それぞれに否定的な感情から深掘りしていってあらたな気づきにもなる
ふりかえりは基本何かを行動した後に実施すべき
フィードバックを最大化していくには、ふりかえりと行動の組み合わせが必須
流れ（Flow）
小さなバリューをもった機能を何度もデプロイする流れを提唱している
大きな機能をまとめてリリースすると、フィードバックを得ることができず、リスクがある状態でリリースすることになる
機会（Opportunity）
XPを実施するとさまざまな問題にぶつかるが、その問題を変化の機会と捉えよう
高みの到達したいならば、問題を学習や改善の機会に変換しないといけない
冗長性（Redundancy）
ソフトウェア開発において重要で困難な問題に対しては、複数の方法で解決を試みること
プラクティスでいうといかにあたる
ペアプログラミング
継続的インテグレーション
全員同席
本物の顧客参加
デイリーデプロイ
失敗（Failure)
失敗をおそれなくていい。最適解がわからないなら、複数のパターンを実施してみることで重要なことを学べることもある。
何をすべきかわからない場合は、失敗のリスクを受け入れることが成功の近道になることがある。
品質（Quality)
品質を落としたとしてもプロジェクトが早くなることはない。むしろ、品質を上げたほうがプロジェクトは早くなる
品質のコントロールができない場合、週次サイクルや四半期サイクルでスコープをコントロールする
品質の定義がわからない場合は、できる限りのことをする。使える時間の範囲で品質をあげていく行動をする。後から、再度品質を上げることを考えればいい。
この考え方はアーキテクチャにもいえる。品質を考えた結果、アーキテクチャが二つ共存してしまった場合でも、後ほどアーキテクチャを片方に移行する作業を行えばいい
ベイビーステップ（Baby Steps）
大きな変更は一気に行うではなく、小さく変更をくりかえすようになる
大きは変更は失敗するとリスクがでかいが、小さい変更は失敗してもリスクが小さい
プラクティスは以下が対象
テストファーストプログラミング
継続的インテグレーション
責任の引き受け（Accepted Responsibility
責任を自ら引き受ける必要がある
責任を引き受ける時には権限も一緒ついてくる。権限がないとコミュニケーションが破綻する。
プラクティスとしては、タスクをアサインした人が見積もり・設計・実装・テストの責任を担うというものがある