5.10关于评审
评审是研发过程（不仅是开发过程）中质量控制的一种机制，所谓“三人行，必有吾师焉”，利用多人的智慧和经验，对分析结果、方案设计、计划、代码等进行审核，发现不足，澄清表达不清之处，对下一阶段工作的开展进行事前质量控制。
评审基本是尽量利用团队或公司的能力，有时甚至借用外部资源。但由于评审往往是多人参与的过程，提高评审效率，加强评审效果，是需要重视的。
据我的经验看，评审有两种低效的情况：
- 评审会开成讨论会，或开成头脑风暴会，漫无边际；
- 参会者对评审材料不熟悉，或者没有仔细审阅，提不出问题，草草了事。
理想的情况是，参会者对评审材料都已仔细审阅，并各自将疑问记录下来，每人至少3个问题，在评审会上，按照论文答辩的形式，参会者将预先准备的问题提出，主讲人逐个解答释疑，如问题确实存在，则记录在案。最后，形式评审结论，是按照通过评审、按照评审意见修订后直接通过，还是修订后重新评审。
5.11项目复盘
敏捷开发对项目复盘特别重视，实际上通过项目复盘，对当前阶段的工作做一个回顾，有发生了哪些问题，遗留问题有哪些，有哪些值得发扬和保持的做法等等。
通过项目复盘，分析问题背后的原因，寻找避免发生类似问题的方案和机制；汇总遗留问题，作为下一阶段的开发任务的输入备忘；总结经验，形成知识库文章或开发约定等。
项目复盘机制，是团队自我完善的成长之路。
5.12上线发布技术支持
即使有测试团队的测试，仍难以保证上线发布不出差错。这是因为线上环境和测试环境有所区别，另外，也难以做到充分的测试。
虽然运维人员对上线有其常规的升级方案，如测试计划和版本回滚方案。但某些场合，仍需要开发人员在线支持，如紧急版本发布。
从开发团队的角度，支持版本上线发布，除了人在现场外，应尽量做到代码的可测试性，如日志信息，测试接口等；或支持灰度发布功能等，这些都是利于上线发布的技术支持。