アジャイルのベロシティの解説。イテレーションごとに完了したポイント、平均の取り方、リリース日の予測への使い方、よくある誤用、そして East Agile Tracker での計算方法と計画への使い方。
ベロシティ は、チームが 1 回のイテレーションで完了する作業量で、ストーリーポイント で測ります。2 週間のイテレーションで 5、3、2、2 ポイントのストーリーを終えたなら、そのイテレーションのベロシティは 12 です。
ベロシティは観測であり、目標ではありません。その役割は、次の計画を現実的なものにすることです。
ベロシティの計算方法
Section titled “ベロシティの計算方法”- 何を 完了 とみなすかを決めます。たとえば、プロダクトオーナーに受け入れられた時点です。その状態に達したストーリーだけが数えられ、途中まで終えた作業は一切数えられません。
- 各イテレーションで完了したストーリーのポイントを合計します。
- 直近数回のイテレーションの平均を取ります。3〜5 イテレーションの移動平均を使うと、休暇、病欠、一度きりの想定外の出来事がならされます。
XP はこれを 「昨日の天気」 と呼びます。次のイテレーションでどれだけこなせるかの最良の推測は、直近数回でどれだけこなしたかです。
ベロシティの用途
Section titled “ベロシティの用途”- 次のイテレーションのサイズを決める。 チームはベロシティとほぼ同じだけのポイントを計画するので、計画が実際に届けられる量と一致します。
- 予測する。 リリースに残っているポイントをベロシティで割ると、残りのイテレーション数が出ます。日付は計算で求められるものになり、話し合いはスコープと日付のトレードオフになります。
- 変化に気づく。 下降傾向は、技術的負債の増加、割り込み、不明確なストーリーを示していることがあり、振り返りで取り上げる価値があります。
よくある誤用
Section titled “よくある誤用”- チーム同士を比べる。 各チームのポイントは自分たちの過去の作業に対する相対値なので、あるチームの 30 と別のチームの 15 は比べられません。
- ベロシティの目標を設定する。 数値を上げる圧力は、デリバリーを速めるよりも見積もりを膨らませる方向に働きがちです。
- 未完了の作業を数える。 部分的に加点すると、ベロシティはチームが届けられる量を過大に示すことになります。
East Agile Tracker での扱い
Section titled “East Agile Tracker での扱い”- ベロシティは履歴から計算されます。 ストーリーは、プロジェクトの 完了状態(Finished、Delivered、Accepted のいずれか。プロジェクトごとに選択)に達した時点で数えられます。ベロシティ を参照してください。
- 平均の取り方は設定できます: 直近 3、5、10 イテレーション、または手動の値です。新規プロジェクトは、履歴ができるまで初期ベロシティから始まります。マネージャーは、Current 列のヘッダーから単一のイテレーションのベロシティを上書きすることもできます。
- ベロシティがイテレーションを計画します。 Backlog はベロシティから今後のイテレーションを投影し、auto-plan iterations がオンのとき、現在のイテレーションはベロシティまで埋まり、それ以上は埋まりません。イテレーションを計画する を参照してください。
- 傾向は Metrics ページにあります。 バーンダウンや、イテレーション間で繰り越されたストーリーと並んで表示されます。メトリクス を参照してください。
- ストーリーポイントとは? — ベロシティを測る単位。
- ユーザーストーリーとイテレーション計画 — ベロシティを使ったイテレーションの計画。
- eXtreme Programming — 「昨日の天気」の由来。