2

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

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

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

4

2 回答 2

1

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

还有像http://www.bugzilla.org/这样的程序可以帮助跟踪一段时间内的事情。

但就真正深入研究为什么存在错误而言，是的，这绝对值得研究，尽管我无法给出收集该信息的标准指标。系统可能有很多错误的原因有很多：

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

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

于 2010-07-14T20:00:35.780 回答
0

高错误率可能是日程安排过于匆忙或不灵活的症状。切换到零缺陷方法可能会有所帮助。在处理新代码之前修复所有错误。

分配原因是查看您是否有问题区域的好方法。我见过和遇到的典型指标是：

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

审查和验证缺陷原因可能很有用。

于 2010-07-14T20:19:46.507 回答