敏捷软件开发-Scrum

本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。

敏捷软件开发框架之 Scrum

Scrum 是一个轻量级框架，可帮助人员、团队和组织通过针对复杂问题的自适应解决方案创造价值。

Scrum 是目前主流的接受度最高的敏捷框架之一，Scrum 的短周期、固定时间盒、稳定的节奏有利于快速响应变化，实现业务价值的快速交付，在互联网行业中深受欢迎。

Scrum 历史

Scrum 的历史最早追溯于 1986 年的组内弘高（管理学者、哈佛商学院教授）和野中郁次郎（日本经营策略学者）在《哈佛商业评论》发表《The New New Product Development Game》文章。阐述了一种新的整体性方法，能够提高商业产品开发的速度和灵活性，并将这种整体性方法与橄榄球比较，引入了 Scrum 术语。

1990 年，肯·施瓦伯（Ken Schwaber）在其公司 Advanced Development Methods 使用了一种方法，这种方法后来发展为 Scrum。

1991年，Peter DeGrace 和 Leslie Hulet Stahl 在《Wicked Problems, Righteous Solutions》一书中将这种方法称为 Scrum，引用在竹内弘高和野中郁次郎的文章中提到的 Scrum 术语。

1993 年，杰夫·萨瑟兰（Jeff Sutherland）在 Easel 公司开发了一种类似的方法，并使用单个词 Scrum 来代表这方法。

1995 年，在奥斯汀举办的 OOPSLA '95 上，萨瑟兰和施瓦伯联合发表了论文首次提出了 Scrum 概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的 Scrum。

2001 年，肯·施瓦伯（Ken Schwaber）与麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用 Scrum 过程》一书，介绍了 Scrum 方法。

2002 年，肯·施瓦伯（Ken Schwaber）与 Mike Cohn、Esther Derby 共同建立了 Scrum 联盟（Scrum Alliance）并建立了 Certified Scrum 认证系列。

2009 年末，肯·施瓦伯（Ken Schwaber）离开了 Scrum 联盟（Scrum Alliance），创立了 Scrum.org，该机构负责监督并行的 Professional Scrum 认证系列。

自 2009 年以来，肯·施瓦伯（Ken Schwaber）和 杰夫·萨瑟兰（Jeff Sutherland）已发布并更新了名为 《Scrum 指南》（Scrum Guide）的公共文件。该版本已被修订 6 次，当前版本为 2020 年 11 月。

2020 年 5 月，杰夫 · 萨瑟兰（Jeff Sutherland）在 2006 年创立的 ScrumInc 公司，开始教授“Scrum Inc 认证系列”。

Scrum 理论基础与三大支柱

理论基础

Scrum 基于经验主义和精益思维。经验主义主张知识源自实际经验以及根据当前观察到的事物作 出的判断所获得。精益思维减少浪费，专注于根本。

Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。Scrum 让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。

Scrum 将 4 个正式事件组合在一起以在一个容器型事件 Sprint 中进行检视和适应。这些事件之所 以起作用，是因为它们实现了基于经验主义的 Scrum 的三个支柱：透明、检视和适应。

三大支柱

• 透明

涌现的过程和工作必须对执行工作的人员和接受工作的人员都是可见的。在 Scrum 中，重要的决 策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。

透明使检视成为可能。没有透明的检视会产生误导和浪费。

• 检视

Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问 题。为了帮助检视，Scrum 以 5 个事件的形式提供了稳定的节奏。

检视使适应成为可能。没有适应的检视是毫无意义的。Scrum 事件旨在激发改变。

• 适应

如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或过程处理 的内容加以调整。调整工作必须尽快执行以最小化进一步的偏差。

当所涉人员没有得到授权或不能自管理（self-managing）时，则适应将变得更加困难。在通过检 视学到任何新东西时，Scrum Team 会做出相应调整。

Scrum 主要内容

Scrum 包括

1. Scrum 团队（3 个角色：Product Owner、Scrum Master、Dev team）
2. Scrum 事件（5 个活动：Sprint 会议、Sprint 计划会议、每日站会、Sprint 评审会议、Sprint 回顾会议）
3. Scrum 工件（3 个工件：Product Backlog、Sprint Backlog、Product Increment）
4. Scrum 价值观（5 个价值观：承诺、专注、开放、尊重、勇气）

Scrum 团队

Scrum 团队由一名 Scrum Master，一名 Product Owner 和 Dev team（通常 5~9 人）组成。在 Scrum 团队中，没有子团队或层次结构，是专业人士的凝聚力单元，一次专注于一个目标，即产品目标。

Dev team：是 Scrum 团队中致力于创建每个 Sprint 可用增量的任何方面的人员。

• Dev team 职责

1. 为 Sprint 创建计划，即 Sprint 待办事项列表
2. 通过遵循“完成”的定义来灌输质量
3. 每天根据 Sprint 目标调整计划

Product Owner：负责 product backlog 的管理，并使 Scrum 团队的工作所产生的产品价值最大化。

• Product Owner 职责

1. 制定并明确传达产品目标
2. 创建并明确传达产品代办事项
3. 确保产品待办列表是透明的、可见的和可理解的

Scrum Master：负责建立 Scrum 指南中定义的 Scrum，对 Scrum 团队的有效性负责，是为 Scrum 团队和更大的组织服务的真正领导者。

• Scrum Master 职责

1. 通过多种方式为 Scrum 团队提供服务
2. 通过多种方式为产品负责人提供服务
3. 通过多种方式为团队提供服务

Scrum 事件

Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的机会。Scrum 使用事件来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。

Scrum 主要包含五大事件：Sprint、Sprint 计划会、每日 Scrum 站会、Sprint 评审会、Sprint 回顾会。

• Sprint

短迭代时间盒，是 Scrum 的核心，将创意转化为价值，包括 Sprint 计划会议、每日 Scrum 会议、Sprint 评审会议和 Sprint 回顾会议。Sprint 是一个固定时长的时间（固定时间盒），一起一个月或更短（短周期），以保持一致性（稳定的节奏）。

在 Sprint 期间：

1. 不能做出危机 Sprint 目标的改变；
2. 不能降低质量；
3. 产品待办列根据需要进行细化；
4. 随着了解更多，范围可能会与产品负责人进行澄清和重新判断。

• Sprint 计划会议

Sprint 计划通过安排要为 Sprint 执行的工作来启动 Sprint。产品负责人确保参与者准备好讨论最重要的产品待办事项以及它们如何映射到产品目标。

Sprint 计划会议解决以下主题：

1. 为什么这个 Sprint 有价值？
2. 此 Sprint 可以做什么？
3. 所选工作将如何完成？

• 每日 Scrum 会议

每日 Scrum 会议的目的是检视达成 Sprint 目标的进展，并根据需要调整适应 Sprint 待办列表，以调整即将进行的计划工作。

每日 Scrum 会议是一个属于 Scrum 团队的开发人员的 15 分钟的事件。

每日 Scrum 会议改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。

每日 Scrum 站会需要回答 3 个问题：

1. 昨天我做了哪些事情
2. 今天计划要做什么事情
3. 是否遇到困难，阻碍打成目标

• Sprint 评审会议

Sprint 审查的目的是检查 Sprint 的结果并确定将来的适应方案。Scrum 团队向主要利益相关者介绍他们的工作结果，并讨论实现产品目标的进度。

• Sprint 回顾会议

Sprint 回顾展的目的是计划提高质量和有效性的方法。Scrum 团队检查有关个人，交互，流程，工具及其完成的定义的最后 Sprint 的进展情况。被检查的元素通常随工作领域而变化。确定使他们误入歧途的假设，并探究其起源。

Scrum 工件

Scrum 工件：Scrum 的工件代表工作或价值。它们旨在最大程度地提高关键信息的透明度。

每个工件都包含一项承诺，以确保其提供增强透明度和重点的信息，以此来衡量进度：

• 对于产品积压列表，这是产品目标
• 对于 Sprint 待办事项列表，这是 Sprint 目标
• 对于增量，它是完成的定义

Sprint 工件主要包括：Product Backlog、Sprint Backlog、Product Increments。

Product backlog

产品待办列表是一个紧急的，有序的列表，列出了改进产品所需的内容。它是 Scrum 团队进行工作的唯一来源。

Sprint backlog

Sprint 待办事项列表由 Sprint 目标（为什么），为 Sprint 选择的产品待办事项项集（做什么）以及交付增量（如何做）的可行计划组成。Sprint Backlog是开发人员制定的计划。这是开发人员计划在 Sprint 期间为实现 Sprint 目标而完成的工作的高度可见的实时图片。

产品增量

增量是实现产品目标的具体垫脚石。每个增量都是所有先前增量的补充，并经过彻底验证，以确保所有增量共同起作用。为了提供价值，增量必须可用。除非符合“完成”的定义，否则不能将作品视为增量的一部分。

Scrum 价值观

Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观：承诺、专注、开发、尊重、勇气。

• 承诺：愿意对目标做出承诺
• 专注：把时间和精力都用到承诺的工作上去
• 开放：Scrum 把项目中的一切开放给每个人看
• 尊重：每个人都有他独特的背景和经验
• 勇气：有勇气做出承诺，履行承诺，接受别人的尊重

总结

Scrum 成为当前软件开发的新范式，被越来越多的企业采用，促进了 Scrum 的发展和繁荣，但也出现了一些挑战和争议。

Scrum 在 1990 年代初被定义、发展和完善，成为当前主流的敏捷软件开发框架之一。Scrum 建立在经验注意和精益思想基础上，非常注重好的思想方法的沉淀和借鉴；同时从精益思想上吸取了众多的优秀理念（精益思想在后面的文章有详细介绍），例如减少浪费、精益求精、关注客户价值等，使得 Scrum 能够很好的满足团队当前的需要和未来的目标。

Scrum 要求是自组织跨职能的全功能团队，这一点已经超出了很多组织结构的能力范畴，这对当前大多数职能型组织而言，特别是以福特或斯隆管理模式（职能部门下的大批量生产方式的软件协作）下采用 Scrum 是极其困难且大概率失败的，因此，采用 Scrum 对于大多数职能型团队而言有很大的风险和挑战。

同时 Scrum 是不完整的，只提供了简单的原则、价值观、工件与角色，且过于简单化，因此缺少实操性，加大了落地的难度。这也是目前在业界 Scrum 听起来很美好，落地却不尽人意的重要原因之一。

《数字化 IT 从业者知识体系》背景 数字化和可持续发展是中国企业未来发展的两大主题，掌握数字化知识，具备数字化能力，应用数字化技术是我们 IT 从业者未来核心竞争力所在。《数字化 IT 从业者知识体系》的初衷是为IT从业者提供的系统性的数字化知识体系，内容涵盖管理实践、工程实践、技术实践三个层次，涉及软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四大方面。 在接下来的《数字化 IT 从业者知识体系》系列文章，何文强将从软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四个方面，为大家进行逐一分享介绍：

1. 软件开发方法主要包括瀑布、敏捷、精益等；
2. 应用技术架构主要包括微服务架构、服务网格架构、无服务器架构、分布式多运行架构等；
3. 应用部署与管理主要包括但不限于虚拟化技术、容器技术与容器编排等；
4. 软件交付与协作主要包括但不限于CMMI、ITIL、DevOps等。

相信该知识体系有利于 IT 从业者构建丰富的技术体系、全面的技术视野和系统的能力建设。欢迎大家前往《数字化 IT 从业者知识体系》话题进行详细阅读。