エンジニアがタスクに費やす実際の時間のトラッキング方法とこの方法が速度というアジャイルの概念にどのように関係するかについて、新しいアジャイルチームのメンバがScrum Developmentグループ(リンク)に尋ねた(リンク)。速度 (Velocity) は、チームがどれだけ速く機能を完成させているか、従って、プロジェクトを完了するのにどれくらいかかるかをトラッキングするアジャイルの計測基準だ。グループの意見は、費やした時間をトラッキングすることは必要ないし、役にも立たないということであった。
最初の投稿によると、彼のチームはストーリーポイントを使ってストーリーのサイズを見積もるとのことであった。チームはストーリーを完了させながら、関連するストーリーポイントを計算する。この計算は、チームの速度を算出するために使う。
チームの速度は、おおよそチームがスプリント毎に達成できる作業量です。おそらく4週間のスプリントで25ストーリーポイントでしょう。この数字は、それに続く各スプリントで引き受ける作業量の判断基準として使えます。
ここまではよいだろう。この投稿では、どのようにチームがストーリーをタスクに分解し、これらのタスクを時間で見積もってトラッキングするのかという説明が続く。
私たちは、バーンダウンチャートを使っています。その一部として、各チームメンバは毎日タスク毎に残っている時間を記録します。これは、バーンダウンチャートスプレッドシートに入力されます。しかし、それは、ただバーンダウンのデータを記録しているだけで、速度の役に立つものではありません。
この混乱状態は、Ron Jeffries氏を含む何人かのアジャイル実践者が、タスクを見積もったり、トラッキングしたりしないよう薦めていること(参考記事)を裏付けている。George Dinwiddie氏(リンク)が彼の見解を続けた。
ストーリーを小さくする場合、バーンダウンで時間をトラッキングする必要はありません。チームはストーリーをトラッキングするだけのほうがうまくいき、再度見積もりする時間をすべて無駄にせずに済むことが分かりました。
この議論のスレッドで、Ron氏や他の人たちは、役に立つ予測をするのに必要なすべての情報は、「4週間のスプリントで25ストーリーポイント」でとらえられたと指摘する。これがチームの速度で、これこそこのチームがおそらく将来完成できるであろうストーリー数を予測するのに必要なものだ。
あなたのチームはタスクの見積もりとストーリーの見積もりをトラッキングするだろうか? コメントを書いて、なぜそうなのか、または、なぜそうではないのか共有しよう。
原文はこちらです：http://www.infoq.com/news/2009/01/Track-Velocity-Not-Tasks