これが良い話だなと思ったので感想メモ。
「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ？」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象
「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば
- 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない（例えばコードのメンテナンス品質が思ったより低い）時も、上げる意識だと終わりにしてしまいたくなる
- 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち
- 何となく、悲観方向で見積もりをつけてしまう
そのため自分は、「安定させた上で、その後は価値提供の量および価値提供のスピード（フロー効率）を意識する」ようにしている。
ただし、以下のコメントもめちゃくちゃ分かる。
チームのベロシティを上げる vs. 安定させる - yigarashiのブログb.hatena.ne.jp安定を優先すべきと頭ではわかっているが、数値的に上がっているのを見てモチベーションにつなげたいときがある
2022/04/26 11:28
この観点に関しては、以下のように考えている。
- 成功体験を積むために、一番気軽な「ベロシティが上がった！」という体験をしたいということがある。つまりチームが理解しやすくするために敢えてベロシティに着目する。
- その場合も、少なくとも先導する側は、「安定してユーザーに価値提供ができるチームを作る」「最速で価値検証ができるチーム」など、最終的な目標への意識を忘れないようにしたい
- かつ、ベロシティに着目することを徐々にやめられるように、少しずつアジャイルの知識をチームに浸透させることが必要だと思う
- なんだけど、「ベロシティあげよう」使ってしまいがちなんだよな〜〜〜〜〜〜〜〜（自戒）
