Scrum 是一种轻量却极具效力的框架。它依托跨职能自管理团队，以短周期模式交付产品与服务，助力团队实现以下价值：

• 快速获取反馈

• 加速创新进程

• 推动持续改进

• 快速响应变化

• 提升客户满意度

• 缩短从创意到交付的周期

“Scrum” 这一术语源自 1986 年《哈佛商业评论》的一篇文章 ——《新型产品开发游戏》。在该文章中，作者竹内弘高与野中郁次郎将高效能的跨职能团队，比作橄榄球运动中的 “争球”进行类比。1995 年，在德克萨斯州奥斯汀举行的 “面向对象编程、系统、语言与应用大会”上，肯・施瓦伯与杰夫・萨瑟兰首次将 Scrum 正式确立为一套框架并公之于众。

尽管 Scrum 起源于软件开发领域，但如今它已应用于几乎所有行业 —— 旨在帮助团队解决复杂性问题，交付真正让客户满意的创新产品与服务。

解锁 Scrum 的底层逻辑：

• 一套包含职责、工件与事件的轻量级框架

• 应对复杂问题的自适应解决方案

• 植根于精益思想与实验主义
  

Scrum 是应用范围最广、也最受欢迎的敏捷框架。“敏捷” 这一术语，描述的是基于《敏捷宣言》确立的、一套用于组织和管理复杂工作的核心原则与价值观。这份宣言的起草者们还曾斟酌过 “轻量级” 与 “适应性” 这两个表述，最终一致认为 “敏捷” 是最契合其初衷的术语。《敏捷宣言》于 2001 年 2 月 11 日正式发布。

Scrum 之所以能体现敏捷原则，是因为它助力团队快速响应各类变化（如市场需求、环境条件、新规政策等），优先考量客户反馈，并以可控的增量形式交付成果。Scrum 之所以被认定为敏捷框架，正是源于它所秉持的敏捷原则与价值观。

《敏捷宣言》阐释了其起草者所秉持的核心价值观：

“个体与互动 高于 流程与工具

可用的软件 高于 详尽的文档

客户协作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管宣言右侧的各项内容也具备价值，但我们更珍视左侧的内容。”

践行 Scrum 框架可带来多重益处，包括：

• 降低风险

• 提升应对优先级变化的能力

• 发现团队与组织中阻碍价值交付的瓶颈

• 通过频繁交付可用产品增量，增强相关方透明度

• 创造检视与调整的机会，基于所学及时修正方向

该框架通过定期开展检视与调整，助力团队持续优化协作模式、缩短产品上市周期，并借助常态化反馈循环提升客户满意度。此外，Scrum 对透明度与协作的重视，能营造更具参与感和积极性的团队氛围，进而提升工作效率与成果质量。

Scrum 团队会在每一个功能增量完成后进行检视，再基于所学经验与反馈调整后续工作计划 —— 从而降低风险、减少浪费。这一循环不断重复，持续为干系人、业务端及 Scrum 团队提供机会，使其能够根据市场环境变化、竞争态势调整等各类需求，灵活做出转向调整。

• 职责

• 工件

• 事件

这三大核心组件与若干简单规则协同作用，构建起持续改进与适应的循环机制，确保团队及组织能够快速响应变化，高效交付高价值产品。

Scrum 包含三大核心职责（此前称为 “角色”），确保各项协作工作均得到有效管理。

• 开发团队：Scrum 团队中的专业人员，通过协作完成产品相关的各类工作，在Sprint期间交付产品增量。任何具备产品构建所需技能的人员，均可承担开发者的核心职责，具体所需技能需根据产品性质而定。
  
  

• 产品负责人：制定并传达产品目标，对产品待办列表全权负责，确保团队始终聚焦最高价值的工作。同时，需平衡干系人、客户与团队的需求，深入理解业务领域、产品市场，并致力于交付客户及用户真正需要的成果。
  
  

• Scrum Master：引领并指导组织进行 Scrum 的采纳与实践。通过引导团队运用 Scrum 框架、内化敏捷原则，助力团队高效构建产品并实现自我优化。核心工作包括辅导团队有效运用 Scrum 事件与工件，日常中协助团队处理各类障碍，对团队整体及成员个人的成长至关重要。

此外，Scrum Master 还通过为组织及干系人提供 Scrum 采纳与实验主义实践的教练支持，为组织敏捷转型提供多维度助力。
Scrum 团队由上述三大核心职责构成：每个团队设一位 Scrum Master、一位产品负责人，开发团队。团队规模通常不超过 10 人，具备自管理与跨职能双重属性。传统项目经理的多项职责会在三大核心职责间合理分配，而部分项目管理职责则可能不再需要。

Scrum 框架包含五大事件。这些事件是开展检视与调整的宝贵契机 —— 既可以针对产品本身进行优化，也可以改进团队的协作方式，有时还能兼顾两者。

• Sprint：Sprint是 Scrum 的核心环节，是一个受时间盒约束的周期（时长不超过 1 个月，常见周期为 1-2 周），团队需在该周期内产出一个或多个增量。所有其他 Scrum 事件均包含在Sprint之内。

• Sprint计划会：全体 Scrum 团队成员共同制定Sprint目标。开发团队会预估为达成该目标，自身能够完成的工作内容，并明确完成所选工作的具体实施方案。Sprint计划会的时间盒有明确上限：若Sprint周期为 1 个月，计划会时长最长不超过 8 小时；Sprint周期更短时，计划会的时间盒也需相应缩短。团队会基于Sprint目标与工作量预估，制定一份初步的执行计划。此外，Scrum 团队可邀请外部人员参与Sprint计划会，为相关工作提供建议或参考意见。

• 每日Scrum站会：在每日Scrum站会中，开发团队会检视Sprint目标的推进进度，并根据需要调整工作计划。这是一项由开发团队自主主导的每日短时事件，核心目的是开展检视与调整，时间盒固定为 15 分钟。每日Scrum站会并非团队调整计划的唯一机会 —— 团队通常会在该事件之外，就需要调整的方向进行沟通。站会期间，团队会同步当日工作安排、识别当前存在的障碍，并讨论需开展的协作事项。通过每日Scrum站会，团队能明确当前计划是否有助于逼近Sprint目标，并在必要时及时调整方向。

• Sprint评审会：整个 Scrum 团队会与干系人共同检视本次Sprint的成果，并确定未来的调整方向。干系人会受邀参与，对团队已达成的成果及产品未来开发方向提供反馈。产品待办列表会根据这些讨论内容进行适应性调整。

• Sprint回顾会：作为Sprint的收尾环节，回顾会是团队进行自我检视的机会。团队会重点反思自身的互动方式、协作模式、工作流程、使用工具，以及其他所有认为与持续改进能力相关的因素。

梳理优化是一项持续不断的活动，核心目的是为后续的Sprint规划会准备好合格的产品待办列表项。团队可在此过程中调整待办项的描述、优先级排序、工作量规模等细节。需明确的是，这并非一项 Scrum 正式事件：部分团队倾向于召开定期会议（通常每个Sprint开展 1-2 次），另一些团队则更偏好按需对产品待办列表项进行梳理优化。

尽管产品负责人最终对产品待办列表的状态与内容负有全责，但他们可将产品待办列表的管理工作委托给他人（责任本身不可转移）。所有相关责任的最终归属，始终是产品负责人。

Scrum 工件是实现透明、检视与调整三大核心原则的载体。它们清晰呈现团队正在开展的工作内容，确保任何人 —— 无论是团队成员、干系人还是管理人员等 —— 都能检视工作成果，并识别出可通过调整优化产品的环节。

• 产品待办列表:这是一份按优先级排序的清单，包含改进产品所需的所有事项，同时关联对应的产品目标。产品目标是产品待办列表的配套承诺，并且是产品待办列表的有机组成部分。

• Sprint待办列表：它由三部分内容构成：一是Sprint目标；二是产品负责人与开发团队共同预估、计划在当前Sprint内完成的产品待办列表项集合（需注意，团队未必能完成全部事项）；三是交付产品增量、达成Sprint目标的具体实施方案。Sprint目标是Sprint待办列表的配套承诺，在Sprint期间不得变更（而工作范围则可根据实际情况调整）。当实施方案在Sprint过程中（或在每日站会中）发生变化时，这些调整都需同步体现在Sprint待办列表中。

• 增量：当一项产品待办列表项的完成符合产品既定的质量要求（通常在完成的定义中明确界定），且能够交付价值、具备可使用性时，它就成为一个增量。每个增量均为累加式增量，其特性是不会破坏此前已完成的成果，并且在后续新的产品待办列表项完成后，仍能长期稳定运行。对增量的承诺，就是完成的定义。

在 Scrum 框架中，每一项工件都对应一项专属承诺，以此确保所有工作始终聚焦于交付高质量与高价值的成果。

• 增量的完成定义：完成的定义明确了增量的质量验收标准，只有满足该标准的产品待办列表项，方可被认定为 “已完成”。一旦产品待办列表项符合完成定义的要求，它就成为一个增量。
  
  

• Sprint待办列表的Sprint目标：Sprint目标是针对单次Sprint设定的、具体且唯一的目标，用于明确本次Sprint的核心意图。Sprint目标是团队对Sprint待办列表的核心承诺，它能帮助所有人聚焦Sprint的核心任务与价值意义。Sprint目标必须为开发团队留出灵活调整工作范围的空间，同时为Sprint期间的所有工作赋予一致性与凝聚力。
  
  

• 产品待办列表的核心导向是产品目标：清晰理解产品的总体目标，是团队高效组织工作的关键前提。一款产品在其生命周期内可能会设定多个产品目标，但同一时间仅能有一个生效。

Scrum 的核心职责、工件与事件 在Sprint周期内形成有机协同。产品负责人结合干系人与用户的反馈信息，通过产品目标明确产品开发方向；同时，识别并定义可交付的价值单元，通过这些价值的逐步交付，持续推进产品目标的实现。

产品负责人需确保产品待办列表的优先级有序排列，让团队清晰知晓各项工作的重要程度。开发团队可协助产品负责人进一步细化待办事项的具体交付要求，产品负责人也可依靠开发团队，共同做出相关的取舍决策。在这一过程中，待办列表梳理优化就成为了 Scrum 团队一项至关重要的实践工作。

尽管 Scrum 框架仅规定了核心要素，但以下是一些入门实操建议：

1.明确 “产品” 定义及产品边界

2.组建新的 Scrum 团队

3.制定产品目标及若干产品待办列表项
4.确立 “完成的定义”

在Sprint计划会上，Scrum 团队通过协作明确Sprint目标。基于该目标，开发团队从产品待办列表中选取工作项（通常优先选择优先级较高的项），并确定具体的交付方案。团队需在一个固定的时间周期（即 Sprint）内达成Sprint目标。期间，团队会通过每日站会检视Sprint目标的推进进度，并规划当日工作安排。在此过程中，Scrum Master需确保团队始终聚焦Sprint目标，并协助团队实现整体能力提升。

Scrum 团队会在Sprint评审会上，向干系人展示本次Sprint的成果。团队既可在评审会中，也可在后续的Sprint规划会上，对产品待办列表做出适应性调整。

团队会召开Sprint回顾会，复盘本次Sprint期间的工作亮点与不足。会议讨论的内容可涵盖协作模式、工具使用、沟通方式以及工作实践 —— 这些因素都曾对Sprint目标的达成起到推动或阻碍作用。团队会基于会议讨论结果制定改进举措，以此优化未来的Sprint工作。

在Sprint计划会上，团队会从产品待办列表中选定下一轮Sprint的任务项，自此，整个迭代周期进入新一轮循环。

向 Scrum 这类敏捷框架转型，需要团队建立全新的思维模式，同时推动组织整体文化的调整。与所有变革一样，这个过程并非一帆风顺。但当团队与组织真正全身心投入 Scrum 实践后，便会收获前所未有的灵活性、创造力与工作灵感 —— 而这些，终将转化为更卓越的工作成果。

Scrum 团队的每位成员都需专注于手头工作，全力支撑Sprint目标的达成。

Scrum 团队始终保持开放心态，积极吸纳新想法、主动把握学习机会；需要帮助时坦诚沟通，同时向团队及干系人透明分享面临的挑战。

Scrum 团队成员彼此尊重，同时尊重产品负责人、干系人以及 Scrum Master。团队深知，自身的战斗力源于高效协作，而Sprint工作的推进，离不开每个人的独特贡献。他们尊重彼此的想法，允许他人偶尔状态不佳，也会认可彼此的工作成就。

Scrum 依托其核心要素运作，这使它格外适用于应对复杂且动态变化的项目。该框架巧妙平衡了结构化规范与灵活性适配的关系，助力团队高效应对需求变更，交付高质量成果。借助自身核心要素，Scrum 为团队提供了一套轻量化的赋能型约束规则，使其能在不确定性中推进工作，并实现工作的持续改进。

Scrum 基于经验主义过程控制理论构建，该理论的核心依赖三大支柱：透明、检视、调整。

有效决策的前提是流程透明、产品进度透明，且参与者需使用统一的共识语言 —— 确保所有人对所看到的信息都有一致理解。

Scrum 的五大事件，为透明、检视与调整三大支柱的落地提供了适宜的实践契机。

定期检视正在进行的工作，对于维护预设流程、达成预期目标至关重要。将这些检视环节无缝融入工作流程，可避免造成任何干扰。

Sprint评审会与Sprint计划会为团队提供了检视产品目标达成进度的机会，而Sprint回顾会则让团队得以审视自身的协作模式、配合状态与工作流程。这一整套流程既推动了团队的持续改进，又能保障工作进度不受阻碍地稳步推进。

调整指的是，当工作出现偏差时，及时对流程或产品做出相应调整。Scrum 团队拥有灵活调整的空间，可在每个Sprint周期内，对产品待办列表、产品本身以及未来工作计划进行优化。这一机制确保了：只要在需求与产能的平衡范围内，所有必要的变更都能以最快速度落地执行。

增量式是指对现有产品或产品线进行的一系列小幅改进，这类改进通常有助于长期维持或提升产品的竞争优势。在高科技行业中，增量式创新的应用十分普遍。企业需要持续优化产品，融入更多消费者青睐的新功能。Scrum 团队采用小批量交付功能模块的方式，正是一种增量式的实践模式。