问测量每小时开发时间中的bug计数有价值吗？

EN

No

测量每小时开发时间的bug计数绝对没有价值。对于每个开发人员来说，每小时测量bug数尤其糟糕。

对于更复杂或更困难的代码，开发人员通常比开发更干净、更简单的代码的开发人员有更多的bug/小时。类似地，在漫长的工作日结束时，devs会产生比开始时更多的bug/小时。

不明确的需求将产生比清晰、结构良好的需求更多的bug。

如果devs因错误过多而受到惩罚，一些测试人员将开始非正式地报告问题，以避免成为devs受到惩罚的原因。其他人很可能会决定变得小气，制造许多小虫子来惩罚他们不喜欢的人。

另外，在单个应用程序--崩溃的bug和一些小的小bug之间有一个区别--哪个对应用程序来说更糟？这些琐碎的bug将被视为比使用这种度量标准破坏应用程序的bug更具有破坏性。

在我看来，使用诸如bug计数/小时之类的东西的唯一方法是，作为一个平均值，用来预测您需要在bug修复计划中留下多少空白:如果团队A通常会产生0.05个bug/小时，而五分之一的bug通常需要修复，那么在500个小时内可能会产生25个bug，其中5个可能需要在发布前修复。如果每个bug修复(包括测试)的典型时间是5个小时，您将包括大约25个小时的填充，以涵盖可能的错误修复。

(请注意:这些数字不是真实的--它们只是为了说明应该如何使用该指标)

就像凯特说的

有经验的人对某种度量标准的通用术语是：

一个糟糕的度量

我会更进一步说，任何一种细菌计数都有可能被耍

这个行业已经做过这样的事情了，比如“衡量生产率的代码行”。你可以想象那会通向哪里！也许几行行才好呢？不是的！这将导致单线代码高尔夫比赛！不可维护的软件！

我强烈建议使用不同的质量标准。

以下是一些很好的衡量标准：

• 从故障中恢复的平均时间(进行更改、运行测试、发布修复)
• 与昨天/上周/上个月/去年相比的用户数
• 与以往期间相比的收入数额
• 转换-客户到达工作流程上某些点的度量
• 设备使用情况与以往周期的比较

同样，正如Vertax所暗示的，并不是所有的bug都是相等的，或者需要付出相同的努力来修复。

我使用的"1000颜色发布错误“比1”我不能使用支付(唯一的收入来源)“错误，但可能比”我必须点击两次“更重要。这一切都取决于太多的因素，是特定于你的情况。

不，

原因有很多。首先，bug是不可量化的。你不能把它们加在一起，然后推断花费的时间。其次，可能很容易修复的bug(可能只修改了一行)可能需要花费许多小时的调试才能找出问题所在。尽管我们希望我们的解决方案有足够的自动化测试覆盖率，并且bug报告包含足够的信息以深入到实际问题，但这并不总是显而易见的，因此，每个开发人员可能有不同的时间来了解需要修复的内容。(如果您在sprint中讨论了这些问题，并且有足够的文档，这会有所帮助)。

一个更好的衡量标准可能是从逻辑上看，与代码的某些特性/部分相关的bug。bug有一种奇怪的聚类倾向，有时这是一个迹象，表明您在开发过程中过于匆忙，在将bug引入到待办事项中之前，可以捕获并修复一些bug。现在，这是否意味着，在sprint期间，您应该禁止在特性中输入bug？不，因为可能总是会引入隐藏的缺陷，这些缺陷甚至是不可触发的，直到在将来的某个点进行更改，从而暴露错误的代码。

最好将它们用作代码健康的度量，确定将资源集中在何处进行修复，而不是作为Dev或Tester‘quality/ code’的度量。