设计会话（Design Session）与简单设计（Simple Design）

　　设计阶段所引入的缺陷不仅包括设计本身的缺陷还包括了因编码人员对设计方案理解的错误和偏差而引入的缺陷。极限编程所强调的是简单设计虽然一定程度上降低了设计本身缺陷的概率，并且也有助于降低设计方案理解偏差而引入缺陷的可能性。但是，从经验过程控制和缺陷预防的角度来看，我们仍然需要将编码人员对设计方案的理解这一影响质量的因素成为可观察的因素，并对其进行检查。

　　笔者在所带的项目中开展设计会话活动。在设计会话中，通常由设计人员借助白板讲解设计方案，其他人员对讲解的内容有疑问和异议时可以提出集体讨论。主讲的设计人员也可以针对其讲解提出一些问题让其他参与人回答，以确定参与人是否真正理解设计方案。设计会话结束后，白板上的内容可以先保留一段时间，以方便事后再查看。有条件的团队也可将其拍照存档。设计会话中所讨论的设计方案可以事后由编码人员写入 Story 文档。由于相关人员事先都参与过设计会话，在 Story 文档评审时对其中的设计部分多少也许自己的认识和意见，这有助于发现对设计方案理解的偏差。

　　设计会话体现了《敏捷宣言》中提到的“个人与交互胜过过程与工具”这一价值观，避免了仅仅通过设计规格说明沟通设计方案导致的沟通效率低下、设计方案理解偏差的问题，充分发挥了人与人直接沟通的优势。

表 3. 设计会话

　　单元测试评审

　　单元测试是软件开发中被普遍接受的优秀实践，也是影响软件质量的一个重要方面。有效的、充分的单元测试能够提高代码质量，从而有效避免了返工。但是如何保证单元测试得到有效的执行呢？按照经验过程控制的思想，我们可以先使单元测试成为一个可观察的因素，然后对其进行检查。检查过程中发现偏差时及时进行纠正从而保证单元测试得到有效的执行。

　　定义单元测试的产出物可以使单元测试活动成为可观察的因素。对单元测试产出物进行评审可以发现单元测试所覆盖的测试用例是否真正执行通过以及测试用例覆盖是否充分。若单元测试评审过程中发现有测试用例未通过的或者遗漏的，则及时反馈给开发人员进行纠正，从而避免了缺陷进入下一道工序——Story 测试。

　　笔者曾经在一个基于 SOA（Service Oriented Architecture）的项目中将单元测试过程中系统所产生的接口日志文件定义为单元测试产出物。在这个项目中，开发人员会将单元测试过程中每个测试用例执行时系统所产生的接口日志文件按所覆盖的测试用例的名称进行命名提交到配置库上，然后知会其他项目组成员进行评审。由于这个单元测试产出物能够反映系统所要实现的功能，评审人员可以通过分析产出物判断每个测试用例是否真正执通过以及测试用例是否覆盖充分。评审者把评审过程中发现的测试用例未通过或者未覆盖等问题会整理成评审意见提交到配置库上，并知会开发人员进行处理。

表 4. 单元测试评审活动