はじめに

DDDの権威である松岡幸一郎さんの「アジャイルのリリース計画教えます。ベロシティを使った中期計画方法」という動画を見たので感想とその内容をアウトプットしようの記事です。

該当Youtubeは以下

記事の内容は以下のリンクにございました

アジャイルプロジェクトにおける計画

悩みますよね

例えばスクラムでは…

スプリント単位の計画はあっても
中期(1ヶ月以上)の計画について明確に定義されていない

でも、

中期計画は往々にして求められる

どうすれば…！

今日は中期計画の全体像を話します

細かい話はそれぞれ話すと長くなる

ストーリーポイントの設定やベロシティの安定化方法など

まず全体像を把握することがめちゃくちゃ重要

全体像を把握すると、逆算して個別の論点で良い意思決定ができる

各スプリントの計画はスプリントプランニング（名前そのまま）でチームメンバー全員で
決めていくという方針があるので迷うことはないが、
上長への報告など、中期的な計画を立てる上でどのように立てればいいかについて確かに
うまくできる自信がないなあ

全体像

結論

①中期開発のストーリーポイント(以下SP)を出す

②ベロシティ(1スプリントあたりのSP)を出す

~~③合計SP / ベロシティ = かかるスプリント数と計算する~~

③合計SP * 統計的バッファ率 / ベロシティ = かかるスプリント数
と計算する

これがポイント

統計的バッファ率がキモです。

これをしないと80％炎上します。

80%という数値は適当です。m(_ _)m

今日はこれについて解説していきます。

ストーリーポイントを使った計画を立てた経験ある
ただ、今回これくらいだから次スプリントも同じくらいかなと思うと違うから
（むしろ毎回これを改善していく必要があると思っている）
それを使ってうまく中期計画を立てるには 統計的バッファ率 というのが大事になるんだろう

用語

ストーリーポイント(以下SP)

これは相対的な「サイズ感」

以下の3つを総合的に考慮

量

複雑度

不確実性

名前はなんでもよい

「かかる日数」ではないのが重要

SP3の開発を、
ある人がやれば1日で終わるが、別の人だと2日かかることがある

これは、

3キロメートルの道のりを、
ある人が走れば15分で走れるが、別の人だと30分かかるのと同じ

つまり

距離の単位は人によって変わらない、
ストーリーポイントも人によってかわらない

だから見積りに使いやすい

ベロシティ

これはなにか

「1スプリントで消化できるストーリーポイント」

ブレを吸収するために、3週の平均を使用する

余談

Art Of Agile Development 2ndでは「キャパシティ」という表現をしていた

「ベロシティ(速度)」と言われると、
アクセルを踏めばすぐに加速できるようなものに感じる

「キャパシティ(容量)」と言われると、
車の構造をカスタムしないといけないと上がらないようなものに感じる

性質としては後者に近い

ペダルを踏むだけで速度が上がれば苦労はないのよ

ストーリーポイント、ベロシティの運用はかなり色々なコツがありますが、
ここでは省略します

中期計画の立て方

前提条件

必要な条件

ストーリーポイントの粒度がある程度安定すること

ベロシティがある程度安定すること

これがなかなか難しい

が、今回はそこはクリアした前提での全体像

計画の流れ

①中期開発のストーリーポイント(以下SP)を出す

合計50SP

②ベロシティを出す

10SP / 1スプリント

③(合計SP * (100% + **統計的バッファ率**) / ベロシティ = かかるスプリント数
と計算する

バッファを積んだ合計SP
50 * (100% + 70%) = 85SP

かかるスプリント数
85/10 = 8.5スプリント

統計的バッファ率の考え方

内訳を明示する

SP自然増(見積り誤差)

例：SP1だと見積もっていたが、あとからSP2に変更した場合の増加分

要件追加

スプリントレビューなどから必要と判断されて追加された機能分

結合テスト

もちろん最初の見積りに入っていればこの枠で計算しなくてOK

テスト観点を整理しないとテストにかかる正確な見積もりはできないが、
計画に必要な精度での概算見積もりをする

ログラス社の例: バッファ率70%

SP自然増: 30%

要件追加: 20%

結合テスト: 20%

内訳を明示することで、納得できるし調整しやすくなる

納得度

「50SPから70%の35SPも増えると言われると怪しい気がするが、
　20%分の10SPぐらいは追加要件ありそうな気はする」

調整例：

「要件追加は少なそうだからここは比率は下げておこう」

「複雑な機能だからテストの比率を上げておこう」

このバッファ率は、統計的に判断することが重要

プロジェクト運営の中で各SP増加内訳を記録し、次回に活かす

例えば、バッファ率30%としていたが…

過去の似たようなプロジェクトでは80%増加していた

じゃあ、ほんとに30%に収まるの？は根拠が必要

統計に基づいて判断すれば、自信が持てる

根拠なく70%バッファを積みます！は勇気が必要

過去実績から判断すれば、それはそれは統計的事実。胸を張って言える。

初見70%のバッファを詰みますと言われるとなかなかGOを出しづらいけど
複数の要素があってその根拠をもとにバッファがこれくらいあるよ
というように聞くと無茶苦茶納得感があるな...と感じた。
そのプロジェクトの人数やスキル、特性からSP自然増などは変わりそうだな〜と思った。
ストーリーポイント高くつけがち低くつけがち見たいなところもはじめはあるので
複数要因から中期計画を立てられると良いなと思う。

FAQ

見積精度を上げればバッファ率を下げられるのでは？

もちろんYes。ただそのために必要な時間は？

1,2時間で精度が上がるならいいよね

1,2週間ぐらい詳細に詰めなければらないのであれば？

どれくらいの精度が必要か

それは、各自で判断する必要がある

実験せずにちょうど良い感覚を掴むのは難しい

初めてのプロジェクトの時はどうすればいい？

まず、小さいプロジェクト(長くても1ヶ月ぐらい)で試しましょう

確実さが必要なら、多めのバッファ率(100％ぐらい)を積んでおくと安全

特に、チーム立ち上げ初期だとSPの粒度もまちまち、
ベロシティも安定しないので楽観的な推測はまず外れます

そんなに積むのが抵抗ある場合

小さめのバッファ率にして「転んで覚える」スタンス

成功したらハッピー、
ダメだったらバッファ率を積む重要性を体感できる。

「なんか雑じゃない？こんな感じでいいの？」

そもそもアジャイルの見積もりに関してのスタンスは、次の動画で解説します

何かを決めるには何事にも根拠が必要だな...と当たり前のことを感じた
そしてそれを振り返ることも大事、次に活かそう

さいごに

直近で１ヶ月程度のプロジェクトが始まったばかりなので
まずバッファ積もう...という気持ちになりました。
アジャイルはとにかくトライアンドエラーの繰り返し
小さな積み重ねの経験を大事にしていきたいと思います。