ベロシティを開発組織のKPIとするのはアンチパターン
数字を目標にすると、正しいプロセスを見失う
どれだけ価値を提供できたか、を目標にする
X日で実装できた！よりもユーザーの声がどのように変わったかを計測すると、同じ目的を共有できる
@k1_c_: 「ベロシティ」ってスクラムに組み込まれている概念だとよく思われてるっぽいけど、スクラムガイドに「ベロシティ」なんて書いてないし、元々はXPがオリジンなんですよね @k1_c_: 「XPの人たちもベロシティの発案については後悔している」のソースが見つからない だれかしりませんか
@komitsubo: 以前のプロジェクトで隙間問題を拾ってくれた人が急に拾わなくなって理由を聞いたら”このプロジェクトでは担当で発生障害数見積りがあって、隙間の障害を拾ったら自分に計上され、結果どうして障害が予想よりも多いんだと上司が上から怒られ、そして自分も怒られたから”と聞いてドン引きした事がある。 @ryuzee: そもそもプロダクトそのものに注目して、成果がでていたらベロシティを気にすることなんてそんなにないんだよな。つまりベロシティに注目しちゃうのは、本当に測りたいものから目を背けて、分かりやすい数字でお茶を濁そうとしている可能性があるってことな @77web: エンジニアに対してアウトカム評価をするなら「俺のいう通りのものを作れ、ただしお前らの評価はそれが売れたかどうかで決める」はサイコパスすぎると思っていて、エンジニアのオーナーシップの話はここから考え始めた。