バグの優先度に開発者に影響を与え、それに応じてそれらを処理する方法は？

現在、作業中のバグプロセスがあります。

バグには3つのレベルがあります。

• P1バグ：ユーザーの作業を妨げるバグ。それらはその場で解決されなければなりません。
• P2バグ：影響はあるが、ユーザーは作業できるバグ
• P3バグ：影響がなく、ユーザーが作業できるバグ。

P1は必須であり、その場で対処する必要があります。しかし、P2とP3については、ケースバイケースで判断します。

3つのレベルがあるため、チームはP2とP3を扱うのではなく、顧客から求められたより緊急の新しい開発に取り組む傾向があります。

質問は次のとおりです。

P4を持つなど、別のレベルの優先度を追加する必要がありますか？

今週のように、緊急ではないチケットを処理するためのターゲットも割り当てる必要があります。コーディングタスクを割り当てない場合は、少なくとも1 P2を処理する必要がありますか。

現在、私が上で挙げたような目標はありませんが、私の懸念は、そのような目標を与えることは残忍なことです。確かなことは、目標について話し合う必要があることです。チームは、特に目標を設定するときに議論に関与するのが好きです。

更新：

この質問は、類似性の観点から提案されました。しかし、まったく似ていません。

私の質問は、厳密なアジェンダを課すことなくバグを処理し、それを解決する方法です。だから、暗示された質問は私を助けない。それでも、ありがとう。

一般的に、バグには重力と頻度の2つの軸があります。

したがって、明らかに重大で頻繁なことが最優先事項です。ただし、深刻ではあるがめったに発生しないものは、深刻ではないが頻繁に発生するものとほぼ同じ程度に重み付けする必要があります。したがって、重力を1から3、頻度を1から3と評価すると、修正する必要があるバグのタイプは、重力1、頻度3、および重力3、頻度1で定義される対角線を越えるバグです。

ブロッキングエラーまたはクライアント情報への潜在的な損傷を引き起こす可能性のあるエラーは、常に重力3になります。同様に、重力1のエラーは、ユーザーが気付かないか、優先度が低くなります。ここでよくわからない場合は、2を割り当てるのがおそらく安全な番号です。

プログラムが起動されるたびにユーザーに表示されるエラーの頻度は3になります。頻度1のエラーは、めったに起こらないことです。繰り返しますが、不明な場合は、2を割り当てるのがおそらく安全な番号です。

重力3のバグまたは頻度3のバグを構成するものはほとんど主観的ですが、常識を使用してください。重力1、周波数2のバグは、ラベルのつづりが間違っている可能性があります。重力2、頻度1のバグは、データベース接続がダウンした場合の適切なエラー処理である可能性があります。

繰り返しますが、これは単なる大まかなアイデアですが、アイデアは一種のトリアージとしてバグ修正の焦点とすべきものに重点を置くことです。明らかに、すべてのバグをブロックまたはその他の方法で排除することはできませんが、少なくともこの方法論では、バグがあまりにも急ぎすぎたり頻繁になったりすることはないと言うことができます。エラーをブロックしているバグのみを修正した場合、高周波エラーは無視され、ユーザーはこれらのバグを修正しなかったことに気付くでしょう。

また、便宜上、重力または頻度の文字等級を提供することを好む場合があるため、バグはB3エラーであり、重力と頻度の両方が明確であると言えます。

幸運を！

これは、あなたがより重要であると考えるものに要約されます。P2バグまたは新機能？

通常、アジャイルプロジェクト管理システムには、タスクが優先度順に並べられ、その順序で作業される優先順位付け会議が含まれます。

開発者は、作業するタスクを選択できません。それがプロジェクトマネージャーの仕事です。予算が尽きる前に、プロジェクトに含まれる重要な機能を可能な限り多く確保する必要がある人。

それが本当に最も重要なことです。「週に少なくとも1 P2を修正する」などの単純なルールは、この目標を実際には助けません。

ソフトウェアが重要ではないバグを積み上げて何か大きな問題を引き起こし、大きなイベントが発生し、それらの多くが一度に修正されるのは、かなり一般的なサイクルです。たぶん、大規模な新しいリリースの前にバグ修正のみにスプリントを1つまたは2つ捧げることによって、またはEOLでありヒープバグを生き延びたソフトウェアによって。

あなたの開発者が彼らに単にスライドさせたなら、あなたは良い仲間です。もちろん、あなたが言ったように「ルール」を調整することもできます（「新しい機能に取り組んでいない場合は、週に少なくとも1つのP2に取り組む必要があります」）。

私の質問は、厳密なアジェンダを課すことなくバグを処理し、それを解決する方法です。

代わりに、全体的な考え方を少し変更し、バックログの第一級市民であるという意味で、バグを機能のようなものにすることをお勧めします。はい、新機能は素晴らしいです。はい、管理と販売は新機能を非常に重視しています。しかし、厄介なバグの巨大な山の代わりに、安定した、適切に機能するアプリケーションを持つことも重要です。

開発者に、自分が好きではない仕事をしなければならないことを伝えないでください。バグに取り組むのが好きなように、大気圏を変えてみてください。バグのないアプリケーションに誇りを植え付けるようにしてください。バグがある場合、そのバグのマニフェストを作成した根本的な理由（つまり、迅速な回避策/ハッキングだけでなく）を実際に修正できるようにすることで、バグに取り組むことをより楽しく（原文のまま）にします。壊れたクラス構造を取り除いて、より適切なものに置き換えることは、開発者にとって非常に楽しいものです。定期的に他の場所にバグが現れる壊れた中央部分がある場合は、中央部分を修正します。

目標をどのように達成するかは、あなた自身のキャラクターとチームのキャラクターに大きく依存します-目標を達成するためにそれらをだますのではなく、オープンな議論を行い、ピア効果を実行してみてください。作業プロセス自体など。