方法论与流程
流程是「一群不完美的人，在有限信息下协作交付」的约定。没有放之四海皆准的流程，只有匹配情境的流程：需求越不确定、反馈越要快，流程就该越「轻」。本篇回答三个问题：有哪些主流方法论、各自长什么样、怎么为团队选型。
先看情境，再谈流程
选流程前先回答四个问题：
| 维度 | 观察点 | 影响 |
|---|---|---|
| 需求确定性 | 需求清晰稳定，还是边做边变 | 越不确定 → 越倾向迭代/敏捷 |
| 反馈周期 | 多久能拿到用户/市场的真实反馈 | 反馈越慢 → 前期分析投入越多 |
| 交付紧迫性 | 固定期限强约束，还是持续运营 | 一次性大版本 vs 持续小步发布 |
| 组织支撑 | 是否有业务方专职做需求决策、高层是否容忍试错 | 无专职 PO → Scrum 会走形 |
需求侧的「为什么做、做什么」见产品方向，本篇聚焦「怎么把要做的事按节奏交付」的执行流程。
主流方法论一览
| 方法论 | 核心思想 | 适用情境 | 典型标志 |
|---|---|---|---|
| 瀑布（Waterfall） | 阶段严格串行，前序输出即后序输入 | 需求稳定、变更代价极高（如合规/硬件） | 需求 → 设计 → 编码 → 测试 → 上线 |
| 迭代式（Iterative） | 一次交付一部分，逐轮逼近完整 | 需求大致清晰但结果难一次到位 | 每轮有可演示产物 |
| Scrum | 固定节奏（Sprint）+ 三类角色 + 明确工件 | 需求变化快、需持续价值验证 | Sprint 评审、每日站会、回顾 |
| 看板（Kanban） | 限制在制品、拉式流动、持续发布 | 需求持续流入、无法按节奏切块的运维类工作 | 看板列 + WIP 上限 + 累积流图 |
| 混合（ScrumBan 等） | Scrum 节奏 + 看板流动约束 | 需要节奏稳定又难以预估的团队 | 保留事件，弱化承诺 |
常见误区：以为「敏捷 = 快」。敏捷不承诺更快，承诺的是更早暴露问题、更低沉没成本；把 6 个月的需求分析压到 1 周再按瀑布执行，只会得到一个更隐蔽的坑。
Scrum：最广泛应用的框架
角色
| 角色 | 职责 | 常见失败 |
|---|---|---|
| 产品负责人（PO） | 维护产品待办列表，决定优先级与验收 | 缺席决策，把排序丢给团队 |
| Scrum Master（SM） | 维护流程、扫除障碍、护航团队自组织 | 变成项目经理发号施令 |
| 开发团队 | 自组织拆解与实现，共同对交付负责 | 隐含层级、单人瓶颈无人担责 |
事件
| 事件 | 时长建议 | 目标 |
|---|---|---|
| Sprint 计划会 | 每 Sprint 启动 | 定目标 + 选择范围 + 拆任务 |
| 每日站会 | ≤15 分钟 | 同步进展、暴露阻塞，不解决细节 |
| Sprint 评审 | 每 Sprint 末 | 向干系人演示成果、收集反馈 |
| Sprint 回顾 | 评审后 | 检视流程、产出改进项（见度量与复盘） |
工件
- 产品待办列表（Product Backlog）：按价值排序的需求池，颗粒度上粗下细，只列「还没做」的；
- Sprint 待办列表（Sprint Backlog）：本次迭代承诺范围 + 达成它的计划；
- 增量（Increment）：每个 Sprint 末可验收、可发布的产物总和——「做完」不等于「能用」。
「做一半永远不叫增量」是 Scrum 最容易破的底线：验收标准见需求与范围。
看板：给流程上「水龙头」
看板不增加角色与事件，只做三件事：
- 可视化工作流：把工作拆成明确的列（如 待办 → 开发中 → 测试 → 已发布）；
- 限制在制品（WIP）：每列设上限，人不是越多越好，同时进行的工作越少，完成得越快；
- 管理流动：观察阻塞点（累积流图上的堆积区），优先疏通瓶颈，而非一味加人。
| 对比项 | Scrum | 看板 |
|---|---|---|
| 节奏 | 固定 Sprint | 持续流动 |
| 承诺 | 每 Sprint 承诺范围 | 不承诺，按吞吐自然流动 |
| 角色 | 三类角色 | 沿用现有角色 |
| 适合 | 可切块的创新型项目 | 支持/运维、需求不可预测 |
混合与规模化
- ScrumBan：保留 Sprint 评审/回顾的节奏感，引入 WIP 上限缓解过度承诺——适合「必须赶版本又常被插队」的团队；
- 规模化（SAFe / LeSS / 自组织多团队）：单团队 Scrum 已是很多组织的天花板。超过 2~3 个敏捷团队前，先解决依赖透明化（看板 + 定期联合计划会）再考虑框架，避免「为了规模化而规模化」。
个人与小团队实践建议：先用最简单的看板跑通「可视化 → WIP → 回顾」三件套，再决定要不要上 Scrum。
常见坑速查
| 坑 | 表现 | 应对 |
|---|---|---|
| 敏捷口号化 | 站会照开、评审走过场，一切如旧 | 用回顾驱动流程真实变化 |
| PO 缺席 | 团队自己排优先级，做出来的没人验收 | 明确业务方必须出席评审/决策 |
| 伪固定期限 | 敏捷迭代又叠加瀑布式硬截止 | 固定范围用瀑布，固定节奏用敏捷，别混着骗自己 |
| 仪式比内容重 | 用「仪式完整度」考核敏捷成熟度 | 衡量产出价值而非仪式数量 |
| SM 兼职包办 | SM 同时承担大量业务开发 | SM 至少空出 20%~50% 精力维护流程 |
检查清单
- [ ] 按四个情境维度记录了团队画像，选型有书面依据
- [ ] 角色与职责明确：谁对价值排序负责、谁对流程负责、谁对交付负责
- [ ] 每个增量都有可演示、可验收的定义，而非「写完了代码」
- [ ] 站会 / 评审 / 回顾有固定节奏且有人对产出负责
- [ ] 若用看板：列定义、WIP 上限、瓶颈可视化都已落地
- [ ] 首次回顾后产出了至少 1 个可执行的流程改进项