バグの優先順位を開発者に影響を与え、それに応じてどのように扱うか？
現在作業中のバグプロセスがあります。
バグには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であり、heap-o-bugsを生き延びたことによって。
ですから、開発者がスライドさせれば、あなたは良い仲間になります。もちろん、あなたが言ったような「ルール」（「新機能に取り組んでいない場合は、少なくとも週に1つのP2に取り組む必要があります」）をいじくり回すことはできますが、それだけでは人気がなくなるでしょう。
私の質問は、厳密な議題を課すことなく人々にバグに対処させ、それを解決させる方法です。
代わりに、全体的な考え方を少し変えて、バックログでバグがファーストクラスの市民であるという意味で、バグを機能のようにすることをお勧めします。はい、新しい機能は素晴らしいです。はい、管理と販売は新機能に非常に力を入れています。しかし、大量の厄介なバグの代わりに、安定して機能するアプリケーションを用意することも重要です。
開発者に、好きではない仕事をしなければならないことを伝えないでください。しかし、バグに取り組むのが好きになるように、雰囲気を変えてみてください。バグのないアプリケーションに誇りを感じさせてください。バグのマニフェストを作成した根本的な理由を具体的に修正できるようにすることで、バグに取り組むのをより楽しく（原文のまま）します（つまり、迅速な回避策/ハックだけではない）。壊れたクラス構造を取り除き、それをより適切なものに置き換えることは、開発者にとって非常に楽しいものです。定期的にバグが他の場所に現れる壊れた中央部分がある場合は、中央部分を修正します。
どのように目標を達成するかは、自分のキャラクターとチームのキャラクターに大きく依存します-達成したいものにだまそうとせず、オープンなディスカッションを行って、ピアエフェクトを実行してみてください。作業プロセス自体など。