问当只有一个一致的组织过程框架时，缺陷包含度量可以很容易地应用到组织级别上吗？

EN

合并缺陷管理听起来是个好主意，除非项目是正交的，以至于需要单独的缺陷管理系统。例如，一个独自进行测试的开发人员可以通过“子弹列表”来完成测试，而一个拥有客户向支持团队报告bug的分布式组织需要一个更重的过程。这是显而易见的，但重要的是要考虑您的整合将如何影响所有相关的开发人员，以及他们是否有购买的动机。

bug度量的问题在于，如果开发人员认为bug计数是衡量其性能的一种方法，那么他们可能会得到伪造的数字(将多个bug合并为一个，低估bug的影响，说他们在上游捕获了bug)。如果您向管理层提交报告，这将是一个特别大的风险。即使您得到了所有开发人员的支持，也可能会有很大的差异，仅仅取决于他们单独报告bug的方式。

缺陷控制模型，特别是似乎持有一个指数增长的成本曲线下游假设。虽然可能是这样，但是agilists 为改变成本曲线提出令人信服的论据。而不是尽早停止缺陷。我对任何假设固定成本曲线的度量方法都持怀疑态度，因为每个项目和错误类型都可能有一个截然不同的成本曲线。

如果下游捕获bug的成本要高得多，那么通过采用更好的工具、采用持续集成、自动化测试或其他敏捷实践来降低成本曲线可能是更好的解决方案。当然，在某些项目中，可能会有大量不可避免的下游成本(例如航天飞机代码)，在这种情况下，缺陷包含度量更有意义。

否则，在我看来，有用的“度量”是按类型对bug进行分类，以帮助分析任何系统缺陷。跟踪bug被捕获的位置(开发、集成或领域)对于分析也很重要，但正如我之前所说的，在将它们插入固定的成本曲线以获得单个数字时，我会犹豫不决。相反，可以通过跟踪开发人员使用Mylyn等工具在bug上花费的时间来估算修复bug的成本，尽管这需要开发人员遵守一些规则。

IMHO的意见(如果你不同意的话，请投反对票)这是正方形钉，圆孔。

像敏捷这样的过程框架之所以存在，纯粹是因为过程不像人那样重要(参见敏捷宣言)。这并不是说度量没有那么重要。例如，重要的速度与用户故事完成的速度有关。缺陷应该与用户故事相关联，并且是短暂的，否则它们就会变成另一个用户故事。但我离题了。

像TDCE和PCE这样的度量标准在敏捷这样的过程框架中没有意义，因为敏捷具体地运行与在宏项目级别上查看软件背道而驰，特别是在开发阶段之前固有地暗示了一组严格的需求的bug解决方案。

这就像试图测量培根的灰尘一样。当然，如果你尝试的话，你可能可以测量它，但你为什么要这样做呢？

话虽如此，流程框架鼓励开发专门满足项目或组织需求的自定义框架。我不明白为什么不能设计一个Mini度量，只要您觉得它对组织、产品和客户是相关的和有益的。

我从“CrossTalk”杂志上找到了一篇文章，名为将缺陷遏制推进到定量缺陷管理，是由雷神公司的两名工程师撰写的。本文描述了一种实现我想做的事情的技术--带来软件缺陷包含度量，并试图使它们在组织级别上有意义。他们称这种技术为定量缺陷管理(QDM)。

它以历史缺陷数据为中心，将当前的项目数据与历史数据进行比较。通过确定在过去类似的项目中在给定阶段中生成的缺陷的数量，可以估计在同一阶段的当前项目中所产生的缺陷的数量。当然，在一个包含持续改进的环境中，您可能会看到缺陷随着时间的推移呈下降趋势，但是您可以解释这一点。

一旦你知道了你的历史数据，你就可以把你在阶段中发现的缺陷和预测的数字进行比较。这允许您为每个开发阶段的各种缺陷检测策略分配时间和资源，以及检查您的缺陷清除和包含数据，以改进该过程以防止未来项目中的缺陷。通过对每个阶段的时间进行适当的预算，并不断地监控和改进用于检测缺陷的技术，人们可以期望在过程和产品质量方面都会有所改善。

作者还讨论了这个指标与六西格玛和CMMI (特别是4级和5级)的关系。

虽然这并不完全符合缺陷控制，但我认为这对管理人员来说是合适的。它将提供可以跨项目使用的数据，以便将当前的过程质量与以前的项目进行比较，为监测产品质量提供更多的数据，并(随着时间的推移)展示流程改进工作的有效性。