为什么我们需要优先级和严重性？

我了解他们的决定，但是将其分配给发现的问题真的有用吗？我的意思是，要么需要快速修复，要么不要求修复。

我知道如何设置它们，对其进行分类等。我知道IEEE / ISO确实需要这样做。我只是不明白为什么。

绝对有可能使这些值不同。如果您要出售给需要高性能但又不会使用模块X的重要政府机构，那么比X模块中的严重错误更早修复较小的数据库可用性错误在很大程度上具有商业意义。基本上，技术原因不是您从事软件业务的唯一因素。

日期和时间错误

错误：年末处理将完全破坏您的数据库。这显然是一个严重的错误。

日期：12月15日。该错误具有很高的优先级。

日期：2月1日。该错误的优先级较低。

意外发射导弹漏洞

错误：从2月28日到3月1日，ICBM控制软件会被4整除的年份。

这与可能存在的错误一样严重。但是，优先级非常低-触发条件时，是否有实际的机会使用该软件？

屏幕上不经意的“坏”字

错误：消息在屏幕上的空间溢出时，会导致无意中亵渎了对Bob的引用。（现实世界：我们在“最终屁股”部门工作。“屁股” =“装配体”。）

不幸的是，明天您将在演示文稿中说明如何获得销售对公司而言是成败。您正在向名为“鲍勃”的人做演示。严重程度：非常低。优先级：非常高。

你写了：

我的意思是，要么需要快速修复，要么不要求修复。

那是对的。但是，如果您像大多数公司一样，您的资源是有限的。您可能没有足够的人员来解决所有问题，或者您没有足够的时间。

鉴于需要快速修复或不快速修复错误，并且您有很多错误需要修复，因此“优先级”回答了以下问题：“我应该首先修复哪个”？

另一方面，严重性是设置优先级的人员使用的指标。从开发人员的角度来看，严重性是一个有争议的问题。从一项分配工作的角度来看，严重性是有助于决策过程的重要信息。

当然，所有这些都是非常笼统的信息。如果您的团队积压了很长的错误，那么优先级和严重性就意味着与拥有几乎空的错误数据库的团队完全不同。

如果您所在的团队具有“高严重性==高优先级”，那么这都不重要，也不需要两个指标。归根结底，这些只是工具。您的团队需要决定如何使用它们。对于您的团队来说，同时使用两者可能没有任何意义。

恕我直言，将优先级和严重性都放在官僚机构中。

实际上，您只需要一种“重要性”度量。通常，将优先级用于优先级，然后将严重性用作技术术语，例如“高=崩溃系统或使其无法使用”，“中等=有故障的行为，潜在有害”，“低=令人讨厌，烦人但无害”

通常，优先级与严重性并存。一些反例是“每个人总是抱怨的烦人”或“在异国环境中曾经发生过一次崩溃”。

...但是，最后，作为开发人员（或经理等），您只需要知道您应该按什么顺序来解决/改进问题，仅此而已。因此，一种措施就足够了。

优先级的需求很明确：要知道应按什么顺序处理错误报告。另一个是惯常的恕我直言，是官僚主义。你为什么需要它？对于优先级排序，它显然没有用。无论如何，后果（严重性描述）在错误报告中都有描述。

我什至认为这是有害的，因为它使得不清楚哪个错误更重要：

• 某些人可能会认为“严重”漏洞的优先级高于“高优先级”漏洞。
• 一些报告错误的用户可能会混淆严重性和优先级
• ...总的说来，它使人们更困惑于应解决错误的顺序

除其他答案外，请考虑这种情况：错误A将需要30分钟修复，严重性为“低”；错误B可能需要2周以上的时间才能修复，并且严重性为“高”。另外，错误B可能需要在开发团队中以及在团队外部进行大量讨论和协调；错误A可能会立即由单个开发人员修复。为错误A设置更高的优先级是完全可以的。

当然，“严重性”和“优先级”可以用不同的方式来解释。

在我自己使用的一个小型错误跟踪器中，我改用了“困难”和“优先级”，在这些问题中，严重性较高的问题始终具有最高优先级，并且我可能会根据难度决定推迟进行处理。

我不喜欢“严重性”的一件事是它仅适用于错误而不适用于功能。最好按优先级和难易程度排列所有问题的清单，因为它可以直接决定“下一步我该做什么”。

我已经在一家通过ISO9001：2007认证的软件公司中设计和实施了流程。自2007年以来，已经对该标准进行了更新，因此可能存在我不知道的其他要求...但是：

ISO9001标准旨在确保贵公司设计和实施具有反馈回路的过程，以在发现产品和过程缺陷时改进过程。

在设计阶段，需求集中在所建议的解决方案是否正确实施上是否会真正解决设计简介（验证），并检查实施是否已实际实现而没有缺陷（验证）

在反馈环路上，当发现缺陷时，仅记录缺陷是不够的。还需要评估缺陷的严重性，并优先考虑返工。

关键部分在于，您的特定公司如何决定评估其严重性并做出有关优先级的决策，ISO标准并未对此进行定义。这是公司决定和记录文件的商业和治理问题。

当将其写入标准作为要求时，任何一家认证公司都将具有围绕评估缺陷严重性的过程以及确定修复漏洞的工作优先级的过程。它们绝对是需要做出的两个单独的决定。

错误的严重程度只是一个数据点。客户影响是另一个数据点。还需要努力修复，缺陷寿命，产品中剩余的使用寿命以及公司决定在决策中包括的任何其他因素。一件事不应该写成“给产品经理决定优先权的缺陷”，因为它仅定义了做出决定的权限，并且没有定义他们遵循决定的过程。

我倾向于优先级排序，优先级排序倾向于提供大量的小而重要的更改，因为这似乎可以最大程度地提高产品的整体可靠性。这意味着，需要花费大量工作才能修复的严重错误，需要将其工作分解为较小的块，才能获得足够的优先级进行调度。

由于优先级和严重性存在很大差异的原因：

一个简单的例子。想象一下，如果您的位置狭窄，无法进行系统扩展，则某些算法的复杂度为O（N ^ 3），其中N是客户商店的数量。客户说明年将开设200家新店，所需的计算（货物分配，运输计划等）将无法及时完成。但是，此客户目前只有30家商店，资源也足够。优化此算法（达到O（N ^ 2）或更好）的任务绝对很重要（如果未实现，将会失去客户），但可能并不紧急：您有几个月的时间来实现新算法。

示例2：应用程序系统崩溃，但是由于升级或迁移，该版本在几天之内就无法使用。修复非常紧急，因为崩溃确实会影响用户体验，但是重要性不高。

当然，这两个参数使用某种度量标准（正式或非正式）统一起来以生成短期工作计划，因为后者是一维的（任务序列）。但从长远来看，它们将不会统一。