Scrum 是符合敏捷开发原则的一种典型且在全球使用最为广泛的框架，它用于复杂产品的开发。本文将介绍包括 Scrum 的角色、事件（仪式）、工件，以及把它们组织在一起的规则等内容。

Tips：Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。与其说Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架。在此框架中你可以使用各种不同的过程和技术，它让你产品管理和开发实践的效果能够更加明显的展示出来，因此你可以去改进它们。

一、什么是 Scrum

Scrum 是一个帮助团队更好协作的框架。就像橄榄球队（它的名字的由来）为赢得大型比赛进行集训一样，Scrum 鼓励团队从经验中学习，以自组织的方式去处理问题，并对他们的胜利和失败反思，不断改进。虽然 Scrum 通常是被软件开发团队使用，但它的原则和经验可用于各种团队合作，这也是 Scrum 如此受欢迎的原因之一。

Scrum 通常被认为是一个敏捷项目管理框架，它描述了一组帮助协同工作的事件、工件和角色，旨在帮助团队更高效的组织和管理其工作。

二、Scrum 框架的主要内容

人们通常认为 Scrum 和敏捷开发是同一回事，因为 Scrum 关注持续改进，而这也是敏捷开发的核心原则。但是，Scrum 是完成工作的一种框架，而敏捷开发是一种思维模式。

并且，仅凭 Scrum 你无法真正“敏捷化”，因为这需要整个团队一致努力，才能改变组织向客户交付价值的思维方式。但是，你可以使用 Scrum等框架来协助你开始思考这一方式，并在日常沟通和工作中实践如何构建敏捷工作流原则。

Scrum 框架是一种基于持续学习和需求多变的启发式框架。它承认团队在项目开始时并不了解所有内容，要求团队吸取经验教训不断发展。Scrum 框架旨在帮助团队自适应不断变化的外部环境和用户要求，并在流程和较短的发布周期中快速调整优先级，以便团队不断学习和改进。

虽然 Scrum 是结构化框架，但它并不是完全僵化的，你可以根据组织需求调整其执行。关于 Scrum 团队如何才能成功有很多的理论。但是，十多年来，在帮助 PingCode 敏捷团队达成工作目标的过程中，我们发现，无论你选择何种框架，沟通、透明、持续改进始终都是框架的核心。

Scrum三个角色及对应职责

Scrum 团队需要三个特定角色：Product Ower（产品负责人）、Scrum（敏捷教练）和 Scrum 团队。由于 Scrum 团队为跨职能部门，因此除开发人员之外，开发团队还包括测试人员、设计人员、用户体验 (UX) 专家和运营工程师等等。

1、Product Ower

主要负责构建正确的产品，确定 Scrum 团队交付什么，并解释为什么做这些工作。Product Ower 是产品方面的佼佼者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。

高效的产品负责人应能：

• 构建和管理产品待办事项（Product Bcklog）。
• 与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。
• 明确指导团队接下来提供哪些功能。
• 确定何时发布产品，且倾向于更频繁地交付产品。
  产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。

2、Scrum Master

主要负责帮助产品负责人和开发团队中的每个人理解和拥抱 Scrum 的价值观、原则和实践，确保 Scrum 流程顺利进行。

Scrum master 是其团队中 Scrum 方面的佼佼者，他们负责对团队、产品负责人、企业进行 Scrum 流程方面的培训，并寻找方法持续优化他们在此方面的实践。

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

3、Scrum 团队

负责以正确的方式构建产品，执行具体工作任务。Scrum 团队是具体工作的执行者，成员通常为 5 到 9 名（并不绝对）。确定团队规模的一种方法是亚马逊首席执行官 Jeff Bezos 提出的著名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。

团队成员具有不同的技能，并且彼此互相学习成长，因此没有人会成为交付工作的瓶颈。强大的 Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成迭代。

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

Scrum三大工件

Scrum 工件是团队要完成的事情，就像是解决问题的工具。在 Scrum 中，常见的三个工件分别是 Product Backlog（产品待办事项）、Sprint Backlog（迭代待办事项），以及你对“DoD（已完成）”定义的增量变化。它们是 Scrum 团队中的三个常量，团队需要不断地对其进行重新审视，并投入额外的时间进行改进。

1、Product Backlog（产品待办事项）

Product Backlog 是整个产品的用户故事集合，这些用户故事可以来自甲方客户、Product Ower 自己对产品的理解、研发团队、公司战略规划拆解等等。

本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或者优先级出现调整等等。

2、Sprint Backlog（迭代待办事项）

Sprint Backlog 指的是在一个迭代周期中要完成的用户故事列表。这些用户故事来自 Product Backlog，每次迭代前，Product Ower 根据交付价值，将优先级最高的用户故事放入迭代。

每次进入迭代之前，团队需要召开迭代规划会议，团队从 Product Backlog 中选择本次迭代计划完成的需求。迭代待办事项可能较为灵活，也可以在迭代期间变化。但是，基本的迭代目标（团队希望通过在当前迭代中实现的目标）不能受到影响。

3、增量（或迭代目标）

增量是指在一个 Sprint 中完成的所有 Product Backlog 的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。

在完成以上三个工件的时候，团队可以选择定义很多变体，因为工件维护最好保持开放态度。比如对“已完成”、“故事点”重新定义，能更好的提升效率和品质，那你完全可以根据需求进行新的定义。

Tips：你应该像处理产品一样敏捷地处理 Scrum 框架，花一些必要的时间来检查事务的进展情况（无论是通过 PingCode 这样的工具或者是其他），并在必要时做出调整，而不要仅仅为了一致性而强迫自己执行某些事项。

Scrum 的事件（仪式）包括哪些

Scrum 框架还包括 Scrum 团队定期举行的一系列仪式。通过这些仪式，我们可以看到团队之间的差异。

例如，有些团队发现举行所有这些仪式既繁琐又重复，而另一些团队则将这些仪式作为必要的信息共享环节。而我们的建议是，在两次迭代阶段使用所有仪式，然后看看其效果。接着，你可以进行快速回顾，看看可能需要进行哪些调整。

以下是 Scrum 团队可能参加的所有重要仪式清单：

1、需求梳理

有时也被称为待办事项梳理，它由 Product Ower 负责。Product Ower 的主要工作是协助实现产品愿景，并持续关注市场和客户。因此，他可根据用户和开发团队的反馈来维护此列表，以协助确定列表的优先级以及保持整洁。

2、Sprint（迭代计划）

由整个开发团队在迭代计划会期间进行，主要规划当前迭代期间要执行的工作（范围）。迭代计划会议由 Scrum Master 主持，而团队则在会议期间决定迭代目标。接着，可将产品待办事项中的用户故事添加到迭代中。这些故事应与目标始终保持一致，且 Scrum 团队也承诺可在迭代期间完成。 在规划会议结束时，每位 Scrum 成员均需清楚在迭代期间可以交付的内容，以及如何交付增量变化。

3、Sprint（迭代）

迭代是 Scrum 团队共同完成增量的实际时间段。两周是一个相当典型的迭代时长，尽管某些团队发现一周更容易确定范围，或是一个月更容易提供有价值的增量变化。但国外知名敏捷教练 Dave West 建议，工作越复杂，未知因素就越多，而迭代就应该越短。但事实上，这取决于团队，而如果不起作用，团队也可以进行改变！

所有事件（从规划到回顾）都是在迭代期间发生的。一旦确定了迭代的特定时间间隔，就必须在整个开发期间保持一致。这有助于团队吸取经验教训，并将这些洞察应用于未来的迭代。

4、每日站会

这是每天在同一时间（通常是早晨）和地点举行的超短例会，为了确保此会议简洁明了，很多团队试图在15 分钟内完成会议，但这只是一个参考。

每日 Scrum 旨在让团队中的每一个成员都保持同步，共同朝着迭代目标努力，并制定未来 24 小时的计划。 你可在每日短会上说出自己在实现迭代目标或解决任何障碍时遇到的问题。 每日短会的其中一种常见举行方法是让每个团队成员在实现迭代目标的过程中回答三个问题：

• 我昨天做了什么？
• 我今天打算做什么？
• 是否存在障碍？
  然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是：它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。

5、Sprint （迭代评审）

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

此次审核会议也是产品负责人根据当前迭代重新处理产品待办事项之时，当前迭代可为下一次迭代规划会议提供相关信息。对于为期一个月的迭代，可考虑将你的迭代审核时间限制为最长四个小时。

6、Sprint（迭代回顾）

迭代回顾会是团队聚集在一起共同记录和讨论迭代、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。我们的思路是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待改进，而不是专注于出了什么问题。

三、Scrum、Kanban（看板） 和敏捷三者之间的关系

Scrum 是一个非常流行的敏捷框架，以至于 Scrum 和敏捷经常被误解为同一个东西。但是除 Scrum 外还有其他框架，例如看板，也是一种流行的替代方案。有的公司甚至选择采用 Scrum 和看板的混合模式。

Scrum 和看板都使用可视化管理方法，例如 scrum 板或看板板来跟踪工作进度。两者都强调效率并将复杂的任务拆分为更小的可管理工作，但他们实现该目标的方法不同。

Scrum 专注于较小的、固定周期的迭代。一旦确定了 sprint 的时间段，就确定了可以在该 sprint 周期内实现的需求。然而，在看板中，首先要在当前周期中执行的任务数或在制品（WIP 限制）是固定的。然后向后计算实现这些功能所需的时间。

看板不像 Scrum 那样结构化。除了 WIP 限制之外，它的原则或者实践是相当开放的。甚至，Scrum 部分概念也能作为其实施的一部分，如 Sprint 审查、回顾、每日站会等。它还更适应跨团队的协作，因为 scrum 团队不依赖外部成员来实现的能力他们的目标，在Scrum模式下要拼凑一个跨职能团队并不简单，其中涉及了思维方式和价值、流程等诸多转变。从这个角度上来看，看板更容易适应。

但是，为什么是 Scrum？

Scrum 框架本身很简单，规则、工件、事件和角色很容易理解。它的半规范性方法实际上有助于消除开发过程中的歧义，同时为公司提供足够的空间来介绍他们的个人风格。

其次，是 Scrum 擅长将复杂的项目转化成一个个可实现的待办事项。此外，角色和计划事件的明确划分确保了整个开发周期的透明度和团队的自组织性。以及快速发布能让团队保持积极性并让用户感到高兴，因为他们可以在很短的时间内看到进展。

然而，完全理解 Scrum 可能需要一些时间，尤其是在开发团队已经适应了典型的瀑布模型的情况下。较小的迭代、每日站会、迭代评审和确定 Scrum Master 的概念对于新团队来说可能是一个具有挑战性的文化转变。

但是，实施 Scrum 所带来的长期收益远远超过最初学习造成的成本。所以 Scrum 无论是在跨不同行业的垂直领域开发复杂的硬件或软件产品方面，都成功使其引人注目的框架。