笔者在所带的项目中开展面对面代码复审。面对面代码复审活动中，代码作者通过电脑显示器或者投影仪向其他参与人展示其代码并逐行对其代码进行讲解。其他参与人则对其讲解进行分析判断，并将其分析判断的结果提出同其他复审人员进行讨论。复审人员发现比较优雅的代码时可以及时指出来，并对代码作者给予肯定。因此，面对面代码复审某种程度上也是编程经验和实践的一个交流形式。另外，对于经过讨论后确认的问题则记入代码复审意见表由复审人员跟踪其处理结果。代码作者对其代码讲解的过程某种程度上说也是其本人对其代码进行回顾和再思考的过程。因此，代码讲解过程中，讲解人往往会自己发现代码中的问题，从而对发现的问题有深刻的印象，这有助于避免同样或者类似的问题再次产生。另一方面，由于代码中的问题会当众暴露出来，对代码往往有种敝帚自珍心理的开发人员在代码复审前会小小谨慎地去检查代码，从而避免“当众出丑”。因此，面对面的代码复审某种程度上也是一种缺陷预防的措施。

表 5. 面对面代码复审活动

　　Story演示与转测试控制

　　《左传·庄公十年》提到“夫战，勇气也！一鼓作气，再而衰，叁而竭”。返工不仅增加了成本，阻碍了进度，还影响了士气降低了质量。返工往往是由于某道工序缺乏它的入口条件控制。比如，Story 转测试这道工序如果没有控制其入口条件，则很容易由于事先未评估被转测的 Story 质量导致在测试时仍然有大量的缺陷存在。这意味着在第一次转测试后，开发人员需要修复大量的缺陷，并且开发人员在修复缺陷的过程中往往又引入了新的缺陷，进而导致了对于同一个 Story 需要进行多次修复缺陷和多次转测试的工序才能使这个 Story 满足质量要求。

　　因此，对 Story 转测试这道工序进行入口控制可以有效避免返工现象。任何一个 Story 在其转测试前，我们要首先评估其质量是否满足一定的要求才决定其能否转测试。

　　笔者在所带项目中通常以 Story 演示作为 Story 的转测试控制。Story 演示要求开发人员在 Story 转测试前召集该 Story 的测试人员及其他相关人员对该 Story 的各个验收测试用例的执行情况进行展示。其他参与演示的人员则根据展示的结果分析各个验收测试用例是否真正通过，进而评价所演示的 Story 的质量水平并决定所演示的 Story 能否转测。

　　Story 演示过程发现的问题以及疑问可以记录入 Story 演示记录。Story 演示记录样例见表 6。

表 6. Story 演示活动

表 7. Story 演示记录样例

　　结论

　　经验过程控制模型为敏捷质量管理提供了一个简单易行的理论指导。缺陷预防是质量管理的一个重要思想，而经验过程控制模型可以帮助我们具体实施缺陷预防。另外，敏捷宣言所体现的敏捷价值观也为质量管理提供了思想指导。