チームは加速するのか～Velocityの使い方 #agilesamurai

先日、アジャイルサムライ渋谷道場に行ってきた。
Velocityについて議論しているとき、速度という概念があるなら加速度みたいなものはあるのか？という質問があった。
そこから考えて、@daipresentsさんのBlogの意味がやっと分かったのでメモ。
間違っていたら後で直す。
※追記：Focus FactorやTargeted value Increaseの定義も解釈も間違っているので、後日直す。

【元ネタ】
Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents

XP with Kanban instead of Scrum | Zsolt Fabo'k's Page

InfoQ: ストーリーポイントは複雑さや時間と関係があるか？

Spring of Scrum

View more presentations from mohsinhijazee

【1】Velocityとは、1スプリントでチームが開発できる開発規模(ストーリーポイント)を表している。

渋谷道場でScrumを実践している人は、1週間で12ポイントぐらいのVelocityですね、と言っていた。
1チーム4人とすれば、1週間で3ポイント/人の開発速度なのだろう。

見積もりには、規模見積もりと工数見積もりの2種類がある。
Scrumは規模見積もりと工数見積もりの2種類を計画作りのプロセスに入れて、スプリント終了時に規模見積もりを工数見積もりへ変換して、補正係数(Velocity)を得る仕組みがある。

ScrumのVelocityが従来のSW開発の見積もりよりも優れている点は、定期的に見積もり結果を評価して、規模見積もりを工数見積もりにすぐに変換できるために精度を上げることが可能なことだと思う。
見積もりの精度がスプリントを経るごとに上がれば、計画作りも楽になる。
詳細は下記に書いた。

Scrumの見積りと計画づくりは何故優れているのか？: プログラマの思索

従来開発では、FP法でいくら厳密に開発規模を見積もっても、実際にどれだけの工数がかかるのか、を知るのは難しい。
COCOMO2を参考にして、規模見積もりを工数見積もりへ変換したとしても、チームのメンバーの能力、開発言語や開発環境などの要因が考慮されていないから、見積りの正当性がない。見積りの評価は、1年後の本番リリースで初めて分かるから、規模見積もりがすぐに役立たない。

InfoQ: ストーリーポイントは複雑さや時間と関係があるか？では、見積もりのゴールについて書いている。

(前略)
見積りのゴールは、「いつ完了するんですか？」や「期日までにどれくらいの機能ができるんですか？」という疑問に答えることです。もしこれが正しければ、どんな単位で見積ろうとも、どんなアプローチをとろうとも、それは時間に関係がある必要があります。
(後略)

見積もりの目的は、いつまでに完了するのか、期限までにどれくらいの機能をリリースできるのか、をおおよそに知りたいこと。
見積もり作業そのものにあまり時間がかかっても意味が無い。
だから、Scrumではストーリーポイントでラフに計測して、PDCAサイクルを早く回して検証して精度を高めていくことを重視しているのだろう。

【2】@daipresentsさんのBlogによれば、各スプリントのVelocityを蓄積すれば、チームの成長度合いを測定できるようだ。
Scrumの資料を漁ってみると、Focus FactorとTarget Value Increaseというメトリクスがある。

(2-1) Focus Factor = 実績のベロシティ / 予想のベロシティ

※注意：@daipresentsさんのBlogでは、分母と分子が逆になっているが、多分、@daipresentsさんの間違いだと思う。

Focus Factorは、予想と実績のVelocityの割合を指す。「達成度」みたいなものだろう。
Focus Factor(FF)の定義から、下記が導かれる。

FF < 1 →実績のVelocityが予定よりも悪いので、開発パフォーマンスが悪い
FF > 1 →実績のVelocityが予定よりも良いので、開発パフォーマンスが良い

個人的には、PMBOKのEVMのCPI(コストパフォーマンス)ないしCR(危険度指数)に似ていると思う。
だから、FFを時系列にグラフ化すれば、チームの成長度合いをより見える化できるだろう。

普通は、初期のFFは数値が低く、スプリントの回数を多く経験するほど、FFは1に近づいて安定するだろうと思う。

(2-2) Target Value Increase = 実績のベロシティ / Sprint1のベロシティ

Targeted Value Increaseは、初期のスプリントからチームがどれだけ成長しているかを示す。
普通の新規開発案件ならば、初めての顧客、初めての技術、初めての開発環境作りなどのリスク要因が大きいから、初期のスプリントの成果物量(出来高)は少ないだろう。
そして、スプリントを経るごとに、顧客の要望の癖が分かったり、フレームワークの癖をメンバーが理解してコーディング量が増えたり、開発環境を安定して使えるようになって、成果物量(出来高)も増えていくだろう。

Targeted Value Increase(TVI)の定義から、下記が導かれる。

TVI < 1 →実績のVelocityがSprint1のベロシティよりも悪いので、開発パフォーマンスが悪い
TVI > 1 →実績のVelocityがSprint1のベロシティよりも良いので、開発パフォーマンスが良い

普通に考えると、最初から数回のスプリントはTVIが徐々に増加して、一定期間後のスプリントになるとTVIは安定するのだろうと推測する。

(2-3) Estimated Velocity = Velocity x Focus Factor

次回スプリントの予定のVelocityは、平均値のVelocityにFocus Factorを乗算したもので出力される。

FFの定義からして、FF < 1ならVelocityは減るし、FF > 1 ならVelocityは増える。
つまり、平均値のVelocityに補正係数を加味して、直近の開発パフォーマンスを反映させている。
次回スプリントのVelocityは、直近の開発パフォーマンスを引きずっているはずだろうから、その分、Velocityの精度は上がり、計画を立てやすくなるだろう。

【3】Focus FactorやTarget Value Increaseの使い道としては、@daipresentsさんのBlogに書かれている通り、Velocityの傾向からチームの開発の傾向が分かることだと思う。

例えば、「過去最高のVelocity」「過去最悪のVelocity」には必ず何らかの原因がある。メンバーが休んだり、初めての技術を使ったり、顧客が今までにない改善要望を出してきた、などの場合があるだろう。
「GWのように祝日の多い週のVelocity」は、普通のスプリントよりも期間が短いのだから、Velocityも期間が短い分に比例して小さくなるはず。
調べてみると色々気づきが出てくると思う。

ScrumのFocus FactorやTarget Value Increaseについてあれこれ考察してみると、PMBOKのEVMに出てくるCPI、SPIの概念に似ているなあ、と思う。
CPI、SPIも、1よりも小さいならパフォーマンスが悪いし、1よりも大きいならパフォーマンスが良い。
PMBOKのEVMは、規模見積もりは無く工数見積もりだけだが、EV(出来高工数)という概念によって、EVを成果物量とみなして、各種のメトリクスを出力して、コストやスケジュールを予測する。

だが、Scrumの方が、見積もりの複雑さをストーリーポイントという仮定された単位で割り切って、より簡単にしているのが面白い。

これらの概念を理解して実運用されている@daipresentsさんはすごいなあ、と思ったりする。
色々考えてみる。