Process 跟踪或测量bug的原因是可行的，还是这只是要求产生意外后果？

是否有一种方法可以跟踪或测量bug的原因，而不会导致开发团队成员的意外后果？我们最近增加了在跟踪系统中指定错误原因的功能。原因的例子包括：错误的代码、遗漏的代码、不完整的需求、遗漏的需求、不完整的测试等等。我不是这方面的支持者，因为我可以看到这会导致开发团队的意外行为。迄今为止，此字段已对团队成员隐藏，未被积极使用

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

---

有没有人找到一种机制来进行这种跟踪而不导致不良行为？如果我们向团队解释数据背后的原因（不是为了推动个人绩效指标，而是为了项目成功指标），是否可能期望团队成员提供有用的数据？有没有其他更好的方法来做这类事情（可能是更特别的事后调查或对问题的公开讨论）？

很多版本控制软件包都有类似于

svn的问题。这不是跟踪bug的直接指标，但它可以告诉您谁签入了对有重大bug的版本的更改

也有类似的程序帮助跟踪时间的推移

但就真正深入了解bug存在的原因而言，是的，这绝对值得研究，尽管我无法给出收集这些信息的标准度量。系统可能有很多问题的原因：


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

这只是举几个例子。。。如果错误太多是一个大问题，那么整个过程中的管理层、首席程序员和任何其他利益相关者都需要坐下来讨论这个问题。
高错误率可能是日程安排过于匆忙或缺乏灵活性的症状。切换到零缺陷方法可能会有所帮助。在处理新代码之前修复所有错误

指定原因是一种很好的方法，可以查看您是否有问题区域。我所看到和遇到的典型指标是：


规范错误（缺失、不正确等）
应用程序错误（错误代码、丢失代码、错误数据等）
测试不正确/无错误（通常预期不正确，或规范尚未实施）

发现和验证缺陷原因可能很有用。
@stimy:这些答案对你有用吗？我想我更担心的是当你要求开发人员提供这些信息时会发生什么。他们不愿意。。。他们最终会因为责任而争吵吗。。。他们是否最终不想承担额外的缺陷，因为责任是负面的。这正是我担心的事情。@stimy:你完全正确。这必须以一种非威胁性的方式进行设置，其中bug报告用于跟踪事情，使它们更容易修复，从而使程序员更容易处理；否则，这和指指点点是一样的。如果跟踪的内容包含某种指责特征，那么所有利益相关者都必须承担同等责任。i、 e.尖叫的销售人员和差劲的项目经理必须平等对待可预防的错误和发布或测试中的严重失误。