Grooves開発ブログスマートフォン用の表示で見るGrooves開発ブログ2015-10-20ベロシティを目標にする危険性について学んだことをアジャイルサムライ風に振り返ってみたこんにちは、Forkwell事業部の中の人です。開発現場で起きたエピソードについてご紹介します。きっかけはあるメンバーの一言でした。「複数メンバーの加入から1ヶ月以上がたった、ベロシティもかなり安定してきた。ような数字を書き加えました。目先のポイントを増やすためにとりあえずリリースして残タスクを先に積む事案が発生、後々の作業が滞る目先のポイントを増やすために、レビューが甘くなり、バグが増えるポイントの見積もりが甘くなり、見積もり結果が信頼できなくなるつまり、ベロシティを上げようとする行為が結果的に不正確なベロシティを招き、正確な見積もりができなくなる事態を招く可能性があるということでした。教えを請うことにしました。ベロシティをあげることを目的にするのではなく、それを落としている障害を取り除く発想が必要じゃ。アジャイルでは、チームメンバーは常に全力で取り組んでいるように扱うし、実際にお前らは自主的に勉強し、成長しようとしておる。はっぱをかけて全力を引き出すという発想自体がアジャイル思想にマッチしない。メンバーが全力で頑張っている以上、できることは障害を取り除くことである。ありがとうございます。自分たちのベロシティを下げているものがないか、洗い出すようにします。その上で、取り除けるのもがあればそれをT(Try)として取り組むようにします。加えて、コスト・納期がどれだけ短縮できるかを考えるより、今までと同じ期間で新しくできるようになったことがどれだけか、というのを考えることが効果的じゃ。ありがとうございます。今までと同じ期間で新しくできるようになったことは何かを、洗い出すようにします。そのKの蓄積が、自分たちの成長だと考えます。一方で、ベロシティ以外の指標で、我々がビジネスサイドにも、しっかりやっていることを伝える方法はないでしょうか。ベロシティは成果ではない。成果とはFeature(顧客へ届けた価値)のことだ。バグの改善やリファクタリングは成果として示せないのでしょうか。バグは、過去に書いたものが間違っていただけで、それを直したからといって成果とはいえない。どれだけ業務をこなしたかを伝えるにはいいかもしれない。ありがとうございます。どんな価値を顧客に提供できたかを、ポストイットを貼ることで報告するようにいたします。いかがでしたでしょうか。今回の事例が、皆さんの現場の参考になれば幸いです。11:46ベロシティを目標にする危険性について学んだことをアジャイルサムライ風に振り返ってみたTweet関連記事2017-12-22ユーザーニーズを把握する「UXリサーチ集中講座」に参加しましたみなさまこんにちは。