Scrum 指南是了解 Scrum 框架元素和相应规则的官方资源。好消息是，Scrum Guide 也将不时被检查和调整，以使其更加有效。通常每 2 到 3 年，它的共同创建者 Ken Shwaber 和 Jeff Sutherland 就会发布一个新版本的 Scrum 指南。
2020年11月，发布了最新版本（2020版）Scrum Guide。在此之前是 2017 年 11 月。根据从各个行业、实施 Scrum 的组织收到的信息，将对 Scrum 指南进行更改。
在本文中，您将能够清楚地了解 2017 和 2020 版 Scrum 指南之间的变化以及这些变化背后的原因。
| 更改说明 | 2017版 | 2020版 | 可能的原因 |
| Scrum 指南的长度（页数） | 19页 | 14 页 | 为了使其不那么规范。作者删除了一些看起来很规范的内容。因此，减少页数背后的原因是使其更有效的“框架”而不是“规范”的方法类型。这意味着使用 Scrum 指南的人将有更多的责任来确定合适的工具、技术、流程和问责制，以便在它们不起作用时进行更改。 |
| 定义 | 人们可以在一个框架内解决复杂的适应性问题，同时以富有成效和创造性的方式交付具有最高价值的产品。 | Scrum 是一个轻量级框架，可帮助人员、团队和组织通过针对复杂问题的自适应解决方案创造价值。 | 复杂的问题意味着，未知多于已知。所以对于复杂的问题，大多数时候你可能没有第一个正确的解决方案，你必须进行试验。因此，为了突出“自适应解决方案”，定义发生了变化。 |
| 定义 | 没有明确提到“不完整” | Scrum 框架故意不完整，只定义了实现 Scrum 理论所需的部分。Scrum 建立在使用它的人们的集体智慧之上。Scrum 规则不是为人们提供详细的说明，而是指导他们的关系和互动。 | 为了明确框架，通过强调Scrum框架的不完整方式来明确。这有助于人们有责任确定正确的实践、流程、工具等。它还关注使用 Scrum 框架的“人”参与。 |
| Scrum 理论 | 没有提到精益 | Scrum 建立在经验主义和精益思想之上 | 无论如何，Scrum 都专注于“消除浪费”，这是精益的主要哲学。现在它更清楚地了解精益思想。 |
| 经验主义定义 | 经验主义断言，知识来自经验，并根据已知的东西做出决定 | 经验主义断言，知识来自经验，并根据观察到的东西做出决定。 | 一个复杂的问题，未知多于已知。因此，解决方案不能一蹴而就，而且可能需要进行多次实验来解决问题。因此，解决方案可以基于多次实验演变。每个实验都提供了一些学习。因此，“观察”一词比“已知”更合适 |
| 角色 | 使用术语“角色”来代表 Scrum 团队 | “角色”被“责任”取代 | 通常，人们可能会混淆角色和职务。而且，一个角色可以由很多人扮演，一个角色可能伴随着一系列责任，扮演这些角色的人只会专注于处理与该角色相关的责任，而不是这些责任的最终结果的所有权。因此，将角色转换为问责制更加强调让人们意识到他们对 Scrum 团队中的结果的问责制。 |
| 开发小组 | 这被用作 Scrum 团队的一部分 | 这被重命名为“开发人员” | “开发团队”更接近于软件，但 Scrum 可以用于任何行业。因此，为了代表开发增量为客户创造价值的人，它被重命名为“开发人员”。 |
| 团队规模 | 开发团队规模应在 3 到 9 人之间 | 团队规模被转移到 Scrum 团队级别而不是开发人员级别。现在 Scrum 团队的规模不超过 10 人。 | 当在开发团队级别提到规模时，听起来开发团队是分开的。为了使其达到 Scrum 团队级别，团队规模被移动到 Scrum 团队级别。 |
| 大型 Scrum 团队 | 没有明确提到如何处理 | 明确提到将大型 Scrum 团队拆分为更小的团队 | 这有助于清楚地了解如何在不影响透明度和有效沟通的情况下组建小型 Scrum 团队来处理更大的项目。 |
| 自组织 | 这用于开发团队应该是自组织的 | 这已更改为自我管理并在 Scrum 团队级别提及 | 自组织意味着人们关心谁，何时以及如何，但“什么”超出了他们的范围。 自我管理意味着团队决定谁做什么、何时以及如何做。为了使 Scrum 团队更加自主和负责，进行了此更改。 |
| 团队技能 | Scrum 团队：跨职能、自组织 开发团队：跨职能、自组织、无其他头衔、无子团队 | Scrum 团队：跨职能、自我管理、无子团队、无层次结构 | 就是强调 Scrum 团队是“一个团队”。 |
| 产品负责人的职责 | 有人提到可以将某些职责委派给开发团队 | 一些产品负责人的职责可以委托给其他人（不仅仅是开发人员） | 根据实施 Scrum 的行业，有时可以将某些产品负责人的职责委派给某些主题专家。然而，它明确提到产品负责人仍然负责。 |
| Scrum Master 的职责 | 职责：建立Scrum | 问责制：建立 Scrum 和 Scrum 团队的有效性 | 明确Scrum Master应该在改进协作、沟通、实践、工具等方面帮助Scrum Team，这将提高Scrum Team的有效性 |
| Scrum Master 服务 | 服务分为： 产品负责人、开发团队和组织 | 服务分为：产品负责人、Scrum 团队和组织 | 有时产品负责人和开发人员可能会一起接受指导，以改善他们的协作、沟通和整个 Scrum 团队的效率。所以除了单独提供给产品负责人的服务之外，一些服务列在 Scrum 团队级别下。 |
| 仆人领袖 | 有人提到 Scrum Master 应该是“仆人式领导者” | 改为“真正的领袖” | 为了避免滥用仆人领袖，它被真正的领袖取代。仆人式领导是“真正的领导者”技能的一部分。还要明确的是，Scrum Master 不是团队级别的，而是具有组织级别职责的领导角色。 |
| 活动 | 仅在 Daily Scrum 中提到“同一时间，同一地点” | “同一时间，同一地点”现在适用于 Sprint 中的所有事件 | 对于硬件/基础设施等一些项目，可能会保留一些物理工件来代替这些事件的进行。因此，将这些事件放在相同的位置将是有效的，因此透明度可以很高并且可以在这些事件期间有效地使用这些工件。 |
| 短跑 | 没有明确提到它是所有其他四个事件的容器 | 现在很清楚，Sprint 是一个容器事件，包含其余四个事件。 | 它清楚地表明 Sprint 是一个独立的单元，其余四个事件将在其中完成以创建有用且可用的增量 |
| Sprint 计划受邀者 | 提到任何其他人都可以根据开发团队的邀请参加 | Scrum 团队可以邀请任何其他人提供建议 | 建议可以是与功能建议、技术建议或与实践和实践相关的任何输入相关的任何内容。因此 Scrum 团队可以邀请相关的其他人参与 Sprint 计划 |
| Sprint 计划主题 | Sprint 计划中列出了“什么”和“如何”主题 | “为什么”主题也被添加为附加主题。 | 重要的是要知道“为什么”正在构建当前的 Sprint 增量，以便开发人员可以在一个方向上进行统一和高水平的协作 |
| 每日站会 | 提到了 Daily Scrum 中要涵盖的 3 个问题。 | 很清楚，开发人员可以决定合适的结构 | 这是为了减少规定性，并将决定 Daily Scrum 必须进行的方式的责任留给开发人员 |
| Scrum Master 和产品负责人在 Daily Scrum 中的角色 | 有人提到开发团队负责进行 Daily Scrum | 它被提到为： 如果产品负责人或 Scrum Master 正在积极处理 Sprint 待办列表中的项目，他们作为开发人员参与。 | 根据团队规模和实施 Scrum 的行业，可能有 Scrum Master 和产品负责人负责 Sprint Backlog 项目。因此包括此声明。不应认为让产品负责人和 Scrum Master 始终作为开发人员做出贡献是最佳实践。 |
| 每日站会后的会议 | 有人提到开发团队可以在 Daily Scrum 后立即开会 | 提到开发人员可以全天开会进行更详细的讨论和重新规划 | 根据需要（例如讨论障碍的解决方案、任何基于对 Sprint 工作的影响的计划外休假，或在开发人员之间分配工作），全天进行讨论是很好的 |
| 冲刺回顾 | 在 Sprint Review 中提供了一个关于谁做什么的脚本，这使得它非常规范。 提到了被产品负责人邀请的受邀者。 | 通过删除分步说明来减少它。 没有明确提到谁邀请了与会者。 | 这是为了减少规定性，让 Scrum 团队决定如何最好地完成 Sprint 评审以使其更有效。 |
| 冲刺回顾 | 没有明确提到将 Retrospective 中确定的改进添加到 Sprint Backlog | 有人提到： “。它们甚至可能被添加到下一个 Sprint 的 Sprint Backlog 中。” | 这是为了提醒开发人员在下一个 Sprint 中进行已确定的改进。 |
| 冲刺积压 | Sprint Backlog 是为 Sprint 选择的产品 Backlog 项目的集合，加上交付产品增量和实现 Sprint 目标的计划。 | Sprint Backlog 由 Sprint 目标（为什么）、为 Sprint 选择的一组产品待办列表项（什么）以及交付增量的可操作计划（如何）组成。 | 它是强调“为什么”我们在做我们在 Sprint 中做的“什么”。因此，将 Sprint 目标添加到 Sprint Backlog 将为开发人员提供明确的方向。 |
| 产品待办列表细化 | 通常不应在 Sprint 中占用超过 10% 的开发团队容量 | 这被替换为“根据需要”。 | 提供 10% 听起来像是一种规范的方式。根据产品类型和实施 Scrum 的行业，Scrum 团队可以决定产品待办列表细化所需的持续时间。 |
| 产品目标 | 此版本未提及 | 它被提及并将成为产品待办列表的一部分。 | 拥有产品目标有助于更有效地集中 Scrum 团队的工作。Goal 帮助他们想象产品的未来并做出相应的计划。 |
| 工件承诺 | 未提及 | 为以下三个工件创建了明确的承诺： 产品待办列表 → 产品目标 Sprint 待办事项 → Sprint 目标 产品增量 → 完成的定义 | 创建对每个工件的承诺将使 Scrum 团队明确方向，并相应地专注于对工作的检查 |
| 增量 | 在 Sprint 结束时增加一个 | 在整个 Sprint 中可以创建多个增量 | 明确基于客户需求的持续价值交付 |
| 增量启动 | 没有明确规定 | 产品待办列表项满足完成定义的那一刻，增量就诞生了。 | Sprint Backlog 中的单个项目可能会为利益相关者创造一个独立的价值，因此它可以在完成后立即独立发布 |
| 在 Sprint 评审之前发布增量 | 没有明确提及 | 明确提到可以在Sprint Review之前发布增量 | 这提高了持续交付和频繁为利益相关者创造价值的速度 |
| 完成的定义 | 由开发团队创建 | 由 Scrum 团队创建 | 在 Scrum 团队之间对“完成”标准的共同理解方面将更加清晰 |
362
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
