ベロシティにバグ修正を入れるべきか？...に依る。

作者 Vikas Hazrati , 翻訳者 編集部Ｎ 投稿日 2011年9月20日

セクション

プロセス/プラクティス,

デベロップメント

トピック

アジャイル技術 ,

Value & Metrics ,

Agile

共有 |

原文(投稿日：2011/09/16)へのリンク

過去、バグ修正をベロシティに加えるべきか多くの議論や論争があった。「１つの」正しい答えは、なさそうである。しかしアジャイラには、どのような状況でバグ修正を追加すべきか、どのように追加すべきか、どこで追加しなくてよいかを提案している人達がいる。

Syed氏は、加えるか、加えないかは ベロシティをどう分類するかに依存する、と言っている。もしベロシティが「価値視点」なら、バグ修正は加えられるべきでない。顧客に何も価値を追加していないからである。しかし、もしベロシティが「コスト視点」なら、バグはベロシティに含まれるべきである。修正に時間と労力がかかっているからである。

Mike Cohn氏は、バグにストーリーポイントを割り当てるべきである、と言っている。氏によれば、

こうすることで両方の世界に最善なことを達成できます。我々はチームが実際どれだけの仕事を成し遂げたかがわかりますし、履歴データも取れますし、各スプリントでどれだけバグ修正ストーリーに時間が取られていたかがわかります。

Jason Yip氏は、面白い比喩を使って、メーターとしてのベロシティを最後にあるゴールに向かってフィールドを走る 場合と較べている。氏は、ここで重要なのはゴールに向かっていることだ、と強調する。

今もし誰かが前進を5m逆方向に進めたら、ベロシティは減る。ベロシティはスカラー量ではなくベクターだからである。

Robert氏は、ベロシティを決めるのに 複式簿記のやり方 を勧める。氏によると、

私はベロシティにバグ修正を加えたいです。しかし複式簿記の古典的なやり方によってです。 私はまた、バグが作られた、もっと前のイテレーションからこの種のベロシティを考慮したいです。それをこのイテレーションへのマイナスのオーバーヘッドとして、カウントします。

Greg氏は、 ベロシティにバグを入れない、と一律に決めるのは危険だ、と言う。入れるか入れないかは、コンテキストと目標の実際の定義に依存するべきだ。

恐らく目的は新しいフィーチャです。恐らく目標は多くの顧客が興奮するような1つのフィーチャを作ることです。恐らく、目標はレガシー製品のバグを修正することです。ベロシティにバグを含めないことにするのは、チーム内では上手くいくでしょうが、意味をなさないコンテキストがたくさんあります。

Jack Milunsky氏は、ベロシティにバグ修正を追加することになるかどうかに関わらず、修正に時間がかかっているので、バグは考慮されるべき である、と言っている。

スプリント計画会議で、バグはユーザーストーリーと一緒にスプリントやイテレーションに計画されるべきです。 タスクの実装やバグ修正の合計時間はチームにために決めた利用可能なキャパを超えるべきではありません。私は、多くのコーチがバグは、別けて追跡されるべきで、スプリントで見つかったバグは処理されるべきだ、と言っているのを知っています。しかし、実際のところ、これは必ずしも実際的ではありません。試してみてください、チームの予見性が格段に改善します。

こうして、バグを考慮することには、多くの人が合意している。バグ修正をベロシティに追加すべきかは、意見の別れる問題で、恐らくそうなるのは当然であり、状況による。