摘要： 近日，Scrum 麻利办法框架的创始人发表了 Scrum 指南的 2020 年版本，依据官网介绍，相比 2017 年版本，本次扭转次要波及七个方面。接下来让咱们一一解读这些变动，谈谈我的集体想法。
Scrum 麻利办法框架的两位创始人 Ken Schwaber 和 Jeff Sutherland 通过直播，向大家宣告公布了 Scrum 指南的 2020 年版本。作为 Scrum 的创始人，Scrum 指南被宽泛认可为是 Scrum 框架的权威定义和解释，有着极高的位置，也因而备受争议。而两位创始人可能继续聆听社区实践者们的反馈，审慎但继续地刷新 Scrum 指南，以响应 Scrum 在实际利用中所面临的问题以及实践者的困惑，这自身也是一种麻利精力的体现。
那么，咱们一起来看看这个 2020 年版本都有些什么变动。在 scrumguides.org 网站上有专门页面介绍各个版本之间的扭转，英文过硬的敌人，也能够间接关上链接浏览：https://scrumguides.org/revis…。留神，下文中，我应用了“产品列表”、“Sprint 列表”等词汇，然而在 2020 年版本的指南中并未翻译这两个及其他一些词汇，而保留了英文原文，如 Product Backlog、Sprint Backlog。为了行文不便，我仍应用中文表白。
2020 年版本相比 2017 年版本的变动，依据官网介绍，次要波及七个方面的扭转。接下来让咱们一一解读这些变动。变动题目那个段落是官网文档中的表述，下方缩进局部的文字是我的个人见解。
变动 1 ——
缩小预描述性：这些年来，Scrum 指南逐步变得有些过于详述。这份 2020 年版本旨在通过删除或软化预描述性语言的形式让 Scrum 回归为一个仅够（最小化但足以失效）的框架。比方，移除了每日 Scrum 的三个问题、软化了 PBI（产品列表条目）属性的形容、软化了 Sprint 列表中对于回顾改良条目标形容、软化了 Sprint 勾销章节的内容，等等；
的确有点回归初衷的感觉，从一开始，在泛滥麻利方法论当中，Scrum 就属于是最为简洁的那个，而且两位创始人在各种场合的解说也都强调具体如何操作是灵便的。而移除的这些个内容，其实都是过来这些年来大家在实践中比拟纠结的焦点。比如说每日 Scrum 到底要不要严格遵守三个问题的格局？公说公有理婆说婆有理，其实是针对不同成熟度的团队，保持和不保持各有利弊，但写在指南外面，不免被认为是普适性都要恪守的。
至于回顾改良条目，是因为在 2017 年版本外面有这么一段话：Sprint 产品待办列表将开发团队用来达成 Sprint 指标的所有工作变得清晰可见。为了确保继续改良，它至多包含一项在前次回顾会议中确定下来的高优先级的过程改良。删除这段话，对我来讲，没有什么影响，该改良的就应该落实，怎么落实最好，就是在以后 Sprint 列表外面以工作或故事模式来进行治理是最棘手的。但对于不那么相熟 Scrum 的实践者来讲，预计又要争执 Sprint 回顾会议上制订的改良措施如何落实了。
至于 Sprint 勾销，则是从原来大略 20 句话简化到了现在就一句话。删除的多是车轱辘话，这个改良应该没啥问题。但简化到就这么一句话这个做法，相当于进一步强化了 PO 对 Sprint 的生杀大权，或者说独裁权。三种角色的职责与势力划分是否还可能保持良好的均衡， 有点难说，外国人喜爱强调分工和职责，但不太去讲如何基于不同分工角色单干的能源，要害是能动性往往却是单干可能产生成果的根底。
变动 2 ——
一个团队聚焦一个产品：指标是要破除在团队内还有一个独自团队的概念，这种做法会导致在 PO 和开发团队之间呈现“代理”或“咱们和他们”等行为。当初，就只有一个 Scrum 团队聚焦于同一个指标，别离承当三组不同职责：PO、SM 和开发者。
不相熟的敌人可能未必能很好了解这个扭转。在以前，Scrum 指南在三种角色的名称定义上有那么点不够谨严，说是有 PO、SM 和开发团队三种角色，而后三种角色独特形成了一个 Scrum 团队，相当于是说 Scrum 团队 = PO + SM + 开发团队，大家就会很纠结那到底是几个团队呢。
对于 PO、SM 可能都还好，但对于开发团队的成员来讲，他们就会很困惑，我到底属于哪个团队？说一名成员属于开发团队又属于 Scrum 团队，对于成员本身的身份认同和团队认同方面，是会造成十分大的困扰的。所以这次间接去掉开发团队外面的团队一词，就是对这种争议的间接回应。2017 年简中版本把很多术语都翻译成了中文，尽管我集体意见是偏向于不翻译、保留原文的，而这次 2020 年简中版本中则少数都保留了英文原文，比方开发团队在 2017 年版本外面的原文是 The Development Team，而在 2020 年版本外面改成 Developers 且保留了英文原文。但我还是比拟关注这个 Developers 的翻译的，因为通常来讲 Developers 都会被等同于开发人员，大家潜意识外面去了解的技能模型就是会写代码的，这就对非编码人员或非编码技能不够敌对，会影响到团队的团结气氛以及非编码人员或非编码技能的能力构建和职业倒退的。2020 年版本外面并没有对 Developers 的具体技能模型和更具体的分工或角色进行形容，从好的角度看，是因为强调自治理，所以把决策权留给了这个 Scrum 团队本人去决定。 但从坏的角度看，就是不负责任了，因为这就意味着要可能利用好 Scrum 框架，做好团队角色的分工和单干，会依赖于主导者或 SM 或麻利教练的教训程度，这也就难以保障 Scrum 落地的成果。
变动 3 ——
引入产品指标：2020 年版本 Scrum 指南引入了产品指标的概念，以帮忙 Scrum 团队聚焦于一个更有价值的指标。每个 Sprint 都应该带动产品更靠近最终产品指标。
Scrum 以前其实并没有太显著或者着重去强调本人是面向产品型研发这个场景的，尽管 PO 这个名字就曾经表明了态度，毕竟它叫产品负责人嘛，当然是围绕产品转的。 在引入了产品指标这个概念之后，进一步强化了框架自身对产品型研发场景或工作场景的聚焦。Scrum 是否用于我的项目研发场景，在过来那么多年，是始终有争议的。将 Scrum 框架跟整个我的项目研发场景对应，会感觉不适宜，因为 Scrum 框架定义中用产品列表去承载整体需要治理，而产品列表是凋谢、继续刷新的，而我的项目范畴则通常都是锁定的。如果用 Scrum 外面的 Sprint 去对应我的项目型研发场景下的我的项目，从资源、时限、范畴等角度看，都是一种提前锁定的模式，十分靠近，但 Sprint 的时长周期，又跟个别所了解的我的项目周期相去甚远，就如同大家都是猫科，但你这个小猫咪的养育办法，用去养育大老虎总感觉有些不对劲。
所以，这个变动，就要看两位创始人给 Scrum 设定的愿景到底是啥了。一方面是否真的想要强化面向产品型研发的场景，另一方面，第 7 个变动说删除 IT 工作化表述，但其实 Product 这个词也有很强的 IT 工作化的暗示。但我想如果要齐全去 IT 化，预计就是伤筋动骨，相似全身整容，比方 Product 这个词汇，贯通了 Scrum 框架的整个脉络。要剔除它，谈何容易。
变动 4 ——
Sprint 指标、实现定义和产品指标的归宿：以前版本的 Scrum 指南提到了 Sprint 指标和实现定义，但并没有真正给它们身份。它们并非工件，但却或多或少都跟工件有关系。2020 年版本不仅是减少了产品指标，还进行了更清晰的论述。三大工件现在都纳入了与之对应的“承诺”。产品列表的承诺就是产品指标；Sprint 列表的承诺就是 Sprint 指标；增量的承诺就是实现定义（当初曾经去掉了双引号）。它们的存在就是为了让各大工件的停顿变得更清晰和更聚焦。
搞笑点说，就是以前它们都是公开恋情，名不正言不顺的。当初正式給它们证了个婚，Sprint 列表跟 Sprint 指标结婚拉钩、增量跟实现定义结婚拉钩，而后给产品列表配了个对象叫产品指标，也结婚拉钩。其实是坏事，但另一方面来讲，也阐明 Scrum 框架在变得更加流程化、规范化，因为从流程定义的角度来讲，不可能只是定义过程中的动作，而不定义过程的后果或者说准出规范的。这几个承诺某种程度上就有点质量标准或者准出规范的滋味。
当然，扭转嘛，没有相对好和相对坏的。比方产品指标，2020 年中文版本中搜寻能够找到 22 个中央，只有一个中央说了谁来制订，那就是 PO 负责“开发并明确地沟通 Product Goal”。 这必然带来问题，相当于 Product Goal 的定义和决策权是独裁的、不受约束的， 那么如果 PO 以产品指标的变动为由，提出可能不那么吻合 Scrum 精力的要求，比方在 Sprint 过程中插入突发工作等要求，该如何解决、该如何解决争议呢？置信肯定会成为后续 Scrum 实践者们的热议焦点。
变动 5 ——
自治理替换自组织：以前版本 Scrum 指南介绍开发团队是自组织地去抉择工作对象以及工作形式。2020 年版本更聚焦于 Scrum 团队，强调一个自治理的 Scrum 团队，抉择工作对象、工作形式以及工作指标。
这个其实有点懒政，从扭转的角度并未讲明确自治理和自组织之间的差异是什么，而从指南独自文档角度也没有解释分明到底自治理意味着啥，也没有讲清楚其争议解决机制是什么， 毕竟这三个角色三权大力，SM 作为事中人是很难以中立角色来协调化解纠纷的。而且更为蹩脚的是，在文档中，介绍变动的中央，说的是“a self-managing Scrum Team, choosing who, how, and what to work on”，而在指南注释外面则是“They are also self-managing, meaning they internally decide who does what, when, and how”，两者并不完全一致。这是会带来问题的。Scrum 指南或者框架近些年的变动以及创始人们的舆论（当然我没有贴身关注他们的动向，所以或者有讲过，但我不晓得），给人的感觉是更偏向于缩小领导性质的具象化形容，而更强调文化、准则导向与问题解决思路，但在自治理团队的定义方面，如此含糊甚至呈现肯定水平的自圆其说，有点匪夷所思。
变动 6 ——
三个 Sprint 打算会议议题：2020 年版本 Scrum 指南在“做什么”和“怎么做”根底上，减少强调了 Sprint 打算会议的第三个议题，也即“为什么”，直指 Sprint 指标。
增强价值导向，有好有坏。原本团队里就存在挑肥拣瘦的状况，不论创始人们减少这个议题的原意如何，摆在这里就是态度， 极有可能会激化抵触。 在英文版本中搜寻 Value 也即价值这个词，有 25 处，但都没有明确定义谁来评判 Value，不过蛛丝马迹之间，更次要是指向了 PO，这个也能够了解。但我放心这会极大地减弱团队对于工作内容的影响力和决策权。对于研发团队来讲，可能并非坏事。
变动 7 ——
全面简化行文以面向更宽广受众：2020 年版本 Scrum 指南着重于打消反复表述及简单语句，并删除了残留的 IT 工作化表述语句（例如测试、零碎、设计、需要等）。Scrum 指南现在只有不到 13 页的篇幅。
Scrum 始终以来都在强调本人不仅仅是实用于 IT 或研发畛域，但毕竟生于此畛域，这些扭转是好是坏，是邯郸学步还是志在高远，外人有余为道，还是要看两位创始人心中的巨大愿景是啥，他们开心就好。至于宽广实践者到底如何感触，过段时间，可能一两年应该就晓得了。我？我是感觉不开心的。这份文档叫指南，指南就没有这么简略的。从内容本质来看，改名为领导准则或核心理念都会更适合一些。普适性和实操性是很难去均衡的，至多心愿同一份文档可能同时满足普适性和实操性，我感觉要求太高了。齐全能够参考我天国做法，既要有规章制度，也要有实施细则。规章制度相似于 Scrum 框架的核心理念和领导准则，是普适于多种场景的，而后针对不同场景出具实施细则，不就能够了么？
这个变动的题目“Overall Simplification of Language for a Wider Audience”体现的是作者们的初衷，就是想要去笼罩更宽广的受众群体，从这个角度来讲， 删除车轱辘话、去 IT 化表述都是好的变动， 是有助于达成这个指标的。
但作为一名次要工作场景依然是 IT 或软件研发工作的实践者，我很难说是开心还是惆怅、称心还是不称心。
附从 scrumguides.org 官网上下载的 2017 年的中英文版本，以及 2020 年的中英文版本。心愿返回官网查看的，请点击 https://scrumguides.org/download.html。
2020-Scrum-Guide-US.pdf 248.39KB
2017-Scrum-Guide-Chinese-Simplified.pdf 1.02MB
2020-Scrum-Guide-Chinese-Simplified.pdf 438.80KB
2017-Scrum-Guide-US.pdf 582.00KB
本文分享自华为云社区《Scrum 指南这么改，我看要完蛋！》，原文作者：kaverjody。
点击关注，第一工夫理解华为云陈腐技术~