跟踪或测量错误的原因是否可行，或者这只是要求产生意想不到的后果？

Question

有没有一种方法可以跟踪或测量错误的原因，而不会导致开发团队成员的意外后果？我们最近添加了在跟踪系统中分配错误原因的功能。原因的例子包括:错误的代码，错过的代码，不完整的需求，缺失的需求，不完整的测试等。我不是这个的支持者，因为我可以看到它导致了开发团队的意外行为。到目前为止，这个领域一直对团队成员隐藏，没有积极使用。

现在我们正处于一个项目的中间，我们有一个比正常数量更多的错误，这种类型的信息将是很好的，以便更好地了解我们哪里出错了，我们可以在未来进行改进（或现在进行调整）。为了获得关于错误原因的良好数据，我们需要打开这个字段供开发和qa团队成员输入，我担心这会导致不良行为。例如，人们可能不想修复他们没有创建的缺陷，因为他们会觉得它对他们的表现反映不佳，或者人们可能会因为类似的原因而浪费时间争论缺陷的分类。

有没有人找到一种机制来做这种类型的跟踪，而不会造成不良行为？如果我们向团队解释数据背后的原因（不是为了推动单个绩效指标，而是项目成功指标），是否有可能期望团队成员提供有用的数据？有没有另一种更好的方法来做这种事情（也许是一个更临时的验尸或对问题的公开讨论）？

Answer 1

很多版本控制包都有这样的东西 svn blame.这不是跟踪错误的直接指标，但它可以告诉您谁签入了对包含主要错误的版本的更改。

还有像这样的节目 http://www.bugzilla.org/ 这有助于随着时间的推移跟踪事情。

但就真正挖掘bug存在的原因而言，是的，它绝对值得研究，尽管我无法给出收集这些信息的标准指标。一个系统可能会有很多错误的原因:

• 写得不好的规格
• 匆忙的时间表
• 低技能编程
• 士气低落
• 缺乏beta或QA测试
• 缺乏准备软件，以至于beta或QA测试甚至是可行的
• 清理bug与获取新功能的时间比例很低
• 在实现无bug增强和实现功能方面所花费的时间比例很低
• 一个非常复杂的系统，很容易被打破
• 代码库之外的不断变化的环境，例如计算机管理
• 对影响程序员薪酬或晋升的错误负责

仅举几例。..如果太多的bug是一个大问题，那么管理层和领导程序员以及整个过程中的任何其他利益相关者都需要坐下来讨论这个问题。

Answer 2

高误差率可能是太冲程或不灵活的时间表的症状。切换到零缺陷方法可能有所帮助。在处理新代码之前修复所有错误。

分配原因是一种很好的技术，可以看出您是否有问题区域。我看到和遇到的典型指标是偶数分裂：

• 规范错误（丢失，缺失等）
• 应用错误（不正确的代码，丢失的代码，坏数据等）
• 不正确的测试/没有错误（通常不正确，或尚未实施的规格）

reveiwing并验证缺陷原因可能是有用的。