バグ修正時間の割り当て

Question

私たちはクライアントから、抱えているすべてのバグについての推定時間を教えてほしいと頼まれました。

バグ修正のスケジュールは設定されており、そのための時間も割り当てられていますが、抱えているバグごとに時間の割り当てを行っているわけではありません。簡単に言えば、私たちはバグに優先順位を付け、最も優先度の高いバグが割り当てられた時間内に修正されることを保証しました。

私はバグに時間を割くのが好きではありません。理由は次のとおりです。

1. 通常、それは不正確です。修正にどれくらい時間がかかるかを把握するのは非常に困難です。
2. 時間の無駄。
3. コードの品質に影響を与える
4. 長期的にはさらに多くのバグが発生します (期限までに完成させようとすると、特定の項目を見逃してしまう可能性があります)。

バグごとの時間数を提供するのではなく、どのバグが修正されるかについての時間枠だけを提供したい場合、この問題にどのように対処すればよいでしょうか?

バグにどのように時間を割り当てますか?効果はあるのでしょうか？時間と労力をかける価値はありますか?

Answer 1

私ができる唯一の答えは、極めて保守的であるということです。どれくらい時間がかかるかを推測し、その推測を 4 倍します。それを見積もりとして使用してください。あなたが言ったように、物事を修正するのにどれくらいの時間がかかるかを把握するのは非常に困難であり、十分に保守的でなかったために「期限を破った」と捕まるよりは、実際よりも時間がかかると言ったほうが良いでしょう。

Answer 2

私が働いている会社では、顧客から理不尽な要求を受けることがよくあります。 覚えておくべき重要なことは、顧客は十分な情報を求めているということです。 これを行うための最良の方法は、ステータス レポートであることがわかりました。

したがって、私たちはまず自分たちの立場をうまく説明します。あなたの例では、これは次のようになります。

私たちはプロジェクトのバグを修正するためのスケジュールを設定しており、これまでスケジュールどおりに進んできた実績があります。ただし、各バグの修正にかかる時間を詳細に説明するプロセスは、非常に間違いが発生しやすいものです。修正されたバグやテスト済みの修正については、喜んで毎週 (お客様によっては週 2 回または毎日) 更新を提供させていただきます。

ただし、各バグの修正にどれくらいの時間がかかるかを見積もってみるのは良いことだと私は考えています。その理由は、すべてのバグを修正するのに合計時間がどれくらいかかるかを理解する必要があるからです。個々の部品の修理にどれくらい時間がかかるかを見積もっていないと、正確な見積もりを得ることができません。もちろん、これらは大まかな見積もりでもかまいません (問題の調査に 1 時間を費やさない程度の見積もりです)。見積もりにあまり時間を費やしたくないでしょう。その後、通常はさらに 20% を考慮に入れます。したがって、バグの見積もりは 3 日、5 日、2 日であるとします。その後、12 日以内にバグを修正できるはずだとお客様に報告します。その場合、当然ながら、成果物を提供する前に、製品のテストと再梱包にさらに時間を追加する必要があるかもしれません。

Answer 3

バグの修正にかかる時間を見積もるという観点からこれを考えないでください。正確に見積もることは不可能だからです。

これを次のように考えてみましょう クライアントの怒りを管理する. 。バグを修正するのにまったく時間がかからず、最終的には 3 か月かかると伝えた場合、クライアントは今は満足していますが、将来はあなたに激怒するでしょう。

バグの修正に 3 か月かかると伝え、実際に修正するのに 3 か月かかる (実際に修正される) 場合、クライアントは今は激怒し、将来はあなたに満足するでしょう。

私は通常、バグにはまったく時間がかからないと言います (2 ～ 3 日が落ち着くのに適した数字のようです)。

Answer 4

これは、抱えている他のタスクを見積もるのと同じはずです。可能な限り小さなタスクに分割し、予期せぬ事態に備えてできる限り正確にタスクを見積もります。次に、明確に定義されていないタスクについて特定の日付に固定されないよう、範囲を指定します。バグ修正にかかる時間を見積もることと、要件が曖昧な機能を実装するためにかかる時間を見積もることの間に違いはありません。

Answer 5

おっしゃるとおり、見積もりは通常不正確です。

おそらく、バグが修正されなかった場合、各バグにどれくらいの費用がかかるかを彼らに尋ねたいと思うかもしれません。その後、適切な計算を実行して、バグを修正する必要があるかどうか、また、各バグにどれくらいの時間を費やすことができるかを (または現実的には) 判断することができます。

Answer 6

バグの重大度に応じていくつかのバンドを選択してみてはいかがでしょうか。1時間、半日、1日、1週間を割り当ててください。一般に、バグの予感はあるでしょう。まったくわからないバグについては、最悪の場合の数字を当てはめてください。

あなたが引用した理由（調査に時間がかかりすぎるなど）により、それより細かいレベルで推定する必要はないと思います。

時間の無駄だとは思いません。顧客はバグの数とその優先順位以上のことを知りたいと考えています。つまり、作業がどのくらい残っているかを把握したいと考えています。

いかなる状況においても、これによりさらなるバグが発生することはありません。これらを修正するために時間との戦いを急ぐべきではありません。1 日と見積もって 10 時間かかったとしても、問題ありません。1 週間と見積もって 2 時間かかった場合、良い結果が得られます。

これは単なる推定の練習です。

Answer 7

通常、特定のリリースでどのバグを修正する必要があるかについて合意し、すべてのバグを修正する期限を定義します。個々のバグごとに修正にかかる時間には多くの不確実性やばらつきがありますが、バグの数が増えると平均化される傾向があります。時間がかかることがわかっている特定のバグについては、いくつかの見積もりを与えることができる場合があります。シミュレータまたはそのためのテスト フレームワークを作成する必要がある場合。

Answer 8

これらが発見され報告されているバグであれば、修正にかかる時間 (および再テストにかかる時間) の見積もりを作成できるはずです。見積もりの​​信頼性は、見積もりに費やした時間に比例する可能性が高く、おそらくこのコストをクライアントに説明します。

関連する小さなバグ レポートが多数ある場合は、それらを 1 つのオムニバス レポートにまとめることができます。これにより、クライアントが純粋に個々の見積もりに基づいてどのバグを修正するかを選択することを回避できる可能性があります。