［アジャイル開発］ベロシティについて👀
Hideyuki Fujihara『スクラムブートキャンプ』を読んで気になった部分をまとめてみようと思いました。
以下、そのまとめです。
Hideyuki Fujiharaベロシティとは、
ある開発チームが1回のスプリントの中で消化する(doneにする)ことが出来たストーリーポイント(SPとも言う)の合計数のことであり、
開発スピードを計測するために使われる。
Hideyuki Fujiharaそして、直近の数スプリント分でそれを抽出して推移を見ることで、
現状の開発チームの体制でどれだけ出来そうかを算出し、
それに基づき計画の修正を行う。
アジャイル開発においては計画はあくまでも推測値であり、
（ウォーターフォール開発でも同様でしょうが）
唯一の具体的なものであるスプリントごとの成果物とそのSPをベースにして考え、
計画の方を修正する、と言ったフローを取る。
計画に対する帳尻合わせをする訳ではない。
Hideyuki Fujihara例えばある開発チームのスプリントは2週間として、
その中でのベロシティが10とする。
ユーザー、または依頼主が欲しいもののSPの合計値が200とした場合、
完成には20スプリント、上記の前提に基づけば40週間を要することが推測できる。
仮に納期が半年後であるとすれば、
この内完成出来るのは約13スプリント分の完成物になる、ということも推測できる。
Hideyuki Fujiharaここで重要なことは、『納期から逆算してベロシティを算出しない』ということである。
ベロシティもまた予測値であり、かつ参考値であるためである。
『人月の神話』にも通じるものと思われる。
Hideyuki Fujiharaまた無理なスケジュールを組んでしまうことで開発チームが疲弊してしまい、品質が劣化することを避けるためであり、
現実的な計画を立てて開発チームの生産性を高めるためである。
Hideyuki Fujiharaつまり開発チームの状態を正しく把握して、
目標に対してどうするのか、目標の修正も含めて検討するための概念、ないしは手段として存在するのであり、
それ自体が目的になったり、それに主眼が置かれていたり、
他者と比較したり、
はたまた評価指標にするべきものでもない。
そもそもその為に存在するものでもなく、特性上その為に使える概念、ツールでもないからだ。
それでもやれば、それは火を見るより明らかだ。
Hideyuki Fujiharaただこれは納期を完全に無視して良いとか、
ずるずると引き延ばし続けて良いと言っている訳ではない。
寧ろその逆だと思われる。
(ただし、開発チームの状態を無視したものになっていないか、これには意識を向け続けて、レビューを入れて修正していくべきではあると思われる)
背景を安易に人月、工数の解決に帰結させないこと。
ハードワークや精神論に帰結させないこと。
開発チーム内で何がボトルネックになっていて、
どんな困り事があり、
どうすればより良く働けるようになり生産性が上がるのか etc...。
こう言ったことにフィーチャーして、
そこでベロシティを用い、
その数字を安定化させることに意識を向ける、
(上げることも大切だが、それよりも安定していることの方が大切)
こうすることで結果的に納期をより合理的に、より安全に、より確実に満たせるようになる。
『ベロシティは納期の為の手段』とは、
詰まる所、こういう意味だと思われる。