现在多数团队开展的敏捷开发活动是以Scrum方法为基础，而《Scrum指南》也一直被视为Scrum方法的最权威官方说明。
该指南在2020年11月进行了最新一次的更新，很有意思的是Ken和Jeff两位作者在新版《Scrum指南》中进一步减少了具体的操作指导，整篇更加偏向于定义做事原则。
下面分享一下2020版《Scurm指南》的重要变化，以便我们在团队日常的敏捷开发过程中进行合理和及时的调整：
1、规定性更低
这些年来，Scrum 指南开始变得越来越有规定性。 2020 版旨在通过删除或淡化规定性语言，使Scrum 重新成为最低限度的框架。例如删除了 Daily Scrum 三个提问，淡化了关于 PBI 属性的相关描述，淡化了 Sprint Backlog 中改进项的相关描述，删除了“取消 Sprint”一节更改为更为简单的描述 ，等等。
解读：
Scrum只是一个轻量级的敏捷开发框架，留有巨大的空间用来给团队进行实践层面的自主，根据不同领域、不同团队、不同工具可以衍生出众多的最佳实践。如同敏捷宣言中隐含的非零和主义价值观一样，为了避免实践层面局限性带来的认知教条化和不适用可能，指南去除了一些具体操作限制以带来其通用性的提升。潜在问题是落地时没有太多参照物，如果没有Scrum专业人士指导落地，很可能走弯路或者学习曲线较长。
* 每日Scrum站会的时候可以不按照“昨天。。。今天。。。阻碍。。。”的固定话术沟通，比如成熟度比较高的团队往往三言两语就能沟通清楚，重点是透明冲刺工作和阻碍性问题。
* 淡化了产品待办列表必须具有描述、次序、估算和价值这些属性，可以根据不同领域来调整和不断增加这些属性，比如不一定要着急对一些特别长远和充满不确定因素的待办列表进行估算和价值描述，重点是团队要不断梳理和精细化PBI，产品负责人帮助团队理解并作出决策。
* 淡化了为了确保持续改进，冲刺待办列表至少包括一项在先前回顾会议中确定下来的高优先级过程改进；冲刺待办列表更多服务于产品交付，可以接受非正式的改进记录和跟踪方式，但重点是要确保改进项可以落地执行。
* 取消了Sprint 可以在 Sprint 时间盒结束之前取消，只有产品负责人才有取消 Sprint 的权力；由于 Sprint 的时间都很短，所以取消 Sprint 的意义不大，当然我们实践过程中取消冲刺的情况也确实很少发生。
2、一个团队，专注于一个产品
我们的目标是消除导致 PO 和 Dev 团队（Dev Team）之间出现“代理”或“我们与他们”行为的团队中独立团队的概念。现在只有一个 Scrum Team 专注于同一目标，有三种不同的职责：PO、SM 和Developers。
解读：
上一版《Scrum指南》在描述Scrum包含的三种不同角色时会有一个“开发团队”的定义，这会让人对Scrum团队和开发团队的定义有所迷惑不解，进而造成产品负责人只关注和开发团队负责人/接口人交流，或者产生产品负责人与开发团队分属不同组织，不是一个整体的结果。为了避免以上问题，新版《Scrum指南》将原来的“开发团队（Dev Team）”重新定义为“开发者（Developers）”，突出只有一个Scrum团队且团队要共同对一个产品负责（主人翁精神）。
3、Product Goal 介绍
2020 版 Scrum 指南引入了 Product Goal 的概念，为 Scrum Team 提供了一个更具价值的目标的专注点。每个 Sprint 都应使产品更接近整体的 Product Goal。
解读：
由于冲刺时间一般不长（比如两周），所以把工作目标只聚焦在冲刺上是不够且短视的，很容易让Scrum团队对工作缺少整体或宏观价值上的理解，进而也无法保证每个冲刺作出调整的合理性和连贯性。（Ken和Jeff很聪明的通过反馈发现了这个优化点并及时进行了调整）
产品是传递价值的载体。它具有明确的边界、已知的利益攸关者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。产品目标是Scrum团队的长期目标。应该先实现（或放弃）一个目标，然后再开始下一个目标。
这与我们现有的项目管理流程侧重点不尽相似，Scrum团队应该周期性的通过立项、启动、定义、实施、运营活动对产品迭代目标及价值不断的进行梳理和总结，而产品待办列表、冲刺目标可以更好的为实现产品目标提供服务。
你清楚自己所负责产品的目标么？及时检查一下自己所做的工作是否是在服务于这个目标？让自己别再继续混沌的工作下去。
4、给 Sprint Goal 、 Definition of Done 和 Product Goal 安了家
之前版本的 Scrum 指南描述了 Sprint Goal 和 Definition of Done ，但是没有真正赋予它们一个身份。 它们不是完全意义上的工件，而是在某种程度上依附于工件。 随着 Product Goal 的增加，2020 版对此提供了更为清晰的说明。现在，三个工件中的每一个都包含一个相应的的“承诺”。 对于 Product Backlog，它是 Product Goal ，对于 Sprint Backlog 则是 Sprint Goal ，而 Increment 则是Definition of Done （现在，Done 不再加引号）。它们的存在是为了带来透明度，并专注于每个工件的进展。
解读：
新版《Scrum指南》因为以承诺的方式将产品目标、冲刺目标和完成定义与三个工件（产品待办列表、冲刺待办列表和产品增量）进行绑定，使得对工件的解释更为自洽，而三个工件之间的关联关系也更加明确。产品待办列表包含实现产品目标的所有工作事项，冲刺待办列表包含实现冲刺目标的所有工作事项且他们是实现产品目标的分解，产品增量是衡量产品目标实现进度的可见物，再通过冲刺评审体现和进行目标实现结果的质量度量，而完成的定义正是质量度量工作的标准。
逻辑是不是与OKR有点类似呢？大目标（产品目标）->小目标（冲刺目标）->关键结果（产品增量，对于完成标准要有具体的说明），两者结合起来应该可以发挥更大价值。
5、自管理胜过自组织
之前版本的 Scrum 指南将开发团队（ Development Team） 称为自组织，选择谁和如何做。 2020版更关注 Scrum Team，强调一个自管理的 Scrum Team，选择谁、如何做以及做什么。
解读：
笔者认为这个更新如果说是升级优化，不如说是两位作者发现上一版《Scrum指南》的一些漏洞后作出的修复尝试，因为之前对于团队自组织定义和解释的不足造成了众多纷争，但遗憾的是“自管理”一词在新版本中的指导性依旧不足。
所以以下理解只能作为个人的一点点揣测：
John Richard Hackman博士在《Leading Teams: Setting the Stage for Great Performances》一书中概述了他的权力矩阵，并描述了授予团队权力的四个级别。Ken和Jeff的灵感可能源自于此，并试图向受众加以理解上的限定：
* 经理领导的团队：让团队成员只拥有执行任务的权力，而经理则监控和管理工作流程、设计人员构成并设定方向。在我们看来，传统职能经理和项目管理团队中的许多专家组都是这种设置的实际例子；
* 自我管理团队：让成员不仅负责任务执行，还负责管理他们的进度。在IT部门内部，我们看到很多看板团队都在应用这种方法，专注于团队任务和价值的流动性；
* 自我设计团队：赋予成员权力来设计和改变他们团队所在的组织环境的各个方面，大多数管理团队都处于这个位置；
* 自治团队：负责所有四个核心职能，如公司董事会、工会或初创企业。
在权威等级中，所谓自组织Scrum团队更近似于自管理团队。Scrum团队自我管理他们的工作（哪个团队成员应该做什么、何时以及如何做），大多数Scrum团队还无法到达自我设计/自治，Scrum团队对其工作和它使用的过程拥有权威，但不包括团队成员或目标的设计。
那Scrum团队就一定无法达到自我设计和自治么？实际上没有人会阻止团队成长并承担更多责任。公司管理层自然会问自己：我们到底希望公司有多自组织？是否应该允许团队决定自主招聘或解雇成员？那不就已经是一个自我设计的团队了吗？ 在大规模使用精益和敏捷的组织中，Scrum 团队应该能够做到这一点，或者至少有相关的发言权。
6、三个 Sprint Planning 话题
Sprint Planning 的话题除了“什么”和“如何”之外， 2020 版 Scrum 指南还强调了第三个话题“为什么”，即 Sprint Goal 。
解读：
在冲刺计划会增加与冲刺目标相关话题的基本逻辑与3近似，主要是增强Scrum团队冲刺工作的目的性和方向感。如果当你每次参与冲刺计划会的时候被一个个琐碎的用户故事搞的晕头转向，完全搞不清相关工作带来的价值以及其服务的目标时请大声的提出来“我们的冲刺目标是什么？他是否与我们的产品目标有关系？”
7、为更广泛的受众而全面简化语言
2020 版 Scrum 指南着重于消除冗余和复杂的陈述，以及删除所有与 IT 工作相关的推断（例如，测试、系统、设计、需求，等等）。现在， Scrum 指南不到 13 页。
解读：
“万物之始，大道至简，衍化至繁”，从2010年第一版《Scrum指南》发布到最新的2020版本已经历10年4次重要更新，最重要的是在这期间Scrum仍然是世界上最为流行的敏捷开发方法，Ken和Jeff两位老先生也在努力将这套方法还原到其最简（初心）模式以便在未来影响更为广泛的领域和受众。
