把每个缺陷都当作潜在的改进机会不仅仅是一个口号，成熟的组织会将其作为一个常态化的实践。相信赵耀同学这篇文章能帮助大家对让这个实践落地的方法有个全面的了解。

在CMMI模型中，改进似乎被作为一种比较高级的玩法，好像需要做到很多低层级的PA后才能开展，但我觉得其实任何时候都可以改进。改进并不一定是翻天覆地，可以是静水潜流，积沙成塔。下面介绍一种在开发过程中比较容易使用的改进方法：EDA分析。

EDA是Escaped Defect Analysis的缩写，即逃逸缺陷分析。逃逸缺陷是指在开发过程中，没有被应该发现的环节发现，而遗漏到下一环节的缺陷。例如应该在开发环节发现的缺陷，却遗留到测试环节；应该在测试环节发现，却遗留到客户那里的缺陷。

Why：当缺陷转换成故障，在客户那里被暴露时，需要复现、定位、升级等，代价是很高的。反之如果缺陷被测试团队发现，代价会更小。进一步，如果缺陷被开发团队发现，代价则更小。以下是一组业界使用瀑布开发模式的软件项目在不同阶段缺陷发现成本的统计数据，从中可以很直观的看到这一点。

因为这个原因，对逃逸缺陷进行分析，确定缺陷为什么会被逃逸，预防进一步的逃逸，以及驱动在开发过程中尽可能的多发现缺陷是有好处的。这也将降低开发的成本，提高软件产品的质量。

What：EDA分析也是一种缺陷预防的过程，通过对逃逸的缺陷进行分析，找出缺陷引入和逃逸的根因，并据此对开发，测试过程进行改进，防止相同的问题再次发生。

Who：那么什么样的缺陷可以进行EDA分析呢？我认为开发过程中的任何问题都可以，但考虑到成本，需要选择性开展。例如，可以包括软件开发环节遗漏到测试环节的严重缺陷；从测试环节遗漏到客户那里的网上问题；以及你认为不该在本阶段出现的各类问题。EDA只是一套改进思路和方法，可适用用各类问题的分析，与开发模型、项目类型并不强相关。

When：什么时候可以进行EDA分析呢？只要有缺陷产生时，都可以进行分析。例如在一次评审结束时，作者可以自己分析一下为什么有些缺陷自己自检时没发现，而被别的评审专家发现了。在一轮迭代级测试结束时，可以分析为什么这些问题自检、评审时都没有发现。

How：如何进行EDA分析呢？其过程如图所示，分为五步：

1.  缺陷标识：对发现的缺陷进行分类，标识需进行EDA分析的缺陷。由于发现的缺陷数量可能很多，不可能对所有缺陷都进行分析，所以需要挑选一些典型的，有代表性的，项目组可自行定义规则，例如分析严重类问题，数量较多的某类问题，数量较多的低级问题等。

2.  缺陷分析：对缺陷进行根因分析，分析两方面的内容：

1)   缺陷的引入点，是什么活动引入的，引入原因是什么；

2)   缺陷的控制点，缺陷在什么活动中逃逸，为什么会逃逸。

3.  措施制定：根据分析结果制定改进措施，措施包括三方面：

1)   对引入点改进的措施，预防此类问题再次发生。根据质量回溯的理论，问题的根因往往在引入点中，即缺陷是如何产生的。如开发人员缺乏技能，没有流程规范等。

2)   对控制点改进的措施，完善开发过程，增加控制活动，避免缺陷再次逃逸。如增加评审，强化测试等。

3)   判断产品中其他地方或组织内其他产品是否会存在类似问题，并一起修改，进行清零。

4.  措施执行及效果分析：执行改进措施，并通过分析度量数据、柏拉图等方法，将新的逃逸缺陷密度、分布与之前的逃逸缺陷进行比较，判断EDA措施的效果。如果效果未达成，说明可能没有分析到位，或措施不理想，需要重新进行分析，优化措施。有些措施需要较长时间才能看出效果，可能无法马上见效，但只要在项目中建立了EDA分析的思想和习惯，经过一段时间的实施，相信项目组交付的产品缺陷会越来越少，质量会越来越好。

5.  结果固化：如果同类缺陷逃逸减少，预防的措施效果明显，并且此措施也可复制到其他项目组，可将此措施固化到组织的流程制度中，在后续的项目中使用。

EDA分析的思路和过程比较简单，其关键在于对逃逸缺陷的分析是否到位，问题找到了，措施才能更有效。还有就是要在项目中贯彻其思想和长期坚持使用，每天改进一点，慢慢的效果就会体现出来。