良いベロシティ

作者 Chris Sims , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2009年5月31日

セクション

プロセス/プラクティス

トピック

Agileの採用 ,

XP ,

アジャイル技術 ,

Best Practices ,

Agile in the Enterprise ,

Pair Programming ,

Agile ,

プログラミング

共有 |

原文(投稿日：2009/5/18)へのリンク

Buddha Buck氏は、最近、Extreme Programmingのメーリングリストにおいて、2週間のイテレーションを行っている7人程のチームにとって「良い」と考えられるベロシティの範囲があるかどうかを尋ねた。Buck氏は、ベロシティが8以下の場合、チームのストーリーが大きすぎるのではないかと考えた。議論の結果、この質問の答えと、質問の裏にある別の質問が得られた。

ベロシティは、チームの今後の生産性を予測するツールとして利用される。チームが取り組むすべてのストーリーが同じ大きさの場合、それらのストーリーを実装するのに必要な作業量は、チームが各イテレーションで完了したストーリーの数を単に数えればよい。既存のチームは、各イテレーションでこれらの同じ大きさのストーリーを同じ数だけ完了する傾向があり、管理する人は、チームで分かっている能力に基づいて計画を立てられるだろう。

多くの環境において、ストーリーは同じ大きさとは限らない。だから、ストーリーは、 たいてい見積もりと呼ばれる相対的な大きさが与えられる。大きさが2のストーリーは、大きさが1のストーリーの2倍であり、大きさが3のストーリーは、大きさが1のストーリーの3倍になる。大きさが2のストーリーは、平均すれば、大きさが1のストーリーを完了する時間の2倍かかると予測するのは当然だ。これらの見積もりのことを簡単に話せるように、大きさの数は「ポイント」や「ストーリーポイント」と呼ばれる単位を指定する。つまり、5ポイントのストーリーは1ポイントのストーリーの5倍の期間がかかると言える。概して、既存のチームはイテレーション毎に同じポイントの作業を完了できるだろう。この数がチームのベロシティだ。つまり、ベロシティはチームの能力だ。ベロシティによって、各イテレーションでチームがどれだけ作業できるかを測る。

Steven E. Newton氏は、「良い」ベロシティをこのように述べた。"良いベロシティは、将来のイテレーションでどれだけの作業を終わらせられるかを予測するのに役立つものです。"

Kent Beck氏は、チームのベロシティを知ることによる別の利点を述べた。

能力を測る別の目的は、スループットを改善することです。自分の能力より少なく計画すれば、あなたができる作業よりも少ない作業しか終わりません。自分の能力よりも多く計画しても、あなたができる作業よりも少ない作業しか終わりません。

Charlie Poole氏は、次のことを読者に気付かせた。開発者は、ストーリーを実装するのに必要な作業量を考える一方で、マネージャや顧客は、ストーリーの完成によって得られる価値の量を考える。重要なのは、ストーリーの見積もりやベロシティが、そこにある作業の量や完了するまでの時間にすべて関係していることに注意することだ。

もっとも基本的な部分に関するBuddha氏の質問は回答された。しかし、メーリングリストの議論では、その中にある難解な問題に関していくつか考察が続けられた。特に、Buddha氏は、チームが取り組んでいるストーリーが大きすぎることを心配していた。議論のスレッドでは、大きなストーリーよりも小さなストーリーのほうが好まれると認めていた。

Tim Ottinger氏が、小さなストーリーは、今、実際にどれだけ作業が進んでいるかをチームとステークホルダが知るのに役立つ、たびたび参照できるマイルストーンとなることを指摘した。

明らかに、ストーリーはイテレーションより大きくなるべきではありません。イテレーション中のストーリーのうち、大きなストーリーほど完了できないリスクが大きくなります。Nポイントや0ポイントになるような状況にはなりたくないでしょう。折り返し地点でストーリーポイントの40%を「完了(done-done)」にできるとよいでしょう。

Steven Gordon氏が、いくつかの関連するガイドラインを示した。

• ストーリーが十分小さいかどうか自信がない場合、ほぼ確実に大きすぎます。
• ストーリーが小さすぎる場合、チームはストーリーを追跡するオーバーヘッドが無駄だと気付くべきです。
• ストーリーが小さすぎるために起こることは、ストーリーが大きすぎるために起こることよりも問題ではありません。だから、ストーリーが小さくて問題になるほうが良いでしょう。
• 小さすぎるストーリーがチームの最大の障害である場合は、XPをマスターしたチームを祝ってください。

Ron Jeffries氏は、ペアプログラミングで1週間に2、3ストーリーを完了できるぐらいの大きさのストーリーが良いと言った。Jeffries氏はポイントの考えにそれほど夢中になっていなかった。

ポイントに関する概念は、ほとんど間違いだと思います。私は、その概念を強く後押ししたことを後悔しています。その概念は、本当に重要な点から外れています。重要な点は、ストーリーが小さくなって大体一定のペースで完了できるくらいまで、ストーリーを分割することです。

あなたのチームは、ストーリーをどのくらいの大きさにするかどうやって決めるのだろうか? 大きさを決めるものではなく指示器としてチームのベロシティを使うだろうか? コメントを残して、あなたの考えを共有しよう。