我们应该修复该错误吗?

时间:2020-03-05 18:51:57  来源:igfitidea点击:

在对发行版的错误进行分类时,通常使用什么标准来确定该发行版的错误是否得到修复?

解决方案

回答

  • 对用户的影响程度
  • 出现频率
  • 有解决方法吗?
  • 修理费用
  • 修复时间
  • 发布截止日期之前剩余的时间
  • 可以进行修复的资源的可用性

回答

以我的经验,这只是:

  • 错误的严重性
  • 发行前的免费开发时间。

回答

批判性,影响力和金钱通常。

  • 关键程度:会发生什么?它会破坏数据,导致系统崩溃吗?
  • 影响:有多少人会受到影响?
  • 金钱:如果我们(不)解决问题,有人会付给我们(或者更糟糕的是,代扣代缴)吗?

回答

我编写的是RDBMS服务器软件,因此任何可能导致数据损坏的错误都将立即成为制胜法宝。同样,任何可能导致数据库服务器在相对正常使用下崩溃的错误都将获得资格,就像从查询返回不正确的数据一样。

它还必须取决于该修复程序有多不稳定,需要花费多长时间。

回答

关于这一点的规范文章是埃里克·辛克(Eric Sink)的《我作为代码经济学家的生活》。

确实值得阅读这篇文章,但是如果我们希望在清单中为我们总结一下:

  • 当此错误发生时,影响有多严重? -严重程度
  • 该错误多久发生一次? - 频率
  • 要解决此错误,需要花费多少精力? - 成本
  • 修复此错误的风险是什么? - 风险

回答

如果严重性很低并且产品即将发布,对我们来说非常常见,最好将修复程序保存为下一个版本。

让睡觉的狗说谎是原则。

有一点需要将代码锁定。代码修复需要进一步的回归测试,这需要时间。

悲伤但真实。

回答

这绝对是一个特定于域的问题。我为对冲基金,道具交易台,共同基金等编写大型交易应用程序,因此:

  • 违反合规性或者引起其他法律问题的事情非常^ 4
  • 可能导致过度交易的事情(我们想购买100,000股DTE,但我们却得到了100,200)非常糟糕3
  • 阻止客户在他们想要的时候进行交易的事情很糟糕2
  • 给客户带来不便的事情是很糟糕的

前几天,我确实与" Bug Triage Manager"(Bug分类诊断经理)进行了交谈,该经理在另一个领域工作。他简单地说:

First I fix the crashing, then I fix the things that cause us to lose money, then I fix the things that makes us look bad, then I fix everything else.

回答

影响严重性的事情我在这篇文章中还没有看到。

  • SLA-对SLA有影响吗?
  • 内部(维护)vs外部收益-外部收益几乎总是获得更高的优先级
  • 视觉与功能-功能通常获得更高的优先级
  • 谁找到的? (客户与同事)-客户获得更高的优先级

回答

通常,我们会在发布周期之外修补会导致系统崩溃的所有错误。

其他任何错误都将添加到产品积压中,并与新功能一起排定优先级。在确定发行版中的内容时,我们仅以最高优先级执行这些任务。这对我们来说很好,因为我们有每月发布周期。

我们使用了与其他线程在此线程中优先级相同的优先级系统,但有一个例外,即客户可以付费以提高错误(或者功能)的优先级。

回答

关于"零缺陷"的心态有很多话要说。任何类型的错误都应始终放在栈顶,否则最终它们将使我们不知所措。

当然,在现实世界中,提供出色的新功能,以便赢得新的大客户可能比解决一些小麻烦更重要。上市时间确实确实会超过质量。

回答

是否值得通过不修复它而陷入技术债务,或者进行快速而肮脏的修复,以期稍后对其进行适当修复。

回答

已经有很多不错的答案,当然情况取决于项目/公司/错误/发布时间/依赖项/ ...

但是,我发现以下两个指标很有用。

  • 有多少用户受到影响?
  • 他们受到的影响有多严重?

两个变量上标记的bug越高,应尽快修复。

回答

我同意@Chris Upchurch的观点,但我认为一个关键因素是在进入关键时刻之前要征得所有各方的同意。这样一来,我们就可以在检查清单上花费最少的咬牙和重拳。

回答

就做出决定而言,不能根据严重性,影响,成本等来更好地解决问题。

但是,在应用这些规则时需要谨慎一点。
我参与了太多的项目,这些项目由于不承担任何责任而被遗忘而无法控制。我想出的最佳工作规则是

  • 如果发现错误,请提出错误报告
  • 如果可以修复,请执行此操作。 (由于存在该错误,因此可能需要报告,因此会提出报告)
  • 如果团队负责人理解该错误,则必须分配优先级(或者团队使用的其他措施)。添加"这实际上意味着什么"信息。团队负责人必须(部分)控制错误列表,这一点很重要。
  • 查看未修复的错误/在管理级别上没有优先级的错误。不了解的错误是巨大的风险,应有的能力应有机会了解风险。
  • 始终在项目范围内查看哪些是最重要的错误(可以将其与优先级分开,例如,排名前5的列表)
  • 鼓励程序员在开发任务中修复错误

然后,当我们考虑发布时。

  • 分支代码并引发功能冻结
  • 确定我们要修复的错误(无需订购它们:-))
  • 仅将可在冻结代码上复制并同意的错误添加到此列表