BT

タスクに費やした時間ではなく開発速度をトラッキングする

| 作者: Chris Sims フォローする 0 人のフォロワー , 翻訳者 大田 緑 - (株)チェンジビジョン フォローする 1 人のフォロワー 投稿日 2009年2月2日. 推定読書時間: 2 分 |

エンジニアがタスクに費やす実際の時間のトラッキング方法とこの方法が速度というアジャイルの概念にどのように関係するかについて、新しいアジャイルチームのメンバがScrum Developmentグループ(リンク)に尋ねた(リンク)。速度 (Velocity) は、チームがどれだけ速く機能を完成させているか、従って、プロジェクトを完了するのにどれくらいかかるかをトラッキングするアジャイルの計測基準だ。グループの意見は、費やした時間をトラッキングすることは必要ないし、役にも立たないということであった。

最初の投稿によると、彼のチームはストーリーポイントを使ってストーリーのサイズを見積もるとのことであった。チームはストーリーを完了させながら、関連するストーリーポイントを計算する。この計算は、チームの速度を算出するために使う。

チームの速度は、おおよそチームがスプリント毎に達成できる作業量です。おそらく4週間のスプリントで25ストーリーポイントでしょう。この数字は、それに続く各スプリントで引き受ける作業量の判断基準として使えます。

ここまではよいだろう。この投稿では、どのようにチームがストーリーをタスクに分解し、これらのタスクを時間で見積もってトラッキングするのかという説明が続く。

私たちは、バーンダウンチャートを使っています。その一部として、各チームメンバは毎日タスク毎に残っている時間を記録します。これは、バーンダウンチャートスプレッドシートに入力されます。しかし、それは、ただバーンダウンのデータを記録しているだけで、速度の役に立つものではありません。

この混乱状態は、Ron Jeffries氏を含む何人かのアジャイル実践者が、タスクを見積もったり、トラッキングしたりしないよう薦めていること(参考記事)を裏付けている。George Dinwiddie氏(リンク)が彼の見解を続けた。

ストーリーを小さくする場合、バーンダウンで時間をトラッキングする必要はありません。チームはストーリーをトラッキングするだけのほうがうまくいき、再度見積もりする時間をすべて無駄にせずに済むことが分かりました。

この議論のスレッドで、Ron氏や他の人たちは、役に立つ予測をするのに必要なすべての情報は、「4週間のスプリントで25ストーリーポイント」でとらえられたと指摘する。これがチームの速度で、これこそこのチームがおそらく将来完成できるであろうストーリー数を予測するのに必要なものだ。

あなたのチームはタスクの見積もりとストーリーの見積もりをトラッキングするだろうか? コメントを書いて、なぜそうなのか、または、なぜそうではないのか共有しよう。


原文はこちらです:http://www.infoq.com/news/2009/01/Track-Velocity-Not-Tasks

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT