AEP読書会 第十六章「ベロシティの見積もり」

第十六章「ベロシティの見積もり」 - AEP読書会 | Doorkeeper

2015年1回目でした。今回はGMOグループからも何人か来ていて、これも藤村さんのリクルーティング活動のおかげか!? と、私もがんばろうと思いを新たにしました。

今回のテーマの「ベロシティ」ですが、私自身あまりうまく使えないなーと悩んでいたところ、ディスカッションの中でいいヒントを貰えました。

ベロシティ上げて欲しい人、安定させたいチーム

PO(やマネージャ)としては当然できることが多くなるほうがいいので「ベロシティを上げるにはどうしたらいいか」という話になります。

一方で、開発チームとしては中期の見通しを立てるために「ベロシティを安定させたい」と思っています。

ここに歪みがあって、こじれてしまうと見せ掛けのベロシティ(完了条件をごまかしたり、過剰見積をしてベロシティが上がったように見せる)にチームが走ってしまったら元も子もないので、今までは「ベロシティは安定させるもの」というスタンスをとってきました。

ベロシティはチームの限界近くまで上がって安定する

ディスカッションの中では、ベロシティは無限に上がり続けることはないが、チームの限界近くまで上げて安定させるべき、という話がでてきました。

そう聞くと当然のことなんですが、回りの状況や、私自身が開発チームに近い場所にいるせいもあって「今だって一生懸命やってるよ」という気持ちが強かったんですよね。

でも、開発チームが工夫や調整、仕組みの改善を精一杯やってるか？って言われると、過去のプロジェクトを見ても胸をはって言えるプロジェクトってあんまりないし、そういう面では甘えもあったのかな、って。

スクラムマスターの役割

Scrumの根っこ というスライドに「責任から逃さないのがSM」という言葉があって、こういう表現の仕方は考えたことなかったな、とハッとしたのでした。

「ベロシティを上げろ」という人には「安定させるものなんです」、開発チームには「どうやったらもっと早く進めるか」という二枚舌でいくのがいいんだなという自身が得られたので、今回もよい読書会でした。