Scrum在研发团队落地，核心是把一个迭代周期内的角色、事件和两级工作项固定成可重复的节奏：先明确产品负责人、Scrum Master和开发团队的分工，再建立产品待办列表与迭代待办列表，按固定长度运行计划、每日同步、评审和回顾。建议先在一个团队试点两三个迭代，再逐步扩大范围。ONES可承载工作项与迭代节奏，本文聚焦整体落地步骤，迭代执行细节与需求池维护另作专题。
要点总览（TL;DR）
- 落地Scrum先定五件事：试点范围、三类角色、迭代长度与事件时间、两级工作项、完成定义，全部具备再开第一个迭代计划会。
- 产品负责人对产品待办列表的内容与顺序负责，Scrum Master保障事件发生与障碍移除，开发团队自组织完成迭代目标，三者职责边界需书面写清。
- 一个迭代按计划会、每日同步、评审、回顾四个事件运行，每个事件都要留下可检查的产出物，没有产出说明职责未落实。
- 第二到第三个迭代常出现事件流于形式、角色兼任冲突、待办列表不梳理等偏差，先判断是否影响迭代目标，再决定纠正投入。
- 连续两三个迭代稳定满足角色到位、事件有产出、完成定义被执行、改进项闭环等标准后，再按团队逐个扩大范围。
落地Scrum先定哪几件事
启动阶段的目标不是把Scrum的全部规则一次配齐，而是让第一个迭代具备可运行的最小结构。以下五件事在第一次迭代计划会之前必须落定，否则迭代一开始就会陷入“边跑边定规则”的混乱。
第一，划定试点范围。选择一个团队、一条产品线作为起点。判断标准是：该团队有相对独立且持续的需求来源，成员能稳定投入，负责人愿意承担推动责任。范围过大是落地失败最常见的原因，多个团队同时启动会让问题归因变得困难。
第二，确定三类角色的人选。产品负责人对产品待办列表的内容与顺序负责，通常由产品经理或业务负责人担任；Scrum Master保障事件发生、流程运转和障碍移除，可以由团队内成员兼任，但要明确其在该职责上的时间投入；开发团队负责把迭代目标转化为可交付增量。人选确定后，需要书面写清各自的决策权限，尤其是“谁有权调整迭代范围”这一条。
第三，确定迭代长度与事件时间。研发团队常见选择是一到四周，初次落地建议取两周，既能形成节奏，又不至于反馈周期过长。四类事件按迭代长度排定固定时间：迭代计划会放在迭代首日，每日同步固定在每天同一时段并控制在十五分钟内，迭代评审与回顾放在迭代末日。时间一旦公布，就作为团队日历上的固定项，不因个别事项临时取消。
第四，建立两级工作项。产品待办列表承载所有候选需求，按价值与优先级排序，条目粒度以“一个迭代内能完成若干条”为宜；迭代待办列表是本次迭代承诺的条目集合，并向下拆解为开发团队认领的任务。两级列表的关系要明确：产品待办列表是唯一的需求入口，迭代待办列表只能从其中选取。
第五，写下完成定义。完成定义描述一个条目达到什么状态才算“做完”，例如代码已合并、通过评审、完成自测、文档更新。它是评审时判断增量是否可交付的依据，必须在第一个迭代前由团队共同确认。
启动检查可以按下面这份清单逐项打勾，全部具备再开第一个迭代计划会：
| 检查项 | 通过标准 |
|---|---|
| 试点范围 | 已明确一个团队与一条产品线，负责人已知晓 |
| 角色 | 产品负责人、Scrum Master、开发团队人选确定，决策权限书面化 |
| 迭代长度 | 已确定周期长度并同步全员 |
| 事件时间 | 计划会、每日同步、评审、回顾的时间已进入团队日历 |
| 两级工作项 | 产品待办列表已建立并排序，迭代待办列表的选取规则已说明 |
| 完成定义 | 团队共同确认并可见 |
角色分工与各阶段交付物
角色职责的清晰度直接决定事件是否产生有效决策。三类角色在每个事件中的输入、动作和输出如下，团队可以据此制作分工卡贴在看板旁。
产品负责人
产品负责人的核心交付物是一份持续更新、顺序明确的产品待办列表。具体动作包括：收集并澄清需求，为每个条目写清验收标准，按业务价值与依赖关系排序，在迭代计划会上解释条目意图并回答团队疑问，在评审会上对照验收标准判断增量是否被接受。产品负责人对“做什么、先做什么”负责，对“怎么做”不介入。
Scrum Master
Scrum Master的交付物是流程的稳定运转和障碍的清除记录。具体动作包括：提前确认四类事件按时召开并控制时长，在每日同步中记录障碍并跟进解决，在回顾会上引导团队形成可执行的改进项，观察团队是否遵守完成定义并及时提出。Scrum Master不代替团队做技术决策，也不承担产品排序职责。
开发团队
开发团队的交付物是符合完成定义的增量。具体动作包括：在计划会上评估条目工作量、拆解任务并共同承诺迭代目标，在迭代中认领任务并更新状态，在每日同步中说明进展与障碍，在评审会上演示可运行的结果，在回顾会上提出改进建议。任务如何拆分、由谁认领，由团队自行决定。
角色与事件对照
| 事件 | 主要输入 | 关键动作 | 输出与完成标志 | 主责角色 |
|---|---|---|---|---|
| 迭代计划会 | 已排序的产品待办列表、上一迭代结果 | 选取条目、澄清验收标准、拆解任务、确认迭代目标 | 迭代待办列表与迭代目标，团队对承诺达成一致 | 产品负责人与开发团队，Scrum Master保障 |
| 每日同步 | 迭代待办列表与任务状态 | 围绕迭代目标说明进展、计划与障碍 | 障碍清单与当日调整，会议控制在十五分钟内 | 开发团队，Scrum Master记录障碍 |
| 迭代评审 | 可运行的增量、验收标准 | 演示增量、收集相关方反馈、判断条目是否被接受 | 验收结论与反馈条目，回填至产品待办列表 | 开发团队演示，产品负责人判断 |
| 迭代回顾 | 迭代过程记录、评审结论 | 复盘做得好的与需改进的，形成改进项 | 若干条可执行的改进项，明确责任人与验证时点 | Scrum Master引导，全员参与 |
这张表的价值在于让每个事件都有明确的产出物。如果某次事件结束后没有留下任何可检查的结果，就说明该事件的职责没有落实。
一个迭代的完整运行示例
以下示例为演示情景，用于说明各环节的做法与产出，团队可结合自身情况调整。
某研发团队负责一条内部业务系统的迭代开发，迭代长度为两周，团队共六人。迭代开始前，产品待办列表中已排序约二十条需求，其中前五条被标记为本次候选。
迭代计划会（首日上午，两小时）。产品负责人逐条说明候选需求的背景与验收标准，开发团队评估后选取其中四条作为本次迭代范围，共同写下迭代目标：“完成订单查询改造并上线灰度”。团队将四条需求拆解为十余个任务，包括接口设计、前端改造、联调、测试用例编写，每个任务标注预估工时并由成员认领。会议结束时，迭代待办列表形成，所有任务均有负责人。
每日同步（每天上午十点，十五分钟）。成员围绕迭代目标依次说明昨日完成、今日计划与遇到的障碍。第二天有成员提出测试环境不可用，Scrum Master记录该障碍并当天协调解决。看板上任务状态从“待处理”流转到“进行中”“待验证”，状态变化由任务负责人自行更新，避免同步会上逐条核对。
迭代评审（末日倒数第二天，一小时）。开发团队在测试环境演示订单查询改造的实际效果，产品负责人对照验收标准逐条确认，其中三条被接受，一条因边界条件未覆盖被退回产品待办列表。参会的业务方提出两条新反馈，由产品负责人记录并排序。
迭代回顾（末日下午，一小时）。团队复盘本次迭代：联调等待时间偏长、测试用例编写滞后于开发。团队形成两条改进项——下个迭代在计划会上为联调预留前置任务，测试用例与开发任务同步启动——并指定责任人，在下一迭代回顾会上验证效果。
整个迭代中，工作项的状态流转路径为：产品待办列表中的条目被选入迭代待办列表，拆解为任务后经历待处理、进行中、待验证、已完成；未通过验收的条目退回产品待办列表重新排序。产出物包括迭代目标、迭代待办列表、障碍记录、验收结论与改进项清单，这些记录构成下一次迭代计划与回顾的输入。
落地过程中的常见偏差与处理
偏差通常在第二到第三个迭代开始显现，此时团队已熟悉形式，但决策质量未必同步提升。下表列出研发团队高频出现的偏差及处理动作。
| 偏差 | 典型表现 | 处理动作 | 责任人 |
|---|---|---|---|
| 事件流于形式 | 每日同步变成逐人汇报，评审会无人提出反馈，回顾会只列问题不定动作 | 为每个事件明确产出物要求，会后检查是否留下决策记录；评审会提前邀请有决策权的相关方 | Scrum Master |
| 角色兼任导致职责冲突 | 产品负责人同时承担开发任务，Scrum Master由团队负责人兼任并主导技术决策 | 明确兼任角色在各事件中的立场，涉及范围调整时由产品负责人单独决策；Scrum Master在回顾会上不替团队下结论 | 团队负责人 |
| 待办列表长期不梳理 | 产品待办列表数周未更新，条目描述只有一句话，排序依据不明 | 固定每周一次的梳理时间，补充验收标准，拆分过大条目，删除已失效条目 | 产品负责人 |
| 条目过大 | 单条需求跨越多个迭代，计划会上无法评估工作量 | 在梳理阶段按可独立交付的粒度拆分，拆分后逐条确认验收标准 | 产品负责人与开发团队 |
| 完成定义缺失 | 评审时对“是否做完”反复争论，增量无法直接交付 | 团队共同补充完成定义并公示，评审时逐条对照；完成定义随团队能力提升定期修订 | 开发团队 |
处理偏差时有一个共同前提：先确认偏差是否影响了迭代目标的达成，再决定投入多少精力纠正。个别事件偶尔超时属于正常波动，连续两三个迭代出现同一问题才需要作为改进项正式处理。
用工具承载Scrum节奏
当角色、事件和两级工作项确定后，团队需要一个稳定的载体来留存状态与产出，避免节奏依赖个人记忆。ONES可承接这一层的管理动作：产品待办列表对应需求池中的需求条目，规划迭代时将需求及相关任务分配至迭代并指定负责人；迭代过程中，团队成员拆解并完成任务，通过敏捷看板更新任务状态，每日同步时借助看板对齐进度与风险，燃尽图用于评估当前研发效率。这些能力对应的是“状态可见”和“进度可查”两个落地需求。
事件产出同样需要留存。迭代完成并发布后，团队可通过燃尽图、工时日志、持续集成报告等数据报表复盘进度、质量与成本偏差；回顾形成的经验可用ONES Wiki沉淀为团队知识库，使改进项在后续迭代中可追溯。对于需要区分角色的场景，ONES Project提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，团队可据此为产品负责人、Scrum Master和开发团队设置不同的操作与查看范围。
需要说明的是，工具承载的是流程运转的记录与协同，角色职责和事件决策仍需团队自己完成。选型时可以先确认三点：两级工作项能否在系统中建立清晰对应，迭代与事件产出能否按周期留存，权限划分能否匹配已确定的角色分工。
落地完成检查
判断Scrum是否真正跑通，不看流程文档是否齐全，而看连续两三个迭代中是否稳定产生可检查的证据。下表可作为验收清单，逐项核对通过标准与证据来源。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 角色到位 | 三类角色人选稳定，决策权限清晰，迭代范围调整由产品负责人决定 | 角色分工说明、迭代范围变更记录 |
| 事件按节奏发生 | 连续两三个迭代中四类事件均按时召开，未因个别事项取消 | 团队日历、会议记录 |
| 事件有产出 | 每次计划会有迭代目标，每次评审有验收结论，每次回顾有改进项 | 迭代待办列表、验收记录、改进项清单 |
| 两级工作项持续维护 | 产品待办列表每周有更新，条目具备验收标准，迭代待办列表只从其中选取 | 待办列表更新记录、条目字段完整度 |
| 完成定义被执行 | 评审时逐条对照完成定义，未达标条目退回而非默认通过 | 评审结论、退回条目记录 |
| 改进项闭环 | 上一迭代的改进项在后续迭代中被验证，未闭环的有明确原因 | 回顾记录、改进项跟踪状态 |
关于扩大范围，建议以“连续三个迭代以上稳定满足上述标准”为参考条件，同时确认试点团队能说清自己的迭代目标如何支撑产品方向。满足条件后，可按产品线或团队逐个扩展，每新增一个团队都重复一次启动清单，而不是直接复制试点团队的配置。团队规模、业务节奏和依赖关系不同，迭代长度与事件形式可以相应调整，检查表关注的是节奏是否稳定、产出是否可查，而非形式是否统一。
常见问题
团队规模很小，Scrum Master可以由开发成员兼任吗？
可以兼任，前提是把职责边界写清楚。兼任者需要在每日同步中记录障碍、在回顾会上引导讨论，这些动作会占用其开发时间，团队应事先约定投入比例。容易出问题的是兼任者同时主导技术决策：涉及迭代范围调整时，应由产品负责人单独决定；回顾会上，Scrum Master负责引导流程，结论由团队共同形成。
迭代进行中需求发生紧急变化，应该调整迭代范围吗？
先由产品负责人判断变化是否影响本次迭代目标的达成。若影响，由产品负责人决定是否替换迭代待办列表中的条目，并把被替换的条目退回产品待办列表重新排序；若不影响，则记录后进入下一轮梳理。关键是这类调整要有记录可查，避免迭代范围在无决策的情况下被逐步侵蚀。频繁出现紧急插入，说明产品待办列表的梳理和排序需要加强。
完成定义由谁制定，需要覆盖哪些内容？
完成定义由开发团队共同确认，产品负责人参与澄清验收标准。内容通常包括代码是否合并、是否通过评审、是否完成自测、文档是否更新等团队认可的条件。它需要在第一个迭代前确定并公示，评审时逐条对照，未达标条目退回而非默认通过。随着团队能力提升，完成定义可以定期修订，修订后同样需要全员知晓。
试点团队跑通后，扩大范围时最容易忽略什么？
最容易忽略的是把试点团队的配置直接复制给新团队。新团队应重新走一遍启动清单：确认自己的试点范围、角色人选、迭代长度与事件时间、两级工作项和完成定义。团队规模、业务节奏和依赖关系不同，迭代长度与事件形式可以相应调整。检查表关注的是节奏是否稳定、产出是否可查，而非形式是否统一。
用工具承载Scrum节奏时，选型先确认哪几点？
可以先确认三点：两级工作项能否在系统中建立清晰对应，迭代与事件产出能否按周期留存，权限划分能否匹配已确定的角色分工。以ONES为例，产品待办列表对应需求池中的需求条目，规划迭代时将需求及相关任务分配至迭代并指定负责人；迭代完成后可通过燃尽图、工时日志、持续集成报告等数据报表复盘，回顾经验可用ONES Wiki沉淀为团队知识库；ONES Project提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配。工具承载的是记录与协同，角色职责和事件决策仍需团队自己完成。
