クライアントから、私たちが抱えているすべてのバグについて時間の見積もりを求められました。
バグ修正のスケジュールが設定されており、時間も割り当てられていますが、バグごとに時間は割り当てられていません。簡単に言えば、バグに優先順位を付け、割り当てられた時間内に最も優先度の高いバグが修正されるようにしました。
私はバグに時間を割くのが好きではありません。理由は次のとおりです。
バグごとの時間数を提供するのではなく、どのバグが修正されるかについての時間枠のみを提供したい場合、この問題にどのように取り組むべきですか?
バグにどのように時間を割り当てますか? 効果的ですか？時間と労力を費やす価値はありますか？
私ができる唯一の答えは、非常に保守的であることです。どれくらいの時間がかかるかを推測し、推測を 4 倍します。それを見積もりとして使用してください。あなたが言ったように、物事を修正するのにどれくらいの時間がかかるかを把握することは非常に困難であり、十分に保守的ではなかったために「締め切りを破った」と捕まるよりも、実際よりも時間がかかると言ったほうがよい.
私が働いている会社は、顧客から不当な要求を受けることがよくあります。 覚えておくべき重要なことは、顧客は十分な情報を得たいということです。 これを行うための最良の方法は、ステータスレポートの観点からです。
それで、私たちは最初に私たちの立場を説明するのにかなり良い仕事をします。あなたの例では、これは次のようになります。
プロジェクトのバグを修正するためのスケジュールが設定されています。これは、歴史的にスケジュールどおりに進んだ実績があります。ただし、各バグの修正にかかる時間を詳細に説明するプロセスは、エラーが発生しやすくなります。修正されたバグとテストされた修正について、毎週（または、お客様によっては週に2回、または毎日）更新を提供させていただきます。
ただし、各バグの修正にかかる時間を見積もるのは良いことだと思います。この理由は、すべてのバグを修正するためにかかる合計時間を理解する必要があるためです。個々の部品の修理にかかる時間の見積もりがないと、正確な見積もりを取得することはできません。もちろん、これらは大まかな見積もりである可能性があります（問題の調査に1時間以上費やすことはありません）。見積もりに多くの時間を無駄にしたくはありません。それから私は通常余分な20％を考慮に入れます。したがって、バグの見積もりは3日、5日、および2日であると言います。次に、12日以内にバグを修正できるはずであることをお客様に報告します。そしてもちろん、成果物を提供する前に、製品のテストと再梱包にさらに時間をかける必要があるかもしれません。
バグを修正するのにかかる時間を見積もるという観点からこれを考えないでください。正しく見積もることができない可能性があります。
クライアントの怒りを管理するという観点からこれを考えてください。バグを修正するのにまったく時間がかからず、最終的に3か月かかると彼らに伝えると、クライアントは現在あなたに満足し、将来あなたに激怒するでしょう。
バグの修正には3か月かかり、実際には修正には3か月かかると伝えると（そうなるでしょう）、クライアントは今激怒し、将来あなたに満足するでしょう。
私は通常、バグはまったく時間がかからないと言います（2〜3日は適切な鎮静化の数のようです）。
バグの重大度について、たとえば1時間、1/2日、1日、1週間など、いくつかのバンドを選択して、それらに割り当ててみませんか。一般的に、あなたはバグの感覚を持っているでしょう-あなたが知らないものは、それに最悪の場合の数字を入れてください！
あなたが引用した理由（調査に時間がかかりすぎるなど）のために、それよりも細かいレベルで見積もる必要はないと思います。
時間の無駄ではないと思います。顧客は、バグの数とその優先順位以上のものを知りたいと考えています。つまり、残りの作業量を把握したいと考えています。
いかなる状況においても、これによってさらに多くのバグが発生することはありません。あなたはこれらを修正するために時間に対して急いでいるべきではありません。1日を見積もり、10時間かかった場合は、問題ありません。1週間と見積もって2時間かかったとしたら、良い結果です！
これは単に見積もりの練習です！
通常、特定のリリースでどのバグを修正する必要があるかについて合意し、すべてのバグを修正するための時間枠を定義します。個々のバグごとに、修正にかかる時間には多くの不確実性/変動性がありますが、それはバグの数が多いほど平均化される傾向があります。時間がかかることがわかっている特定のバグについては、たとえばシミュレーターやテストフレームワークを作成する必要がある場合など、いくつかの見積もりを出すことができる場合があります。
これらが発見され報告されたバグである場合は、それを修正する時間（および再テストする時間）の見積もりを作成できるはずです。見積もりの信頼性は、見積もりに費やす時間に比例する可能性が高く、おそらくこのコストをクライアントに説明します。
関連する小さなバグレポートが多数ある場合は、それらを1つのオムニバスレポートにまとめることができます。これにより、クライアントが、純粋に個々の見積もりに基づいて修正するバグを選択しようとするのを回避できる場合があります。
それはあなたが持っている他のタスクを見積もることと同じでなければなりません。可能な限り最小のタスクに分割し、予期しないもののためにパディングを使用して、それらをできるだけ正確に見積もります。次に、適切に定義されていないタスクの特定の日付に固定されないように、範囲を指定します。バグを修正する時間を見積もることと、あいまいな要件を持つ機能を実装する時間を見積もることに違いはありません。
そうです、見積もりは通常不正確です。
バグが修正されない場合、それぞれのバグにどれだけの費用がかかるかを彼らに尋ねたいと思うかもしれません。次に、適切な計算を実行して、バグを修正する必要があるかどうか、および各バグにどれだけの時間を費やすことができるか (または現実的には彼ら) を把握できます。