Scrum 是一种以经验主义为基础的敏捷开发框架：把复杂工作拆成固定长度、可交付增量的迭代（Sprint），由产品负责人、Scrum Master 和开发团队三类角色分工，通过 Sprint 规划、每日站会、评审和回顾四类事件持续检视与调整，并用产品待办列表、Sprint 待办列表和增量三类工件承载工作内容。下文依次说明它的定义与特征、范围边界、角色分工、事件与工件的运转机制，并与 Kanban、瀑布做概念区分；ONES 可作为承载 Scrum 工作项与文档协作的平台。
要点总览（TL;DR）
- Scrum 是一个以经验主义为基础的敏捷开发框架，用固定长度的 Sprint 持续交付可交付增量，规则来自《Scrum Guide》。
- 框架由三类角色（产品负责人、Scrum Master、开发团队）、四类事件（Sprint 规划、每日站会、评审、回顾）和三类工件（产品待办列表、Sprint 待办列表、增量）构成。
- Scrum 规定协作框架，技术实践、工具选型、考核制度以及需求池日常维护、迭代执行细节不在其规定范围内。
- 与 Kanban 相比，Scrum 有固定节奏和明确角色；与瀑布相比，它以滚动规划替代前期完整计划，二者可与 Kanban 组合使用。
- 判断是否算 Scrum，看角色分工、事件时间盒与工件承诺关系是否真正落地，而非是否使用了看板工具。
Scrum 是什么：一句话定义与核心特征
Scrum 是一个轻量级的敏捷开发框架，用于在需求不确定、环境变化快的条件下持续交付有价值的产品增量。它由一套角色、事件、工件及其规则关系构成，规定的是“谁在什么节奏下、围绕哪些工作内容、按什么规则协作”，而不是一套覆盖全部研发活动的完整方法论。Scrum 的规则来自《Scrum Guide》，该指南由 Ken Schwaber 与 Jeff Sutherland 维护，历经多次修订，对角色、事件、工件给出了通行定义。
理解 Scrum，可以抓住四个识别特征：
- 经验主义底色。Scrum 认为复杂工作的结果无法靠事前完整预测获得，只能通过透明、检视、适应三个支柱不断逼近目标。透明指工作状态对参与者可见且口径一致；检视指按固定节奏检查工作与增量；适应指发现偏差后及时调整计划或做法。
- 固定长度迭代。工作被切分为长度固定的 Sprint，通常为 1 至 4 周，每个 Sprint 结束时产出可交付的增量。固定节奏让检视有稳定的时间锚点。
- 可交付增量。每个 Sprint 的产出应当是满足“完成定义”、具备可用性的增量，而非阶段性文档或半成品。
- 自组织与跨职能。开发团队自行决定如何完成工作，团队内部具备交付增量所需的多种技能，减少跨团队等待。
需要区分的是，Scrum 提供的是框架规则，具体怎么排期、怎么开评审会、怎么维护需求池，属于迭代管理与需求池管理的操作范畴，框架本身只给出边界和节奏。
Scrum 包括什么、不包括什么
Scrum 的范围可以用“三类要素”概括：角色、事件、工件。三者相互约束，构成框架的最小完整集合。超出这个集合的内容，Scrum 不规定，也不应被当作 Scrum 的组成部分来要求团队。
| 类别 | 属于 Scrum 的内容 | 不属于 Scrum 规定范围的内容 |
|---|---|---|
| 角色 | 产品负责人、Scrum Master、开发团队 | 职能经理、项目考核人、外部干系人的组织设置 |
| 事件 | Sprint、Sprint 规划、每日站会、Sprint 评审、Sprint 回顾 | 需求评审会、技术方案评审、上线审批等团队自定会议 |
| 工件 | 产品待办列表、Sprint 待办列表、增量 | 需求池的日常分级方法、缺陷库、知识库的组织方式 |
| 规则 | 事件的时间盒、工件的承诺关系、完成定义 | 技术实践（如结对编程、测试驱动开发）、工具选型、绩效考核制度 |
这张表的意义在于划清责任：Scrum 规定协作框架，工程实践由团队按技术判断选择，工具由组织按管理需要选型，考核制度属于组织治理范畴。把工程实践或考核规则写进“Scrum 要求”，容易让团队把框架当成负担，也会模糊真正的改进点。
与相邻主题的边界同样需要说明。Sprint 规划怎么开、站会怎么主持、评审如何组织反馈、回顾如何产出改进行动，属于迭代管理的操作内容；产品待办列表如何分层、如何排序、如何做需求澄清，属于需求池管理的日常内容。Scrum 给出这些活动的存在与目的，具体做法由团队在框架内决定。
三个角色：产品负责人、Scrum Master、开发团队
Scrum 只定义三个角色，每个角色对应一类明确的决策权与交付责任。角色清晰是框架能运转的前提，角色混淆往往表现为“谁都能改优先级”或“没人对障碍负责”。
| 角色 | 核心职责 | 关键决策权限 | 常见混淆点 |
|---|---|---|---|
| 产品负责人 | 对产品待办列表的内容、可用性与排序负责，对产品价值最大化负责 | 决定做什么、先做什么；确认增量是否满足预期 | 被当成“需求传声筒”，只收集需求而不做取舍 |
| Scrum Master | 对 Scrum 框架被正确理解和落地负责，清除团队障碍，推动协作改进 | 推动事件按规则进行；对框架偏离提出纠正 | 被当成项目经理或团队领导，承担派活与考核 |
| 开发团队 | 对每个 Sprint 交付满足完成定义的增量负责 | 自行决定如何完成工作、如何在团队内部分工 | 被外部逐人派活，失去自组织空间 |
三个角色的交接点集中在工件上：产品负责人把排序后的产品待办列表带入 Sprint 规划，开发团队据此形成 Sprint 待办列表并承诺 Sprint 目标，Scrum Master 保障规划过程按规则推进；Sprint 结束时，开发团队展示增量，产品负责人检视增量并决定后续排序。交接靠工件状态和事件完成，而非靠口头转达。
小团队中允许一人兼任多个角色，但要注意权限冲突。产品负责人与开发团队成员兼任，容易出现“自己排优先级、自己承诺交付”的闭环，削弱检视效果；Scrum Master 与产品负责人兼任，则可能让框架纠偏让位于交付压力。兼任时建议明确每个事件中行使哪个角色的权限，并在回顾中检查是否出现自我检视失效的迹象。
四类事件与三类工件如何串成一个 Sprint
Scrum 的运转可以理解为一条时间轴：产品待办列表是输入，Sprint 是容器，四类事件分布在容器内外，增量是输出。下面按时间顺序描述这条链路。
Sprint 规划发生在 Sprint 开始时，团队确定本次 Sprint 的目标，并从产品待办列表中选择条目形成 Sprint 待办列表，同时商定如何完成。规划的输出是 Sprint 目标与 Sprint 待办列表，二者构成团队在本次迭代内的承诺范围。
每日站会在每个工作日固定时间举行，时间盒通常为 15 分钟。开发团队同步进展、对齐当天计划、暴露障碍。站会检视的是 Sprint 目标的达成趋势，必要时调整 Sprint 待办列表，但范围变更需与产品负责人协商。
Sprint 评审在 Sprint 结束时举行，团队向干系人展示增量，收集反馈，产品负责人据此调整产品待办列表。评审检视的是“做出来的东西是否有价值”，而非进度汇报。
Sprint 回顾紧随评审之后，团队检视协作方式、工具与流程，识别改进项并形成可执行的改进行动，通常带入下一个 Sprint。
三类工件在这条链路上各有承诺对象：产品待办列表对应产品目标，是持续演进的排序清单；Sprint 待办列表对应 Sprint 目标，是本次迭代的工作集合；增量对应完成定义，是可用且满足质量标准的产出。完成定义是贯穿工件的质量约定，它明确“做到什么程度算完成”，让增量具备可检视的基础，也避免团队在评审时对“是否完成”产生分歧。
在工具层面，这条链路需要工作项状态与文档协作来承载。ONES 支持经典的 Scrum 研发场景，产品负责人可按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审需求；迭代过程中团队通过敏捷看板管理任务状态，在每日站会中借助看板对齐进度与风险，并用燃尽图评估研发效率；迭代完成后可召开回顾会，结合燃尽图、工时日志、持续集成报告等报表复盘进度、质量与成本偏差，再用 ONES Wiki 沉淀经验形成团队知识库。这些能力承载的是 Scrum 中的管理动作，框架规则本身仍由团队按 Scrum 定义执行。
Scrum 与 Kanban、瀑布的区别
这三个概念常被并列讨论，但它们回答的问题不同：Scrum 提供带节奏的框架规则，Kanban 提供流程可视化与在制品控制方法，瀑布提供按阶段推进的计划方式。判断选型时，先看工作是否适合固定节奏交付、变更频率如何、角色是否需要明确划分。
| 维度 | Scrum | Kanban | 瀑布 |
|---|---|---|---|
| 节奏 | 固定长度 Sprint，事件时间盒明确 | 连续流动，无固定迭代边界 | 按阶段推进，阶段间设评审节点 |
| 角色 | 定义产品负责人、Scrum Master、开发团队 | 不规定角色，按现有岗位协作 | 通常按职能分工，设阶段负责人 |
| 变更方式 | Sprint 内范围相对稳定，变更经产品负责人协商进入后续 Sprint | 随时按优先级拉动新工作，通过限制在制品控制节奏 | 变更需走阶段评审与基线调整，成本较高 |
| 计划方式 | 以 Sprint 为单位滚动规划，目标清晰 | 以流动效率为核心，按队列补充工作 | 前期完整计划，后期按计划执行 |
Scrum 与 Kanban 可以组合使用：团队保留 Sprint 节奏与角色分工，同时在 Sprint 内部用看板可视化任务流转、限制在制品数量，减少并行过多导致的等待。这种组合在运维支持、需求持续涌入的团队中较常见。Scrum 与瀑布的组合则多见于硬件或强合规项目，用 Sprint 管理研发探索阶段，用阶段评审管理交付节点，但需要明确哪些环节适用哪套规则，避免两套节奏互相牵制。
一个具体例子与常见误解
以下为演示情景，用于说明机制如何运转，不代表真实项目数据。一个五人开发团队采用两周 Sprint：产品负责人提前整理产品待办列表并按价值排序；Sprint 规划会上，团队选定若干条目形成 Sprint 待办列表，确定“完成支付流程改造”的 Sprint 目标，并拆出任务；每日站会 15 分钟，成员对着看板说明昨天完成什么、今天做什么、遇到什么障碍，Scrum Master 记录障碍并跟进；第二周结束时召开评审，向业务方演示可用的支付流程，收集反馈并记入产品待办列表；随后回顾会讨论“联调等待时间过长”，形成“提前一天冻结接口”的改进行动，带入下个 Sprint。整个过程中，增量是否完成以完成定义为准，评审与回顾的结论都回写到工件上。
围绕这个例子，有三条常见误解值得澄清：
- 误解一：每日站会是向领导汇报。站会的参与者是开发团队，目的是同步进展、对齐当天计划、暴露障碍，检视对象是 Sprint 目标的达成趋势。管理者可以旁听了解情况，但站会不承担汇报与考核职能，否则成员会倾向隐藏问题。
- 误解二：Scrum 等于没有计划。Scrum 有明确的计划层级：产品待办列表体现产品层面的排序，Sprint 规划产出本次迭代的目标与工作集合，每日站会调整当天安排。它的特点是以固定节奏滚动规划、按检视结果调整，而非取消计划。
- 误解三：用了看板工具就是 Scrum。看板只是可视化任务状态的载体，Scrum 的识别特征在于角色分工、四类事件的时间盒与三类工件的承诺关系。工具可以承载这些规则，也可以只被当作任务列表使用；是否算 Scrum，取决于规则是否真正落地。
对初次接触 Scrum 的团队，建议先按框架把角色、事件、工件跑通一个 Sprint，再根据回顾结论调整做法。ONES Project 为敏捷、瀑布等项目制研发提供工具支持，适配需求管理、任务管理、缺陷管理、迭代管理等场景，并提供敏捷、瀑布、通用任务协同等多种项目模板；ONES 敏捷研发管理解决方案打通“需求—研发—测试”流程，把需求提出方、产品经理、研发、测试等角色连接起来。工具能降低协作成本，框架能否生效仍取决于团队是否按规则检视与适应。
常见问题
团队规模很小，还需要完整设置三个 Scrum 角色吗？
Scrum 定义三个角色，但小团队可以一人兼任多个角色。关键在于兼任后是否仍保留有效的检视机制：产品负责人与开发团队成员兼任时，优先级排序与交付承诺容易形成闭环，建议在评审和回顾中引入外部干系人参与检视；Scrum Master 与产品负责人兼任时，需要为框架纠偏留出独立空间，避免交付压力挤占改进讨论。兼任不等于取消角色，每个事件中行使哪个角色的权限仍应明确。
Sprint 进行中需求发生重大变化，应该怎么处理？
Scrum 的原则是 Sprint 内保持 Sprint 目标相对稳定，范围调整需与产品负责人协商。常见做法是把新需求记入产品待办列表并重新排序，评估是否影响当前 Sprint 目标：若不影响，可在团队容量允许时纳入；若直接冲击 Sprint 目标，由产品负责人决定是否终止当前 Sprint 并重新规划。终止 Sprint 属于例外处理，频繁终止说明规划或需求管理环节需要复盘。
完成定义（Definition of Done）由谁制定，需要多细？
完成定义是团队与产品负责人共同约定的质量基线，开发团队对其可执行性负责。它应覆盖增量可交付所需的关键条件，例如代码评审、测试通过、文档更新等，粒度以团队能在评审时据此判断“是否完成”为准。组织层面可以给出统一底线，团队再按技术特点补充。完成定义过粗会让评审流于形式，过细则增加维护成本，建议在回顾中按实际分歧点逐步调整。
已经在用看板管理任务，还需要引入 Scrum 吗？
取决于工作需要的是固定节奏还是连续流动。如果需求持续涌入、优先级频繁变化、团队更适合按队列拉动工作，Kanban 的连续流动与在制品限制可能更贴合；如果需要稳定的检视节点、明确的角色分工和按迭代交付的增量，Scrum 的 Sprint 节奏与事件时间盒更有帮助。两者也可以组合：保留 Sprint 与角色分工，在 Sprint 内部用看板可视化任务流转并限制并行数量。
Scrum 落地时，工具能解决哪些问题、哪些仍需团队自己处理？
工具可以承载工作项状态、迭代规划、看板视图、燃尽图与文档沉淀，降低信息同步成本。例如 ONES 支持产品负责人按优先级把需求规划至迭代、团队通过敏捷看板管理任务状态、用燃尽图评估研发效率，并可用 ONES Wiki 沉淀回顾经验。工具无法替代的是规则执行：站会是否聚焦障碍、评审是否真正检视增量、回顾结论是否形成行动并跟进，这些取决于团队自身的协作习惯与管理支持。
