Scrum 框架是什么
Scrum 是最常被引用的敏捷框架，由三个角色、三个工件与五个事件构成，合称 3 角色、3 工件、5 事件。它的核心机制是用固定长度的时间盒把不确定性切成小段：每个 Sprint 结束时必须产出可用的增量，并以增量是否满足完成定义来判断真实进度。Scrum 是框架而非细则，落地时需结合组织治理与发布流程裁剪。
基本信息
| 角色 | 产品负责人（PO）、Scrum Master（SM）、开发者 |
|---|---|
| 工件 | 产品待办列表、Sprint 待办列表、增量 |
| 事件 | Sprint、Sprint 规划、每日 Scrum、Sprint 评审、Sprint 回顾 |
| 团队规模 | 通常 10 人以内，常见 5 到 9 人 |
典型使用场景
- 需求频繁变化的产品研发：用短 Sprint 换取快速反馈与方向修正
- 交付节奏不稳定的团队：用固定时间盒暴露阻塞与估算问题
- 跨职能交付：把开发、测试与运维能力放进同一个团队，减少交接等待
- 与业务方定期对齐：Sprint 评审让业务方直接看到可运行增量
- 持续改进机制建设：Sprint 回顾提供固定的流程复盘时点
三大构成
| 类别 | 内容 | 作用 |
|---|---|---|
| 角色 | 产品负责人、Scrum Master、开发者 | 分别对价值排序、流程有效性、交付负责 |
| 工件 | 产品待办列表、Sprint 待办列表、增量 | 构成从需求到成果的单一信息链 |
| 事件 | Sprint、规划、每日站会、评审、回顾 | 用固定节奏产生透明与调整机会 |
关键规则
| 规则 | 要求 | 常见偏离 |
|---|---|---|
| Sprint 长度 | 固定时长，通常 1 到 4 周 | 每周变长变短，节奏无法度量 |
| 时间盒 | 事件按时结束，超时即中止 | 站会拖成一小时的问题解决会 |
| Sprint 目标 | 每个 Sprint 有单一目标 | 只列任务清单，无共同目标 |
| 完成定义 | 团队共同约定的完成标准 | 把编码完成当成工作完成 |
| 待办排序 | PO 对产品待办列表负最终责任 | 多方同时插需求，排序失效 |
| 期间变更 | Sprint 内不插入新需求 | 临时需求随手塞入，目标作废 |
团队规模与角色
团队规模与角色
Scrum 团队通常 10 人以内（常见 5 到 9 人）
# 规模过大时应拆分为多个 Scrum 团队并约定协调机制
# 角色可兼任工作，但责任不可混淆：
# PO 负责价值排序与需求澄清，SM 负责流程有效性与障碍清除Scrum 只规定框架，不规定估算单位、工具与发布流程。落地时的关键是把完成定义、待办列表排序规则与质量门槛写清楚。
SM 兼任 PO 或同时承担大量交付任务，流程监督会失效：发现流程问题的人恰好是受益于绕过流程的人。
在受监管或多团队协作场景，Scrum 需要与发布管理、合规评审衔接；完全脱开治理的 Scrum 会在上线阶段付出代价。
实施检查点
- Sprint 目标是否唯一且可判断达成，而非任务清单的罗列
- 完成定义是否包含测试、文档与部署，避免半成品计入进度
- 产品待办列表是否由产品负责人排序，是否存在多方直接插单
- 回顾会的改进项是否指派责任人与验证时点，避免每轮提同样问题
- 评审会是否邀请真实业务方并收集反馈，而非仅做内部演示
三个工件的透明度决定框架能否生效：产品待办列表不排序、增量不发布，Scrum 就只剩下一套会议节奏，无法产生可验证的进展。