每隔几年，Scrum 的作者 Ken Schwaber 和 Jeff Sutherland 就会聚在一起更新 Scrum 指南中定义的 Scrum 框架。这些是 Scrum 的官方规则，它们已经经历了多次迭代。
到 2020 年底，他们的最新版本发布了，它的标题只是2020 Scrum Guide ™。目标是简化框架并减少不需要的部分，以便更多的受众更容易访问该框架。这可以从 Scrum 指南的大小减少（从 19 页到 13 页）中得到最好的体现。
他们还对框架进行了一些更改，虽然有些不那么重要，但我相信有些值得考虑。
在这里，我将概述我认为最重要的 5 个变化，告诉你它们为什么重要（或不重要），并就这些变化给出我的意见。这绝不是一份全面的变更清单。这只是我认为值得讨论的前 5 名。
变化 1：责任 (Accountability) 取代角色 (Role)
更改：“角色”一词已被删除，取而代之的是“责任”一词，以标记 Scrum 团队中的个人。
对您团队的影响：对于经验丰富的团队 - 您可以接受或放弃此更改，因为名称和标签对您和您的团队来说更有可能只是学术性的。对于新团队 - 您可能会决定简单地换个词——或者不。
BRIAN 的观点：显然有些人认为“角色”一词意味着职位。作者想找到一个更像运动队职位的术语。例如，所有球员都是棒球运动员，但每个人都负责特定的职责：接球手接球，一垒手跟踪一垒发生的事情。但是您的一垒手当然也时不时地发挥作用，并且以同样的方式，任何职位都可以填补特定的 Scrum 团队角色，而无需雇用具有该职位的人。Scrum Master 不必在简历上写上“Scrum Master”；项目经理可以扮演 Scrum Master 的角色，只要他们遵守 Scrum 指南为该角色规定的内容。因此，“问责制”试图将这两个概念分开：角色和头衔不是一回事。
但是，“问责制”一词并不能解决问题。当大多数人（包括我自己）想到责任时，他们想到的是责任：“我有责任将碗碟放入洗碗机。” 问题在于我可以对多件事负责，但新的 Scrum 指南指出，Scrum 团队“由一名 Scrum Master、一名产品所有者和开发人员组成”。这些术语代表一些未定义的词，其中包含多个其他责任。例如，每个开发人员都对质量负责，为冲刺制定计划，并相互问责。那个缺失的词对我来说听起来很像一个角色。如果这对某些人来说是个问题，请坚持 Scrum 的体育主题并将其称为职位。不管你怎么看待他们，他们是人们为了玩 Scrum 而进入的部分。在我看来，“问责制”并没有描述这一点，只会增加混乱。
变化 2：不再有开发团队
CHANGE：不再有开发团队，只有开发人员。
Scrum 指南的作者 Jeff 和 Ken 表示，他们一直不喜欢在 Scrum 团队内部拥有一个开发团队的“团队中的团队”。在这个最新版本中，他们通过摆脱开发团队的概念来解决这个问题。Scrum 团队是现在 Scrum 中唯一的团队，它由三个职责组成：Scrum Master、产品所有者 (product owner) 和开发人员 ( developer)。
对您团队的影响：对于经验丰富的团队 - 这种变化可能只是表面上的。它让人回想起过去；我们曾经称他们为开发人员，而不是开发团队。但要明白，这种语言的转变是为了强调“一个团队”的概念。
对于新团队——简单理解，现在只有 Scrum 团队由三个职责组成：产品负责人、Scrum Master 和开发人员。
BRIAN 的意见：虽然我明白这个改变的目的并且同意 Scrum 中只有一个团队，但我有点担心这个改变的意外后果。这主要是由于新 Scrum 指南的下一个方面：开发人员指南。以前的版本明确说明了该组的权利和责任。现在，以简洁的名义缺少了这一点。看到 go 运行时我特别难过的一句话是，“没有人（甚至是 Scrum Master）告诉开发团队如何将产品待办事项列表转化为潜在可发布功能的增量。” 虽然有些人可能认为这是隐含的，因此不需要，但我相信有很多组织不习惯以这种方式运作，并且需要这个特殊提示来告诉他们如何 开发产品的决定权完全取决于开发人员。
从表面上看，这应该是一个积极的变化。但是作为从业者，我们需要帮助组织理解独立的意图仍然存在，即使它不再明确说明。
只要我们在修改名称，我宁愿将其更新为制作人或创作者之类的东西。开发人员是一个以软件为中心的术语，并且不鼓励软件之外的许多人使用 Scrum。我希望新的 Scrum 指南能借此机会提供一个与软件世界联系较少的词。
变化 3：不再有仆人领袖
更改：Scrum 指南在描述 Scrum Master 时删除了“仆人式领导者 (servant leader) ”一词，取而代之的是“真正的领导者 (ture leader)”。
对您的团队的影响：对于经验丰富的团队 - 除非“真正的领导者”有一个不清楚的替代含义，否则这里可能没有影响。对于新团队 - 由于您没有使用此短语的任何历史记录，因此这可能对您没有影响。
BRIAN 的意见：我认为这种变化是最难理解的。作为一个术语，仆人式领导有什么冒犯之处？到底什么是“真正的领导者”？
我只能推测这种变化的原因。也许这与科技界的运动有关，在数据库中删除主/从术语，因为有些人认为它可以被视为对奴隶制的引用，因此具有攻击性。不管你对此有什么看法，我也确实听到敏捷圈子里的一些传言，出于同样的原因，也许我们应该重新考虑 Scrum Master，甚至是 Servant Leader 这个词。
仆人式领导与奴隶制无关。仆人式领导是罗伯特·格林利夫在 1970 年代发起的一项运动，旨在描绘一个谦逊的领导者为那些希望被领导的人服务的画面。这是在商业世界中发生的令人难以置信的强大范式转变——Scrum Master 的角色传统上与这个术语联系在一起是有充分理由的。我上面说过，我认为“真正的领导者”是一个毫无意义的词。没有“真正的领导者”运动或哲学。听起来好像有人想保留仆人式领导的意思，但用类似的词代替。如果这是新术语出现的地方，那将是一种耻辱；它将基于错误信息和对什么是仆人式领导缺乏了解。
我希望作者们会重新考虑，他们会重新审视“仆人领袖”一词的传统和政治正确性。我希望这个术语能够回到未来版本的 Scrum 指南中。
变化 4：添加承诺 (Commitments)
变更：每个工件现在都有一个伴随的“承诺”：产品待办列表 (product backlog) 的产品目标 (product goal)、Sprint 待办列表 (Sprint backlog) 的 Sprint 目标 (Sprint backlog) 和增量 (increment) 完成的定义 (Definition of Done)。
对您团队的影响：对于经验丰富的团队 - 如果您已经在使用产品愿景，这应该不会影响您的团队。对于新团队 - 在 Scrum 中，您将越来越少地听到产品愿景，而更多地听到这个产品目标。它们似乎通常是同义词。
BRIAN 的意见：这个改动有点棘手。在这些承诺中，Sprint Goal 和 Definition of Done 都存在于之前版本的 Scrum 指南中，但不是作为对其工件的附加承诺。产品目标是唯一的新想法，至少在涉及到 Scrum 指南时是这样。
大多数培训师和教练多年来一直在教导产品所有者拥有产品愿景的好处，这是产品的指导力量。正如 Roman Pichler 所说，这是产品的“真正的北方”。现在让我们看看新版 Scrum 指南是如何引用产品目标的：
“产品目标描述了产品的未来状态，可以作为 Scrum 团队计划的目标。”
如果您无法区分产品愿景和产品目标之间的差异，那么您并不孤单。为什么作者选择忽略社区已经在使用术语产品愿景并将其替换为产品目标？除了它与 Sprint Goal 更好地配对之外，我找不到其他原因。如果可以说明 Product Vision 和 Product Goal 有何不同，我还没有听说过。因此，如果您今天正在使用产品愿景并开始称其为产品目标，那么这可能就是您在技术上与新的 Scrum 指南保持一致所需要做的全部工作。
这个添加的一个小细节让我感到恼火，因为它在 Scrum 指南中定义。对于产品目标和 Sprint 目标，这个新的 Scrum 指南说这些项目在它们各自的待办事项中。如果不是这么明确地说明，我不会再考虑这一点。但是，考虑到产品待办列表由生产产品所需的所有已知信息组成，这怎么可能呢？Sprint Backlog 类似地包含产生 sprint 的产品增量所需的所有已知信息。在这两种情况下，待办事项都是要做的事情：功能、任务、错误、峰值等。那么在待办事项中的目标如何？除非我们重新定义积压工作或为目标创建积压工作的特殊新部分，否则它们在积压工作中似乎没有意义。我让出肥皂盒。
变化5：Sprint计划 (Sprint Planning) 三个问题 (3 Questions)
变化：Sprint 计划已经从两个问题（什么和如何）扩展到三个 - 为什么 (Why)、什么 (What) 和如何 (How)。
对您团队的影响：如果有的话，影响很小。
BRIAN 的观点：多年来，Sprint Planning 活动的目标是回答两个问题：我们将做什么以及我们将如何完成它？在最新版本的 Scrum 指南中，作者在顶部添加了一个问题：“为什么这个 Sprint 有价值？” 然后他们继续解释 Scrum 团队合作创建 Sprint 目标。
这些都不是新鲜事。
作为 WHAT 讨论的一部分，团队总是有一个由产品负责人提出的 Sprint 目标，然后整个 Scrum 团队协作定义。如果我们在这里挑剔的话，我不确定 Sprint 目标是否为我们提供了 sprint 的原因。它给了我们冲刺的目标，但不是为什么这个目标很重要。换句话说，Scrum 团队不需要证明他们的目标是正确的，他们只需要定义它。
在我看来，这是定义团队将从事的工作的常规部分。如果您的团队需要三个描述的问题来确定 Sprint 目标、产品待办列表项以及创建它们的任务，请随意。
问两三个问题可能对 Scrum 团队如何运行他们的冲刺没有影响。我还没有听到关于为什么在新的 Scrum 指南中明确指出这一点的有效解释。
这些变化的共同主题
您可能已经注意到这里的一个主题。此新版本中的大多数更改不会对您今天在组织中运行 Scrum 的方式产生实质性影响。当然，您可能会更改您使用的术语，或者您可能会在测试中以稍微不同的方式回答问题，否则您将不需要更改任何内容来遵守最新版本的 Scrum。
更大的影响来自被删除的内容。为了使 Scrum 指南更小，一些人认为是关键的元素已被删除。如果组织记得 2017 Scrum 指南并且现在不改变他们的方法，那么可能没有问题。对于第一次采用 Scrum 的新组织来说，他们没有那种历史可言，框架中可能存在关键漏洞，无法以符合 Scrum 历史优势的方式加以填补。我希望这些组织能够寻求指导以帮助他们解决缺乏经验的问题。如果组织仅从 2020 Scrum 指南中学习，我们可能在未来几年内看不到这些变化的影响。
362
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
