エクストリーム・プログラミング プラクティス
たとえば、週に40時間で会議に5時間が費やされるのであれば、これは35時間以下になる。
バランスをとる: チーム内のすべてのプログラマーにタスクが割り当てられたら、タスクの推定時間と負荷率を比較される。その後、プログラマー間でタスクが調整される。あるプログラマーがオーバーコミットしている場合、他のプログラマーが彼のタスクの一部を引き継ぐ必要がある。その逆も同様である。
ステアリングフェーズ
タスクの実装は、イテレーションのステアリングフェーズで行われる。
タスクカードを取る: プログラマーは、自分がコミットしたタスクのうちの1つのタスクカードを取る。
パートナーを探す: プログラマーは他のプログラマと一緒にタスクを実装する。これについてはペアプログラミングのプラクティスで詳しく説明する。
タスクの設計: 必要に応じて、プログラマーはタスクの機能を設計する。
テスト駆動開発(TDD)を用いてタスクを実装する(以下を参照)。
機能テストの実行: 機能テスト(関連するユーザーストーリーとタスクカードの要件に基づいた)が実行される。
スコープの選択: 次のリリースで完了されうるユーザーストーリーを選択する。ユーザーストーリーに基づいてリリース日が決定される。
価値でのソート
ビジネス側は、ユーザーストーリーをビジネス価値でソートする。それらは3つの山に整理される:
クリティカル: それがないとシステムが機能できない、または意味がないストーリー。
重要なビジネス価値(英語版): 高いビジネス価値を持つクリティカルでないユーザーストーリー。
あってよかった: 高いビジネス価値を持たないユーザーストーリー。
リスクでのソート
開発側は、ユーザーストーリーをリスク順にソートする。こちらも3つの山で分類する:低、中、高リスクのユーザーストーリー。以下は、このアプローチの一例:
リスク指標の決定: 各ユーザーストーリーに、次の各要素について0から2のインデックスを付ける: 完全性 (我々はストーリーの詳細をすべて知っているか?) 完全 (0) 不完全 (1) 不明 (2) 変動性(変化する可能性があるか? 低い (0) 中間 (1) 高い (2) 複雑さ(どのくらい作りにくいか?) 単純(0) 標準的 (1) 複雑 (2)
すべてのインデックスがユーザーストーリーに追加されたら、ユーザーストーリーに低(0–1)、中(2–4)、または高(5–6)のリスク指標が割り当てられる。
ステアリングフェーズ
ステアリングフェーズの中で、プログラマーとビジネス側はプロセスの「舵取り」をすることができる。つまり、変更を加えることができる。個々のユーザーストーリーや、さまざまなユーザーストーリーの相対的な優先順位が変更される場合がある: 見積もりが間違っているかもしれない。これは、それに応じて計画を調整するチャンスである。