エクストリーム・プログラミング
単純さの観点で言うと、当然のことながら、システム開発にはコーディング、テスト、傾聴以上のものは必要ないと言える。 これらのアクティビティが適切に行われていれば、その結果は常に動作するシステムになるはずだ。しかし、実際にはそうはならない。 設計せずに長い道のりを歩むことはできるが、いつかは行き詰まる。 システムが複雑になりすぎて、システム内の依存関係が明確でなくなる。 システム内のロジックを整理する設計構造を作成することで、これを回避できる。 優れた設計は、システム内の多くの依存関係を回避する; つまり、システムのある部分を変更しても、システムの他の部分に影響を与えない。
XPは、1990年代後半から2000年代初頭にかけてソフトウェアコミュニティの間で大きな関心を集め、その起源とは根本的に異なる多くの環境で採用された。
元のプラクティスに求められていた高い規律はしばしば道端に捨て置かれ、厳しすぎると思われていたプラクティスの中には、銘々のサイトで非推奨になったり、縮小されたり、あるいは未完成のままにされるものもあった。 たとえば、各プロジェクトにおける一日の終わりの統合テストの実施を、週の終わりのスケジュールに変更したり、単に相互に合意した日でのテストに減らしたりする。 そのような弛んだスケジュールでは、一日の終わりのテストに合格するためだけに人為的なスタブを生成しなければならないという焦りを感じることはない。厳格でないスケジュールでは、代わりに、数日間も費やして複雑な機能を開発してしまう。
一方、他のアジャイル開発プラクティスは立ち止まっておらず、XPも、2019年の時点で、他のプラクティスを利用するために、現場での経験による多くの教訓を取り入れて進化し続けている。 初版から5年後の第2版の書籍『エクストリームプログラミング』(2004年11月原著発行)では、ケント・ベックはより多くの価値とプラクティスを追加し、基礎プラクティスと周辺プラクティスを区別した。
持続可能なソフトウェア開発の理論は、エクストリーム・プログラミングチームがチームの混乱にもかかわらず成長できる理由が説明されている 。
エクストリーム・プログラミング、XP(英: extreme programming)は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。
エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある。この方法論は、伝統的なソフトウェアエンジニアリングのプラクティスの有益な要素を「極端な(エクストリームな)」レベルに持っていくという考えからその名前を取っている。例えば、コードレビューは有益なプラクティスと考えられており、これを極端にすれば、コードを「継続的」にレビューする、つまり、ペアプログラミングのプラクティスとなる。