作为内部研究项目的一部分，我们正在尝试从Bugzilla数据库中收集一些指标;我们已经找到了一个工具来帮助我们从中收集一些指标（BugzillaMetrics），但我们现在要问自己应该收集哪些指标？
现在，这就是我想问你的原因：
**
**
在我们的办公室，团队很小（2到5个开发人员），我们已经考虑过每个开发人员的错误，每个开发冲刺，每个类别的错误（GUI，业务逻辑，数据库）等指标，但我们希望听到一些其他想法。
提前致谢=）
答案 0 :(得分：4)
相关指标之一是在时间单位上发现的缺陷数（例如，周，测试迭代等）。对于何时可以停止测试和修复，这可能是一个很好的指标。当然，这个指标也可以考虑错误的优先级（如果每周报告10个琐碎错误，那么你可能不太感兴趣，而不是每周有1-2个主要缺陷）。
您可能会发现另一个有用的指标是修复缺陷的平均时间（报告和修复/关闭错误之间的时间）。
答案 1 :(得分：2)
每个类别的错误肯定。我还会做时间估算与实际花费的时间。为开发人员提供了一个学习如何进行准确估算的工具。估计时间是一个众所周知的模糊过程，您的最佳来源是经验。使用此指标，您可以对每个人给出的估算值充满信心。
但是请注意，您仍然无法说Bug X应该花费Y时间，因为它与Z Bug类似。但是你可以让开发者贝克看看它，当“需要2天时间来修复”时，你可以判断他的准确程度。
答案 2 :(得分：1)
我建议遵循指标列表：
答案 3 :(得分：1)
以下是更有用的：
每次迭代发现的CRITICAL和MAJOR错误的比率，以及解决它们所需的平均时间。 例如可以在几个小时内针对关键时段和几天内的主要目标进行定位，目标可以根据历史数据进行修订，以实现真正具有挑战性的目标。
没有。发布时产品中剩余的MAJOR Bugs。根据产品/行业/客户，可以接受3或5或7 MAJOR的发布。 {{假设CRITICAL Bugs = 0，即不可接受。 }}
高优先级终身比率：P1分辨率时间与所有优先级的平均分辨率时间的比率。
重新开放率：CRs迭代中固定的重新开放案例的百分比。
2天内没有评论/答案的CR：创建后2天内没有R＆amp; D回应的案例比例。
严重错误的优先级阻止者和关键CR的平均优先级
具有分辨率INVALID |的已解决案例的比率或者重复。
Susheel Jalali