エクストリーム・プログラミング
ケント・ベックは、クライスラー総合報酬システム(英語版)(C3)給与計算プロジェクトでの業務の中で、エクストリーム・プログラミングを開発した。ケント・ベックは1996年3月にC3プロジェクトリーダーになった。彼はプロジェクトで使用された開発方法論を改良し始め、その方法論に関する本を書いた (エクストリームプログラミング, 1999年10月出版)。クライスラーは7年後の2000年2月、ダイムラー・ベンツが同社を買収した際にC3プロジェクトをキャンセルした。
エクストリーム・プログラミングの多くのプラクティスは以前から存在していた。この方法論は、「ベストプラクティス」を極端なレベルに引き上げる。 たとえば、「テストファースト開発のプラクティス、各マイクロインクリメントの前にテストを計画して書く」は、1960年代初頭のNASAのマーキュリー計画で早くも使われていた。総開発時間を短縮するために、一部の正式なテストドキュメント(受け入れテストのためのものなど)は、ソフトウェアのテストの準備がされるのと並行して(あるいは少し前から)開発されてきた。NASAの独立テストグループは、プログラマーがソフトウェアを書いてハードウェアと統合する前に、公式な要件と論理的限界に基づいてテスト手順を書くことができた。XPは、この概念を極限のレベルにまで引き上げて、機能という大きなテストしかしないのではなく、ソフトウェアコーディングの小さなセクションでさえも動作を検証する自動テスト(時にはソフトウェアモジュールの内部)を記述する。
継続的インテグレーション
リファクタリング もしくは 設計の改善
小さなリリース
エクストリーム・プログラミングでは、フィードバックはシステム開発のさまざまな側面に関連している:
システムからのフィードバック: ユニットテストを書いたり、定期的に統合テストを実行することで、プログラマーは、変更した後にシステムの状態から直接フィードバックを得ることができる。
顧客からのフィードバック: 機能テスト(別名:(受け入れテスト)は、顧客とテスターが作成する。彼らは、システムの現状について具体的なフィードバックを得られる。このレビューを2~3週間に1回のペースで計画することで、顧客は容易に開発の舵取りができる。
チームからのフィードバック: 顧客が計画ゲームで新しい要求を出すと、チームは直接、実装にかかる時間を見積もる。
フィードバックは、コミュニケーションとシンプルさに密接に関係している。 システムの欠陥は、特定のコードが壊れることを証明するユニットテストを書くことで簡単に伝達される。 システムからの直接のフィードバックは、プログラマーにこの部分を再コーディングするように伝える。 顧客は、ユーザーストーリーとして知られる機能要件に従って、定期的にシステムをテストすることができる。 ケント・ベックを引用すると、「楽観主義はプログラミングの職業上の危険である。フィードバックが治療法である。」
これは、すべての問題を、あたかもその解決策が「非常にシンプルである」かのように扱うことだ。 伝統的なシステム開発手法では、将来を見据えた計画を立て、再利用性を考慮したコーディングを行うように言われてきたが、エクストリーム・プログラミングはこれらの考え方を否定する。
エクストリーム・プログラミングの支持者は、一度に大きな変更を加えてもうまくいかないと言う。 エクストリーム・プログラミングでは、漸進的な変更を適用する: 例えば、システムは3週間ごとに小さなリリースを行うかもしれない。 多くの小さな段階が作られると、顧客は開発プロセスと開発中のシステムをより詳細に制御できるようになる。