5.10关于评审

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

  评审基本是尽量利用团队或公司的能力,有时甚至借用外部资源。但由于评审往往是多人参与的过程,提高评审效率,加强评审效果,是需要重视的。

SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。

  据我的经验看,评审有两种低效的情况:

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

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

 

5.11项目复盘

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

  通过项目复盘,分析问题背后的原因,寻找避免发生类似问题的方案和机制;汇总遗留问题,作为下一阶段的开发任务的输入备忘;总结经验,形成知识库文章或开发约定等。

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

 

5.12上线发布技术支持

  即使有测试团队的测试,仍难以保证上线发布不出差错。这是因为线上环境和测试环境有所区别,另外,也难以做到充分的测试。

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

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

扫码关注我们
微信号:SRE实战
拒绝背锅 运筹帷幄