有些人争论说，缺陷必须在整个生命周期中进行跟踪，从而获得高质量的软件。另有一些人说反对早期跟踪软件缺陷。为也给组织确定出佳答案，你需要检查你当前的流程，并确定出问题所在区域。本文告诉你需要问题哪些问题、为什么它们很重要，及你如何使用这些答案为组织制定最好的决策，并尊重缺陷跟踪。

你所收集的数据有附加值吗？

少数人会对知名的软件工程原则产生质疑：越早发现缺陷，将会开发出越高质量的软件。但是这一原则所有组织的所有情况下都是真理吗？

几年前，我与之工作的到一个客户，他希望提高软件团队的敏捷性，但还要确保任何的变化都没有危及其CMMI 3级合规性。为了达到此目标，我们从构建软件团队使用的流程图开始。

我们故意不看客户的记录CMMI 3级流程，而是建立这些流程图，是基于人们告诉我们他们为了完成软件所都做了什么。我们通过流程资产（程序、模版、指南）给每一个流程图作上注释，这些资产是人们所使用的。所有存在于他们CMMI 3级流程仓库中的流程资产并没有结束于一个流程图上，而是成为了淘汰或合理化的备选。

在消除或合理化一个资产前，我们问几个问题：如果没有人使用仓库中的东西，它为什么还要存在？我们是否在浪费时间教导别人某个流程资产或步骤，这些步骤在流程中没有附加价值？我们是否确信，人们如果遵循了某个流程步骤比没有遵循的更有助于完成工作，且更高效？

让我给你一个具体的例子。此组织有一个缺陷跟踪系统，这个系统需要收集大量进行系统的缺陷数据——例如，阶段发现、阶段注入、缺陷类型、缺陷原因、什么阶段的缺陷应该被发现。这个过程也需要定期分析收集到的数据。当我们给缺陷跟踪系统建立了流程图，表明人们实际在做什么，我们发现所有人都访问了所有数据，因为缺陷跟踪工作的要求，但没有人返回后分析或使用这一数据。

在进一步的调查中，我们确定所有缺陷需求数据的原因是：有人错误地认为CMMI需要它。我们还发现，整个过程非常繁琐，实际上已经使人没有勇气进入真正缺陷中，真正发现它们。当我们合理化这一流程后，消除大部分的数据要求，甚至不再需要报告某些类型的缺陷，我们发现人们开始使用系统更加一致。这种行为提升了软件质量，最后加强了组织的CMMI合规性，因为人们遵从他们所定义的流程更一致。

跟踪缺陷：三个问题

这个故事说明了三个问题。我们如何确保我们没有危害组织的CMMI标准，当我们改进了缺陷报告系统时？为什么会减少缺陷需要输入的信息及减少缺陷类型报告，并改进质量？这是否使你面对了知名的软件工程原则：越早发现缺陷，软件质量越高。

为了解决这些问题的答案，我先来分享三个组织应该辨问的关于缺陷的问题，这将有助于你决定什么时候开始进行缺陷跟踪。

1.给软件质量造成大量麻烦的，两个或三个最常见的缺陷类型是什么？

2.什么时候这些缺陷会注入到产品中？

3.对于你要给每一个缺陷收集的你要考虑的每一部分数据，要问：谁会使用这些数据，当这些数据的帮助下，人们如何提升软件质量？

Pareto原则告诉我们，80%的缺陷产品造成20%的问题。经过多年努力我发现，大多数组织了解导致重大问题的，两三个常见的缺陷类型，而且当这些缺陷注入到产品中时，他们有很好的想法。我还发现，你不必收集大量的关于缺陷的信息，就可以采取有效的措施反击未来出现的问题，提升软件质量。

关注于最有价值的数据

我们怎么确保我们没有危害到CMMI合规性？一个常见的疑惑是，人们往往认为CMMI需要收集关于缺陷的数据。CMMI希望组织进行同行评审，并期望组织从同行评审中分析数据，如缺陷数据。但是CMMI不会告诉你，关于你的缺陷或缺陷类型你需要收集什么样的具体数据。

基于对组织有意义的原则下，每一个组织都应该确定出这些问题的答案。一旦你了解到什么样的缺陷是重点查找的，什么时候它们会流放到产品中，那么你不可以很容易地在生命周期中确定最佳时间来关注缺陷跟踪。

例如，如果组织因为缺乏定义或过早流放的不时需求而导致大量的麻烦的话，那么你就需要跟踪并及早采取措施消除这些缺陷。但是如果你的问题主要是在详细设计或编码，及越来越趋向稳定的需求上时，那么就不用过早地进行缺跟踪。

减少你所收集数据的数量，关注于最有价值的数据会给鼓励你的团队更一致地使用缺陷跟踪系统。与我们大多数人教导的相反，早期你发现的多少个缺陷并不重要；在缺陷要注入到你的软件时，发现更关键，更昂贵的缺陷才是更重要的。

通过先问这三个关于缺陷的问题，组织可以事先安排一个精益的缺陷跟踪系统，这将有助于关注更昂贵的问题，从而在你的缺陷投资中获得最佳回报。