バグトラッカーの優先順位とポリシー
The Old New Thing に関する質問をきっかけに、私は質問したいと思います：
バグトラッカーの優先順位をどのように設定しますか？より一般的には、それらに取り組むためのあなたのルールは何ですか？ 「最初にバグを修正する」ことについて、どの程度厳格ですか。それらすべて？
このコミュニティウィキにマークを付けました。別の回答として投稿します。 （だから、彼らが吸うと思うなら、あなたはそれらを投票することができます:)
私たちはこのようなものを使用します（実際には意味は少し曖昧です）：
バグ：
1。ブロッカー-壊滅的な障害のために予約されています-例外、クラッシュ、データの破損など、（a）誰かがタスクを完了できず、（b）回避策がありません。これらは非常にまれなはずです。それらはすぐに（同日）修正し、修正プログラムとして展開する必要があります。
2。クリティカル-これらは、未処理の例外、または特定の特定の条件下でのみ発生するその他の「重大な」バグを指す場合があります（つまり、実用的な回避策が利用可能です）。解決時間に厳しい制限はありませんが、1週間以内に修正する必要があり（ホットフィックス）、次のリリースまでに修正する必要があります。 （1）と（2）の主な違いは、重大度や影響ではなく、回避策の存在です。
。メジャー-通常、パフォーマンスの問題のために予約されています。生産性を著しく阻害するものの、実際には作業の実行を妨げるものではありません。次のリリースで修正。
4。マイナー-これらは「迷惑な」バグです。デフォルト設定が適用されていない、編集可能（またはその逆）として表示される読み取り専用フィールド、UIの競合状態、誤解を招くエラーメッセージなど。優先度の高い問題がない場合は、このリリースを修正します。次のリリース。
5。些細な-外観上の問題。スクロールバーが表示されるべきではない場所に表示され、ウィンドウは保存されたサイズ/場所、タイプミス、ラベルの最後の文字が切り取られていることなどを記憶していません。修正に数分しかかからず、誰かが同じ画面/機能で同時に作業している場合は修正されます。それ以外の場合は、修正されない可能性があります。これらには保証はありません。
変更依頼（機能）
2。設計エラー-のように、仕様を誤解していて、機能が想定どおりに機能しないか、機能が不十分で使用できない。これは変更リクエストの最高の優先度ですが、それでも優先度2です。変更リクエストがブロッカーのバグよりも優先されることはありません。これらは次のリリースまでに修正する必要があります。
。重要-大幅なコスト削減（またはソフトウェアの種類によっては潜在的な利益）、主要なパフォーマンスの向上、アプリをより素晴らしいものにするもの。または、管理者によってこのレベルにエスカレートされたもの-これは機能の最高のエスカレーションレベルです。次のリリースに入る予定ですが、時間や現金が不足した場合はカットされる可能性があります。
4。通常-基本的に多くの人が望んでいるもの（または1つVIPが望んでいる））、そしてその論理的根拠は明確で合理的ですが、特別なことは何もありません他の一般的なリクエストよりも優先されることが保証されます。パフォーマンスを微調整し、このフィールドまたはこのボタンまたはこのレポートを追加し、この種類をアルファベット順ではなく数値として作成します。次のリリースに割り当てられますが、遅延が発生した場合に最初にカットされます。
5。影響が少ない-レイアウトの変更、文言の変更、ベースライン要件と競合する可能性のある変更、実装に数か月かかる可能性のある空のパイ機能など。これらは自動的に割り当てられます。より重要なことに取り組んでいない限り、将来のリリース（これは...決してありません）。多くの場合、次のリリースがリリースされると、より重要な要求が積み重なるにつれて、これらは偶数さらにリリースに延期されます。
6。オプション-実際にはcallオプションではありません（正式には「時間許可」だと思います）が、それはこれはほとんど何ですか。通常、2つのクラスの変更のために予約されています：（a）ほとんどの人を悩ませるだけであることがわかっているダムリクエスト（「ユーザーがこのボタンをクリックしようとするたびに確認ダイアログを表示する」）、および（b）内部で考案された機能上記の公式リクエストをコストで正当化しないでください。どのリリースにも割り当てられていません。
私は コードエコノミストとしての私の人生 エリックシンクがここに属していると信じています。その本質は、重大度、頻度、コスト、およびリスクに応じてバグに優先順位を付けることです。すべてのバグを修正するのではなく、それほど深刻ではないバグのリストを用意して、作業を進めながら修正してください。
今のところ答えに問題はありませんが、生産性についての見解を付け加えたいと思います。プログラマーがバグを修正するためにサブシステムに入る場合、コードを再理解するためにいくらかの時間と労力が費やされます。したがって、そのサブシステムから発生していると思われるすべてのバグを修正してください。最初に作業するサブシステムと、次の優先サブシステムにいつ移動するかについて、適切な判断を下してください。この判断は確かにカスタマーサポートの考えや他の人がバグをどのように分類したかに影響されますが、効率も非常に重要です。
私のチームはタスクを優先度だけで分類するのではなく、3つの重要な基準を使用します：優先度、重大度、およびvisibility。
優先度は開発スケジュールを示します。優先度の高いバグまたは機能とは、現在の開発サイクルで完了する予定であるか、特定の比較的近い日付までに顧客に約束されたものです。優先度の低いタスクの例としては、まだ開発の初期段階にあり、しばらくの間公式ロードマップに表示されない機能のバグがあります。
重大度は、バグの存在または機能の不在（拡張要求の場合）の影響を示します。ユーザーデータを台無しにしたり、ハードウェアを損傷したり、永続的に回復不可能な状況を作り出したりする可能性のあるバグが最も深刻です。社内の別の重要なチームがバグの修正や機能の追加を待っている場合、そのタスクの重大度もかなり高くなります。中程度の重大度のランク付けは、パフォーマンスの最適化など、プロジェクトが機能するために重要であるが必須ではないタスクに与えられます。重大度の低いタスクとは、エラーメッセージのスペルミスや、内部デバッグ/テストを容易にするのに役立つ機能のようなものですが、エンドユーザーには表示されません。
可視性誰がバグを見ることができるかを示します。起動時にすべてのユーザーのソフトウェアをクラッシュさせるバグは、視認性の高いタスクになります。特定の珍しい構成に依存しているバグ、または当社（または当社のパートナー）のラボでのみ見られるバグは、中程度の可視性を持っています。内部デバッグおよびテスト機能内のバグ（およびエンドユーザーが遭遇することはできません）は、可視性が最も低くなります。
着信するバグ、拡張要求、または計画された機能/新開発ごとに、優先度、重大度、および可視性（略称P/S/V）の値を1〜5（5が最高）に割り当てます。一般に、「やること」リストを3つの値の合計でソートすることにより、作業に優先順位を付けます（大まかに言えば、これはファジー論理システムです）。 P/S/Vが2/5/4のバグレポートは、値が5/1/3の新しい開発タスクの前に処理されますが、値が5/2/5の拡張要求の後でのみ処理されます。
これは（もちろん）不正確な科学であり、システムには常に例外があります。ランクの高いバグも回避できる場合は、ランクの低い拡張リクエストを処理する方が望ましい場合があります。ランクがXのすべてのタスクでは、ランクXのバグは通常、ランクXが拡張される前に対処されます。また、通常、すべてのランキングには+/- 1の許容誤差があると見なされます。
このシステムの欠点は、タスクがやることリストに載っている時間の長さ（古い、古いタスクの中には長い間ぶらぶらしている可能性がある）や推定時間の長さが考慮されていないことです。タスクが完了するまでにかかります。幸いなことに、私たちのチームには十分な人数がいるので、誰かが1日かけて、ランクの低いタスクをときどきクリアすることができます。
私たちの優先順位付けシステムは、常にソフトウェアの現在の反復のコンテキストにあり、次のように機能します。
- 優先度1-このアイテムを除くすべての作業が停止します。テストされ次第、修正をリリースします。
- 優先度2-このアイテムが解決されない限り、次のリリースはリリースされません。
- 優先度3-このリリースでは本当に望まれていますが、時間がなくなった場合はプッシュします。
- 優先度4-このリリースでこれに到達することは実際には期待していませんが、タスクが不足している場合は、それに取り組んでください。
- 優先度5-それに取り組んではいけません。
「バグを最初に修正する」という警告について。私たちは一般的にそれを行いますが、常識も適用します。すべてのバグが同じように作成されるわけではありません。システムが10、000年を過ぎたときに日付を正しくフォーマットしない場合、その修正を取得するために機能をプッシュバックすることは確かに重要ではありません。誰かの銀行残高を誤って計算する場合、それはリストの一番上になります。
私たちの場所で：
「fixfor」と優先度（この順序で）を使用して、バグと機能のリクエストに推奨される解決順序を示します。
私たちの優先事項は次のとおりです。
- Assign Priority-これが最も高く、デフォルトです。
- 緊急！緊急！-これは「他のすべてを削除する」場合を対象としています。-少しばかげた-名前は、人々がそれを悪用しないようにするために選択されました。これは今のところうまく機能しています。
- Showstopper-これは、誰かが効率的に作業を行うのをブロックしている、一部の機能のデモを妨げている、または同様のものです。
- 必要-割り当てられている次のリリースに必要です。私たちが約束した機能、またはお客様固有のプロジェクトマイルストーンの一部である機能
- 期待-次のリリースに含まれるはずですが、削除できます。
- 時間がある場合は修正-「時間がたくさんあるときにそれを行う」というのは、「息を止めないでください」とローカルで同等であるため、少し舌を出します。
「優先度の割り当て」が最も高く、デフォルトで送信が簡単です。開発者が行う必要のある最低限のことは、重大度を評価し、それを再現できるかどうかを確認し、重複を解決することなどです。
ほとんどの場合、開発者は製品の一部に十分に関与しているため、自分で注文を把握できます。新しいケースを評価する前に、showstopeprを修正する場合があります。一般的に、私はそれぞれのマネージャーが疑わしい場合にこれらを明確な順序に並べることを期待します-それはnotプログラマーの仕事ですが、彼らは通常それが得意です。
ところで、FogBugzを使用しています。
公式には、当社には「最初にバグを修正してから、新しい機能を作成する」という厳格なポリシーがありました。しかし、実際にそれを支持しているように見えた少数の人々は、新しい開発の観点から最も重要な人々でもありました。しばらく時間がかかりましたが、100人のクライアントを満足させる新機能を追加するよりも、1人のクライアントを満足させるバグを修正することの方が重要であることがわかりました。
さらに、私たちの製品は今では非常に大きいので、すべてのバグを本当に修正するには何年もかかります。これは、新しい機能/バージョンが完全に不足しているため、許容できる期間ではありません。
この時点で、非常に適切なバグトラッカーとクラッシュダンプシステムがあるため、簡単なバグのほとんどすべてが修正され、残りのバグの多くは煩わしいものですが、ショーストッパーはないという考えになりました。
「バグを最初に修正する」という適切な方法で、お客様が迅速な修正（システムを不安定にする）を求めて私たちに多くのことをプッシュし、プッシュバックできなかったため、「煙」システムを決定することになりました。迅速な修正（つまり、適切にレビューまたはテストされていない-顧客を満足させるためにプッシュされただけ）は、「煙」バグとしてカウントされます。オープンスモークバグの数が5を超えると、クランプダウンして減速ドライブを開始します。また、これが発生した後は迅速な修正を行わないことを公表し、プロセス全体にお客様を関与させました。
あなたの質問に正確に答えているわけではありませんが、このアプローチは私たちにとって有用であることがわかりました。
私は個人的に常に最初にバグに取り組むようにしていますが、安定した製品としての拡張機能は、拡張機能を実装するのが簡単です。今では完璧な世界ではないため、常に発生するとは限りませんが、それが私の目標です。
最初に2時間以内に修正できるバグ、次にもっと時間が必要なバグ。