Scrum指南这么改，我看要完蛋！

2023-10-24 08:01:58

摘要：近日，Scrum敏捷方法框架的创始人宣布了Scrum指南的2020年版本，根据官方介绍，相比2017年版本，本次改变主要涉及七个方面。接下来让我们逐个解读这些变化，谈谈我的个人想法。

Scrum敏捷方法框架的两位创始人Ken Schwaber和Jeff Sutherland通过直播，向大家宣告发布了Scrum指南的2020年版本。作为Scrum的创始人，Scrum指南被广泛认可为是Scrum框架的权威定义和解释，有着极高的地位，也因此备受争议。而两位创始人能够持续倾听社区实践者们的反馈，谨慎但持续地刷新Scrum指南，以响应Scrum在实践应用中所面临的问题以及实践者的困惑，这本身也是一种敏捷精神的体现。

那么，我们一起来看看这个2020年版本都有些什么变化。在scrumguides.org网站上有专门页面介绍各个版本之间的改变，英文过硬的朋友，也可以直接打开链接阅读：https://scrumguides.org/revisions.html。注意，下文中，我使用了“产品列表”、“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