作为内部研究项目的一部分，我们正在尝试从 Bugzilla 数据库收集一些指标；我们已经找到了一个工具来帮助我们从中收集一些指标 (BugzillaMetrics)，但我们现在问自己应该收集哪些指标？
现在，这就是我想问你的原因：
**
**
在我们的办公室，团队很小（2 到 5 名开发人员），我们考虑了每个开发人员的错误、每个开发冲刺、每个类别（GUI、业务逻辑、数据库）的错误等指标，但我们想听听一些其他想法。
提前致谢 =)
【问题讨论】：
标签： metrics
其中一个相关指标是在一个时间单位（例如，周、测试迭代等）上发现的缺陷数量。这可能是一个很好的指标，表明何时可以停止测试和修复。当然，这个指标也可以考虑 bug 的优先级（如果每周报告 10 个微不足道的 bug，您可能会比每周报告 1-2 个主要缺陷更不感兴趣）。
您可能会发现另一个有用的指标是修复缺陷的平均时间（报告和修复/关闭错误之间的时间）。
【讨论】：
每个类别的错误肯定。我也会对实际花费的时间进行时间估算。这一点为开发人员提供了一个工具来学习如何进行准确的估计。估计时间是一个出了名的模糊过程，你最好的来源是经验。使用此指标，您可以获得对每个人给出的估计的信心。
但是请注意，您仍然不能只说 Bug X 应该花费 Y 时间，因为它类似于 Z Bug。但是您可以让 Developer Baker 看看它，当“需要 2 天才能修复”时，您可以判断他的准确程度。
【讨论】：
我建议以下指标列表：
【讨论】：
以下是比较有用的：
每次迭代发现的 CRITICAL 和 MAJOR 错误的比率，以及解决这些错误所花费的平均时间。 例如CRITICAL 可以在几小时内确定目标，MAJOR 可以在几天内确定目标，可以根据历史数据修改目标以具有现实挑战性。
没有。发布时产品中剩余的主要错误。根据产品/行业/客户的不同，发布 3 或 5 或 7 MAJOR 可能是可以接受的。 {{ 假设 CRITICAL Bugs = 0 即不可接受。 }}。
高优先级生命周期比率：P1 解决时间与所有优先级的平均解决时间之比。
Reopened Rate : CRs 重新打开的案例占迭代中已修复案例的百分比。
2 天内没有评论/答案的 CR：创建后 2 天内没有得到研发部门回复的案例的比率。
严重错误的优先级 阻止程序和关键 CR 的平均优先级
解决的案例与解决方案无效的比率 |或重复。
苏西尔·贾拉利
【讨论】：