今年是敏捷宣言发表20周年，去年是Scrum 的25岁生日，2020年11月18日Scrum 的共同创始人Jeff 和 Ken 发布了新的演进的Scrum 指南，Scrum 联盟将CSM 认证考试的内容做了相应的调整。Scrum 联盟国际认证讲师CST 的教学大纲也做了相应的更新，那么对于我们一线工作的ScrumMaster 和敏捷教练来说，有什么具体的影响和指导意义呢？疫情的第二个春节，我花了一些时间来梳理，写下来与大家一起交流和学习，欢迎批评和指正：
新的Scrum 指南（英文版）从原来的18页删减到13页，有哪些部分砍掉了，为什么？
新的Scrum 指南文档变得更轻量级了，她回归到Scrum 的本质（essence），但Scrum 本身没有改变，只是需要我们采用当下最好的方式去描述她，目前应该是较好的文档。
1. 删除了有关IT 领域晦涩的词汇比如 “架构，系统，特性，功能，测试，发布” 等。Scrum 邀请和欢迎非IT 领域的应用，比如审计，运营，营销等复杂的工作。
过去五年，Scrum 在其它领域的应用越来越广泛。记得去年给一家制药企业培训时，我不小心用到需求（requirements）一词，学员理解起来非常困难。新的指南用词更通俗，便于大家理解，也邀请业界的朋友尝试Scrum 。
2. Daily Scrum 的三个通用的问题被移除了。
三个问题作为例子参考, 对新的Scrum 团队启动是一个好的起点，但也有可能会误导——站会就是回答这三个问题。时间久了，每日站会变成形式主义和汇报会，没有理解Scrum 站会的真正目的。
新的指南让ScrumMaster 和开发人员来选择他们想要的会议结构和技巧，不再拘泥于这三个问题的回答，同时给与SM 更大的灵活性去set up 站会的形式。
3. 产品待办条目（PBI）的属性我们经常用INVEST 的原则来严格的描述，新的指南强调需求的属性与工作的领域有关，比如属性包括清晰度的描述，规模 (size) 大小，价值等， 但这些属性不是必须的。
4. 新的Scrum 指南对有关回顾会的行动项在下一个Sprint 待办列表的跟踪，只是一个好的实践，但不是唯一的选择。另外取消Sprint 的描述的段落也减少了，完成的定义 “Done” 去掉了括号。如果PBI 满足了DoD 的要求，增量就产生了。增量是可用的（usable）即有价值，也可能有多个增量在Sprint 产生。Sprint 不是发布的cycle , Scrum 中Sprint review 与何时发布没有直接关系，也不是发布的gate 。
新的指南增加了什么？
1. 新的指南引入了产品目标（product goal）的概念，在过去的教学中，我们会介绍产品愿景，产品策略或产品路线图，甚至发布计划的目标。这次引入产品目标更有利于Scrum 团队看到一个total goal (big picture) , 产品目标指导团队工作的聚焦和激发及赋能团队，同时也可以规划（frame）每个Sprint 目标。产品目标描述了产品的未来状态，产品目标符合SMART 的原则。Agility 或Scrum 不是目标，产品愿景和产品目标是有区别的。产品愿景更长远，给人们于想象力和触发团队的灵感，A product goal is the next actionable step towards a product vision。新的指南定义了最少的且最接近团队的产品目标，没有讨论更高的策略和愿景，留给足够的空间想象和实践。新的指南对产品也进行了定义——“它是传递价值的载体”。产品目标要包括在产品待办列表中， 增加了透明性，透明才便于大家理解，根据客户的真正反馈去调整（pivot）。如果没有目标导向，我们的专注点会被传统的预算时间成本所绑架。
2. 三个承诺（commitment）的归位和归宿
Scrum框架中有三个核心的工件：产品待办列表，Sprint 待办列表，增量。这三个工件反映了价值和工作，体现了透明性，但需要有具体的承诺来 “规范” 这些价值。他们是产品目标，Sprint 目标和完成的定义（Done 不带括号）。过去学员经常会把完成的定义当作工件，这三个承诺并不是工件，但确实与工件有关。新的指南对三个工件有了具体的对应三个承诺。三个承诺的存在，为每个工件的进度及其度量带来了透明和专注。Scrum 的价值 “承诺” 赋予了具体的涵义。对三个工件的承诺，也意谓着Scrum 的价值 “专注” 。
3. Sprint 计划会议除了原来的两个主题 what 和 how , 增加了一个主题 “why”，即Sprint 的目标。Sprint 目标是Scrum 团队在计划会议上共同制定的，Sprint 目标包括在Sprint 的待办列表中，增加了透明性。
新的指南强调和强化了什么？
1. Scrum 的框架中只有一个团队，就是Scrum team，不存在所谓的开发团队 ( dev team) 或sub-team，也不会有这样的称谓：“我们”或“你们”，we all together。开发团队在新的指南中改称为开发人员（developer），开发人员是一个通用的称呼，而不是特指的程序员（programmer）。我认为这是一个正向的改变，在Scrum的实践中我们经常发现PO 是游离于 “开发团队” 之外的一个代理， 开发团队和PO 的关系本质上变成一个合同游戏（contract game）的关系， 这也是为什么我们谨慎使用DoR 。PO 会告诉开发人员做什么，如果不理解这种协作关系，会加重合同关系。Scrum 中每一个人都应该关注价值，挑战价值， PO 或开发人员不应该分开。其结果是，Scrum team 实际上成了一个 “摆设” 或 “虚拟体” ， 多数情况下PO 只是一个来自业务部门或甲方的代表，没有真正的融合在一个团队中。所以，新的指南强化一个团队，我相信这个正向的改变会对未来组织架构设计有影响，一个真正的团队（real team），专注一个产品和一个产品目标。
2. 角色 (role) 改为 担责 (accountability)
新的Scrum 指南没有给你的组织定义职务（title） 或角色（role），而是一组责任（担当）。角色 (role) 和担责 (accountability)，仔细研究，这两个概念有区别的。角色就像actor，比如一名 “教师” ，一个人可能有不同的角色，比如父亲，丈夫，和书法家等。Scrum 团队有ScrumMaster，PO，开发人员，他们之间的关系不是简单的几个 “角色” 组合，Scrum 更强调一个完整的Scrum 团队， 团队approach （rugby）方式去工作和创造价值， 强化团队文化， 每个人以 Scrum 的价值观为生（live by values）。
担责 (accountability) 强调的是一个人，而不是一个角色（role），只有一个人对某些事情和活动有担当（be accountable），担责赋予更多的力量和后果。担责 (accountability) 是不能共享的（shared），PO 是一个人，而不是一个委员会。Accountability 强调问责制 (it is on ‘me’) ，但是 “我” 可以把一些工作委托他人去做，最终还是 “我” 有责。责任人是最终对活动或决定负责的个人。
3. 真正的领导者（True leader）
ScrumMaster (SM) 是一个真正的领导者 ( true leader)，为Scrum 团队和更大的组织提供服务。在旧的指南中SM 定义为服务型领导 （a servant leader），甚至有人翻译成 “仆人式” 的领导，就更糟糕了。容易给人误解SM 就是一个打杂的admin 或秘书（比如站会记笔记）。新的指南拔高了SM 的地位，首先强调是一个真正的领导者，然后表述服务的对象。SM 为组织实施Scrum 提供规划和建议 (planning and advising)，SM 对Scrum 团队的效能负责 （accountable for Scrum team’s effectiveness），SM 是组织变革的催化剂。 我建议组织在推行Scrum 的过程中把SM 的责任和担当并公布出来和可视化，让组织的每一个人真正了解他的职责。
4. 自组织到自管理
自组织在旧的Scrum 指南强调开发团队的自组织，Jeff 解释 “自组织”（self-organizing） 一词的启发来源于复杂自适应系统（CAS），自然界有许多自组织的行为，系统围绕目标自身有自我调节和自我管理的能力。但我们在Scrum 的实施中，人们会混淆自组织就是 “自由” 或无自律，人们很难解释什么叫自组织团队。这次的修改就是使用大家普遍容易理解的语言——自管理团队。Scrum 团队的自管理选择谁（who）来做什么 (what)，以及用什么样的方式（how）去聚焦实现共同的目标（why）。
作者：Jim Wang
写于2021年2月22日春节期间
参考资料：
（1） 2020 Scrum指南
（2）2017 和 2020 Scrum 指南的变化
（3）一些敏捷社区论坛对Scrum 指南更新讨论
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295400.html