首页 > 代码库 > Retrospective--The Way To Make Things Better
Retrospective--The Way To Make Things Better
回顾这个词最近见得比较多的一个可能原因是因为敏捷开发的如火如荼,对敏捷领域而言,尤其是Scrum,回顾是作为整个框架中的一个步骤来执行的,很多学者认为回顾是敏捷开发中最需要做的一件事情,个人也深表赞同。尤其是在团队尚在成长期,面临研发过程中诸多问题的时候,回顾就是我们手中的武器,是要紧紧握在手里,时刻不能丢掉的。同时,因为回顾在敏捷领域受到的广泛关注,平时在团队中推行回顾的时候很大程度上参考了现有的一些著作和资料,其中受Esther Derby和Diana Larsen合著的《Agile Retrospectives: Making Good Teams Great》启发最大,本文中也大量参考和引用该书中的一些思路和做法。
一. 为什么我们要做回顾?
在项目/产品研发过程中的某个时段,结合并不成熟的团队状况,或多或少会面临研发管理不合理的现状,比较典型的有:
- 多项目交叉
- 分布式、多部门协作
- 开发资源、任务并行
- 项目缺乏计划性
- 产品缺乏创新点
这些现象导致的结果归根结底就是进度上的问题,无论是项目按计划验收还是产品根据市场快速做出反应,时间永远是软件企业最需要把控的一个核心要素,对互联网公司更是如此。但当因为研发过程中产生这种那种的问题导致进度不尽理想时,大家有想到要做些什么吗?
要做的事情有很多,个人认为首当其冲的就是“Stop And Thinking”,包括两个主要方面:- 检视(Inspect):检查和诊视。通过分析现状、收集数据、头脑风暴等方式总结和梳理团队目前存在的问题,包括需要量化的过程记录性数据作为过程改进的输入以及流程改进点本身存在的问题这两个主要方面。
- 调整(Adapt):过程改进。有了量化的数据和流程改进的突破点,就可以确定调整策略和下一步的工作计划,并落实责任人。
二. 怎么做回顾?
1. 会议的流程
回顾的流程可以分为5个部分,当然各个团队可以根据实际情况进行调整和裁剪,但会议的输入、输出和议程应该是一致的:
- 确定目标:确定本次回顾会议中需要改进的目标,一般一次回顾会议1~2个目标是最合理的
- 收集数据:为了对改进过程有量化的标准,需要进行数据收集。数据来自日常研发过程中与该改进目标相关的方方面面
- 激发灵感:使用数据进行集思广益,通过各种激发灵感的工具和活动让团队成员提出自己的想法
- 决定做什么:收集团队中的灵感并进行讨论和分析,最终确定下一步的目标
- 总结收尾:总结本次回顾会议的过程和成果并落实行动计划和责任人
其中前两步需要在会议前完成,回顾会议的目的是对研发过程中的客观数据进行分析从而得出结论和行动计划。
2.会议召开的时机
3. 参与者和持续时间
回顾会议的参与者不要太多,主要包括:
- 团队成员:执行过程改进的整个团队,确保需要参加的人员都到位
- 顾问:顾问很多时候是需要的,顾问可以来自其他职能团队,也可以是其他研发团队中有回顾和过程改进经验的同事
4. 背景和目标
5. 活动和工具
6. 产出和行动
三. 场景分析
本节将根据上文中的回顾会议流程进行一些场景分析,帮助大家了解和掌握回顾会议中的具体做法和注意点。文中的实例可能并不适合所有的团队,仅供参考。
1. 确定目标
确定目标有两个活动,分别是“聚焦”和“不良事件响应”。聚焦是主动地去关注研发过程中的某一个潜在需要改进的点,而不良事件响应通常是因为发生某个事故导致我们不得不被动的去应对这些事故并探讨是否有可以避免再发生该类事故的方法。从质量成本的角度讲,聚焦是一种一致性成本而不良事件响应是不一致性成本,日常研发过程中如果有条件的话应多采用聚焦的方法以降低质量成本。
下面是一个聚焦的例子,我们关注Jenkins使用情况,发现有若干次构建失败的场景,根据团队工作的规则,可能就需要触发我们去召开回顾会议看看是什么原因导致Jenkins构建工作会经常性的出现问题。通过回顾我们通常会得出代码提交、系统集成方面流程上的不规范性,从而进一步确定相关规则:
关于不良事件响应的例子也很多,下面就是一个内部服务发布缺少配置导致相关功能测试失败的例子,从这个不良事件中我们也可以看出服务发布的流程上缺乏相应进行服务器配置的校验工作,所以也可以在回顾会议上展开流程方面的讨论:
2. 收集数据
3. 触发灵感
“头脑风暴“是我们经常使用的一种触发灵感的活动,下面是需求和UI界面匹配问题团队成员之间一次简单的头脑风暴,通过讨论大家就工作流程做了一项改进:
表现端端开发人员:需求文档中的界面和UI效果图中的界面不是很一致,我处理起来要返工。
服务器端开发人员:我是参考需求文档中的界面设计的接口
需求分析师:嗯,两者应该尽量统一
项目经理:那我们以后UI效果图出来之后,BA和UED碰一下头之后再发布给开发
“5个为什么“也是敏捷领域比较推崇的一个过程改进实践,原理很简单但确实很有效。下面是对某项目服务器部署失败而进行的“5个为什么“分析,并最终确定开发人员在服务发布之前与发布人员进行沟通和确认是保证该流程正确执行的一项有效实践:
下面是一张”鱼骨图“,鱼骨图又叫因果图、石川图,是质量控制领域最具代表性的分析工具之一,也被广泛使用到过程改进中。图中从研发团队的各个方面出发找出导致开发效率低的原因,从而为我们后续的行动计划指明方向:
“学习矩阵”相对比较少用,但在有些场景下也是我们可以用来进行灵感触发的有效工具。如下图,针对分布式协作下的团队开发,我们首先总结做得好的和做得不好的方面,再看看有没有新的想法,如果实现不行我们也可以看看找谁帮忙,这些过程性成果都可以通过类似的学习矩阵进行细化和明确:
4. 决定做什么
关于决定做什么,虽然后续工作安排取决于具体的目标,但个人认为有两个方面我们需要注意:
- 关注流程:从点覆盖到面是我们梳理流程的一个目标。例如,从Jenkins打包失败这个点提出在流程上需要进行提交代码前先本地打包这一覆盖到面的改进;再如,从测试环境部署失败看流程问题的话就需要我们先搭建开发环境然后在发布前先部署开发环境。
- 使用SMART原则:SMART原则是指具体(Specific)、可衡量(Measurable)、可实现(Attainable)、相关性(Relevant)和有时间限制(Time-bound),是目标管理领域的一个核心原则。我们在指定行动计划时如何判断改进工作安排是否合理和可行很大程度上可以参考这一原则。
5. 总结收尾
四. 关于周会
五. 小结
Retrospective--The Way To Make Things Better