バグの痕跡に対処する方法は？
リリースごとに、バグの痕跡は増え続けています。これらは有効なバグですが、競争に参加するには新しい機能も作成する必要があります。また、これらの機能はバグ修正よりも多く使用されます。より良いROIを提供します。
他のエンジニアや製品所有者はこの状況にどのように対処していますか？
技術レベルでは、バグ、機能、それはすべて同じであり、変更要求です。価値がないために機能を追加しないことにしたことはありますか？バグも同じです。バグと機能の唯一の違いは商用です-「顧客」は機能に対して支払い、「会社」はバグ修正に対して支払います、またはそのようなもの。
ただし、機能リクエストと同様に、すべてのバグレポートには変更追跡チケットが必要です。チケットは、開くのと同じくらい簡単に閉じる必要があります。これが、意思決定に必要なデータを取得する唯一の方法です。
変更要求はできるだけ早く閉じる必要があります。この理由は、オープンリクエストは分析に時間がかかり、システムを詰まらせ、ほとんど価値を追加しないためです。あなたはそれをしないことを決定するための迅速な方法を必要とし、そしてその決定がなされたら、チケットを閉じます。アイテムを複数回開くか閉じるかについては、決して話し合わないようにする必要があります。私が思う最大の問題の1つは、人々が「修正されない」というチケットを閉じることに抵抗があるため、チケットを開いたままにしておくことです。あなたがそれを修正するつもりがないなら、みんなに正直に言って、「私たちはそれを修正するつもりはない、それを乗り越えなさい」とだけ言ってください。
チケットに優先度と重大度の両方を含めます。システムに対する欠陥の影響は、その重大度、販売およびマーケティングが優先順位を設定することです。
その他のヒント：バグを修正するための機能リクエスト/拡張機能の予算からの数値（たとえば20％）を使用します。 （つまり、機能を追加するのに10日かかる場合、バグを修正するのに2日かかります）。予算が使い果たされるまで、バグは優先順に修正されます。これは、機能のみの開発のための商用ドライブを回避します。
欠陥のコストは、欠陥の挿入からその欠陥の修正（または修正しないという決定）までの時間に指数関数的に比例します。あなたがそれらを修正せず、それらを閉じることを拒否するために不釣り合いな金額を費やすそれらの小さなバグを防ぐために、オープンチケットは定期的に優先度が上げられ（5つの優先度レベルを言う-月に一度）、下げることはできません。そうすれば、たとえば6〜12か月以内に対処する必要があります。
トリアージ と優先順位の会議を定期的に開催する必要があります。
以前の仕事では、製品の所有者と開発リーダー（私）で構成される毎週の会議がありました。私たちは
- 現在の優先事項を確認する
- 新しいバグに優先順位を付ける
- 新機能に優先順位を付ける
目標は、私たちが取り組んだことのバランスが取れていることを確認することでした。特定の問題を無視することのコストと、それらが将来的にどれだけのコストになるかを説明します。また、各変更の開発コストについて説明し、必要に応じて代替案を提示します。その見返りに、私はビジネスにとって特定の機能の重要性を感じるでしょう。これは私と製品マネージャーの両方に
- リソースがどのように使われていたかについての良いアイデア
- 私たちが持っているリソースをどのように活用するかについてのコンセンサス
- ビジネス全体のより深い理解
信頼関係が確立されると、会議はほとんど意見の相違なしにすぐに終わりました。
すべてのバグとバグレポートをデータベースに保持し、新機能の関連性がなくなったときに対処し、最も頻繁に発生し、プログラムに最も影響を与えるバグに焦点を当てます。