5.2 敏捷 vs. 瀑布方法
项目怎么跑，对最终结果的影响，至少不亚于你"做什么"。
最广为人知的两种方法，是瀑布和敏捷。
这两者并没有谁绝对"更好"——选哪一个，要看项目的性质、规模，以及你需要承受多大的变化。这一节我们来看它们各自的特点、什么时候用哪一种，以及怎么把它们结合起来。
什么是瀑布模型？
瀑布按阶段推进——需求 → 设计 → 开发 → 测试 → 发布——是一种顺序、单向的流程。每一步都要走完并被批准，下一步才能开始。
主要特征
- 流程清晰，便于管理和监控
- 线性流动：跳过或回头都不容易
- 非常适合范围明确、对变化容忍度低的项目
最适合
- 需求固定、改动少的项目（比如内部 IT 基础设施）
- 对文档或合规有严格要求的行业（比如金融、医疗）
- 多供应商、职责划分清晰的环境
什么是敏捷方法？
敏捷把项目拆成小周期（迭代），在快速循环里构建、测试、调整。
Scrum 和 Kanban 是最流行的框架。
主要特征
- 对变化的适应度很高
- 频繁地交付可工作的部件
- 团队和干系人之间紧密沟通
最适合
- 需求会演进的项目（比如新产品研发）
- 需要快速整合反馈
- 需要频繁与干系人对齐
瀑布 vs. 敏捷：对比表
| 维度 | 瀑布 | 敏捷 |
|---|---|---|
| 工作流程 | 顺序、线性 | 迭代、增量 |
| 需求处理 | 前期固定，难以变更 | 灵活，可在中途演进 |
| 交付时机 | 项目末尾一次性发布 | 可分阶段、提前发布 |
| 沟通风格 | 文档为主，正式评审 | 每日站会、实时讨论 |
| 进度管理 | 偏重计划，里程碑驱动 | 灵活、按 sprint 规划 |
混合方法：用瀑布做计划，用敏捷做执行
实际上，多数现代团队都是把两者混着用——混合模式——而不是选一边。
常见的模式包括：
- 用瀑布的方式做里程碑规划，工作本身用敏捷的方式跑
- 文档走瀑布，测试走敏捷
- 阶段层面用瀑布的结构，团队层面用敏捷的执行
这种灵活性在大型或多团队项目里尤其重要——单一方法论很少能适配整个组织的每个角落。
AB 对方法的灵活支持
AB 让你自然地把两种方法结合起来：
- 用类似 WBS 的结构来规划任务，类瀑布
- 在敏捷看板视图里把任务在状态之间移动
- 在甘特视图里跟踪宏观时间线，同时在内部自由迭代
这种灵活性让你可以根据团队成熟度和项目特点设计自己的方法。
结语：让项目本身决定方法
敏捷和瀑布并不是对手——它们是需要被聪明使用的工具。
问题不是"哪个更好？"，而是"哪个最适合这个项目？"
这种思维方式，才是战略性项目领导力和组织敏捷性的核心。
在 AB 中是这样的
同一个 AB Project Management 项目结构两种方法都能跑——产品不会替你选方法论，它会适配你已经选好的生命周期（也就是这份指南 1.0–2.4 章节里讲的那些）。敏捷团队在任务上加 sprint 标签或筛选，把看板当作主要的工作面；瀑布团队用 Milestone 任务类型作为阶段关卡，并依赖日历的时间线视图。混合团队两边一起做——用里程碑撑结构，用 sprint 跑节奏。
→ 接下来：5.3 任务管理工具 — 把计划高效落地的实用工具。