XP（eXtreme Programming）とは
- ウォーターフォール型の問題点を克服するために1990年代後半に考案されたアジャイル開発手法です。（XPは単独で使用されるよりも、スクラムと組み合わせて使用されることが多いです。）
- プロジェクトが途中で変更されることを前提に、5つの価値（ポイント）と12（19）のプラクティス（実践方法）に基づき柔軟に計画を変更します。
XPの5つの価値
| XPの5つの価値 | |
|---|---|
| コミュニケーション | 失敗するプロダクトの多くはコミュニケーション不足に起因しており、開発チーム内だけでなく、顧客とのコミュニケーションも重視します。 |
| シンプル | ・早計な共通化や将来を見越した過度な実験（オーバーエンジニアリング）をしてしまうことがあります。もしかすると、役に立つこともあるかもしれませんが、得てしてこういった思惑は外れることが多く、実装や検証に使った労力は無駄になることが多いため、シンプルさを重視し、まずはできるだけ単純な実装で済ませるようにします。YAGNIと略されることもあります。（YAGNI(You ain’t gonna need it)：機能は実際に必要となるまで追加しないのがよい）
・またシンプルなコードによるシンプルな設計は、ほとんどのチームメンバーが簡単に理解できる、という利点もあります。 |
| フィードバック | ある有名な調査では、ソフトウェアでよく使用される機能は全体の20%にしか過ぎないとの調査結果があります。これはユーザのフィードバックを得ていないために発生しているとされていますが、開発の初期段階ではシステムに対する理解が浅く、重要な部分の特定が困難です。そのため、XPでは、ユーザーを巻き込んで一緒にシステムを開発し定期的にフィードバックを得ることで、本当に重要な機能を早期に提供します。 |
| 勇気 | XPで言う”勇気”とは、上記の3つの価値を実現するための勇気です。
XPは、今までのウォーターフォール型の開発とはかなり異なっており、実行するためには勇気が必要になります。また最初に綿密な計画を立てないという特性上、途中で発生する大胆な変更に向かい合う勇気も必要になります。 |
| 尊重 | ソフトウェア開発は多くの場合はチームで行うものであり、いかに優れた方法論でも、人と人が尊重し合わなければ役にも立ちません。
プロジェクトを円滑に進めるためには、互いの尊重が必要不可欠です。 |
XPの12のプラクティス
| XPの12のプラクティス | ||
|---|---|---|
| 詳細スケールフィードバック | ペアプログラミング | 2人1組で1人がコードを記述し、もう1人はそれを確認・補佐するプログラミング技法です。記述しながら確認を行うことで、細々とした問題をその場で解決できるなどのメリットがあります。 |
| 計画ゲーム | Scrum開発のリリースプランニング、スプリントプランニングにあたります。 | |
| テスト駆動開発（TDD） | プログラムの実装よりもテストコードを先に作成することにより、求められる機能が洗い出され、シンプルな設計が実現できます。 | |
| チーム全体 | XPにおける「顧客」は請求書を支払う人ではなく、システムを実際に使用する人であり、XPでは、顧客は常に近くにいて、質問に対応できるようにしておくべきと、述べられています。 | |
| 継続的プロセス | 継続的インテグレーション（Continuous Integration） | 開発チームは常に最新バージョンのソフトウェアで作業する必要があります。継続的インテグレーションにより、統合に起因する、プロジェクトの後半での遅延を避けることができます。 |
| リファクタリング | 完成したコードを、外部の動作を変えずに、内部構造だけを変更し分かりやすく書き換えることです。これによりメンテナンス性の向上や不具合の発生頻度の低下が期待できます。 | |
| 小さなリリース | ソフトウェアの配信は、具体的な価値を生み出す機能の頻繁なリリースを介して行われます。小さなリリースは、顧客がプロジェクトの進捗状況に自信を持つのに役立てられます。 | |
| 共通理解 | コーディング規約 | 開発チーム全体がプロジェクト全体で遵守することに合意した一連のルールです。規約は、使用するプログラミング言語でのソースコードの一貫したスタイルと形式を規定するもので、欠陥が発生する可能性を減らすための避けるべき様々なプログラミング構造やパターンも含まれます。コーディング規約の順守は、コードコメントの削減にもつながります。 |
| ソースコードの共同所有 | ソースコードの共同所有は、すべてのコードに対してすべての人が責任を負うことを意味するものであり、誰もがコードのどの部分であっても変更することができます。ソースコードの共同所有によって、メンバーへの支援が改善され、知識と学習の幅が広がり、コードの責任が共有され、コードの品質が向上し、やり直しが減る一方で、メンバー間の衝突の増加、バグの増加、開発者の集中力の乱れと思案の中断、開発時間の増加、またはコードの理解不足につながる可能性もあります。 | |
| シンプル設計 | プログラマーは、ソフトウェア設計に「シンプル・イズ・ベスト」のアプローチを取るべきです。新しいコードが書かれるときはいつでも、「同じ機能を導入するためのより簡単な方法はないか」と自問自答する必要があります。答えが「イエス」であれば、よりシンプルな方を選択すべきです。 | |
| システムメタファー | 関係する誰もがシステムがどのように機能するかを語ることができるストーリーのことです。たとえば、図書館のシステムは、借り手（クラス）の貸出_記録（クラス）を作成し、項目が期限切れになった際に目録（クラス）に対して「延滞_発生」操作を実行します。それぞれのクラスや操作の機能は、チーム全体から見ても明らかです。 | |
| プログラマーの福利 | 持続可能なペース | 開発サイクルが連続的インテグレーションの短いサイクルであり、開発（リリース）サイクルがより頻繁に行われるため、XPのプロジェクトでは、他のプロジェクトが必要とする（残業が必要となる）よくあるクランチタイム（締め切り前の踏ん張りどころ）には従いません。この概念には、人は十分な休息をとっていれば、最高のパフォーマンスを発揮し、最も創造的な活動を行うことができるということも含まれています。 |
XPの19のプラクティス
| XPの19のプラクティス | |
|---|---|
| 共同のプラクティス | 反復 |
| 共通の用語 | |
| オープンな作業空間 | |
| 回顧 | |
| 開発のプラクティス | テスト主導型の開発 |
| ペアプログラミング | |
| リファクタリング | |
| 集団的所有権 | |
| 継続的インテグレーション | |
| YAGNI | |
| 管理者のプラクティス | 責任の受け入れ |
| 援護 | |
| 四半期ごとの見直し | |
| ミラー | |
| 持続可能なペース | |
| 顧客のプラクティス | ストーリーの作成 |
| リリース計画 | |
| 受入テスト | |
| 頻繁なリリース | |
