Scrum是一套轻量级敏捷开发框架，用固定长度的迭代（Sprint）把复杂工作切成可交付的小块，由产品负责人、Scrum Master和开发团队三类角色协作，通过Product Backlog、Sprint Backlog和增量三类工件，以及Sprint规划、每日站会、Sprint评审和回顾四类事件持续检视与调整。本文围绕框架定义、组成要素与边界展开，帮助读者判断团队讨论的是否为同一件事。
要点总览（TL;DR）
- Scrum是一套轻量级敏捷开发框架，用固定长度的Sprint把复杂工作切成可交付的小块，通过角色、事件、工件和规则四类要素持续检视与调整。
- Scrum明确规定三类角色、四类事件、三类工件及它们之间的规则；具体工程实践、工具选型、组织架构和绩效考核由团队自行决定。
- Scrum适合需求不确定性高、需要频繁交付与反馈的工作；任务高度确定、变更极少时，框架的检视价值会减弱。
- Scrum与看板、XP、瀑布处于不同层次：看板关注持续流动，XP聚焦工程实践，瀑布按阶段串行，Scrum提供迭代增量的框架结构。
- 常见误解包括把Scrum等同于没有计划、把Scrum Master当作项目经理、把站会当作进度汇报，理解角色与事件的真实目的即可纠正。
Scrum的直接定义
Scrum是一套轻量级的敏捷开发框架。它把复杂、易变的工作放进固定长度的时间盒中推进，每个时间盒称为一个Sprint，通常为两到四周。团队在每个Sprint开始时选定要完成的目标，在Sprint结束时交付出可用的产品增量，再根据反馈决定下一步做什么。这套框架要应对的核心问题是：需求本身复杂且变化频繁，而传统长周期交付让反馈来得太晚，团队难以在过程中校正方向。
Scrum由四类要素构成，它们共同定义了一套工作规则：
- 角色：产品负责人（Product Owner）、Scrum Master、开发团队（Developers）。三类角色各有明确责任，共同组成一个Scrum Team。
- 事件：Sprint本身，以及Sprint规划、每日站会、Sprint评审、Sprint回顾。事件为检视与调整提供固定节奏。
- 工件：Product Backlog、Sprint Backlog、增量。工件承载团队的工作内容与交付结果。
- 规则：把角色、事件、工件绑定在一起的约束，例如谁负责维护哪个工件、哪个事件产出什么结果。
Sprint是框架的基本时间单位。它是一段固定长度、有明确目标的工作周期，其他事件都发生在Sprint之内或边界上。Sprint的长度一旦确定就保持稳定，目的是让团队形成可预期的节奏，也让检视与调整有稳定的参照点。需要说明的是，Scrum定义的是上述要素之间的关系，它不规定团队使用什么工具、采用什么技术方法，也不规定组织如何设置部门与考核。
Scrum包括什么、不包括什么
把Scrum的边界划清，能避免把相关实践都算进框架本身。Scrum明确规定的是角色、事件、工件以及它们之间的规则；工程实践、工具选型、组织架构和绩效考核属于团队自行决定的部分。下面这张表按“属于/不属于”两列做对照。
| 属于Scrum明确规定的内容 | 不属于Scrum规定的内容 |
|---|---|
| 三类角色及其责任划分 | 具体工程实践，如测试驱动开发、持续集成、代码评审方式 |
| 四类事件及其目的与时间盒 | 工具选型，如使用哪款项目管理或看板工具 |
| 三类工件及其承诺对象 | 组织架构、汇报关系与部门设置 |
| 角色、事件、工件之间的规则约束 | 绩效考核方式、薪酬与晋升制度 |
Scrum与敏捷的关系需要单独说明。敏捷是一组价值观与原则的集合，强调个体互动、可工作的软件、客户合作和响应变化；Scrum是落实这些理念的一种具体框架。也就是说，Scrum属于敏捷的实现方式之一，采用Scrum不等于覆盖了敏捷的全部内容，敏捷也不只有Scrum一种实现路径。
Scrum的适用条件与它的设计目标相关：工作内容存在较高不确定性、需求会随反馈变化、团队需要频繁交付并获得反馈。当任务高度确定、变更极少、交付节奏由外部固定约束时，团队仍可使用Scrum的事件节奏，但框架带来的检视价值会相应减弱。是否采用，应结合工作性质判断，而非作为统一要求。
Scrum如何运转：角色、事件与工件的配合
Scrum的运转可以理解为一个Sprint内的连续闭环：Product Backlog提供待办来源，Sprint规划确定本轮目标，每日站会维持同步，Sprint评审检视增量，Sprint回顾检视协作方式，结果再回流到下一轮。下面按角色、事件、工件分别说明，再串成一个周期。
三类角色各自负责什么
- 产品负责人：对Product Backlog的内容、排序和价值负责，决定做什么、先做什么，并确保团队理解需求。
- Scrum Master：对Scrum的正确实施负责，帮助团队理解并遵循框架规则，移除阻碍团队推进的障碍，促进事件有效进行。
- 开发团队：对每个Sprint交付可用增量负责，自行拆解任务、决定如何完成工作，并对工作质量负责。
四类事件的目的与顺序
- Sprint：容纳其他所有事件的时间盒，期间保持目标稳定，不随意插入范围外的需求。
- Sprint规划：在Sprint开始时进行，确定本轮Sprint目标，并从Product Backlog中选出要完成的事项，形成Sprint Backlog。
- 每日站会：每天固定时间进行，开发团队同步进展、对齐当天计划、暴露阻碍，控制在十五分钟左右。
- Sprint评审：在Sprint结束时进行，向相关方展示增量并收集反馈，据此调整Product Backlog。
- Sprint回顾：在评审之后进行，团队检视协作方式与流程，识别改进项并落实到下一轮。
三类工件与各自的承诺对象
| 工件 | 内容 | 承诺对象 |
|---|---|---|
| Product Backlog | 产品待办事项的有序列表，随反馈持续调整 | 产品目标（Product Goal） |
| Sprint Backlog | 本轮Sprint选定的待办事项及完成计划 | Sprint目标（Sprint Goal） |
| 增量 | Sprint结束时形成的可用成果，可叠加交付 | 完成定义（Definition of Done） |
一个Sprint的衔接流程
以两周Sprint为例：产品负责人维护并排序Product Backlog；Sprint规划会上，团队与产品负责人共同确认Sprint目标，选出待办事项并拆解为Sprint Backlog；Sprint期间，开发团队按计划推进，每日站会同步进展与阻碍，Scrum Master协助排除障碍；Sprint结束前，团队完成增量并对照完成定义检查；Sprint评审会上展示增量、收集反馈，产品负责人据此调整Product Backlog；随后Sprint回顾会检视协作过程，形成改进项带入下一轮。至此，一个闭环完成，下一轮Sprint规划随即开始。
在这个流程中，Backlog的排序、迭代进度的可视化和评审回顾的记录，是团队日常需要承载的管理动作。ONES 敏捷研发管理解决方案支持产品负责人按需求优先级将待办事项规划至对应迭代，并在迭代计划会议上与团队共同评审需求；迭代过程中团队可通过敏捷看板管理任务状态，在每日站会中对齐进度与风险；迭代完成后可结合燃尽图、工时日志等报表复盘进度、质量与成本偏差。这些能力对应的是框架落地时的协作承载，框架本身的规则仍由团队按Scrum定义执行。
Scrum与看板、XP、瀑布的区别
Scrum常与几个相邻概念一起出现，混用会导致讨论失焦。下面按同一口径对照它们的核心差异：时间组织方式、对变更的处理、覆盖层次。
| 对比对象 | 核心差异 | 与Scrum的关系 |
|---|---|---|
| 看板（Kanban） | 以持续流动组织工作，通过限制在制品数量控制节奏，不设固定迭代边界 | 关注工作流动的可视化与节流，可与Scrum结合使用，但本身不是Scrum的组成部分 |
| 极限编程（XP） | 聚焦工程实践，如测试驱动开发、结对编程、持续集成、小步发布 | 处于工程实践层，Scrum处于框架层，两者可配合，XP的实践不属于Scrum规定内容 |
| 瀑布模型 | 按需求、设计、开发、测试等阶段串行推进，阶段间设评审关口 | 以阶段串行为特征，与Scrum的迭代增量方式不同，变更处理方式也不同 |
常见的混淆有三类。其一，把每日站会等同于Scrum——站会只是四类事件之一，缺少角色、工件和其余事件的配合，站会本身不构成框架。其二，把看板等同于Scrum——看板是一种可视化与流动管理方法，Scrum的迭代节奏和事件结构是另一套组织方式。其三，把用户故事等同于Scrum——用户故事是描述需求的一种写法，Scrum并未规定必须使用这种写法，Product Backlog中的事项可以用多种方式表达。区分这些概念的关键，是看它属于框架层、实践层还是表达层。
一个具体例子与常见误解
下面用一个两周Sprint的例子把定义落到具体场景中。假设一个团队负责某产品的订单模块，Sprint长度为两周。
- 第0天，Sprint规划：产品负责人从Product Backlog中按优先级选出若干订单相关事项，与团队确认本轮Sprint目标为“支持订单批量导出”。团队将事项拆解为具体任务，形成Sprint Backlog。
- 第1至9天，Sprint执行：开发团队按任务推进，每日站会同步昨天完成、今天计划与遇到的阻碍；Scrum Master跟进阻碍事项，协调外部依赖。期间Sprint目标保持稳定，新增想法记录到Product Backlog，留待下轮评估。
- 第10天，Sprint评审：团队向相关方演示批量导出功能，收集使用反馈，产品负责人记录需要调整的事项并更新Product Backlog排序。
- 第10天，Sprint回顾：团队讨论本轮协作中的问题，例如联调等待时间偏长，形成一条改进项，落实到下一轮的具体做法。
这个例子中，角色、事件、工件各司其职：产品负责人决定做什么，开发团队决定怎么做，Scrum Master保障框架运行；规划、站会、评审、回顾按顺序衔接；三类工件分别承载产品目标、Sprint目标和完成标准。
三个高频误解及纠正
- 误解一：Scrum等于没有计划。纠正：Scrum有明确的计划动作，Sprint规划确定本轮目标与待办事项，Sprint Backlog就是执行计划；区别在于计划按短周期滚动调整，而非一次定死长期方案。
- 误解二：Scrum Master就是项目经理。纠正：Scrum Master的职责是保障框架正确实施、促进事件有效进行、帮助团队移除障碍，不承担分配任务和管控进度的职能；任务如何完成由开发团队自行决定。
- 误解三：站会就是汇报进度。纠正：站会是开发团队内部的同步机制，用于对齐当天计划、暴露阻碍并协调协作，面向的是团队自我管理，而非向上级汇报。
理解这三点后，可以回到框架本身做判断：Scrum提供的是一套角色、事件、工件与规则的组织方式，团队在其上选择工程实践与工具。ONES Project 为研发团队提供需求管理、任务管理、缺陷管理、迭代管理等场景支持，并提供敏捷、瀑布、通用任务协同等多种项目模板，可作为团队承载Scrum日常协作的选择之一；具体采用哪种工具与模板，仍应结合团队的工作性质与协作习惯决定。
常见问题
团队规模很小，也适合用Scrum吗？
Scrum并未规定团队人数下限，框架关注的是角色责任、事件节奏和工件是否清晰。小团队同样可以运行Sprint规划、每日站会、评审和回顾，只是部分角色可能由同一人兼顾，例如产品负责人同时承担较多需求沟通工作。需要留意的是，角色可以合并，责任不能模糊：谁对Product Backlog排序负责、谁对增量质量负责，仍应明确。团队规模属于组织条件，是否采用Scrum应结合工作不确定性和交付节奏判断。
Sprint长度定不下来，可以先试几周再调整吗？
可以。Sprint长度一旦确定应保持稳定，目的是形成可预期的检视节奏；但在团队刚开始实践时，先选一个长度试运行几轮，再根据反馈调整，属于常见的起步方式。调整时建议整轮调整，避免每个Sprint随意变化，否则评审和回顾的参照点会失去可比性。长度选择与工作性质相关：变更频繁、反馈需求强的场景倾向较短周期，需要较多验证或外部依赖的场景可能选择稍长周期。
Scrum Master和项目经理可以由同一人担任吗？
在小型团队中，同一人可能同时承担多种职责，但需要区分两类工作的性质。Scrum Master对框架的正确实施负责，包括促进事件有效进行、帮助团队理解规则、协助移除障碍；项目经理通常涉及范围、进度、资源和跨团队协调的管控。若由同一人担任，建议在具体场景中明确当前行使的是哪种职责，避免用管控进度的方式介入开发团队的任务安排，否则会削弱团队自我管理。组织如何设置岗位属于团队自行决定的部分，Scrum本身不作规定。
已经在用看板，还需要再引入Scrum吗？
两者可以并存，也可以只选其一，取决于团队需要解决什么问题。看板以持续流动组织工作，通过限制在制品数量控制节奏，适合工作项持续到达、优先级频繁变化的场景；Scrum以固定Sprint提供稳定的检视与调整节点，适合需要周期性交付和跨角色对齐的场景。实践中常见做法是在Sprint内使用看板可视化任务流动，用看板的列和限制辅助团队管理在制品数量。引入前建议先明确当前痛点：如果问题在于交付节奏和反馈周期，Scrum的事件结构可能更有帮助；如果问题在于工作堆积和流动不畅，看板的节流机制更直接。
Sprint进行中来了紧急需求，应该怎么处理？
Scrum的原则是Sprint期间保持Sprint目标稳定，不随意插入范围外的需求。紧急需求出现时，通常先记录到Product Backlog，由产品负责人评估优先级，留待下一轮Sprint规划时决定；如果需求确实紧急到影响当前目标，应由产品负责人与团队共同判断是否调整Sprint范围，并明确调整对Sprint目标的影响。关键在于把变更决策放在明确的规则下进行，而不是由个人直接插入任务。具体如何处理紧急插入，属于团队在框架规则下自行约定的协作方式。
