从预测式到敏捷：为什么复杂工作要『多次小步纠偏』
第 1 节讲过预测式（predictive）/瀑布生命周期：一开始就定死全部范围与计划——它适合需求与技术都确定的工作。但软件/产品类工作复杂、需求常变，前期把一切算准并不现实。
Scrum 的解法是经验式过程控制：用短迭代（Sprint）每次交付一小块可用增量，检视反馈，再调整下一步——把『一次押注全部』拆成『多次小步纠偏』，从而降低风险与返工成本。
这正是 2001 年 17 位软件先驱在《敏捷软件开发宣言》里达成的共识。宣言确立四条价值观：
- 个体与互动 高于 流程与工具
- 可工作的软件 高于 详尽的文档
- 客户协作 高于 合同谈判
- 响应变化 高于 遵循计划
宣言背后还有 12 条原则，例如：可工作的软件是进度的首要衡量标准、欢迎需求变化、频繁交付、业务与开发每日协作、保持可持续的步调。
Scrum 骨架（上）：经验主义三支柱、三种担责角色、五个时间盒事件
《Scrum 指南（2020）》的官方定义：『Scrum 是一个轻量级框架，帮助人、团队和组织通过对复杂问题的自适应方案来创造价值。』它建立在经验主义（empiricism）与精益思想（lean thinking）之上——经验主义即根据已观察到的事实做决策。三大支柱：
- 透明（Transparency）：过程与工作必须可见；
- 检视（Inspection）：频繁检视工件与目标进展；
- 调整（Adaptation）：发现偏差就尽快调整过程或产物。
Scrum 不规定具体怎么做，只给框架，把工程实践留给团队。
一个 Scrum 团队通常 10 人或更少，没有子团队与层级，统一对一个产品目标负责。三种担责（accountabilities）：
- 产品负责人（Product Owner）——对『最大化产品价值』负责，管理并排序产品待办列表；
- Scrum Master——对『按指南确立 Scrum』负责，是服务式的真正领导者（true leader）：帮团队移除障碍、维护规则，不是发号施令的工头；
- 开发者（Developers）——对『每个 Sprint 交付可用增量』负责，自己制定 Sprint 计划、按完成定义保证质量。
五个事件用固定节奏创造规律、减少额外会议（下列时间盒以一个月 Sprint 为上限，更短的 Sprint 相应缩短）：
1. Sprint——所有工作的容器，固定时长一个月或更短，上一个结束立刻开下一个；
2. Sprint 计划会（Sprint Planning）——最长 8 小时，定本 Sprint 做什么、怎么做；
3. 每日站会（Daily Scrum）——15 分钟、给开发者用，对齐进展、调整当天计划；
4. Sprint 评审（Sprint Review）——最长 4 小时，向干系人展示增量、收集反馈；
5. Sprint 回顾（Sprint Retrospective）——最长 3 小时，团队复盘如何改进协作。
Scrum 骨架（下）：三件工件与承诺、五个价值观、三个流行误解
每件工件都配一个『承诺（commitment）』来聚焦并衡量进展（2020 版引入）：
- 产品待办列表（Product Backlog）——要做的事的有序清单，承诺是产品目标（Product Goal）：团队长期要达成的大目标；
- Sprint 待办列表（Sprint Backlog）——本 Sprint 选出的工作+计划，承诺是 Sprint 目标（Sprint Goal）：本迭代的唯一焦点；
- 增量（Increment）——本 Sprint 产出的、可用的成果，承诺是完成定义（Definition of Done）：『做完』的统一质量标准，不达 DoD 不算完成、不可发布。
事件、角色、工件只是骨架。《Scrum 指南》明确：成功用好 Scrum，取决于人们在五个价值观上变得更娴熟——承诺（Commitment）、专注（Focus）、开放（Openness）、尊重（Respect）、勇气（Courage）：团队承诺达成目标、专注于 Sprint 工作、对工作与挑战开放、彼此尊重、有勇气面对硬问题。价值观缺位时，Scrum 容易退化成『走流程』的形式主义。
① 『Scrum = 把瀑布切成几个小瀑布』——错。每个 Sprint 都要产出可用增量并据反馈调整，不是把分析/开发/测试按阶段塞进迭代里串行走完；
② 『Scrum Master 就是项目经理/组长』——错。SM 是服务式领导，不分派任务、不替团队定技术方案；
③ 『每日站会是给经理汇报进度』——错。Daily Scrum 是 15 分钟、给开发者自己对齐 Sprint 目标与当天计划用的，不是状态汇报会。
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
评审会上有同事说：『敏捷宣言写了「可工作的软件 高于 详尽的文档」，所以我们项目组从今天起不用再写任何文档了。』对宣言的正确理解是哪个？
答案：他读错了——宣言原文强调『虽然右项也有价值，但我们更重视左项』：这是优先级排序，文档等右项仍有价值，只是两边冲突时左项优先
『可工作的软件 高于 详尽的文档』是 2001 年敏捷宣言四条价值观之一，但宣言原文紧接着强调：『虽然右项也有价值，但我们更重视左项』——这是优先级排序，不是否定右边：敏捷团队照样写文档、守合同、做计划，只是冲突时把左项放在更高优先级。12 条原则里也没有任何一条禁止写文档，反而强调可工作的软件是进度的首要衡量标准。（出处：Manifesto for Agile Software Development，2001，agilemanifesto.org）
第 1 节讲过：预测式（瀑布）生命周期一开始就定死全部范围与计划。为什么软件/产品这类复杂工作，Scrum 主张改用经验式的短迭代？
答案：因为这类工作需求常变，前期把一切算准不现实；短迭代每次交付一小块可用增量、检视反馈再调整，把『一次押注全部』拆成『多次小步纠偏』，降低风险与返工成本
预测式适合需求与技术都确定的工作；而软件/产品类工作复杂、需求常变，前期不可能把一切算准。Scrum 用 Sprint 做经验式过程控制：每个迭代交付一小块可用增量、检视反馈、再调整下一步——这正呼应敏捷宣言『响应变化 高于 遵循计划』。注意它不是不做计划（每个 Sprint 都有计划会），预测式在合适的场景下也依然成立。（出处：The Scrum Guide 2020；Manifesto for Agile Software Development 2001）
Scrum 建立在经验主义之上——『根据已观察到的事实做决策』。支撑经验式过程控制的三大支柱是哪一组？
答案：透明（Transparency）、检视（Inspection）、调整（Adaptation）
《Scrum 指南（2020）》：Scrum 是建立在经验主义与精益思想之上的轻量级框架，三大支柱是透明（过程与工作必须可见）、检视（频繁检视工件与目标进展）、调整（发现偏差就尽快调整过程或产物）。『启动、规划、收尾』是项目生命周期的阶段划分（见第 1 节），『承诺、专注、勇气』是 Scrum 五个价值观中的三个，『范围、进度、成本』是三重约束——都不是三支柱。（出处：The Scrum Guide 2020）
Sprint 计划会上，新上任的 Scrum Master 把 Sprint Backlog 的任务逐条分派到每个开发者头上，还替团队拍板了技术方案。按《Scrum 指南》，问题出在哪？
答案：SM 越界了——SM 对『按指南确立 Scrum』负责，是服务式领导：帮团队移除障碍、维护规则；Sprint 的工作计划由开发者自己制定，SM 不分派任务、不替团队做技术决定
Scrum Master 对『按指南确立 Scrum』负责，是服务式的真正领导者（true leader），不是发号施令的工头：不分派任务、不替团队做技术决定。对『每个 Sprint 交付可用增量』负责的是开发者——他们自己制定 Sprint 计划、按完成定义保证质量；产品负责人管价值与优先级，同样不命令开发者怎么实现。（出处：The Scrum Guide 2020，Scrum Team 三种担责角色）
判断：Scrum Master 本质上就是换了个头衔的传统项目经理——团队的任务分派和技术决策最终都由他说了算。
答案：错误
错误。Scrum Master ≠ 传统项目经理：他对『按指南确立 Scrum』负责，是服务式的真正领导者，职责是帮团队移除障碍、维护规则——不分派任务、不替团队做技术决定。『SM 就是项目经理/组长』正是关于 Scrum 的常见误解之一；Sprint 里的活由开发者自己计划和安排。（出处：The Scrum Guide 2020）
一个团队采用一个月的 Sprint。按《Scrum 指南》给出的时间盒上限，下面哪组安排是符合规则的？
答案：Sprint 计划会最长 8 小时；每日站会 15 分钟；Sprint 评审最长 4 小时；Sprint 回顾最长 3 小时
以一个月 Sprint 为上限：Sprint 计划会最长 8 小时、每日站会（Daily Scrum）15 分钟、Sprint 评审最长 4 小时、Sprint 回顾最长 3 小时；Sprint 本身是所有工作的容器，固定时长『一个月或更短』，上一个结束立刻开下一个。更短的 Sprint 相应缩短这些事件。固定时间盒的意义正是创造规律、减少额外会议。（出处：The Scrum Guide 2020，Scrum Events）
2020 版《Scrum 指南》给三件工件各配了一个『承诺（commitment）』。下面哪组配对是正确的？
答案：产品待办列表→产品目标；Sprint 待办列表→Sprint 目标；增量→完成定义（Definition of Done）
正确配对：产品待办列表（要做的事的有序清单）的承诺是产品目标——团队长期要达成的大目标；Sprint 待办列表（本 Sprint 选出的工作+计划）的承诺是 Sprint 目标——本迭代的唯一焦点；增量（本 Sprint 产出的可用成果）的承诺是完成定义（DoD）——『做完』的统一质量标准，不达 DoD 不算完成、不可发布。承诺机制是 2020 版引入的，用来聚焦并衡量进展。（出处：The Scrum Guide 2020；Scrum Guide Revisions）
判断：《Scrum 指南》明确，成功用好 Scrum 取决于人们在五个价值观上变得更娴熟——承诺、专注、开放、尊重、勇气；这些价值观缺位时，Scrum 容易退化成『走流程』的形式主义。
答案：正确
正确。《Scrum 指南》原文明确：成功使用 Scrum，取决于人们在承诺（Commitment）、专注（Focus）、开放（Openness）、尊重（Respect）、勇气（Courage）五个价值观上变得更娴熟。事件、角色、工件只是骨架，这五个价值观才是让框架真正运转的软性内核——团队承诺达成目标、专注于 Sprint 工作、对工作与挑战开放、彼此尊重、有勇气面对硬问题；缺位时 Scrum 就容易变成只走仪式、不产实效的形式主义。（出处：The Scrum Guide 2020，Scrum Values）
判断：Scrum 的正确打开方式是『把瀑布切成几个小瀑布』——每个 Sprint 内部按分析→开发→测试的阶段串行走完，可用的成果攒到最后一个 Sprint 一起交付。
答案：错误
错误。『Scrum = 小瀑布』是常见误解：Scrum 要求每个 Sprint 都产出可用增量并根据反馈调整，而不是把分析/开发/测试按阶段塞进迭代里串行走完、成果攒到最后。如果可用成果要等到最后一个 Sprint 才出现，经验式过程控制（透明—检视—调整）就失去了意义：中途没有真实可检视的东西，也就无从『小步纠偏』。（出处：The Scrum Guide 2020）
判断：每日站会（Daily Scrum）的主要目的，是让开发者逐个向经理和干系人汇报昨天的工作进度。
答案：错误
错误。『站会=汇报会』是常见误解：Daily Scrum 是 15 分钟、给开发者自己用的事件——对齐朝 Sprint 目标的进展、调整当天的工作计划，不是向经理或干系人做状态汇报。向干系人展示增量、收集反馈另有专门场合：Sprint 评审（最长 4 小时）。（出处：The Scrum Guide 2020，Daily Scrum / Sprint Review）