なぜ優先度と重要度の両方が必要なのですか？
私は彼らが何を決定するのか理解していますが、見つかった問題にそれらを割り当てることは本当に役に立ちますか？つまり、すぐに修正する必要があるかどうかです。
私はそれらを設定する方法、それらを分類する方法などを知っています。IEEE/ ISOがそれを行うために必要であることを知っています。理由はわかりません。
これらの値が異なることは絶対にあり得ます。高いパフォーマンスを必要とするが、モジュールXを使用しない重要な政府機関への販売がある場合、Xモジュールの重大なエラーよりも早くデータベースの可用性の小さなエラーを修正することは、多くのビジネス理にかなっています。基本的に、ソフトウェアビジネスを実行する場合、技術理由だけが要因ではありません。
日付と時刻のバグ
バグ：年末処理によりデータベースが完全に破損します。それは明らかに深刻なバグです。
日付：12月15日。バグの優先度は非常に高い。
日付：2月1日。バグの優先度は低い。
ミサイルバグの偶発発射
バグ：2月28日から3月1日まで4で割り切れる年にICBM制御ソフトウェアが起動する。その結果、コマンドが起動されない。
それは、存在し得る限り深刻なバグです。優先度は非常に低いですが、条件がトリガーされたときにソフトウェアが使用される現実的な可能性はありますか？
画面上の不注意な「悪い」言葉
バグ：メッセージが画面上のスペースをオーバーフローすると、ボブへの不注意な冒とく的な参照が表示されます。 （実世界：「最終的な尻」部門で働いていた人々がいました。「尻」=「アセンブリ」。）
残念ながら、明日は、会社にとって売り上げが有利になるようなプレゼンテーションを行う予定です。あなたは「ボブ」という名前の人にプレゼンテーションを行っています。重大度：非常に低い。優先度：非常に高い。
他の回答に加えて、このシナリオを検討してください。バグAは修正に30分かかり、重大度は「低」です。バグBの修正には2週間以上かかり、「重大度」が高い場合があります。さらに、バグBは、開発チームで、そしておそらくチーム外で、多くの議論と調整を必要とする可能性があります。バグAは、単一の開発者によって直ちに修正される可能性があります。バグAに高い優先度を設定しても問題ありません。
もちろん、「重大度」と「優先度」は異なる方法で解釈されます。
自分用に作った小さなバグトラッカーで、代わりに「難易度」と「優先度」を優先しました。この場合、重大度の高い問題が常に最も優先度が高く、難易度に基づいてそれらの作業を延期することもできます。
「重大度」について私が気に入らない点の1つは、バグにのみ適用され、機能には適用されないことです。すべての問題を単一のリストにして、優先順位と難易度で並べたほうがよい場合があります。「次に何をするか」を決定する方が直接役立つためです。
私見、優先度と重要度の両方を置くことは単に官僚制です。
実際には、「重要度」の測定値が1つだけ必要です。多くの場合、優先度が使用され、重大度は「高=システムのクラッシュまたは使用不能にする」、「中=バグのある動作、潜在的に有害」、「低=迷惑、迷惑だが無害」などの技術用語として使用されます。
通常、優先度は重大度と関連しています。いくつかの反例は、「誰もがいつも不平を言う迷惑」または「異国情緒的な環境で一度クラッシュが起こったこと」です。
...しかし、結局のところ、開発者（またはマネージャーなど）として、修正/改善すべき順序を知るだけで十分です。したがって、1つのメジャーで十分です。
優先度の必要性は明らかです。バグレポートに取り組む順序を知ることです。もう一つは、いつものように私見ですが、官僚です。 なぜ必要ですか？優先順位がそれを行うので、それはソートのために明らかに役に立たないです。そして結果（重大度の説明）はいずれにしてもバグレポートに記載されています。
どんなバグがより重要であるかが不明確になるため、それは有害だとさえ思います。
- 「クリティカル」バグは「高優先度」バグよりも優先度が高いと考える人もいます。
- バグを報告する一部のユーザーは、重大度と優先度を混同する場合があります
- ...全体として、バグをどの順序で処理するかについて混乱を招く
あなたが書いた：
つまり、すばやく修正する必要があるかどうかです。
それは正しいです。ただし、ほとんどの企業と同様に、リソースは限られています。すべての問題を修正するのに十分な人がいないか、十分な時間がありません。
バグをすばやく修正する必要があるかどうかにかかわらず、修正する必要のあるバグがたくさんある場合、「優先度」は「どちらを先に修正するか」という質問に答えます。
一方、重大度は、優先順位を設定する人が使用する指標です。開発者の観点から見ると、重大度は重要なポイントです。作業を割り当てる1つの観点から見ると、重大度は意思決定プロセスに役立つ重要な情報です。
もちろん、これらはすべて非常に一般的な情報です。非常に長い数のバグのバックログがあるチームの場合、優先度と重大度は、ほぼ空のバグデータベースを持つチームの場合とはまったく異なるものを意味します。
「高重大度==高優先度」のチームに所属している場合、これは問題ではなく、両方のメトリックは必要ありません。結局のところ、これらは単なるツールです。チームはそれらの使用方法を決定する必要があります。あなたのチームにとって、両方を使用するのは意味がないかもしれません。
ISO9001：2007の認定を受けたソフトウェア会社でプロセスを設計および実装しました。 2007年以降、標準が更新されているため、私が認識していない追加の要件がある可能性があります...
ISO9001規格は、製品およびプロセスの欠陥が特定されたときにプロセスを改善するためのフィードバックループを持つプロセスを会社が設計および実装することを保証することを目的としています。
設計フェーズの間、要件は、提案されたソリューションが正しく実装されれば実際に設計ブリーフを解決できるかどうか（検証）、実装が実際に欠陥なく実装されているかどうか（検証）に焦点を当てます
フィードバックループでは、欠陥が特定されても、それらを記録するだけでは不十分です。欠陥はまた、重症度について評価され、再作業が優先されます。
重要な部分は、特定の会社がその重大度を評価し、優先順位について決定を行う方法がISO規格で定義されていないことです。これは、会社が決定して文書化することは商業上およびガバナンス上の問題です。
要件として規格に記載されているため、認定企業には、欠陥の重大度を評価するプロセスと、バグを修正する作業の優先順位を決定するプロセスがあります。これらは間違いなく、2つの異なる決定を下す必要があります。
バグの重大度は1つのデータポイントにすぎません。お客様への影響もう1つのデータポイントです。また、修正、欠陥の年齢、製品に残っている商業的寿命、および会社が意思決定に含めることを決定したその他の要因への取り組みもあります。 「優先順位を決定するために製品マネージャーに存在する欠陥」として記述すべきではない1つのことは、決定を行う権限を定義するだけであり、決定を行うために彼らが従うプロセスを定義しないためです。
私は優先順位付けを優先します。優先順位付けは、小さな重要な変更を高率で提供することに偏っています。これは、修正するのに多くの作業を必要とする深刻なバグでは、スケジュールを設定するために十分な優先順位を取得するために、その作業を小さなチャンクに分割する必要があることを意味します。