FYIRH 发表于 2022-1-9 18:08:14

敏捷研发Sprint回顾的流程

第一次召开Sprint回顾会议的团队,ScrumMaster要申明Sprint回顾会议的目的,避免大家对Sprint回顾会议有不同的理解。
很多ScrumMaster给团队讲解的关于Sprint回顾会议的目的如下。
ScrumMaster说:“回顾会议就是咱们常说的反思会,大家回顾一下这个Sprint运行过程中有什么问题。”
“反思”“回顾问题”,这样的讲解会让大家觉得回顾会议就是来吐槽说问题的。这会给回顾会议创造一个负面的场域。
ScrumMaster说:“回顾会议,就是咱们对Sprint做个总结,花几分钟时间,每个人说一下,这个Sprint哪些好,哪些不好,完了我把会议纪要发给领导。”
回顾会议不是总结会,更不是给领导汇报的总结。这样的讲解给大家的印象是回顾会议是为了形成报告给领导看。
ScrumMaster应该这样给团队讲解Sprint回顾会议的目的。

[*]Sprint回顾是对这个Sprint过程中的团队、对外关系、过程和工具这几方面进行检视,但不限于这几方面。
[*]找出这个Sprint做得好的地方和需要改进的地方,决定改进措施,从而让我们团队持续改进。


给团队明确了Sprint回顾会议的目的后,ScrumMaster就可以正式开始Sprint回顾会议了。
Sprint回顾会议与迭代的关系,以及Sprint回顾会议的步骤,如图6-12所示。图6-12回顾与迭代的关系及回顾步骤
资料来源:《敏捷回顾:团队从优秀到卓越之道》(AgileRetrospectives:MakingGoodTeamsGreat),2012年9月
Sprint回顾会议的步骤如下。
第一步:开场
ScrumMaster在Sprint回顾会议的开场,需要覆盖以下内容:

[*]介绍会议的目标和原则,以及回顾的工作协议;
[*]介绍会议议程;
[*]介绍回顾会以什么方式开展,回顾的范围是什么;
[*]最重要的是,要创造一个开诚布公的场域。


ScrumMaster可以采取以下措施创造一个开放的场域。

[*]选择一个令人轻松、愉悦的场地召开Sprint回顾会议。比如咖啡间,大家可以边喝着咖啡边聊。团队离开了拘束的办公场地,自然就放松起来,内心也更加开放。
[*]设计一个可以促进团队互动的座位布局。比如,让大家围坐一圈,面对面而坐,而不是端正整齐地坐在会议室里。也不要使用投影仪,如果ScrumMaster一本正经地翻PPT,那么他/她就成了会议的主导者,而这种主持风格并不能让每个人都积极参与。


ScrumMaster要向团队介绍诺姆·科尔特(NormKerth)提出的回顾的基本原则:“不管我们发现了什么,我们理解并且相信,每个同事在其已有的知识、技术、能力、资源以及当下所处的环境下,付出了最大的努力。”这样的原则可以为团队创造尊重、互信的气氛。关于回顾范围,ScrumMaster可以给团队一个思考框架,以帮助大家打开思路,比如团队的工作流程(并不局限于Scrum本身)、团队之间的协作(工具、工作环境、技术、对外协作)。
Sprint回顾会议的基本原则、议程、工作协议、回顾范围都可以被可视化到墙上,以营造一个开放的公共场域。
第二步:收集数据
Sprint回顾会议收集的数据包含两方面:客观的度量数据以及Sprint里发生过的事件。
对于客观的度量数据,需要ScrumMaster在会前将这个Sprint和这个版本的交付数据,以及任何需要团队关注的度量数据准备好,带到Sprint回顾会议上来。
Sprint回顾会议经常收集的数据有三个:团队的速率、Sprint燃尽图、版本燃尽图(详见第9章)。
ScrumMaster不是将数据贴到墙上就完了,而是要带领团队解读数据,让大家对团队的交付情况有共同的认识。比如,这个Sprint没有完成的目标;目前的速率低于最近的几个Sprint;按照现在的速率,从版本燃尽图上能看到我们将推迟1个月发布版本;这个Sprint的前3天,燃尽图上SprintBacklog没有一点燃尽,导致我们后来几天加班赶进度,最后到Sprint结束的时候也没有完成目标;等等。
整个团队就数据达成一致的认识后,再开始回忆和分析产生这样结果的原因。
第三步:产生改进意见
ScrumMaster在会前准备好进行头脑风暴的框架,供大家沿着框架产生改进意见。框架有很多种,可以隔一段时间换一换,这样团队会对回顾保持新鲜感。
图6-13所示的回顾方法采用的是SSCC(Start-Stop-Continue-Chang)框架,分成如下四个部分。

[*]Start:哪些实践应该开始尝试。
[*]Stop:哪些问题或者实践应该立即停止。
[*]Continue:哪些现有的实践应该继续保持。
[*]Change:哪些情况应该改变。



图6-13SSCC框架示例

为避免思绪被他人影响,每个提议用一张报事贴书写,然后放到相应的区域。不出意外的话,经过这一步,团队会形成很多改进建议。
但是也有意外的情况发生,团队写不出什么东西来。比如,一个6个人的团队,一共只写了3张报事贴,连框架都填不满。这种团队一般是那种被管理层和公司的体制压抑得太久,员工失去了主动反映问题的习惯,或者是对公司的改变彻底不抱有希望,所以就算有主意也懒得提了。这时候,ScrumMaster需要有耐心,让团队逐渐打开思路。刚开始的时候,ScrumMaster可以设置一个下限,比如,每个人最少写两条意见,时间可以适当长一点,给大家足够的思考时间。随着每个Sprint都有改进措施落地执行,团队会重拾希望,思路也会逐渐打开。
第四步:决定改进措施
面对大量的改进意见,团队是否该全部采纳呢?
团队的精力和时间是有限的,即便大家对所有的意见都认同,也不能什么都做。Sprint回顾会议产生的改进意见需要放到Sprint中,团队边交付产品边改进。如果每个Sprint实施太多的改进,就会影响正常的产品交付工作。因此,团队必须对改进意见缩小范围。团队可以采用点投法,比如,每人有5个点的限额,投出你认为最需要做的几个改进事项。点投的时候,大家不要商量探讨,也要采用“沉默”投票法。
每个人投完后,点数最多的1~3个事项将浮出水面,团队就这几个事项讨论具体的措施。
需要注意的是,改进措施分为两类。

[*]一类是新的实践、规范或者共识,不需要作为一个具体任务来落地实施。这类往往为工作协议。比如,点数最多的报事贴上写的是:“不要过多承诺Sprint目标。”团队注意依据自己的速率和可用的产能来装载SprintBacklog,不要过载即可。
[*]另一类是需要团队完成一个具体的任务。比如,点数第二多的报事贴上写的是:“测试效率太低,Sprint最后几天,测试工程师加班到半夜。”这样的改进需要团队来讨论如何提升测试效率。如果团队讨论的结果是开发测试自动化框架,那么就需要团队里有专人来认领这个任务。并且,这个任务也许需要长期进行,不是一个Sprint就可以搞定的。对于这种长期任务,团队需要将其分解到Sprint里来执行:下一个Sprint开始做什么,再下一个Sprint做什么。在每个Sprint结束的时候做检视,看看效果如何,下一个Sprint是否需要调整策略。


在下一个Sprint计划的时候,一定要记得,这种需要占用团队时间的改进措施也是SprintBacklog的一部分,需要占用团队产能。在任务板上,团队要将它与其他的SprintBacklog条目一起可视化,并跟踪它的进展。
第五步:收尾
改进措施确定后,主持人需要做一些收尾的工作,包括:

[*]对大家花时间共创一个美好的Sprint回顾表示感谢;
[*]拍照作为历史记录存档;
[*]将改进措施报事贴放到任务板上,用来跟踪进展;
[*]做一个关于回顾的回顾,以帮助团队在下次回顾中做得更好。


当然,不需要每次回顾都做关于回顾的回顾。在团队刚开始尝试Scrum方法的时候,花几分钟做关于回顾的回顾,有助于ScrumMaster听到团队的反馈,下次回顾会做得更好。


页: [1]
查看完整版本: 敏捷研发Sprint回顾的流程