XPが目指すソフトウェア開発

• 人の満足

ユーザだけでなく開発者も幸せになりたい。

• 変化に適応

すべてが予想できないことを予想しておく。

• 実績重視

未知の実装を既知の実績ベースで予測する。

XPが重視する開発姿勢

• コミュニケーション

目的のソフトウェアに向けて、ユーザも含め緊密に連携して開発を行う。

• シンプル

基本的にシンプルに。要求仕様を最もシンプルな形で実装する。
あれこれ可能性を考慮しない。

• フィードバック

開発の状況を常に把握し、よりよいソフトウェアに向けて、改善点をフィードバックする。

• 勇気

必要であれば大きな方向転換も辞さない。

プラクティス

XPの目指すソフトウェア開発を実現するための具体的な手法。
開発するソフトウェア、メンバ構成によって取捨選択を行う。
コーディングに例えると、デザインパターンに相当する。

Sit Together

プロジェクトに関わる全員が同じ場所で仕事をする。
コミュニケーションに起因する問題を解決することを目的とする。
(コミュニケーション)

Planning Game

ユーザサイドと開発者サイドでそれぞれことなった目線でプロジェクト計画を立てる。ユーザサイドは、期間、必要な機能、優先度など。
開発者サイドは、詳細なスケジュールや実現方法など。
お互いに計画に必要な情報交換は行うが、お互いの領域に踏み込まないようにする。
お互いの担当領域での計画を立てることで、名実共に担当範囲に責任を持つことができる。また目的に向けて不要な折衝、調整を減らし変更に迅速に対応することも可能になる。
(シンプル、コミュニケーション)

Customer Tests

ユーザが欲しい機能を提示し、それを満たすかどうかをユーザ自身がテストする。ユーザと開発者の間のギャップをなくすことができる。
(コミュニケーション、フィードバック)

Small Release

短期で何度もリリースすることで完成品と、やりたいことのギャップを埋めていく。
(フィードバック)

Simple Design

You aren't going to need it.(今必要なことをやれ)
必要な機能だけを実装する。設計を複雑にしない。
(シンプル)

Pair Programming

ペアで1台のマシンを使ってコーディングを行う。
(コミュニケーション、フィードバック)

Test-Driven Development

テストをコーディング前に書く。
必要な機能を把握できる。
後になってコードを変更したときに回帰テストの役割を果たせる。
(フィードバック)

Design Improvement:Refactoring

コードをシンプルに保つために、何か機能を追加するたびにリファクタリングを行う。
(シンプル、勇気)

Continuous Integration

常に結合テストを行うことで、いつでも動作するソフトウェアを得ることが可能。
(フィードバック)

Collective Code Ownership

誰でも、いつでも、どのコードでも変更できるようにしておく。
(コミュニケーション、シンプル)

Coding Standard

コーディング規約。少なくとも見た目を統一することで、コードをチームで共有しやすくなる。
(コミュニケーション）

Metaphor

誰も見たことがないソフトウェアを実現するために、説明しやすい他のものに例えて、チーム内のイメージを統一する。
(コミュニケーション)

Substainable Pace

無理のない開発ペースを維持する。
計画の段階で、無理がないペースになるように見積もりを行う。
何度もリリースを繰り返しながら、無理がないペースを徐々に見定めていく。
(フィードバック)

まとめ

XPはどんな仕組みがより効率的か、ではなく、どのようにすればより人間が力を発揮できるか、に焦点を当てた手法。

ソフトウェアの中に存在するあやふやさを認め、いかにそのあやふやさに対応するか、を問題解決の中心に据えている。

従来手法がなし得なかった作業効率を実現できる可能性がある反面、人間に頼る部分が多いため、プロジェクトに関わるすべての人間に対し、より高いレベルを求める傾向があると思われる。