エクストリームプログラミングについて

エクストリームプログラミングとは

エクストリームプログラミング(XP:Extreme Programming)とは

エクストリームプログラミング(以下XP)とは、アジャイル開発手法の一つであり、短い開発サイクルと最小限のドキュメンテーションで、スピードとシンプルさを追求する柔軟性に優れた開発手法です。
XP の起源は、Kent Beck 氏が1990年代後半にプロジェクトを管理するために考案・実践し、1999年10月に「Extream Programming Explained – Embrace Change」を出版したことに始まります。

XPは、変化する顧客要求への対応力を高めるために、常にフィードバックを行って修正・再設計していくことに重点を置いています。
そのために、XPでは、5つの指針となる価値観と、いくつかのプラクティスを定義しています。

XPのプラクティスとは

XPにおけるプラクティスとは、ビジネス分野において「慣習」となっている手法のことをいいます。
これらのプラクティスを実行して、価値を実現することが、XPを実行することになります。

なお、プラクティスの数については、12→24→19と変化しています。
初版時点では12個であったが、数度の改定を得て、19個と定義されることが多くなっています。
ただし、本質的な意味合いは変化することなく、より効果的な内容へと改定されています。

エクストリームプログラミングの５つの価値

コミュニケーション(communication)

プロジェクトが失敗する原因の多くはコミュニケーション不足です。
XPでは開発チーム内だけでなく、顧客とのコミュニケーションも重視します。

シンプル(simplicity)

XPでは柔軟性と素早さが求められるため、必要な機能のみを実装することが優先されます。
不要な機能をできるだけ排除して、本当に必要な機能だけ追加し、シンプルな設計にします。

フィードバック(feedback)

XPでは、早く・シンプルに製品を作り、それを顧客と共有し、即座にフィードバックを受けていきます。
積極的にフィードバックを得て、必要な改善を繰り返し行うことで、開発の精度を高めていきます。

勇気(courage)

XPでは最初に綿密な計画を立てないという特性上、途中で大胆な変更が求められる場合があります。
仕様変更などの変化を受け入れ、積極的に行動するための「勇気」が大切です。

尊重(respect)

チームとしての生産性を高めるためには、様々な意見を発言できる環境が必要です。
そのためには、ほかのメンバーを尊重する姿勢は欠かせません。
メンバーを尊重することは、生産性やお互いのモチベーションの向上につながります。

エクストリームプログラミングの 12 のプラクティスとは

以下は、XPの第1版で提案された12個のプラクティスとなります。
これらのプラクティスは、すべてを実施しなければならないという強制的なものではなく、選択して利用することができます。
また各プラクティス間には相関関係があり、併せて利用するとより効果的なケースがあります。

プラクティス	内容
チーム全体(Whole Team)	XPでは、顧客、プログラマー、マネージャー、テスター等がチームになって活動します。チーム全員が同じ場所に集まれることが理想ですが、必要になったらすぐコミュニケーションが取れる環境であることが重要です。また、要件に優先順位を付ける主体でもある、ビジネス側の代表として「顧客」を含んでいる必要があります。
計画ゲーム(Planning Game)	計画ゲームとは、イテレーション期間内に実装する機能を決定するやり取りのことです。開発者は機能の規模を見積り、顧客は機能の優先順位を提示することで開発機能が決定されます。 ※ゲームとはイテレーションごとに（通常は週に一度）開催される会議のことです。
小さなリリース(Small Releases)	XPチームは、テストされ、正常に動くソフトウェアを各イテレーションで顧客に提供します。これにより、顧客から早くフィードバックを受け取り、より改善を実施していきます。
持続可能なペース(Sustainable Pace)	XP での作業はハードであるため、持続可能なペースを設定することが大切です。チームは、そのやり方でイテレーション内にどれだけの成果を出せるかを決め、それを基にして無理のない納期を設定します。初期のKent Beck氏は「週40時間労働」を提案しています。
顧客テスト(Customer Tests)	XPでは、顧客が要求した機能が動作していることを確認するために、自動化された受け入れテストを定義します。顧客テストは、ユーザーの立場から見てユーザーストーリーが実現できているかを証明します。
メタファー(Metaphor：隠喩)	メタファーとは、比喩を使って、作るソフトウェア全体をストーリーとして表現する手法です。関係者全体でシステムの構造や振る舞いを理解するために、わかりやすい事例・例え話を示して知識を共有します。
シンプルな設計(Simple Design)	XPではソフトウェアをシンプルな設計を保ちます。現在の機能性を満たすために適切な設計を保つことで、ソフトウェアをいつでも次の変更への準備が整っている状態にします。
コーディング標準 (Coding standards)	XPチームでは共通のコーディング標準に従います。すべてのコードが、最も有能な一人の人間によって書かれたように見えるのが理想です。
コードの共同所有(Collective Code Ownership)	全てのコードはチーム全員で共有し、誰でも修正できるようにします。これにより、すべてのコードに対してすべての人が責任を負うことを意識させます。
継続的インテグレーション(Continuous Integration)	CIとは、ビルドやテストを頻繁に繰り返し実施することで問題を早期に発見し、品質を保証しつつ、開発効率を向上する手法です。ソースコードの変更をコミットする度に、ビルドとテストを実行することで、デグレードを抑止します。
ペアプログラミング(Pair Programming)	ペアプログラミングとは、開発者が２人一組になって、プログラミングを行うことです。 2人のプログラマが1人分の仕事をすることは非効率に見えますが、最終成果物の品質を向上させることができます。またペアを組むことは、スキルの向上を促し、チーム全体への知識の伝達に貢献します。
リファクタリング(Refactoring)	リファクタリングとは、機能を変更することなく、コードを改善する技法です。設計の改善(Design Improvement)を行い、良質でシンプルな設計をキープします。

エクストリームプログラミングの 19 のプラクティスとは

当初12個だったプラクティスは、その内容をより理解しやすくするための改定が数度行われています。
改定により、プラクティスの追加と対象者の立場（共通、開発者、管理者、顧客）による分類が実施されています。
ただし、本質的な内容や理念は変わってはいません。

共同プラクティス

共同プラクティスは、エクストリームプログラミングにかかわる全てのメンバーを対象としています。

プラクティス	内容
反復	全体の開発期間をイテレーション（1～2週間の短い期間）で区切った、反復型の開発を実施します。イテレーション毎に部分的な設計・実装・テスト・リリースを繰り返し、徐々に完全なシステムを構築します。
開けた作業空間	会話・相談しやすく、作業に打ち込める雰囲気を作ります。できれば顧客も含めて一箇所に集まって作業を行うことが望ましい。
共通の用語	用語集を作成し、チーム全員の使用する用語とその概念を一致できるように手配する。
回顧	頻繁な振り返りを実施します。現状を正しく把握し、フィードバックを素早く反映させるための環境、体制を構築します。

開発プラクティス

開発プラクティスは、開発チームが対象です。

プラクティス	内容
テスト駆動開発(Test-Driven Development: TDD)	テスト駆動開発は「テスト→実装→リファクタリング」を繰り返して成長しながら完成させていくような開発手法です。テストを先に作成することで、真に必要な機能が明確化され、シンプルな設計が可能になります。
ペアプログラミング	旧版と同じです。
リファクタリング	旧版と同じです。
YANGI (You Aren't Going to Need It)	「あなたはそれを必要としないでしょう」という意味通り、余計な機能を付けないようにします。無駄な機能があれば削り、今必要な機能だけのシンプルな実装に留めておきます。これによって変更に対応しやすいシンプルさをキープできます。
ソースコードの共同所有	旧版と同じです。
継続的インテグレーション	旧版と同じです。

管理者プラクティス

管理者プラクティスは、プロジェクトを管理するメンバーが対象です。
開発が適切に進んでいるかを把握して、チームに情報を共有します。

プラクティス	内容
責任の受け入れ	管理者は、最終的な開発の責任が自分にあることを受け入れます。
援護	チームのメンバーの不足部分を補助し、開発の援護を行います。
ミラー	ミラーとは、プロジェクトの状況をチームに知らせることです。現在の全体状況を把握し、チームに共有することで、チーム全体がどこに居るのかを理解することを周知します。
四半期毎の見直し	四半期ごとにプロジェクトの状況を見直し、開発の進行を調整します。
最適なペースの仕事	チーム・メンバーの負荷が大きい場合には、進行や役割を調整します。

顧客プラクティス

顧客プラクティスは、システムの受け入れ側であるユーザー(顧客)が対象です。

プラクティス	内容
ストーリーの作成	求める機能のコンセプトを短い文章で記した「ストーリーカード」を作成します。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、機能の詳細を決定する。
リリース計画	どのストーリーをどのイテレーションで実施するのか、チーム全員で考えて、チームで合意します。
受け入れテスト	イテレーション毎に顧客の立場からテストを行います。作成したストーリーが実装されているか確認して、問題がある場合は指摘します。
短期リリース	短い時間間隔で、動くソフトウェアのテストとリリースを繰り返します。必要に応じて顧客がフィードバックしていくことで、徐々にソフトウェア・システムの精度を上げていきます。