アジャイルソフトウェア開発手法のなかで代表的なものである。
較的少人数の開発にもっとも適用しやすい。
XPはドキュメントよりもソースコードを、
組織的開発の歯車となることよりも、個人の責任と勇気を
重んじる人間中心の開発プロセスであるとしている。
共同のプラクティス
反復
開発を反復から構成する（⇒反復型開発）。
全体の開発期間をイテレーションという1～2週間の短い期間に区切り、
イテレーションごとに部分的な設計・実装・テストを行い
半完成品システムのリリースを繰り返す。
より小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。
共通の用語
用語集を作成し、チーム全員の使用する用語とその概念の不一致を解消する。
開けた作業空間
会話しやすく作業に打ち込める雰囲気を作る。
回顧（頻繁な振り返り）
現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がける。
そのための環境、体制を構築しておく。
開発のプラクティス
テスト駆動開発
実装を行う前に自動化されたテストないしは手順の明確化されたテストを作成する。
実装はそのテストをパスすることを目標に行う。
テストを先に作成することで、求める機能が明確化されシンプルな設計が可能になる。
ペアプログラミング
二人一組で実装を行う。
一人が実際のコードを書き、他方はそれをチェックしながらナビゲートする。
この役割を随時交代しながら作業を進める。
これにより、細々した問題解決に要する時間が短かくなる、
常にコードレビューを行うことができる、集中力が持続する、
コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ、
などの多彩な効果が得られる。
リファクタリング
完成済みのコードも随時、改善処置を行う。
この際、外部から見た動作は変更させずに
内部構造がより見通し良く優れたものになるようにする。
テストが作成されていることが前提になる。
ソースコードの共同所有
誰が作成したソースコードであっても開発チーム全員が断り無く修正を行うことができる。
全てのコードに対する責任を全員が担う。
継続した結合
単体テストをパスするコードが完成するたび、すぐに結合テストを行い、
問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。
YAGNI
You Aren't Going to Need It（今必要なことだけ行う）。
先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。
むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。
このことで後のイレギュラーな変更に対応しやすいようにする。
管理者のプラクティス
責任の受け入れ
援護
四半期毎の見直し
ミラー
今どういう状態かをチームに知らせる。
最適なペースの仕事
知的作業には週40時間の労働時間が最適である。
XPでは集中力を高めて効果を生む事を重視しているため、
心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。
そのため、計画的に開発スピードの調整を行う。
顧客のプラクティス
ストーリーの作成
求める機能のコンセプトを短い文章で記したストーリーカードを作成する。
そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。
リリース計画
どのストーリーをどのイテレーションの対象とするかを
チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
受け入れテスト
イテレーションごとに顧客の立場からテストを行い、
ストーリーが実現できているか、望むシステムになっているか確認する。
もし満足できない場合は、それを指摘する。
短期リリース
現状においてはこの全てのプラクティスを同時に実行することは非常に困難であるため、
テスト駆動開発やリファクタリングなど、単独でもある程度有効なプラクティスだけが、
一部導入されているケースが多い。
