什么是 Scrum 以及如何入门

人们通常认为 Scrum 和敏捷开发是同一回事，因为 Scrum 关注持续改进，而这是敏捷开发的核心原则。但是，Scrum 是完成工作的框架，而敏捷开发是一种理念。敏捷开发理念侧重于通过小规模和频繁的发布进行持续的渐进改进。您无法真正“敏捷化”，因为这需要整个团队一致努力才能改变其向客户交付价值的思维方式。但是，您可以使用 Scrum 等框架来协助您开始思考这一方式，并在日常沟通和工作中实践如何构建敏捷开发原则。

敏捷开发和 Scrum 的定义之间的区别可以在 Scrum 指南和敏捷宣言中找到。敏捷宣言概述了四个价值观：

• 个人和交互优先于流程和工具

• 工作软件优先于全面的文档

• 客户协作优先于合同谈判

• 响应变化优先于遵循计划

Scrum 的定义基于经验主义和精益思维。经验主义说，知识来自经验，决策是根据所观察到的情况做出的。精益思维可以减少浪费，并专注于本质。Scrum 框架是一种基于持续学习和波动因素调整的启发式框架。它承认团队在项目开始时并不了解所有内容，并通过吸取经验教训不断发展。Scrum 的结构旨在帮助团队自然而然地适应不断变化的条件和用户要求，并在流程和较短的发布周期中重新调整优先级，以便您的团队不断学习和改进。

虽然 Scrum 是结构化框架，但它并不是完全僵化的。它的执行可以根据任何组织的需求量身定制。关于 Scrum 团队必须如何工作才能取得成功，有很多理论。但是，十多年来，在帮助 Atlassian 敏捷团队完成工作的过程中，我们发现，无论您选择何种框架，清晰的沟通、透明度和致力于持续改进始终都是该框架的核心。剩下的，就得靠您自己了。

Scrum 框架概述了 Scrum 团队在交付产品或服务时遵循的一系列价值观和原则，以及一些实践案例。该框架详细介绍了 Scrum 团队的成员及其责任、定义产品和产品创建工作的“工件”，以及指导 Scrum 团队完成工作的 Scrum 仪式。

Scrum 团队是一个小而灵活的团队，致力于提供承诺的产品增量。Scrum 团队的规模通常很小，只有 10 人左右，但此等规模已足以在冲刺中完成大量工作。Scrum 团队需要三个特定角色：产品负责人、Scrum 大师和开发团队。由于 Scrum 团队跨职能部门，因此“开发团队”除了开发人员之外，还包括测试人员、设计人员、用户体验专员和运维工程师。

Scrum 产品负责人

产品负责人是产品的领航者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能：

• 构建和管理产品待办事项。

• 与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。

• 明确指导团队接下来提供哪些功能。

• 确定何时发布产品，且倾向于更频繁地交付产品。

产品负责人并不一定是产品经理。他们专注于确保开发团队为企业带来最大的价值。此外，产品负责人必须是一个人。没有开发团队需要多个产品负责人的混合指导。

Scrum 主管

Scrum 主管是其团队中 Scrum 方面的领航者。他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法精确调整其在此方面的实践。

高效的 Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为首席推动者，此角色负责安排冲刺规划、每日站会、冲刺审查和冲刺回顾所需的资源（人力和物力）。

Scrum 开发团队

Scrum 团队是具体工作的执行者。他们是可持续发展实践方面的翘楚。效率最高的 Scrum 团队关系紧密、同地协作，成员通常为 5 到 7 名。确定团队规模的一种方法是遵循 Amazon 首席执行官 Jeff Bezos 提出的著名“两个披萨原则”，也就是“团队规模不应过大，以便分享两个披萨”。

团队成员熟练掌握不同的技能，并且彼此互相锻练，因此没有人会成为交付工作的瓶颈。强大的 Scrum 团队会自我组织，以明确的团队态度来处理项目。团队的所有成员互相帮助，以确保成功完成冲刺。

Scrum 团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。

Scrum 工件是 Scrum 团队使用的重要信息，它可帮助定义产品以及创建产品而需完成的工作。Scrum 中有三种工件：产品待办事项、冲刺待办事项以及您对“完成”的扩展定义。Scrum 团队应在冲刺期间和一段时间内回顾这三个固定元素。

• 产品待办事项是产品负责人或产品经理需要完成和维护的主要工作列表。它是功能、要求、增强功能和修复的动态列表，并用作 Sprint 待办事项的输入。本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或是可能会以其他方式解决问题。

• Sprint 待办事项是开发团队为实现当前冲刺周期而选择的项目、 用户故事或缺陷修复列表。每次冲刺之前，在冲刺规划会议（我们将在后文进行讨论）中，团队从产品待办事项中选择要通过冲刺处理的项目。Sprint 待办事项可能较为灵活，可以在冲刺期间发展。但是，基本的冲刺目标（团队希望通过在当前冲刺中实现的目标）不能受到影响。

• 增量（或冲刺目标）是冲刺中可用的最终产品。在 Atlassian，我们通常会在冲刺结束演示期间展示“增量”，团队会展示在冲刺期间完成的内容。在此领域之外，您可能不会听到“增量”一词，因为它通常是指团队对“已完成”、里程碑、冲刺目标，甚至是完整版本或已交付长篇故事的定义。这取决于您的团队如何定义“已完成”以及您如何定义冲刺目标。例如，某些团队选择在每次冲刺结束时向客户发布某些东西。因此，他们对“已完成”的定义将是“已交付”。但对其他类型的团队而言，可能并非如此。假设您正在开发基于服务器的产品，该产品只能每季度向客户交付一次。您仍可选择在为期 2 周的冲刺中工作，但是，您对“已完成”的定义可能只是“完成您计划一起发布的更大版本的其中一部分”。当然，软件发布所需的时间越长，软件未能达到预期结果的风险就越高。

如您所知，您的团队可以选择定义许多变体，即使是在工件内也是如此。正因如此，必须保持开放态度，积极改进工件维护方式。也许您对“已完成”的定义会给您团队减压，您需要返回并选择一个新的定义。

Scrum 框架包括 Scrum 团队需定期执行的 Scrum 实践、仪式和会议。在敏捷仪式中，我们会发现各团队之间的最大差异。例如，有些团队认为举行所有这些仪式既繁琐又重复，而另外一些团队则将其作为必要的登记手段。我们的建议是，先在两个冲刺阶段执行所有仪式，看看感觉如何。然后，您可以进行快速回顾，看看哪些方面需要调整。

下面列出了 Scrum 团队可能参加的所有重要仪式：

1. 整理待办事项列表：有时称为待办事项列表梳理，这项活动由产品负责人负责。产品负责人的主要工作是推动产品实现其产品愿景，并时刻把握市场和客户的脉搏。因此，他/她会利用用户和开发团队的反馈意见来维护这个列表，以帮助确定优先级，并保持列表的整洁，以便随时开展工作。可以点击此处了解有关健康待办事项列表的更多信息。

2. 冲刺规划：在这次会议上，整个开发团队对当前冲刺期间要执行的工作（范围）进行规划。该会议由 Scrum 大师主持，团队在会上决定冲刺目标。然后，从产品待办事项为冲刺添加具体的用户故事。这些故事始终与目标保持一致，并经 Scrum 团队一致认为在冲刺期间实施是可行的。

   在规划会议结束时，每个 Scrum 成员都需要明确在冲刺中可以交付的内容，以及如何交付增量。

3. 冲刺：冲刺是 Scrum 团队合作完成一个增量的实际时间段。两周是一个冲刺的典型长度，但有些团队认为一周更容易确定范围，或者一个月更容易交付有价值的增量。Scrum.org 的 Dave West 建议，工作越复杂，未知因素越多，冲刺的时间就应该越短。但这确实取决于您的团队，如果行不通，您不应该害怕改变它！在此期间，如有必要，产品负责人和开发团队可以重新协商范围。这就是 Scrum 经验主义的核心。

   从规划到回顾，所有活动都发生在冲刺阶段。一旦确定了冲刺的时间间隔，就必须在整个开发期间保持一致。这有助于团队从过去的经验中吸取教训，并将该洞察信息应用到未来的冲刺中。

4. 每日 Scrum 或短会：这是一个超短会议，该会议在某个地点于每天的同一时间（通常是早晨）召开以确保简单。许多团队试图在 15 分钟内完成会议，但这只是一个指导原则。该会议也被称为“每日短会”，强调它必须是一个快速的会议。每日 Scrum 的目的是让团队中的每个人都保持同步，与冲刺目标保持一致，并为接下来的 24 小时制定计划。

   您可以在每日短会上说出自己在实现冲刺目标或解决任何障碍时遇到的任何问题。

   每日短会的一种常见举行方法是让每个团队成员回答三个与实现冲刺目标相关的问题：
   
   • 我昨天做了什么？
   • 我今天计划做什么？
   • 是否有任何阻碍？
   
   然而，我们看到会议很快就变成了大家念念昨天和第二天的日程表。短会的理论基础是，它可以将分散注意力的唠叨转移到每日的会议中，这样团队就可以在当天剩下的时间里专注于工作。因此，如果它变成了每天日程表宣读会，则应果断做出改变以求创新。

5. 冲刺审查：在冲刺结束时，团队聚在一起进行非正式会议，以观看增量演示或检查增量。开发团队向利益相关者和团队成员展示目前处于“已完成”状态的待办事项，以征求他们的反馈。尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。

   此次审查会议也是产品负责人根据当前冲刺重新制定产品待办事项的时候，这可以为下一次冲刺计划会议提供信息。对于为期一个月的冲刺，可考虑将您的冲刺审查时间限制为最长四个小时。

6. 冲刺回顾：回顾是指团队聚集在一起共同记录和讨论冲刺、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。这样做的目的是创造一个场所，让团队能够专注于哪些工作进展顺利和哪些地方有待下一次改进，而不是专注于出了什么问题。

2016 年，Scrum 指南添加了五个 Scrum 价值观。这些价值观为 Scrum 团队的工作、行动和行为提供了指导。它们对于 Scrum 团队的成功至关重要。

承诺

Scrum 团队规模小且敏捷，每个团队成员都对团队的成功起着重要作用。因此，每个团队成员都应同意承担自己可以完成的任务，而不是过度投入。应经常就工作进度进行沟通，通常采用站会形式。

勇气

对于 Scrum 团队来说，勇气就是勇于质疑现状或任何阻碍其成功的东西。Scrum 团队成员应该有勇气尝试新事物，并感到足够安全。Scrum 团队应该有勇气和安全感，对障碍、项目进度、延误等情况保持透明。

重点

Scrum 团队工作流的核心是冲刺，这是一段有针对性的特定时段，团队在此期间完成一定数量的工作。冲刺不仅提供了清晰的工作结构，还有助于集中精力完成计划的工作量。

开放

每日站会可以促进开放性，让团队可以公开谈论正在进行的工作和障碍。在 Atlassian，我们的 Scrum 团队经常会解决以下问题：

• 我昨天做了什么？

• 今天要做什么？

• 哪些问题阻碍了我？

这有助于突出进度并发现障碍。每个人都分享进展时，还有助于加强团队力量。

尊重

敏捷团队的优势在于协作，以及认识到每个团队成员都在冲刺中为工作做出了贡献。他们互相庆祝成就，并尊重彼此、产品负责人、利益相关者和 Scrum 主管。

Scrum 是一个极受欢迎的敏捷框架，以至于 Scrum 和敏捷方法常被误解为同为一物。此外，还有一些其他框架（比如看板）也是很受欢迎的替代方案。某些公司甚至会选择采用 Scrum 与看板的混合模式，并将其命名为“Scrumban”或“Kanplan”；即，附带待办事项列表的看板。

Scrum 和看板均使用 Scrum 板或看板面板等可视化方法来跟踪工作进度。两者虽均强调效率，并可将复杂的任务拆分成易于管理的若干较小工作，但它们实现目标的方法却各有不同。

Scrum 专注于较小、固定长度的迭代。冲刺的时间段最终确定后，便会确定在此冲刺周期内可实施的故事或产品待办事项条目。但在看板中，当前周期中要实施的任务数量或正在进行的工作量（WIP 限制）起初却是固定的。随后，会反向计算实现这些功能所花费的时间。

看板的结构化程度不如 Scrum。与 WIP 限制不同，人们对它的解释可谓相当开放。但是，Scrum 在实现过程中必须强制实施几个明确的概念，如冲刺审查、回顾、每日 Scrum 等。此外，它还坚持跨职能性，即 Scrum 团队不依赖外部成员来实现目标的能力。组建跨职能团队并非易事。从此意义来讲，看板的适应度更高，而 Scrum 则可视为开发团队的思维过程与运作方式的根本性转变。

Scrum 框架本身很简单。规则、工件、事件和角色都不难理解。其半规范性方法实际上有助于消除开发过程中的模糊性，同时可为公司提供足够的空间来引入自己的个性风格。

Scrum 可将复杂的任务组织成易于管理的用户故事，是棘手项目的理想之选。此外，明确划分角色和规划开展的活动可确保整个开发周期的透明度和集体自主权。快速发布可保持团队的积极性和用户满意度，因为他们可以在短时间内看到工作进度。

但是，我们可能需要一定的时间才能充分理解 Scrum，尤其是在开发团队已经习惯使用典型的瀑布式模型的情况下。小型迭代、每日 Scrum 会议、冲刺审查和确定 Scrum 大师的概念对于新团队来说可能是具有挑战性的文化转变。

但是，长期的好处远远超过最初的学习曲线。Scrum 在跨不同行业和垂直领域开发复杂的硬件和软件产品方面取得的成功，使其成为满足贵组织需求的卓越框架。

如需通过 Jira 了解 Scrum，请 查阅本教程。