Scrum 是一种敏捷项目管理框架，通过价值观、原则和实践帮助团队组织和监督工作。Scrum 鼓励团队从经验中学习，在解决问题时自主组织，并反思成败以持续改进。

谁是 Scrum 框架的主要使用者？

软件开发和工程团队广泛采用 Scrum 方法，以适应不断变化的需求并控制成本。但开发人员和工程师并非唯一使用者，其原则和经验可应用于各类团队合作，从营销团队到 IT 团队均适用。

人们常将 Scrum 与敏捷混为一谈，因为 Scrum 以持续改进为核心—这正是敏捷的核心原则之一。但实际上，Scrum 是一套工作执行框架，而敏捷是一种理念。

敏捷理念的核心是通过小型、频繁的发布实现持续增量改进。您无法真正“实现敏捷”，因为这需要整个团队全力以赴，改变其向客户交付价值的思维方式。

不过，您可以借助 Scrum 等框架开启这种思维模式，并在日常沟通与工作中践行敏捷原则。

敏捷与 Scrum 的区别可参考《Scrum 指南》和《敏捷宣言》。《敏捷宣言》明确了四项价值：

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

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

• 客户合作高于合同谈判

• 通过遵循计划应对变化

Scrum 基于经验主义和精益思维。经验主义认为，知识源于经验，决策应基于可观察到的事实而做出。

精益思想常与看板配合使用，旨在减少浪费、聚焦核心要素。Scrum 理论基于三大核心原则—经验主义、精益思想与迭代改进。

若应用得当，该理论将指导 Scrum 实施的结构设计、实践落地与持续改进。

Scrum 框架的发展历程之所以能取得如今的成功，很大程度上要归功于 Jeff Sutherland 的开创性工作。20 世纪 90 年代初，Sutherland 与 Ken Schwaber 共同研发了 Scrum，旨在应对复杂软件开发项目的管理挑战。

Sutherland 为项目管理带来了独特视角，强调团队合作、适应性和清晰沟通。他在高压环境中的实践经验塑造了 Scrum 协作式、迭代式的特质，使其成为解决复杂问题的有力工具。

如今，Scrum 团队在工作组织、价值交付和持续改进等方面的实践，均清晰体现了 Sutherland 的影响力。

Scrum 要求明确的角色与组成部分，包括 Scrum 大师、产品负责人和 Scrum 团队，通过迭代冲刺交付价值。

Scrum 框架概述了 Scrum 团队在交付产品或服务时遵循的一系列价值观、原则与实践。它详细定义了 Scrum 团队的成员及其职责或 Scrum 工件。

这些工件定义了产品本身及产品创建所需的工作，而 Scrum 仪式则指导 Scrum 团队推进工作。Scrum 团队是一个小型、跨职能、自主管理的单元，负责在每个冲刺阶段交付有价值的产品增量。

虽然 Scrum 具有结构化特点，但并非完全僵化。其执行方式可根据任何组织的需求进行调整。关于 Scrum 团队如何运作才能取得成功，存在诸多理论。

但是，在 Atlassian 助力敏捷团队开展工作十多年后，我们总结出：无论您选择何种框架，清晰的沟通、透明度以及对持续改进的专注，都应作为核心。

其余部分，则由您掌控。

Scrum 团队是一个小而灵活的团队，致力于交付承诺的产品增量。它通常是一个精简且紧密协作的群组，规模约 10 人左右。

但具备在一个冲刺阶段内完成大量工作的能力。大多数 Scrum 团队需要三类角色：产品负责人、Scrum 大师和开发团队。

产品负责人是其产品的掌舵者。他们专注于理解业务需求、客户需求及市场需求。

该角色会相应地对工程团队要完成的工作进行优先级排序。高效的产品负责人需具备以下能力：

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

• 通过制定、排序及透明化管理产品待办事项实现冲刺待办事项管理，确保规划与优先级排序的有效性。

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

• 为团队提供明确指导，确定后续需交付的功能。

• 决定产品的发布时机，倾向于更频繁地交付产品。

产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大的价值。

产品负责人必须由个人担任。没有开发团队愿意接受来自多位产品负责人的混乱指导。

Scrum 大师是团队内部 Scrum 实践的倡导者。他们为团队、产品负责人及业务方提供 Scrum 指导，并寻找优化实践的方法。

Scrum 大师的核心职责是通过辅导、清除障碍及推动 Scrum 流程落地，提升 Scrum 团队的工作效能，进而助力团队改善整体绩效与交付能力。

有效的 Scrum 大师能深入理解团队工作内容，协助团队优化工作透明度与交付流程。

作为核心协调者，他们负责安排必要的资源（包括人力与后勤资源）。这些资源涵盖冲刺规划、每日站会、冲刺审查及冲刺回顾等所有相关资源。

Scrum 开发团队执行力极强，是可持续开发实践的践行典范。

最高效的 Scrum 团队紧密协作、集中办公，成员规模通常为 5 至 7 人。确定团队规模的一种方法是采用亚马逊 CEO Jeff Bezos 提出的著名“双披萨原则”：团队规模应小到能分享两份披萨。

团队成员需具备多元化技能组合并相互交叉培训，避免任何个人成为工作交付中的瓶颈。优秀的 Scrum 团队具备自组织能力，以明确的“团队协作”态度推进项目。

所有团队成员相互支持，确保冲刺阶段圆满完成。Scrum 团队主导每个冲刺阶段的计划制定。

他们会以历史速度为指导，预测迭代周期内可完成的工作量。团队通过过往表现评估自身产能，提升冲刺规划的准确性。

固定迭代周期长度能为开发团队提供关于估算与交付流程的重要反馈，使预测愈发精准。基于此评估，团队会审慎规划下一冲刺阶段可交付的内容。

Scrum 工件是 Scrum 团队用于明确产品定义及开发所需工作的核心信息。Scrum 包含三类工件：产品待办事项、冲刺待办事项，以及符合完成标准 (DoD) 的增量

Scrum 团队应在冲刺期间及整个开发过程中对这三个常量进行复盘。

这是产品负责人或产品经理需负责制定和维护的核心工作清单。它是一份动态更新的清单，包含功能、需求、优化及问题修复等内容，是冲刺待办事项的输入来源。

本质上，它是团队的“待办事项”清单。

产品待办事项由产品负责人持续回顾、重新优先级排序和维护。随着团队认知加深或市场变化，部分清单项可能不再相关，或相关问题已通过其他方式解决。

待办事项列表项目的优先级排序以最大化客户价值为核心，确保交付的功能能直接提升客户满意度和长期业务价值。

这是开发团队选定在当前冲刺周期中实施的项目、用户故事或缺陷修复清单。在每个冲刺前的冲刺规划期间，团队会从待办事项列表中挑选将要处理的项目。

冲刺待办事项可保持灵活性，并在冲刺期间动态调整。但核心的冲刺目标—团队在当前冲刺中需达成的成果—不可妥协。

增量，通常也称为冲刺目标，是冲刺阶段产出的可用最终产品。在 Atlassian，我们通常会在冲刺结束演示会上展示该增量，团队会在演示中呈现冲刺期间完成的成果。

该术语常被称为团队的完成标准、里程碑、冲刺目标，甚至是完整版本或已发布的长篇故事，具体取决于团队对完成以及冲刺目标的定义方式。

例如，部分团队会在每个冲刺结束时向客户发布产品。因此，他们的“完成标准”即为已交付。由此可见，即使在同一类工件范围内，团队也可以灵活定义多种不同的”完成标准“。

这正是为何要保持开放心态，持续优化工件的维护方式。或许您的完成标准给团队带来了过度压力，此时就需要重新审视并选择新的完成标准。

Scrum 框架包含 Scrum 团队定期执行的实践、仪式与会议。敏捷仪式是团队间差异最明显的环节。

建议团队先完整执行所有仪式两个冲刺周期，再评估实际效果。之后可以进行快速复盘并确定调整方向。以下是 Scrum 团队可能参与的所有关键仪式清单：

该活动有时也被称为待办事项列表梳理，由产品负责人负责。产品负责人的核心职责是朝着产品愿景推进产品，并持续掌握市场动态与客户需求。

他们会结合用户与开发团队的反馈维护这份清单，以确定优先级，确保清单清晰有序，随时可以投入工作。

整个开发团队会在本次会议中规划当前冲刺期间需执行的工作（范围）。该会议称为冲刺规划活动，由 Scrum 大师主持。

本次会议期间，团队将确定冲刺目标并规划需完成的工作。然后，从产品待办事项中选取具体的用户故事添加到该冲刺中。

这些故事始终与目标保持一致，并经 Scrum 团队一致确认在冲刺期间可落地实施。规划会议结束时，所有 Scrum 团队成员均应明确了解冲刺期间需交付的内容，以及如何实现该增量。

冲刺是 Scrum 团队协作完成产品增量的实际时间段。这种有时间限制的迭代周期被称为冲刺，通常持续 1 至 4 周。

两周是常见的冲刺时长，但部分团队会认为 1 周更便于明确工作范围，有的则选择 1 个月以交付更具价值的产品增量。Scrum.org 的 Dave West 建议，工作越复杂，未知因素越多，冲刺阶段就应该越短。

但这取决于您的团队，而且您不应该害怕在行不通时改变它！在此期间，如有必要，产品负责人和开发团队可以重新协商范围。

这正是 Scrum 经验主义本质的核心所在。从规划到回顾，所有活动都发生在冲刺阶段。一旦确定了冲刺的特定时间间隔，就必须在整个开发期间保持一致。

这有助于团队从过去的经验中吸取教训，并将该洞察信息应用到未来的冲刺中。

每日 Scrum 或站会

这种超短时间的日常会议需同步进行（通常在上午），原则是简洁高效。这类关键的有时限会议被称为每日 Scrum，旨在检视冲刺目标的达成进度、协调团队活动，并识别阻碍因素。

很多团队都尝试在 15 分钟内完成会议，但这只是一个指导原则。此会议也被称为“每日站会”，强调其需快速高效。

每日 Scrum 的目的是让团队中的每个人都保持同步，与冲刺目标保持一致，并为接下来的 24 小时制定计划。可使用每日站会模板快速启动会议，提升组织效率。

站会是团队成员表达对达成冲刺目标的担忧或提出障碍的时机。开展站会的常见方式是，每位团队成员围绕冲刺目标的达成回答以下三个问题：

• 我昨天做了什么？

• 我今天计划做什么？

• 是否有任何阻碍？

然而，我们发现这类会议很快就会演变成大家单纯宣读昨日和次日的日程表。站会的核心理念是将分散注意力的讨论集中在每日会议上，从而让团队在当天剩余时间专注工作。

因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。

在冲刺结束时，团队聚在一起进行非正式会议，以观看演示或检查增量。开发团队向利益相关者和团队伙伴展示目前处于“已完成”状态的待办事项列表项目，以征求他们的反馈。

尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。此次审查会议也是产品负责人根据当前冲刺重新处理产品待办事项之时，其结果可用于下一次冲刺规划会议。

对于为期一个月的冲刺，可考虑将您的冲刺审查时间限制为最长四小时。

回顾是团队共同记录和讨论冲刺、项目、人员或关系、工具乃至特定仪式中有效与无效的环节。

其目的是为团队创造一个聚焦于“亮点做法”和“下次改进方向”的空间，而非过度纠结于过往问题。

2016 年，《Scrum 指南》新增了五项 Scrum 价值观。这些价值观为 Scrum 团队的工作方式、行动和行为提供了指导方向。在敏捷环境中，有效协作、对任务的投入以及对 Scrum 原则的坚守，是团队取得成功的关键所在。

承诺

由于 Scrum 团队规模小且具备敏捷特性，每位团队成员都对团队的成功起着关键作用。每位团队成员都应同意承担自己能够完成的任务，避免过度承诺。

应经常就工作进展进行沟通，通常采用站会形式。

勇气

Scrum 团队的勇气，本质上是敢于质疑现状或任何阻碍其成功的事物的魄力。Scrum 团队成员应具备勇气，并在心理上感到足够安全，从而勇于尝试新事物。

Scrum 团队还应具备勇气，且在心理上感到足够安全，以便坦诚公开项目阻碍、进展情况及延期问题。

重点

Scrum 团队工作流的核心是冲刺，这是一个目标明确、期限固定的周期，团队需在此期间完成既定工作量。冲刺不仅为工作提供了结构化框架，更能让团队集中精力完成计划内的工作量。

开放性

每日站会倡导开放的沟通氛围，使团队能够公开讨论正在进行的工作及遇到的障碍。在 Atlassian，我们通常要求 Scrum 团队解决以下问题：

• 我昨天做了什么？

• 今天要做什么？

• 哪些问题阻碍了我？

这有助于凸显工作进展并识别障碍。分享进展还能增强团队凝聚力。

尊重

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

尽管 Scrum 是应用最广泛的敏捷框架，但它并非唯一选择。看板提供了另一种方法，其强调持续交付与工作流转，而非固定时长的迭代周期。

在看板中：

• 工作项通过面板可视化呈现，并受进行中的工作量 (WIP) 限制管控。

• 团队仅在产能释放时才拉入新工作，以构建稳定、持续的工作流。

• 无预设角色或仪式，相比 Scrum，看板更具灵活性和轻量化特性。

何时使用看板：

• 适用于需处理持续涌入任务的团队（如支持团队或运营团队）。

• 当优先级频繁变动、难以维持固定冲刺承诺时尤为实用。

何时使用 Scrum：

• 最适合产品或功能开发场景，此类场景中增量交付、结构化和可预测性至关重要。

• 对于能从明确角色定义、仪式和冲刺目标中获益的团队效果显著。

混合方法：

部分团队会融合两种框架的元素，形成通常所说的 Scrumban 或 Kanplan（带待办事项列表的看板）。这种混合模式允许团队保留 Scrum 的待办事项列表和规划机制，同时融入看板在执行层面的灵活性。

Scrum 联盟是帮助人们深化对 Scrum 原则的理解并推进职业发展的主要资源平台。作为一家致力于推广 Scrum 框架的全球性组织，Scrum 联盟提供一系列认证和培训计划。

它们专为 Scrum 大师、产品负责人和其他 Scrum 从业者而设计。实际上，认证 Scrum 大师 (CSM) 和认证 Scrum 产品负责人 (CSPO) 是特别受欢迎的认证。

它们为专业人士构建 Scrum 实践与价值观的坚实基础。获得这些认证不仅体现了个人对敏捷方法的执着追求，更为其开启项目管理和软件开发领域的新机遇。

借助活跃的社区资源、持续教育支持及行业认可的认证体系，Scrum 联盟助力个人与组织通过 Scrum 实现成功。

采用 Scrum 及其他敏捷方法对任何组织而言都可能是一次重大变革，此时敏捷教练便能提供协助。敏捷教练与 Scrum 团队紧密合作，引导他们完成转型过程，并指导团队成员在日常工作中应用 Scrum 原则。

他们协助组织 Scrum 活动（如冲刺规划会和回顾），并就协作与沟通的最佳实践为团队提供指导。敏捷教练在扫除团队进度障碍方面发挥着关键作用。

核心目标是让 Scrum 团队专注于价值交付。敏捷教练通过提供定制化培训与支持，赋能团队成员接纳敏捷实践。

这将培育持续改进的文化，并提升跨多个团队和项目场景下 Scrum 团队的工作效能。

即使是经验丰富的 Scrum 团队，也会面临变革阻力、方向不明确以及 Scrum 培训不足等挑战。从小规模入手（例如从一个项目或一个团队开始），有助于克服这些障碍。

全面的培训和持续的指导能增强团队对 Scrum 及敏捷方法的信心。清晰的目标、角色与职责可确保所有人保持行动一致。

定期回顾和反馈会议能助力团队反思过往、灵活调整并持续改进。通过尽早应对这些挑战，Scrum 团队可以增强弹性、提升协作效率，进而借助 Scrum 框架达成目标。

跟踪 Scrum 团队的进度与成效，对于持续改进和项目成功至关重要。Scrum 团队通常使用冲刺速度、燃尽图和客户满意度评分来衡量绩效。

监控提前期、周期时间和缺陷密度也能为团队工作流和产品质量提供洞察信息。定期的冲刺审查与回顾是关键的 Scrum 活动。

这些审查让团队能够反思成果、识别成长空间，并庆祝冲刺的成功完成。通过持续衡量这些指标并根据反馈采取行动，Scrum 团队不断优化实践、交付更大的客户价值，确保通过 Scrum 框架实现长期成功。

Scrum 框架本身很简单。规则、工件、活动和角色均易于理解。其半规范性方法有助于消除开发过程中的模糊地带。

但是，也为公司预留了足够空间以融入自身特色。通过将复杂任务整理为可管理的用户故事，Scrum 成为复杂项目的理想选择。

清晰的角色划分与规划好的活动能确保开发周期中的透明度与集体责任感。快速发布机制既能保持团队积极性，也能让用户在短时间内看到项目进展，提升满意度。

但是，完全理解 Scrum 可能需要一定时间，尤其是对于习惯典型瀑布模型的开发团队而言，更是如此。较短的迭代、每日 Scrum 会议、冲刺审查以及确定 Scrum 大师，对新团队来说可能是一次具有挑战性的文化转型。

但从长远来看，其带来的收益远超过初期的学习成本。Scrum 在不同行业和领域的复杂软硬件产品开发中均取得了成功，使其成为组织值得采用的极具吸引力的框架。

如需学习如何结合 Jira 使用 Scrum，请查阅本教程。