BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース チームの改善のためにベロシティを計測することへの懸念

チームの改善のためにベロシティを計測することへの懸念

原文(投稿日:2014/04/03)へのリンク

アジャイルチームは自分たちのスプリントごとのベロシティを計測する。そうすることで彼らは、計画をたて、進捗をトラッキングし、プロダクトオーナーにプロダクトのリリースプランを作るための手がかりを与えることができるようになる。チームは、自らを改善したいときに、ベロシティのデータを利用できるのだろうか? 何人かの著者がベロシティについて書いており、チームの生産性を高めることを目的としてベロシティを計測することについての懸念を伝えている。

Catia Oliveira 氏はScrum AllianceのWebサイトで「チームとプロダクトに役立つベロシティの計測と活用のしかた」について書いた。彼女は、ベロシティの計測がチームにとってどんな役に立つのかについて、このようにまとめている。

自分たちのベロシティがわかれば、こんなことがわかるようになるでしょう。

  • どれだけの価値を今までに届けたか(ストーリーポイントや完成したユーザーストーリーでいうと)
  • いつプロダクトバックログに含まれるすべてのユーザーストーリーを届けられるのか
  • ストーリーポイント何ポイント分をある期日までに届けられるか

また、彼女はベロシティに影響する可能性のある要因をリストアップしている。

  • 道路封鎖 -- 障害、インペディメントとも
  • 燃料 -- モチベーション、私たちを駆り立てるもの
  • ドライバーの経験 -- 開発者の知識、技能、適性
  • 車のコンディション -- 開発環境
  • 視界 -- プロジェクトの透明性
  • 方向 -- プロジェクトの目標
  • 交通規則/運転規則 -- プロセス
  • 目的地 -- プロダクト

George Dinwiddie氏は「ベロシティをトラッキングする」という記事をブログに書いた。彼はチームによるベロシティの計測は、自分たちが今どんな風にやっているかを知る手がかりになるので便利だと説明している。しかし生産性を測ることを目的としてベロシティデータを利用することについてはこのように警告している。

ベロシティについて言えば、これは生産性の相似形ではありません。そう思ってしまう罠に陥るのは簡単です。“28ポイントというのは、あるスプリントで私たちが完成させることのできる仕事量です。” ただし、28ポイントは単なる仕事量ではありません。これは見積りです。(中略)私たちはストーリーポイントをもっと大きく見積もるとか、あるいは作業をもっと小さなストーリーにスライスすることで(訳注:ストーリーポイントでなくストーリーの数で見積もる場合)、簡単に操作することができるのです。これは実に簡単で、私たちは知らず知らず、あるいまた意図的にそうすることができてしまいます。

(中略)ベロシティは生産性をざっくりトラッキングできるかもしれませんが、これを使ってさらに生産性を上げようとした途端に、私たちにはトラッキングできないものになるのです。

2012年、Tim Ottinger氏は「アジャイルチームのベロシティにまつわる14個の奇妙な見解」という記事をブログに書き、ベロシティについて彼がよく聞かれる質問とそれに対する答えをリストにした。彼はまず、ベロシティの計測は可能でも、それを直接コントロールすることはできない、と述べている。

ベロシティは計測器であって調整ノブではありません。ベロシティを単に上げるということはできないのです。努力することによって計測器を壊すことができるだけです。

チームのパフォーマンスが上がったことと計測されたベロシティとの関連は複雑になりうる、とTim氏は説明している。

チームが改善すれば、ベロシティは上がりストーリーポイントはだいたい同じままか、もしくはベロシティは概ね同じままストーリーに振られる見積りが減るかになるでしょう。しかし、ある程度はどちらも同時に起きるというのが非常によくあることです。チームをまたいでベロシティを比較してはいけないという理由の1つはこれです(他にもたくさんの理由はあるでしょうけど)。

Jeremy Jarrell氏はブログ記事「ベロシティはゴールではない」の中で、アジャイルチームにとって予測可能なベロシティを持つことがなぜ重要となり得るのかを説明している。

高いベロシティを連続して叩きだすチームは、多くの場合、組織にとって価値があるものとして扱われます。しかしこういったチームは、あるスプリントで高いベロシティを叩きだしたかと思えば次のスプリントでは急降下するといったように不安定になりがちで、最初に思ったより価値は高くないかもしれないのです。

その理由は、ベロシティ予測可能性よりも価値の高いものではないからです。私たちがアジャイルなやり方でやることの大半は、自分たちのチームの予測可能性を高める目的で実行されます。チームの予測可能性が高まれば高まるほど、将来に向けてより効果的に計画ができるようになるのです。これによって私たちはより賢くリスクを取ることができ、また同時に、与えられた時間枠の中で届けられそうなものをベースにした、より現実的な戦略を練ることができるようにもなるのです。

Jeremy氏は、チームがベロシティを高めつつ予測可能性をもっと上げたい時の解決策を提示している。

このことは、チームがベロシティを生み出すよう努力してはならないということを意味しているのでしょうか? まったく違います。チームのベロシティを高めることが目的であってはならないという意味です。それよりもチームは、ベロシティを上げるために必要な素質そのものにフォーカスすべきです。エンジニアリングプロセスを継続的に改善するとか、リスクを系統的に識別し追い出すといったプラクティスは、自然とベロシティを上げることになるのです。

Nathan Dintenfass氏はブログ記事「アジャイルの用語は破綻している」の中で、チームの生産性を上げるためにベロシティデータを使ったときのリスクについて言及している。

生産性の定量化が可能なものさしとしてのベロシティ。これは、ほとんどのチームがそのやり方を変えるときに設定して始めるゴールそのものに悪影響を与えます。マネージャーたちはベロシティを上げたいがために、より多くのストーリーポイントを"done"にすればボーナスを与えるといったようなやり方をしがちです。こういった言動はまったくもって見当違いです。チームがポイントを水増ししたりする理由を与えられたり、あるいは逆に、数字自体が目的で合計をより大きく出すことを考えついた場合は、インセンティブは明らかに腐敗しているからです。私たちが本当に欲しいものは、与えられたサイクルの中で"done"にできるものを、正確に、かつ自信を持ってきっちり読み取るための、相対的な難しさについての正直な見積りです。ベロシティがまっとうな見積り(ひいてはコミットメント)を達成するための手段ではない何かに成り下がってしまったら、良いソフトウェアの生産には最終的に悪い影響を与えるのです。

Tim Ottinger氏は「アジャイルチームのベロシティにまつわる見解」の中でこう結論を下している。

ベロシティに関する最大の問題は、ベロシティを理解していないことから生じるのでも、ベロシティを生産性や多忙さの一般的な指標として扱うことから生じるのでもありません。その秘訣は、そんなに深刻的に捉えないこと、そして、ベロシティを上げようとするのではなく仕事の仕組みや組織を改善することなのです。

この記事に星をつける

おすすめ度
スタイル

BT