Velocity計測の注意

Velocityの計測について@ryuzeeさんの記事が参考になるのでリンクしておく。

【元ネタ】
[Scrum]ベロシティに対する誤解 | Ryuzee.com

Redmineでアジャイルチームのスピードやパワーを見える化する | 世界のdaipresents

工数見積もりで陥りやすい罠: プログラマの思索

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

Velocityの本来の定義は、実際に納品できたストーリーポイントの合計値。
Velocityの単位が人日ではなくストーリーポイントという開発規模を表す単位である点が重要。
しかも、ストーリーポイントはファンクションポイントとは違って、開発規模を相対比較する。
だから、イテレーションを実施するたびにチームが成長して、アウトプットの規模が大きくなったとしても、規模を相対比較しているから誤差はあまり生じない。
人日で計測する場合、実績のコストと実際の出来高の単位が混同されてしまう。
そのため、本来作った開発規模はどれだけだったのか、過去のデータと狂ってしまう。

また、ストーリーポイントで計測するという意味は、顧客がそのストーリーを作っていることから、ビジネス要求そのものに対応している。
つまり、LOCのようなコーディング量ではなく、ビジネス要求そのものの規模に対応している。
だから、顧客の観点と開発者の観点のシステム規模で認識相違が起きにくい。

また、他チームとVelocityを比較する意味がないという指摘も重要。
ストーリーポイントは相対比較だから、基準値は各チームで異なるのが普通だし、基準値が異なっていれば各チームのVelocityを比較しても意味がない。
つまり、Velocityはそれぞれのプロジェクトだけでしか意味を持たない。
だが、一プロジェクトのVelocityを計測し続けていれば、そのチームの開発ペースが分かるし、チームに見合った仕事量がどれだけなのか、も把握できる。

Velocityの概念はXPのプラクティス「週40時間労働」「持続可能な開発ペース」にもつながる。
色々考えてみる。