エクストリーム・プログラミング (XP) は、アジャイル開発手法の一つで、柔軟性が非常に高いことが最大の特徴です。開発途中の仕様変更を前提とし、短いサイクル（イテレーション）で「設計→開発→テスト→改善」を繰り返すことで、変化に迅速に対応し、顧客のニーズを素早く反映させます。
XPの主な特徴（価値観に基づく）
XPは、以下の5つの価値を重視し、それらを実践するための様々なプラクティス（開発手法）を特徴としています。
コミュニケーション (Communication)
開発メンバー間だけでなく、顧客（オンサイト顧客）との直接的な対話を非常に重視します。
文書よりも、口頭での対話を通じて認識の齟齬を防ぎます。
シンプルさ (Simplicity)
**「今、必要な機能だけ」**を実装し、設計を極力シンプルに保ちます。
将来的な拡張を見越した複雑な設計は行わず、必要になった時点で機能を追加・改善します。
フィードバック (Feedback)
短期間のイテレーションで頻繁に動くソフトウェアを顧客に確認してもらい、素早くフィードバックを受け取ります。
これにより、問題の早期発見や、無駄な機能の開発を防ぎます。
勇気 (Courage)
要件変更などの変化を歓迎し、受け入れる勇気を持つことが求められます。
不要になったコードを破棄する、コードをシンプルにするためにリファクタリングするなど、積極的に行動する勇気も含まれます。
尊重 (Respect)
開発メンバー同士、および顧客と開発チームが互いに尊重し合い、協力的な関係を築くことが重要視されます。
XPを支える主な開発プラクティス
XPの特徴を実現するために、具体的な開発手法（プラクティス）が採用されます。
| プラクティス | 内容 | 特徴・目的 |
| 短い開発サイクル（イテレーション） | 設計・実装・テストを1〜2週間程度の短い期間で繰り返します。 | 変化への柔軟な対応、問題の早期発見、迅速なリリースを可能にします。 |
| ペアプログラミング | 2人1組で1台のコンピュータに向かい、一人がコーディングし、もう一人がレビュー・助言を行います。 | コード品質の向上、知識の共有、バグの早期発見、対応可能な人数（バス係数）の増加につながります。 |
| オンサイト顧客 | 顧客の担当者が開発チームと常に同席し、質問に答えたり、完成したソフトウェアを即座に確認したりします。 | コミュニケーションの円滑化、確認待ち時間の最小化、使い勝手の良いソフトウェア開発を促します。 |
| テスト駆動開発 (TDD) | テストコードを先に書き、そのテストが失敗することを確認してから、テストをパスするための最小限のコードを実装します。 | コード品質とカバレッジの向上、設計の簡素化、リファクタリング時の安全性の確保に貢献します。 |
| 継続的インテグレーション (CI) | 開発者が頻繁にコードを共有リポジトリに統合し、自動でビルドとテストを実行します。 | 統合時の問題を早期に発見し、手戻りを最小化します。 |
| コードの共同所有 (Collective Code Ownership) | チームメンバー全員がコード全体に対して責任を持ち、誰でも修正・改善できるようにします。 | 知識の分散、ボトルネックの解消、迅速な問題解決を可能にします。 |
| 計画ゲーム | ビジネス側（顧客）の要求と、開発チームの実現能力を考慮に入れ、優先順位付けと計画を短期間で調整します。 | ビジネス戦略と開発の現実的なバランスを取り、無理なく継続的に貢献できるようにします。 |
これらの特徴から、XPは特に要件が頻繁に変わるプロジェクトや、少人数で高品質なソフトウェアを迅速に開発する必要があるプロジェクトで効果を発揮します。
