为什么瀑布模型会「失速」
项目启动会上，需求文档写得满满当当，评审通过、排期冻结，一切看起来井井有条。三个月后交付，用户却指着屏幕说：这不是我想要的。这不是个例，而是瀑布模型最典型的失效场景——它假设需求在开工前就能被完整、准确地描述清楚，并且在整个开发周期里保持稳定。一旦这个假设不成立，越往后走，返工的代价越大。
瀑布模型把开发切成需求、设计、编码、测试、交付这几个阶段，每个阶段必须「流」到下一个阶段才开工。它的优点是阶段清晰、文档齐全、便于按合同验收；缺点同样明显：反馈回路太长。用户在项目末期才第一次看到可运行的软件，此时任何需求偏差都已经渗透进了设计、代码和测试用例。
瀑布模型最大的问题不是「慢」，而是把「验证」放在了整条链路的尽头。软件开发的不确定性越高，这种「先做完再验收」的模式就越危险。
于是行业开始寻找一种能缩短反馈回路的方法：把大块交付拆成小块，每一小块都完整地走一遍需求、设计、开发、测试，并在每个循环结束时拿到反馈。这，就是敏捷的出发点。
- 反馈回路迭代式交付把验证前移，让偏差在低代价阶段被纠正。
- 敏捷宣言四条价值观与十二条原则，是方法的源头而非仪式清单。
- Scrum用固定长度的迭代、明确的角色与工件，把「敏捷」变成可执行的流程。
- 用户故事以「作为…我想要…以便…」的结构承载需求，并配上验收标准。
- 度量速率、燃尽图与在制品限制，用来暴露问题而不是考核个人。
敏捷宣言与四条价值观
2001 年，十七位开发者在雪鸟城写下了《敏捷宣言》。它没有给出任何具体流程，只提出了四条价值观，并强调「左项虽重要，但更看重右项」：
- 个体与互动 高于流程与工具——工具是为协作服务的，别让流程压过沟通。
- 可工作的软件 高于详尽的文档——文档仍要写，但可运行的交付物才是进度的唯一证据。
- 客户协作 高于合同谈判——与需求方持续对齐，比一次性签死需求更有效。
- 响应变化 高于遵循计划——计划是导航而非轨道。
四条价值观之下还有十二条原则，其中几条对工程实践影响最深：尽早、持续地交付有价值的软件；欢迎需求变更；以自组织团队为中心；以及技术卓越与良好设计——这条常被忽略，但它恰恰是敏捷能否持续的前提。没有良好的工程实践，迭代只会加速积累技术债务。
需要特别提醒的是：敏捷不等于「没有计划」，也不等于「取消文档」。它反对的是没有反馈的过度计划和为了文档而文档。一份只为应付评审、从没人回看的说明书，才是敏捷真正想淘汰的东西。
Scrum 的角色、事件与工件
Scrum 是目前落地最广的敏捷框架，它用一组清晰的角色、事件与工件，把抽象的价值观变成每天可执行的节奏。三者相互咬合：事件由角色主导，工件在事件中被检视和调整。
| 类别 | 组成 | 作用 |
|---|---|---|
| 角色 | 产品负责人 / Scrum Master / 开发团队 | 分别负责价值排序、流程守护与交付实现 |
| 事件 | 迭代计划会 / 每日站会 / 迭代评审 / 迭代回顾 | 在固定节奏里完成计划、同步、演示与改进 |
| 工件 | 产品待办列表 / 迭代待办列表 / 增量 | 承载需求、当前计划与可交付成果 |
迭代通常固定为两到四周，长度一旦确定就不轻易改变——固定节奏本身就是一种纪律。每个迭代结束时必须产出一个可交付的增量，否则迭代的反馈价值就被架空了。
一个常见误区是把 Scrum Master 当成「项目经理」。Scrum Master 不分配任务、不催进度，他的职责是移除障碍、守护流程，让团队能够自组织地完成工作。同样，产品负责人也不是「需求传声筒」，他要对价值排序负责：先做哪件事、为什么先做它。
用户故事与需求拆解
需求要进入迭代，先要变成团队能估算、能验收的小块。最常用的载体是用户故事，它用一句话把「谁、要什么、为什么」讲清楚，并配上可验证的验收标准：
# 用户故事的标准结构
作为 <角色>
我想要 <某个功能>
以便 <获得某种价值>
# 示例
作为 会员用户
我想要 用手机号一键登录
以便 不必记住复杂的密码
# 验收标准（Acceptance Criteria）用 Given-When-Then 描述
Given 用户已注册且手机号可用
When 用户在登录页填写手机号并获取验证码
Then 输入正确验证码后成功进入首页
And 验证码错误时提示「验证码不正确」并允许重试写用户故事时，最容易犯的错误是把技术方案写进需求里。用户故事应该描述问题与价值，而不是实现方式；真正的技术设计放到后面的架构阶段去做。
一个用户故事如果无法在一个迭代内完成，就要继续拆分。常用拆法有按数据流拆、按业务规则拆、按操作步骤拆，以及先做「最薄的一条竖切」——把从界面到数据库的首尾链路打通，再逐层加厚。
迭代计划与看板管理
迭代计划会要回答两个问题：这个迭代做什么，以及团队大概能做完多少。前者由产品负责人依据价值排序决定优先级，后者由团队依据历史速率共同承诺。承诺必须由团队自己给出，管理者代拍的数字通常只是美好愿望。
任务进入执行后，看板是最直观的可视化工具。一个基本的看板至少包含「待办 / 进行中 / 待验证 / 已完成」几列，并为「进行中」设置在制品（WIP）上限。WIP 上限的意义在于：限制并行，逼迫团队先完成再开始，避免大量任务同时半途而废。
# 一个看板状态的简化数据结构
board:
todo: ["登录页表单校验", "短信服务接入"]
in_progress: ["验证码接口联调"] # WIP 上限 = 2
review: ["登录接口单元测试"]
done: ["数据库用户表建模"]
wip_limit:
in_progress: 2
review: 2看板要「真实」。如果卡片被压着不动，不要急着把卡片挪到「已完成」来美化进度，而要在每日站会或回顾中把阻塞暴露出来——可视化工具的价值，恰恰在于让问题无法被藏住。
每日站会与可视化度量
每日站会控制在十五分钟内，围绕三个问题展开：昨天完成了什么、今天打算做什么、遇到了什么障碍。站会不是汇报会，团队对着看板说，而不是对着管理者说。
进度度量常用两类图：燃尽图看当前迭代剩余工作量随时间的变化趋势，速率图看每个迭代实际完成的故事点，用于预测而非考核。
# 用一段小脚本计算迭代速率与逐日剩余工作量（伪代码）
def velocity(completed_points):
# 去掉波动最大的极值后取平均，作为未来迭代的参考容量
points = sorted(completed_points)
trimmed = points[1:-1] if len(points) > 2 else points
return sum(trimmed) / len(trimmed)
def remaining_per_day(total, done_per_day):
left = total
for d in done_per_day:
left -= d
yield left # 逐日剩余工作量，用于绘制燃尽图
sprints = [18, 21, 15, 19, 22] # 过去五个迭代完成的故事点
print(round(velocity(sprints), 1)) # 20.0 左右，作为下个迭代的参考容量度量的红线是：只用于改进流程，绝不用于排名与奖惩。一旦速率被当作 KPI，团队就会通过「故事点注水」来对付指标，度量随即失去意义。指标一旦变成目标，它就不再是好指标。
落地常见误区与改进清单
敏捷落地失败，多半不是因为框架选错了，而是把框架做成了仪式。以下是高频误区与对应做法：
- 站会变成汇报会：改为团队围着看板对齐，管理者只旁听不点评。
- 迭代内随意插单：需求变更走产品负责人的待办列表重新排序，而不是由管理者直接塞给开发。
- 只做迭代、不做回顾：回顾会产出的改进项必须落到下个迭代的行动里，否则团队会失去信任。
- 没有「完成的定义」：事先约定「完成」包含代码评审、测试通过、文档更新，避免「大概做完了」。
- 技术实践缺位：没有单元测试与持续集成，迭代越快，技术债积累越猛。
最后记住一句话：敏捷是一套让团队更快获得反馈并据此调整的工作方式。当你在纠结某个仪式要不要保留时，只需要问自己——它是否真的缩短了反馈回路？
流程服务于交付，仪式服务于沟通。任何不产生反馈的会议，都值得被重新审视甚至砍掉。