エクストリーム・プログラミング プラクティス
探索フェーズ
これは、要件を収集し、それら各要件の作業影響を見積もるという反復的なプロセスである。
ストーリーを書く: ビジネスには問題が伴う; ミーティング中に、開発はこの問題を定義して要件を取得しようとする。ビジネス上の問題に基づいて、ストーリー(ユーザーストーリー)を書かなければならない。これはビジネス側で行われ、システムの各部に何をしてほしいのかを指摘していく。開発側がこのストーリーに影響を与えないことが重要である。ストーリーはユーザーストーリーカードに書き込まれる。
ストーリーの見積もり: 開発側は、ストーリーカードがほのめかす作業の実装にかかる時間を見積もる。開発側は、問題を分析したり解決するためのスパイクソリューションを作成することもできる。このソリューションは見積もりに使われ、全員が問題の明確な可視化を得た時点で破棄される。繰り返しになるが、ビジネス要件に影響を与えてはいけない。
ストーリーを分割する: すべての設計上の重要な複雑さは、イテレーション計画を開始する前に対処する必要がある。開発側でストーリーを見積もれない場合は、分割して再度書き直す必要がある。
ビジネス側がこれ以上の要件を思いつくことができない場合に、コミットメントフェーズに進む。
コミットメントフェーズ
このフェーズでは、コスト、メリット、スケジュールへの影響を判断する。 4つのコンポーネントを有する:
価値でのソート: ビジネス側は、ユーザーストーリーをビジネス価値(英語版)で並び替える。
リスクでのソート: 開発側は、リスクによってストーリーを並び替える。
速度の設定: 開発側は、プロジェクトを実行できる速度を決定する。
プログラマーやソフトウェア開発者は週40時間を超えて働いてはならず、ある週に残業があったとしても、その次の週にはそれ以上の残業をしてはならないという考え方である。 開発サイクルが連続的インテグレーションの短いサイクルであり、完全な開発(リリース)サイクルがより頻繁に行われるため、XP のプロジェクトは、他のプロジェクトが必要とする(残業が必要となる)よくあるクランチタイム(訳注: 締め切り前の踏ん張りどころ)には従わない。
また、この概念には、人は十分な休息をとっていれば、最高のパフォーマンスを発揮し、最も創造的な活動を行うことができるということも含まれている。
持続可能なペースを達成するための重要な要因は、頻繁なコードマージと、常に実行可能でテストが網羅された高品質のコードである。 絶え間ないリファクタリングの作業方法は、チームメンバーに新鮮で注意深い心を強制する。 チーム内での激しい共同作業のやり方は、週末に充電する必要性を駆り立てることとなる。
十分にテストされ、継続的に統合され、頻繁にデプロイされるコードと環境は、予期せぬ本番の問題と停止の頻度、関連する時間外の夜間や週末の作業を最小限に抑える。
XPの教義は、今日必要なものだけをプログラミングし、それをできるだけシンプルに実装することを推奨しているため、時には、これによってシステムが行き詰ることがある。
この症状の一つは、二重 (または複数の) メンテナンスの必要性である: 機能の変更は、同じ(または類似した)複数のコピーされたコードへの変更を要求し始める。
別の症状として、コードのある部分の変更が他の多くに影響を与えることである。
XPの教義によると、これが発症するのは、システムが、アーキテクチャを変更してコードをリファクタリングし、よりシンプルで汎用的にするように指示しているのだそうである。
XP内では、「顧客」は請求書を支払う人ではなく、システムを実際に使用する人である。
XPでは、顧客は常に手元にいて、質問に対応できるようにしておくべきだと述べている。例えば、財務管理システムを開発するチームには財務管理者が含まれるべきである。