なぜ優先度と重大度の両方が必要なのですか？

私は彼らが何を決定するのか理解していますが、見つかった問題にそれらを割り当てることは本当に便利ですか？つまり、すぐに修正する必要があるかどうかです。

それらの設定方法、分類方法などを知っています。IEEE/ ISOがそれを行う必要があることは知っています。理由がわかりません。

これらの値を異ならせることは絶対に可能です。高性能を必要とするがモジュールXを使用しない重要な政府機関への販売がある場合、Xモジュールの重大なエラーよりも早くマイナーデータベース可用性エラーを修正することはビジネス上理にかなっています。基本的に、ソフトウェア事業を営む際には、技術的な理由だけが要因ではありません。

日付と時刻のバグ

バグ：年末処理によりデータベースが完全に破損します。これは明らかに重大なバグです。

日付：12月15日。バグの優先度は非常に高い。

日付：2月1日。バグの優先度は低い。

ミサイルバグの偶発的な発射

バグ：ICBM制御ソフトウェアは、4で割り切れる年で2月28日から3月1日まで行くと、おかしくなります。その結果、コマンドが発行されなくなります。

これは、存在する可能性のある重大なバグです。優先度は非常に低いですが、条件がトリガーされたときにソフトウェアが使用される現実的な可能性はありますか？

画面上の不注意な「悪い」言葉

バグ：メッセージが画面上のスペースをオーバーフローすると、ボブへの不注意な不敬な参照が表示されます。（現実の世界：「最終的な尻」部門で働く人々がいました。「尻」=「アセンブリ」。）

あいにく、明日は、会社にとって売り上げを得るかどうかのプレゼンテーションを行っています。「ボブ」という名前の人にプレゼンテーションを行っています。重大度：非常に低い。優先度：非常に高い。

あなたが書いた：

つまり、すぐに修正する必要があるかどうかです。

それは正しいです。ただし、ほとんどの企業のようであれば、リソースは限られています。すべての問題を修正するのに十分な人員がいないか、十分な時間がありません。

バグを迅速に修正する必要があるかどうか、および修正する必要のあるバグがたくさんあるという事実を考えると、「優先順位」は「どちらを先に修正するか」という質問に答えます。

一方、重大度は、優先度を設定する人が使用するインジケータです。開発者の観点から見ると、重大度は重要なポイントです。作業を割り当てる人の観点から見ると、重大度は意思決定プロセスに役立つ重要な情報です。

もちろん、これらはすべて非常に一般的な情報です。バグのバックログが非常に長いチームの場合、優先度と重大度は、バグデータベースがほとんど空のチームにいる場合とはまったく異なることを意味します。

「重大度==優先度が高い」チームに所属している場合、これは重要ではなく、両方のメトリックは必要ありません。結局のところ、これらは単なるツールです。チームはそれらの使用方法を決定する必要があります。あなたのチームにとって、両方を使用することは意味がないかもしれません。

私見、優先度と重大度の両方を置くことは、単なる官僚主義です。

実際には、「重要度」の尺度が1つだけ必要です。多くの場合、優先度が使用され、重大度は「高=システムをクラッシュまたは使用不能にする」、「中=バグのある動作、潜在的に有害」、「低=迷惑、迷惑だが無害」などの専門用語として使用されます。

通常、優先度は重大度と連動します。いくつかの反例は、「誰もが常に不満を言う迷惑」または「エキゾチックな環境で一度発生したクラッシュ」です。

...しかし、最終的に、開発者（またはマネージャーなど）としては、物事を修正/改善する順序を知る必要があるだけです。したがって、1つのメジャーで十分です。

優先順位の必要性は明確です。バグレポートに取り組むべき順序を知る必要があります。もう一つは、いつものように私見ですが、官僚主義です。なぜ必要なのですか？優先順位はそれを行うため、ソートには明らかに役に立たない。とにかく、結果（重大度の説明）はバグレポートに記載されています。

どのバグがより重要であるかを明確にしないので、私はそれが有害だとさえ思います：

• 「重大な」バグは「高優先度」のバグよりも優先度が高いと考える人もいます。
• バグを報告する一部のユーザーは、重大度と優先度を混乱させる可能性があります
• ...全体として、むしろバグに取り組むべき順序について混乱を招く

他の回答に加えて、このシナリオを検討してください。バグAは修正に30分かかり、重大度は「低」です。バグBの修正には2週間以上かかり、重大度は「高」になります。さらに、バグBは、開発チームやチーム外で多くの議論と調整を行う場合があります。バグAは、単一の開発者によってすぐに修正される場合があります。バグAに高い優先度を設定しても問題ありません。

もちろん、「重大度」と「優先度」は異なる方法で解釈される場合があります。

私自身の使用のために作成した小さなバグトラッカーでは、代わりに、重大度の高い問題が常に最も高い優先度である「難易度」と「優先度」を優先しました。

「重大度」について気に入らないことの1つは、バグにのみ適用され、機能には適用されないことです。「次に何に取り組むか」を決定する方がより直接的に役立つので、優先度と難易度の順に並べられたすべての問題の単一のリストを持つ方が良いかもしれません。

ISO9001：2007の認定を受けたソフトウェア会社でプロセスを設計および実装しました。2007年以降に規格が更新されているため、追加の要件があるかもしれませんが、気付いていませんが...

ISO9001規格は、製品およびプロセスの欠陥が特定された場合にプロセスを改善するためのフィードバックループを備えたプロセスを会社が設計および実装することを保証することに関するものです。

設計段階では、要件は、提案されたソリューションが正しく実装された場合に設計概要を実際に解決するかどうか（検証）と、実装が実際に欠陥なく実装されたかどうかを確認する（検証）に焦点を合わせます

フィードバックループでは、欠陥が特定されても、それらを記録するだけでは不十分です。また、欠陥の重大度を評価する必要があり、再作業が優先されます。

重要な部分は、特定の会社がその重大度を評価し、優先順位について決定することを決定する方法がISO規格で定義されていないことです。会社が決定し、文書化することは商業的およびガバナンスの問題です。

要件として標準に書き込まれているため、認定企業は欠陥の重大度を評価するプロセスと、バグを修正する作業の優先度を決定するプロセスを持っています。彼らは間違いなく2つの別々の決定を下す必要があります。

バグの重大度は1つのデータポイントにすぎません。顧客への影響は別のデータポイントです。製品を修正する努力、欠陥の年齢、製品の残存寿命、および会社が意思決定に含めることを決定したその他の要因もあります。「優先順位を決定するためのプロダクトマネージャーへの現在の欠陥」と書かれてはならない1つのことは、決定を行う権限のみを定義し、決定を行うために従うプロセスを定義しないためです。

優先順位付けは、製品全体の信頼性を最大限に高めるように思われるため、小さな重要な変更を高い割合で提供することに偏っている優先順位を優先します。これは、修正に多くの作業を必要とする重大なバグが、スケジュールを取得するのに十分な優先度を得るために、その作業を小さなチャンクに分解する必要があることを意味します。

優先度と重大度が大きく異なる理由：

簡単な例。システムのスケーリングを妨げる狭い場所がある場合を想像してください-アルゴリズムによっては複雑さO（N ^ 3）があります。ここで、Nはクライアントのストアのカウントです。クライアントは、来年に200の新しい店舗をオープンする予定であり、必要な計算（商品の配送、輸送計画など）が時間内に完了しないと言います。しかし、現在、このクライアントには30店舗しかなく、リソースは十分です。このアルゴリズムを（O（N ^ 2）以上に）最適化するタスクは間違いなく重要です（実装しないとクライアントを失います）が、緊急ではない可能性があります：新しいアルゴリズムを実装するのに数か月かかります。

例2：アプリケーションは体系的にクラッシュしますが、このバージョンはアップグレードまたは移行のために数日で使用できなくなります。クラッシュはユーザーエクスペリエンスに実際に影響するため、修正は緊急ですが、重要性は低いです。

もちろん、短期的な作業計画は単一次元（タスクのシーケンス）であるため、両方のパラメーターは何らかのメトリック（正式または非公式）を使用して統合され、短期の作業計画を作成します。しかし、長期的な観点では、それらは統一されてはなりません。