エクストリームプログラミング

エクストリームプログラミング（XP）はアジャイルソフトウェア開発手法の1つである。

XPとは、効果のない技術的・社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである
XPとは、自分が今日やるべきことを十分に理解することである
XPとは、明日をよりよくしようとすることである
XPとは、チームのゴールに貢献した自分を評価することである
XPとは、ソフトウェア開発で人間としての欲求を満たすことである

価値・原則・プラクティス

価値というものはとても抽象的なものである。なので、「この1000ページのドキュメントを書いたのは、コミュニケーションに価値をおいているからです」という意見は、正しいかもしれないし、間違っているかもしれない。

逆に、プラクティスといものはとても具体的である。「毎朝10時にスタンドアップミーティングに参加する」というプラクティスは、参加出来ているかどうかを簡単に判断できる。

この価値とプラクティスの間には大きな隔たりがある。価値は普遍的なものであるが、プラクティスは状況によって大きく異なる。この2つの間のギャップを埋めるのが原則である。

VALUE_PRINCIPLE_PRACTISE

価値

コミュニケーション：Communication

チームによるソフトウェア開発で最も重要なのはコミュニケーションであり、チーム感覚や効果的な協力関係を生み出すために重要なものである。

シンプリシティ：Simplicity

問題を解決するための最もシンプルな方法を選択する。無駄に複雑な方法を選択する必要性はない。ただし、シンプルであるかどうかは状況によって異なるものである。

フィードバック：Feedback

最初に決めた方向性が、ずっと有効であることは無い。それが、ソフトウェアの要件・システムのアーキテクチャなどであっても同じである。経験をする前に何かを決めてしまうとすぐに駄目になってしまう。変化は避けられないものであり、対応するためにはフィードバックが必要となる。

勇気：Courage

勇気とは恐怖に直面したときの効果的な行動である。勇気を持って真実を語れば、コミュニケーションや信頼が強化される。勇気を持って新しい解決策を見つければ、シンプリシティが促進される。

リスペクト：Respect

チームメンバーはお互いに人として等しく重要である。ソフトウェア開発において人間性と生産性を同時に高めるには、チームに対する個人の貢献をリスペクトする必要がある。

原則

人間性：Humanity

ソフトウェアを開発するのは人間であり、人間性を保つために個人の欲求を満たすことが重要である。しかし、チームによるソフトウェア開発で難しいのは、個人の欲求とチームのニーズの両方のバランスを取り、みんなが自分らしくいられるようにすることである。

経済性：Economics

ソフトウェア開発における経済性には2つの側面があり、貨幣のタイムバリューとシステムやチームのオプションバリューである。貨幣のタイムバリューでは、今日のお金は明日のお金よりもバリューがあるとされる。将来のオプションバリューでは、ある機能を再利用できたとすると本来の目的だけに使うよりもバリューが高いということになる。

相互利益：Mutual Benefit

相互利益とは現在の自分・将来の自分・顧客に対する利益を求めることである。誰かにとって不利益となる解決策をとってしまうと、そこから敵意が生まれ、人間関係を引き裂くことになってしまう。

自己相似性：Self-Similarity

ソフトウェア開発においても、異なる規模の問題に対して、解決策の構造を新しい文脈にコピーしようとする。

改善：Improvement

「完璧な」プロセス・設計・ストーリーは存在しない。だが、「完璧に」プロセス・設計・ストーリーをやることはできる。改善によってソフトウェア開発の高みを目指し、今日できる最高のことをやるのである。

多様性：Diversity

お互いがよく似ているチームは、居心地は良いかもしれないが、機能的ではない。解決策を導き出すには多様性が必要である。

ふりかえり：Reflection

優れたチームは、どうやって仕事をしているのか・なぜ仕事をしているのかを考えている。なぜ失敗したのか・なぜ成功したのかを分析している。ミスを明らかにしそこから学ぼうとするのである。偶然に優秀になれる人などいないのである。

流れ：Flow

流れとは、すべての開発作業を同時に行い、バリューあるソフトウェアの安定した流れを生み出すことである。ソフトウェアのデプロイやインテグレーションの頻度を下げると、フィードバックの頻度が減り状況が悪化してしまう。

機会：Opportunity

問題を変化の機会と考えよう。その場を切り抜けるための問題解決しかしないサバイバルな姿勢では不十分である。より高みを目指すには問題を学習や改善の機会へと変換すべきである。

冗長性：Redundancy

重要で困難な問題は、複数の方法で解決すべきである。ひとつの解決策が失敗しても、その他の解決策で惨事を食い止めることができる。冗長性にコストが掛かるとしても、大惨事を回避できるならそのコストは支払うべきである。

失敗：Failure

失敗することにより解決策を導き出すのに必要な知識を得ることができる。その知識が得られたのであれば決して無駄ではない。ただし、よりよい方法を知っていながら失敗することを正当化するものではない。

品質：Quality

低品質を受け入れることでプロジェクトが早くなることはない。高品質を要求することでプロジェクトが遅くなることもない。むしろ、品質を高めることでデリバリーが高速になることが多い。品質基準を下げてしまうと、デリバリーが遅くなり予測できなくなってしまう。

ベイビーステップ：Baby Step

大きな変更は、大きなステップでやりたくなるものである。しかし、重大な変更を一気に行うのは危険であり不安を伴う。大きな変更が失敗してチームが無駄に後退するよりも、小さなステップで進むオーバーヘッドのほうが小さい。

責任の引受：Accepted Responsibility

責任とは割り当てるものではなく引き受けるものである。責任には権限が伴わなければいけない。このバランスが取れていないと、チームのコミュニケーションが破綻してしまう。

プラクティス

全員同席：Sit Together

チーム全体が入れる十分な広さのオープンスペースで開発すること。物理的に近くにいれば、コミュニケーションが促進される。ただし、近くにプライベート空間を用意するなどして、メンバーのプライバシーや自分だけの空間といった欲求を満たせるようにすること。

チーム全体：Whole Team

プロジェクトの成功に必要なスキルや視点を持った人たちをチームに集めること。1日に無理なくやり取りできる人数は12人までである。また、小数点以下の人間を入れてしまうと、情報の共有に時間を割く必要がでてきたり、チーム感が失われたりと、非生産的である。

情報満載のワークスペース：Informative Workspace

仕事の内容が分かるようなワークスペースを作ること。プロジェクトに関しがある人が近づいて見たときにが、抱えている問題などの情報が得られるようにしておこう。また、お菓子を用意したり、仕切りのある机を用意したりと人間のその他の欲求も満たす必要がある。

いきいきとした仕事：Energized Work

生産的になれる時間だけ働くこと。無理なく続けられる時間だけ働くこと。意味もなく燃え尽きてしまい、次の2日間の作業が台無しになれば、自分にとってもチームにとってもよろしくない。

ペアプログラミング：Pair Programming

同じマシンを前にした2人で、本番用の全てのプログラムを書くこと。これにより、お互いにタスクに集中したり、意見を出し合ったりすることができる。ただし、ペアプログラミングは疲れるプラクティスであるので、適度な休憩をはさみつつ進めると良いだろう。

ストーリー：Stories

「これまでのレスポンスタイムで5倍のトラフィックを処理する」といった、顧客に見える機能の単位を使って計画すること。そして、開発工数を見積もること。これにより、ビジネスと技術の観点からお互いにやり取りができる。

週次サイクル：Weekly Cycle

1週間分の仕事の計画をまとめて立てること。そして週の初めに、進捗の確認・着手するストーリーの選択・必要なタスクの見積もりを行うこと。週の終わりまでにデプロイ可能なソフトウェアを作ることが目的である。また、週次サイクルは、実験を行うための手軽で頻繁で予測可能なプラクティスでもある。

四半期サイクル：Quarterly Cycle

四半期分の計画をまとめて立てること。四半期に一度はチーム・プロジェクト・進捗・ゴールについて振り返ること。四半期は自然で広く受け入れられている時間の尺度であり、ビジネス活動ともうまく同期できる。

ゆとり：Slack

どのような計画にも、遅れたときに外せるような重要度の低いタスクを含めること。あとからストーリーを追加したり、多くのストーリーをデリバリーしたりするのは後からでもできる。

10分ビルド：Ten-Minute Build

自動的にシステム全体をビルドして、全てのテストを10分以内に実行させること。時間がかかると使用頻度が減り、フィードバックの機会が失われてしまう。

継続的インテグレーション：Continuous Integration

数時間以内に変更箇所のインテグレーションとテストをすること。インテグレーションのステップはプログラミングよりも時間のかかることが多い。インテグレーションに時間がかかれば、その分だけコストが上がり、予期しないコストも増えてしまう。

テストファーストプログラミング：Test-First Programming

コードを変更する前に、失敗する自動テストを書くこと。これにより、不要なコードの追加を防いだり、疎結合で凝集度の高いコードを書いたり、自然で効率的な開発のリズムを得ることができる。

インクリメンタルな設計：Incrementel Design

システムの設計に毎日手を入れること。システムの設計は、その日のシステムのニーズにうまく合致させること。小さくて安全なステップで稼働中のシステムを変更する経験を積み重ねていくと、設計にかける労力を遅延させることができるようになる。そうすれば、システムはシンプルになり、進捗は早くなり、テストが書きやすくなる。