解决哪些bug会带来最大的成本效益

Question

我想根据它解决的容易程度和它能给我带来多大的好处来对bug进行分类。例如，如果有一个bug需要一个小时(双文件关闭等)。解决与另一个需要一天(分割错误)的问题。但是，如果解决第一个错误不是很重要，那么我可能会研究第二个bug。

是否有一种实用的方法或方法来根据成本效益或类似的指标对bug进行分类？

假设可以根据错误特征(例如安全漏洞、内存错误、逻辑错误等)对bug进行分类。另一方面，可能存在困难(容易、中等、硬)等参数。我还需要寻找其他的维度吗。为了简化事情，我可以假设两件事：

1. 团队中的每一个程序员都同样有能力解决任何错误。
2. 没有最后期限

Answer 1

你描述的问题很常见，最好的答案可能是“用你的直觉”。

我通常将bug分为三类:崩溃、烦人、化妆品(它们可能被称为1、2、3--这并不重要)，然后对修复每个bug所需的时间做一个总体估计(所有的bug都必须随时有一个粗略的更新估计)。

当解决bug时，崩溃>恼人>化妆品，然后我只做一个“最短的工作优先”，以获得尽可能多的初始吞吐量。

我发现很难计算从解决任何错误中获得的任何直接经济利益--除非这是一份范围非常紧的有偿工作。

您可能需要注意的一点是，您确实应该在乔尔试验上实现第五点--这可能会受到团队规模和在其他各种“本地”问题中的分布的影响，但这通常是良好实践的标志。

Answer 2

另一个考虑因素可能是在试图确定bug和修复的影响和成本时，发现错误的测试或测试组织的类型。单元测试或功能测试可能指向设计中需要更改的内容，因此，早期纠正可能比以后更容易，成本更低。系统测试或集成测试可能指向一些影响更广泛的客户的东西。而标准测试，虽然对大部分客户来说往往是非关键的，但如果不加以纠正，可能会导致认证的丧失，并对业务产生负面影响。

也就是说，仅仅因为一个特定的测试组织有一个测试失败，就不应该自动使一个bug变得“关键”。例如，可能会有一种诱惑，比如“所有系统测试都必须在交付之前通过，因此任何系统测试如果失败，都会自动导致严重/高度严重的错误”。希望没有任何组织会这么说(好的测试退出标准是一种不同的讨论)，但问题是，错误的“严重程度”应该根据它对客户、产品或公司形象的影响来判断，而不是在什么地方或什么时候被发现。

解决这一问题的一个可能方法是区分“严重性”和“紧迫性”。例如，随着发布日期的临近，可能会有时间压力来确定一个明显较低的bug是否会影响一大部分客户，从而使该bug具有更大的“紧迫性”，并将该bug的工作提升到(一些)之上，至少直到确定为止。两者之间的适当平衡，加上经验和良好的判断，将有助于指导花费时间和精力的地方。

Answer 3

除了其他人所说的关于bug的分类等，还可以考虑使用传入耦合(Ca)来确定某一特定bug可能代表的临界程度。如果您在一个具有高Ca计数的模块中有一个bug，我可能会考虑首先修复这个错误，因为它可能会使系统中的其他组件受益。Ca可以帮助您确定责任的级别，其中包含bug的负责任模块损害了整个应用程序(请阅读更多关于Ca的信息：http://www.ibm.com/developerworks/java/library/j-cq04256/index.html)。

考虑到这一点，我们倾向于对bug进行分类，并根据它们对客户的影响来确定它们的优先级。您的客户会有所不同，但是让他们参与讨论将最终驱动哪些bug应该被修复而不是其他的。这并不是真正的科学，但作为一个整体，我们倾向于就big的优先级和分类达成共识，每个人都有关于“大big”的输入(所有涉众都可以提供输入)，我们从那里开始堆叠和排列。