06-scrum的核心流程

Posted 2021-04-25 敏捷DevOps那些事儿

前面的文章中已经对scrum做了入门介绍，也对scrum规定的三个角色做了说明，这一篇我们简单聊一聊scrum的核心流程是什么样的。

迭代计划会议（sprint planning meeting）

其实scrum本身就是一个非常简洁的框架，我们上一篇介绍过product owner，PO会整理一个需求清单叫产品待办事项列表（product backlog），那我们今天的话题就从这个Backlog说起。

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

从这一段描述中我们能够知道，产品待办事项列表是需求的载体，只不过和传统的需求规格说明书有一些区别，传统需求文档给人的印象更多是大段大段的文字，力求通过尽量详尽的文字描述，把需求说清、说透、说完整，并要求后续的过程严格遵守文档中的要求，按部就班的进行实现。并且当我们发现实际需求与文档说明存在差异时，应该通过正式的变更流程进行审批，经过各关键干系人认可的变更才能体现在修改后的文档中，而scrum中的产品待办事项列表中存放的是用户故事，也就意味着描述更加简洁，很多细节需要在后续的沟通中进一步澄清，但是简洁不意味着随意，用户故事有它固有的书写格式，每条用户故事都应该能够对应到具体的客户价值上，而这个产品待办事项列表也应该满足如下DEEP原则：

粗细适宜的（ D etailed appropriately）：待办事项列表顶端的百分之十可能包含非常小且分析得很详细的事项，而其他的百分之九十则不是那么具体;
估算过的（ E stimated）：团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术风险估算;
涌现式的（ E mergent）：要定期梳理产品待办事项列表。产品负责人会不断地更新产品待办事项列表，以反映客户需求的变化、新想法或见解、竞争而导致的变化、出现的技术障碍等;
排好优先级的（ P rioritized）：在产品待办事项列表顶端的事项具有最高优先级，或者是从1开始顺序排列。

回到我们说的scrum流程上来，我们每一个sprint的开始都要开一个会议叫做迭代计划会议，而这个会议的重要输入就是我们刚刚说到的产品待办事项列表，这个会议可以分两部分来看，第一部分是关于“做什么”，也就是需要从产品待办事项列表选择哪些用户故事需要在当前的迭代完成，而这个选择的动作是团队做出的，当然选择了哪些故事也是要和产品负责人进行沟通和协商的，当大家对做什么能够达成一致时，就可以开始会议的下半场了，也就是第二部分关于“怎么做”，团队需要把选择的用户故事拆分成具体的任务，而这个拆分的过程往往都会有新的收获，比如拆分时发现了新的风险或者是遇到了不理解的地方，所以这个过程也是加深需求理解的好时机，简单整理下计划会议可以归纳成如下的步骤：

1、讲故事
2、问题答疑
3、重新整理和估算用户故事
4、选择迭代用户故事
5、拆分成任务
6、检查sprint backlog合理性
7、给出承诺

这个步骤不是所谓的官方标准，只是希望不知道如何开展计划会议的朋友可以作为一个参考，而计划会议的输出就是scrum中另外一个非常重要的工件：sprint backlog，它和产品待办事项列表是有很多相似的特点的，但内容是任务（虽然实际工作中很多公司并没有拆分成任务），并且列表中的每一个任务都应该有且只有一个负责人。

每日站会

计划会议结束后，1-4周的迭代就开始了，具体迭代的周期是每个团队根据自己的实际情况确定的，但是有一点规则是必须遵守的，迭代的周期确定下来后就不要随意变换，如果是一周那每次迭代都是一周，如果是两周每次迭代就该是两周，不能想做多久就做多久，时间盒是必须遵守的。

而在迭代的每一天都需要开一个每日站会（Daily Scrum Meeting），每日站会顾名思义是需要站着开的会议，之所以站着开是希望会议不要过于冗长（建议不超过15分钟），站着大家都不舒服，那就把关键信息交换后，快速结束即可，如果有需要深度探讨的问题，可以会后以其他名义的会议进行沟通，因为有些内容不是站会上每个人都需要关注的，让无关的人充当观众是没有必要的，而会上每个成员交流的问题，主要是三个方面：

1、我昨天做了什么工作；
2、我今天打算做什么；
3、有没有问题对我产生阻碍；

在实际工作中，我发现有的组织对站会有误解，觉得每日站会就是每日晨会，必须在早晨刚上班的时候开，其实scrum并没有约束会议的具体时间，你可以选择早晨开也可以选择中午开，甚至是晚上下班再开，决定来源于团队，并且即使你选择了在早晨开，笔者也不赞成在早晨刚上班的时候开始，比如：如果每天9点上班，你把站会安排在9:10，那基本上很多人都会等待着9:10分开站会，大家会把站会当做一天工作的开始，这10分钟就这样被浪费掉了，你可以选择10:00开，或许效果会更好。但是不管怎么安排，时间和地点应该是固定的，这样让大家形成习惯和仪式感，在开站会的地点，我们一般会配置白板，通过结合看板对工作进行可视化促进站会的高效展开。

迭代评审会（Sprint Review Meeting）

迭代结束的时候，需要通过评审会议，来展示迭代的成果，出席会议的人有产品负责人、团队成员以及ScrumMaster，再加上客户、利益相关人、专家、领导层和任何有兴趣的人。评审会内容的展示对两个角色是非常重要的，第一个就是PO，作为产品负责人需要评判团队交付的功能是不是TA想要的，是否满足要求，所以PO也就是有一票否决权的人，而另外一个目的是展示给团队自己，有的朋友可能会有疑问，功能是团队交付的，为什么还要展示给自己看，其实不管你对这些功能有多么熟悉，在这样一个正式的场合进行展示时，这种成就感是非常重要的，也是团队非常需要的， 就像马斯洛需求层次理论里表述的一样，每个人的需求层次不一样，我们满足的方式也要有所区别，而评审会就是要满足高层级的被尊重需求和自我实现的需求，所以评审会议不仅是交付功能给相关方的动作，也是团队自己付出努力的一个总结。

关于评审会还有一个很重要的观念，评审会不是评比会，评比会是要比较谁做的好，谁做的不好，而评审会要从团队整体的交付出发，不会有针对个人的排名，个人的比较对团队的帮助比你预想的要小的多。

迭代回顾会议（Sprint Retrospective Meeting）

迭代回顾会议是个人认为在敏捷中最重要的会议，但是在实际工作中很多团队都没有开好，甚至就没有开这个会议，敏捷强调的是适应性，是根据面临的变化不断调整的，如果团队不回顾，又如何有新的想法和思路，又如何优化现有流程和机制？
会议可以从如下的五个方面考量：
1、哪些方面产生的价值较少要尽量少做；
2、哪些方面效果很好可以多做；
3、哪些工作需要保持现状；
4、哪些方面可以考虑做一些新的尝试；
5、哪些方面要坚决杜绝，不要再发生。
至于会议的议程，也可以参考如下的步骤：

1、预设会议基调；
2、收集数据；
3、激发灵感；
4、决定做什么；
5、总结收尾。

• 预设会议基调 是要陈述会议议程和会议规则，这个过程并不是一直要做的，如果团队已经非常成熟，对回顾会议也驾轻就熟，那就没有必要每次都陈述会议议程了；
• 收集数据 是为了后续的决策做准备，而数据的收集也可以通过一些工具和方法来获得，比如时间线法、雷达图法等；
• 激发灵感 可以考虑组织头脑风暴并结合一些分析工具来进行，这个过程非常重要的一点就是全员参与、集思广益；
• 决定做什么 比较强调确定下来的任务应该是具备可操作性，比如是否符合smart原则的，任务应该有明确的时间要求、可实现、可验证才能确保有效落地，如果回顾会上确定的改进项都不能落地那还不如没有改进项，杜绝浪费也是团队要时刻关注的点，而scrum master也要起到监督、发现并引导团队做有价值工作的作用。
• 总结收尾 除了总结之外还应该在团队内开展感谢活动，感谢这个迭代帮助过你的人，感谢大家的付出，如果大家不好意思表达，则可以利用看板墙把想说的话写出来贴在墙上，这也是团队氛围建设的有效措施。
  关于会议规则在实践中很多团队还比较容易犯一个错误，就是没有对参会人员没有约束，不想表达的就不表达，做IT的同事很多都是不愿表达的，如果你开了这个口子，不想说的就可以不说渐渐地你会发现回顾会上鸦雀无声 ，大家都没什么可说的，这也符合破窗理论。

一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象，就是犯罪心理学中的破窗效应。

以上就是对scrum流程的简要描述，主要是围绕四个关键会议进行的阐述，其实还要一个会议没有提及，就是产品待办事项列表梳理会，这个会是在迭代的过程中去梳理下一个迭代的待办事项列表，我们不能寄希望于在迭代计划会议上去进行待办事项列表的梳理，计划会议的输入应该是一个已经完成梳理的待办事项列表，这样才能确保计划会议的高效开展，而关注各个会议的开展技巧，其实还有很多可以讨论的内容，会在后续的文章中针对性的做一些介绍，也欢迎您持续关注系列文章。