エクストリーム・プログラミング
書籍『エクストリームプログラミング』では、エクストリーム・プログラミングは、より高品質なソフトウェアをより生産的に生産するために人々を組織化するソフトウェア開発の規律として説明されている。
XPは、長い開発サイクルではなく、複数の短い開発サイクルにより、要件変更のコストを下げようとする。 この教義では、変更はソフトウェア開発プロジェクトの自然で避けられない望ましい側面であり、変わることがない要件定義をしようとするのではなく、計画すべしとしている。
エクストリーム・プログラミングでは、アジャイルプログラミングのフレームワークに加えて、いくつかの基本的な価値、原則、およびプラクティスを取り入れている。
XPでは、ソフトウェア開発プロセス内で実行される4つの基本的なアクティビティ(コーディング、テスト、傾聴、設計)を描き出す。これら各アクティビティを次に説明する。
テストはエクストリーム・プログラミングの中心である。 エクストリーム・プログラミングのアプローチは、少しのテストでいくつかの欠陥を取り除ければ、多くのテストでより多くの欠陥を取り除くことができるというものである。
ユニットテストは、特定の機能が意図した通りに動作するかどうかを判断する。プログラマは、コードを「壊す」可能性のある自動テストを思いつく限り多く書く; すべてのテストが成功したら、コーディングは完了である。書かれたすべてのコードは、次の機能の作成に進む前にテストされる。
受け入れテストでは、プログラマーが理解した要件が顧客の実際の要件を満たしているかどうかを検証する。
システム全体の統合テストは、最初は、互換性のないインターフェースを早期に発見し、各セクションが首尾一貫した機能から大きく乖離する前に再接続するために、毎日の終業時に実施することが推奨されていた。しかし、システム全体の統合テストは、システムの全体的なインターフェースの安定性に応じて、週1回、またはそれ以下の頻度にまで減少した。