敏捷研发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]