理顺软件开发各个环节-17（开发管理-评审、复盘及上线支持）

5.10关于评审

　　评审是研发过程（不只是开发过程）中质量控制的一种机制，所谓“三人行，必有吾师焉”，利用多人的智慧和经验，对分析结果、方案设计、计划、代码等进行审核，发现不足，澄清表达不清之处，对下一阶段工做的开展进行事前质量控制。

　　评审基本是尽可能利用团队或公司的能力，有时甚至借用外部资源。但因为评审每每是多人参与的过程，提升评审效率，增强评审效果，是须要重视的。

　　据个人经验看，评审有两种低效的状况：

• 评审会开成讨论会，或开成头脑风暴会，漫无边际；
• 参会者对评审材料不熟悉，或者没有仔细审阅，提不出问题，草草了事。

　　理想的状况是，参会者对评审材料都已仔细审阅，并各自将疑问记录下来，每人至少3个问题，在评审会上，按照论文答辩的形式，参会者将预先准备的问题提出，主讲人逐个解答释疑，如问题确实存在，则记录在案。最后，形式评审结论，是按照经过评审、按照评审意见修订后直接经过，仍是修订后从新评审。

 

5.11项目复盘

　　敏捷开发对项目复盘特别重视，实际上经过项目复盘，对当前阶段的工做作一个回顾，有发生了哪些问题，遗留问题有哪些，有哪些值得发扬和保持的作法等等。

　　经过项目复盘，分析问题背后的缘由，寻找避免发生相似问题的方案和机制；汇总遗留问题，做为下一阶段的开发任务的输入备忘；总结经验，造成知识库文章或开发约定等。

　　项目复盘机制，是团队自我完善的成长之路。

 

5.12上线发布技术支持

　　即便有测试团队的测试，仍难以保证上线发布不出差错。这是由于线上环境和测试环境有所区别，另外，也难以作到充分的测试。

　　虽然运维人员对上线有其常规的升级方案，如测试计划和版本回滚方案。但某些场合，仍须要开发人员在线支持，如紧急版本发布。

　　从开发团队的角度，支持版本上线发布，除了人在现场外，应尽可能作到代码的可测试性，如日志信息，测试接口等；或支持灰度发布功能等，这些都是利于上线发布的技术支持。