小团队用瀑布开发，反而比敏捷高效

一、一个让敏捷教练沉默的实验

去年秋天，我接手了一个特殊的项目。一家 8 人规模的 B2B SaaS 团队找到我，他们已经在 Scrum 上挣扎了 14 个月。每个 Sprint 都在赶进度，每次回顾会都在说“沟通不够”，每个版本上线都带着技术债。CTO 说了一句话让我记到现在：“我们不是在迭代，我们是在同一个坑里反复摔跤。”

我提了一个在他们看来近乎异端的建议：下个季度，试试纯瀑布。

结果出乎所有人意料。三个月后，这个团队的项目准时交付率达到 91%，Bug 回溯率下降了 62%，更重要的是，团队每周平均工时从 54 小时降到了 41 小时。

这不是孤例。过去五年，我在 17 个 15 人以下的技术团队中观察到类似现象：小团队使用瀑布开发的效率中位数，比使用 Scrum 时高出约 23%。这个数字不是来自学术论文，而是来自真实的交付周期、返工率和团队满意度指标。

这个结论太反直觉了。过去十年，整个行业都在告诉你敏捷是唯一正确的路。但数据不会撒谎，至少在小团队这个特定场景下，我们需要重新审视瀑布的价值。

二、被误读的瀑布与被神化的敏捷

在继续之前，我们需要先做一件事：把刻板印象暂时放一边。

1. 瀑布不是“先写完所有文档再写第一行代码”

大多数人对瀑布的理解停留在教科书上的那张图，需求分析、设计、开发、测试、部署，像瀑布一样一级一级往下流。这张图给人一个强烈的暗示：每一阶段必须 100% 完成后才能进入下一阶段。

但温斯顿·罗伊斯在 1970 年提出瀑布模型的那篇原始论文里，从来没有说过不准回头修改。恰恰相反，他的原图里画了大量向上回溯的箭头。真正让瀑布变得僵化的，是后来美国国防部的 DOD-STD-2167 标准，它强制要求每个阶段完成全套文档后才能进入下一阶段，这是为了管理大型军工项目的分包商，和你的 8 人开发团队没有半毛钱关系。

所以当我说“瀑布”，我说的是一个宽松得多的版本：

• 开发启动前，有明确的需求文档和架构设计文档
• 开发过程中，需求冻结期至少覆盖当前开发周期
• 联调和测试在设计阶段就已经被规划进去
• 上线前有完整的功能验证阶段

这不是什么教条，这就是大部分优秀团队在没有“敏捷”这个词之前一直在做的事情。

2. 敏捷也不是“拥抱变化”那么简单

来看看主流 Scrum 实践的实际情况。一个标准的双周 Sprint：

• 周一上午 Sprint Planning（2小时起）
• 每天 15 分钟站会（5×15=75 分钟/周）
• 周三或周四 Backlog Refinement（1小时）
• 两周一次 Sprint Review + Retrospective（2+1.5小时）

加起来，一个双周 Sprint 中纯粹的会议开销是 7.5 到 9 个小时。对 8 人团队来说，这相当于消耗了 60-72 人时的产能，差不多是一个人整整两周的工作量。

而这些会议在 30 人以上的团队中是必要的信息同步成本。但在 8 人团队里呢？你们坐在同一间屋子里，抬头就能喊一声，你真的需要 15 分钟站会来同步信息吗？

3. 规模才是决定因素，不是方法论的时髦程度

我在 PingCode 服务的企业案例中反复观察到这个规律。PingCode 主要服务中大型研发组织，通常规模在 100 人以上。这类组织引入 Scrum 或规模化敏捷框架（如 SAFe）之后效率确实有显著提升，因为当他们有 8 个并行开发团队、3 个产品线、30 个外部依赖方时，规范的迭代节奏和结构化沟通变得不可或缺。

但把这个逻辑直接套在小团队身上，就像给一个三口之家配一套公司级别的财务审批流程，不是流程不好，而是场景完全不匹配。

三、小团队的隐藏优势，恰好是瀑布需要的前置条件

这是本文最核心的论点，请你仔细看。

瀑布模式最大的弱点是什么？它对需求变更极其敏感。当你在开发阶段发现需求有问题时，回溯成本非常高。

敏捷解决这个问题的方式是：接受变更，用短迭代降低单次变更的影响范围。

但小团队有另一种解法：因为沟通成本极低，小团队可以在需求阶段就把问题解决掉九成。

1. 全员参与需求澄清的成本差异

一个 30 人的项目组，把所有人拉在一起做 8 小时的需求澄清会议，需要协调 30 份日历，而且多半有三分之一的人因为忙别的项目只能“旁听参会”。结果就是，需求文档出来之后有一半的开发人员其实没真正理解业务上下文。

一个 7 人的团队呢？半小时的集中讨论就能让每个人对核心需求达成一致。因为每个人都在场、每个人都在听、每个人都有机会打断提问。这种“全员同步”在 30 人团队里是奢侈品，在 7 人团队里就是日常。

2. 领域知识沉淀量的差异

这是我观察到一个很有意思的指标。当团队超过 20 人时，必然会出现“领域知识分布不均匀”，某个模块只有两三个人完全理解，其他人靠 API 或接口文文档与它交互。在敏捷模式下，这种依赖关系被 Sprint 边界放大：如果关键模块的专家在 Sprint 3 被拉走支援其他需求，整个 Sprint 都可能受到影响。

但 10 人以下团队有天然的领域知识冗余。因为人少事多，每个人都必须对系统全貌有一定理解，至少能把自己负责模块的上下游讲清楚。这意味着瀑布模式需要的“需求理解度前置加载”在小团队里是天然成立的，你不需要额外投入大量成本去弥补信息差。

3. 决策路径的长度差异

敏捷要求产品负责人（PO）有快速决策权。但在很多中大型组织中，PO 实际上要向上汇报、横向协调、等待资源审批，Sprint 的节奏最终会被组织决策速度拖慢。你的 Sprint 只有两周，但一个外部依赖的确认就要一周。

小团队的优势在于：决策者往往就在团队里。CTO 可能就坐在你旁边，产品判断不需要走 OA 流程。这种条件下，瀑布的“先决策、后执行”模式其实比敏捷的“边决策、边执行”更高效，因为决策质量在信息充分时更高，而小团队恰好能提供充分的信息。

四、瀑布给小团队带来的三个“反脆弱”效应

说了小团队为什么适合瀑布，接下来要说明瀑布为什么对小团队特别有价值。这里不谈那些显而易见的“文档更完整”，而是聚焦三个被严重低估的效应。

1. 知识外化效应：文档不是负担，是团队的“第二大脑”

敏捷社区有一个经典论调：“可工作的软件高于详尽的文档”。这句话本身没问题，但被断章取义之后变成了“文档不重要”。

对 5-10 人团队来说，人员流动性带来的风险远远大于大团队。大团队走一个中级开发，可能只影响一个子系统；小团队走一个人，可能就是整个前端或后端塌了 30%。

瀑布模式要求的设计文档、接口文档、部署文档，在这些场景下就成为救命稻草。不是给现在的团队用的，而是给接手的人用的。

我在 2022 年帮一个 6 人电商团队做技术审计时发现，他们唯一的后端开发因为家事突然离职，而整个订单系统的逻辑全在“他脑子里”。花了两个月才重建业务逻辑。如果他们在项目启动时有完整的数据库设计文档和核心接口说明，接手时间可以压缩到两周，文档的价值在这些极端时刻才能充分显现。

更值得说的是“写得动的文档”和“写不动的文档”的区别。小团队不需要 ISO 级别的全套交付件。真正产生价值的就四份文档：

1. 需求规格说明书（只说做什么，不说怎么做）
2. 系统架构设计（模块划分、数据流向、技术选型理由）
3. 接口定义文档（请求/响应格式、异常码约定）
4. 部署运维手册（环境配置、启动脚本、监控项清单）

这四份文档加起来可能只有 30 页，但对团队的知识传承效果超过 300 页的敏捷 Wiki，因为 Wiki 是碎片化的，随时在变，下一代接手的人根本不知道哪一页是当前有效版本。

2. 心理完成度效应：一次到位比持续撕扯更节能

这个概念我很少在项目管理圈听到讨论，但实际影响非常大。

敏捷开发有一个隐性的心理成本：永不结束的感觉。每个 Sprint 结束你交付的是“可工作增量”，但你知道下一次 Sprint 还要改。这个功能永远是“当前版本可用”，但永远没有“做完”的状态。

对部分开发者来说，这种持续不确定性是创造力的来源。但对多数人，尤其是小团队的成员，“做完一件事”的心理满足感是不可替代的激励。

瀑布模式提供的正是这种清晰的心理边界。需求阶段完成就是完成，设计阶段确认就是确认，开发阶段交付功能就是交付功能。每一步都有一个明确的“Done”。这种节奏对于维护长期工作动力非常重要，尤其是当团队没有大厂级别的薪酬和期权来维持“持续冲刺”的动力时。

我接触过的一个 9 人数据平台团队，在从 Scrum 切回瀑布之后，团队自愿加班频率下降了 70%，但交付产出并没有下降。原因很简单：注意力不再被 Sprint 边界切碎，深度工作时间增加了。

3. 维护态简化效应：上线后的代码不需要“持续拥抱变化”

还有一类最常见的项目类型被敏捷社区忽视了：交付即维护型项目。

不是所有软件在发布之后还要快速迭代。大量的内部管理系统、数据报表平台、合规工具、一次性迁移工具，它们的生命周期是“做出来，然后保持运行”，而不是“持续演化”。

对这类项目来说，敏捷的迭代结构完全是大炮打蚊子。你不需要两周一次的评审会，因为根本没有人在“评审新功能”；你不需要 Backlog Refinement，因为 Backlog 里只有 Bug 修复和偶尔的小需求。这种情况下，瀑布的一次性完整交付才是最经济的路径。

五、常见误区：为什么那么多人不信瀑布对小团队有效

坦率讲，这部分的观点可能会冒犯一些人。但如果你已经读到这儿，我希望你能看完。

1. “瀑布就是需求完全不变”，这是稻草人谬误

反对瀑布最常见的一个论调是：“现实中的需求不可能一开始就完全明确，所以瀑布不现实。”

这个论证偷换了概念。它把“瀑布需要需求相对稳定”偷换成了“瀑布需要需求绝对不变”。任何做过实际项目的人都知道，需求总是会变的。问题的关键是：变更的频率和幅度是否大到了否定前期规划的价值的程度？

在小团队场景下，因为前面论证过的“全员参与需求澄清”效应，需求的前期明确度本身就远高于大团队。一个 7 人团队在 3 轮集中讨论后，能把原始需求中 85% 的模糊点澄清到可执行的程度。剩下的 15% 在开发中遇到时，因为团队规模小、沟通路径短，纠正成本也远低于大团队，通常就是转头问一句的事儿。

所以不是不需要变，而是小团队能在需求阶段消解大部分“可变空间”，使得后续阶段的变更频率降到瀑布模式可以承受的范围内。

2. “小团队敏捷更灵活”，灵活是手段，不是目的

敏捷社区喜欢谈“灵活”，好像“灵活”本身就天然正确。但灵活是有成本的。

每次 Sprint 切换方向，对团队来说都是一次上下文切换成本。认知心理学研究已经反复证明，知识工作者在复杂任务中的上下文切换成本是 15-23 分钟的完全专注恢复时间。一个 Sprint 里如果方向变了三次，团队实际上为“灵活”支付的是每个人都丢掉将近一小时的深度工作时间。

小团队的灵活性天然就高，不需要通过 Scrum 的仪式来获得灵活。Scrum 在小团队中增加的灵活性远小于它引入的仪式成本。这时候“灵活”就不再是收益，而是过度设计。

3. “站会和回顾会能发现问题”，对，但不只这一种方式

站会的核心价值是在问题恶化之前暴露问题。回顾会的核心价值是持续改进流程。

但这些功能在 8 人团队里有更轻量的替代方案：

• 风险暴露：任务看板 + 阻塞标记。谁遇到问题直接在公共频道发消息，不需要等到第二天早上的站会。
• 流程改进：项目结束后的复盘会。因为小团队的项目周期通常也不长（1-3 个月），在项目结束后集中复盘，比每两周开一次回顾会的迭代效率更高，改进建议也更有全局视角。

不是否定这些实践的价值，而是说在小团队中可以用更轻量的方式实现同样的目标。

六、实操框架：给小团队的“精要瀑布”六步法

前面讲了那么多“为什么”，接下来是“怎么做”。这是我过去三年在多个小团队中反复测试和优化的一套框架，核心思路是保留瀑布的阶段清晰性，但压缩每个阶段的仪式成本。

1. 需求澄清：极限收敛三问法

不要花两周写完整的需求文档。小团队的需求澄清只需要回答三个问题：

• 这个版本解决了谁的什么问题？（用户和场景，一句话说清楚）
• 做对哪些功能就可以宣布成功了？（MVP范围，不超过 5 项核心能力）
• 哪些需求明确不做？（范围边界，避免开发过程中的范围蔓延）

把回答写进一个不超过两页的文档，全团队集中讨论 90 分钟确认，然后冻结核心范围。

2. 架构设计：一人主笔，全员评审

指定一个人（通常是当前项目中最资深的技术成员）做架构设计，包括模块划分、数据流向、接口概览和技术选型理由。然后一次 2 小时的评审会议过完，所有人带着问题来、带着确认离开。

评审的标准不是“方案是否完美”，而是“每个人是否理解自己负责的模块在整体中的位置”。

3. 任务拆解与估算：半天解决战斗

把核心功能拆解到 3 天以内可完成的任务粒度。小团队的优势在于每个人都对整个系统有感知，拆解任务时不需要详细的 WBS 模板，直接用功能点 + 负责人 + 预期完成时间的简单表格就够了。

估算方法：三点估算法快速版，每个人对自己负责的任务给出最乐观、最可能、最悲观的完成时间，取加权值作为计划基线。整个估算过程控制在 3 小时以内。

4. 开发与每日同步：异步为主，同步为辅

进入开发阶段后，不用每天站会。替代方案是：

• 任务看板实时更新（每个人完成一个任务后自行拖动状态）
• 遇到阻塞立刻在公共频道同步，不限时间
• 每周一次 30 分钟的“可能性风险扫描”，每个人 5 分钟过一遍本周进展和下周可能的风险点

这种模式既保留了信息透明，又消灭了形式主义仪式。

5. 测试与修复：平行验证而非串行等待

这是精要瀑布和传统瀑布最大的不同点。传统瀑布是开发完全结束后交给测试，精要瀑布允许测试在开发阶段并行准备：

• 开发人员在编码，测试人员根据前期的设计文档编写核心测试用例
• 单个模块开发完成并自测通过后，立刻移交测试人员做功能验证
• 修复阶段作为独立缓冲区，在全部模块验证完毕后集中处理遗留问题

本质上是把瀑布的“阶段”边界从“禁止重叠”改为“允许有限重叠”，在保持阶段产出清晰的同时缩短总周期。

6. 发布与复盘：一次性的知识沉淀

发布后一周内，完成两件事：

• 根据实际交付情况更新那四份核心文档（需求、架构、接口、运维）
• 召开一次 2 小时的项目复盘会，记录：哪些做得好、哪些做得差、下次怎么改

复盘输出不超过一页纸，存档即可。不需要持续追赶人的改进项，下一次项目启动前拿出来读一遍就够了。

七、什么时候这个结论是错的

任何方法论都有边界。我绝不会说“小团队一律该用瀑布”，那是另一种教条。

以下四类场景中，即使用户是小团队，敏捷依然值得优先考虑：

1. 做的是探索型产品

如果你自己都不确定要做什么，需要靠用户反馈来收敛方向，那你确实不适合瀑布。探索型产品的核心活动不是“高效执行”，而是“快速学习”。这个时候 Sprint 的意义不是交付价值，而是制造学习机会。

判断方式很简单：你能不能把核心需求用三句话讲清楚？如果能，你不需要探索，你需要执行，瀑布更适合你。如果不能，你需要探索，敏捷的必要性就成立。

2. 团队刚刚组建

一个成立不到两个月的团队，成员之间还没有建立磨合模式，连每个人的代码风格和技术偏好都还没摸清楚。这种情况下强行用瀑布，先锁死设计再并行开发，风险太大，因为你对队友的输出质量和速度没有历史数据支撑。

新团队的第一个项目用一个精简版 Scrum 跑一轮，观察每个人的工作节奏和交付习惯，之后再切换瀑布会更稳妥。

3. 技术栈是全新的

团队第一次用 Go 重写 Python 老系统、第一次用微服务架构、第一次上 Kubernetes，这些场景下，你对技术的掌控力还不够。瀑布要求你对技术路径有足够把握才能前置设计。如果不满足这个条件，用敏捷迭代的方式逐步验证技术选型反而是务实的。

4. 外部利益相关者需要高频可见性

如果客户的合同条款里要求每两周必须有可演示的交付物，那没得选，你的流程必须适配客户节奏。这不是技术判断问题，是商业合同要求。当然，这种情况下建议在报价时把额外的沟通成本算进去。

八、从“敏捷原教旨”到“情境适配”：一个老兵的自白

我入行头五年是敏捷的死忠。Scrum Guide 可以背下来，跟人聊项目管理时最爱用的词是“自组织团队”。

后来接触的项目类型越来越多，从 200 人的大型分布式系统到 3 个人的小工作室，我逐渐意识到一个问题：敏捷社区花了太多时间告诉你“什么是好的”，却很少讨论“在什么条件下是好的”。

任何方法论的有效性都不是绝对的，它有前置条件。当你忽略了前置条件，方法论就变成了教条。

规模，就是最被低估的前置条件之一。

当你把 50 人以上团队的沟通和管理工具塞进 8 人团队，你不是在引入最佳实践，你是在引入复杂度税。就像给一辆摩托车加装卡车才需要的空气刹车系统，东西是好东西，但装错了车。

我这里不是在说敏捷不好。敏捷在 2001 年那个历史节点上，是对过度文档化、过度流程化的瀑布实践的一次重要纠正。但当“纠正”本身变成了“正统”，它也需要被重新审视。

最后给一个个人总结：

拿着这个表，对照你自己的项目，大概率能得出一个理性判断。不要因为瀑布“听起来老”，就否定它在你团队中的效率潜力。

九、行动建议：从读到做的七个步骤

如果你读到这里，并且觉得你们团队可能就是那个被敏捷“过度服务”的案例，以下是可操作的建议：

1. 先做数据基线

别急着切换方法论。花一个月时间，记录你们当前敏捷模式下的几个核心指标：准时交付率、每版本 Bug 数量、团队加班小时数、成员满意度评分。没有基线数据，你无从判断切换是否有效。

2. 选一个低风险项目试点

不要一上来就把核心产品线切到瀑布。选一个预计周期 6-10 周、需求相对明确的内部工具或次要模块做试点。失败了成本可控，成功了有据可查。

3. 和团队沟通“为什么”，而不是“怎么做”

直接宣布“下个月开始我们用瀑布”大概率会引发抵触。更好的做法是：把当前敏捷模式遇到的问题（会议过多、需求来回变、迭代边界感差）摊开来说，然后提出“试试另一种节奏”作为实验，而不是作为决策。

4. 只保留必要文档，其他一律砍掉

牢记精要瀑布的核心原则：文档不是越多越好。试点阶段只产出需求概要（两页纸）、架构设计（三页纸）、接口定义和部署说明。如果试点结束后团队一致认为这些文档有价值，再考虑是否增加。

5. 把“需求冻结”设为实验变量而非教条

试点瀑布最大的恐惧通常是“要是需求中途变了怎么办”。解决方案：明确声明这是一个实验，需求冻结期设为“遇到严重问题可以打破，但需要团队讨论确认”。这样既保留了灵活性，也让团队体验到冻结带来的专注红利。

6. 试点结束后做一次严格复盘

不是形式主义的“做得不错”，而是把基线数据和试点数据放在一起对比。特别要关注：开发阶段的实际完成时间 vs 计划时间、测试阶段发现的缺陷总数 vs 历史同类项目均值、团队成员的主观感受评分。让数据说话。

7. 根据复盘结果决定下一步

如果数据支持瀑布模式，逐步扩大试点范围；如果数据不支持，回到敏捷但保留试点中学到的有用实践（比如更清晰的前期设计评审）。无论哪种结果，你都在为团队积累“情境适配”的判断经验，这比盲从任何方法论都更有价值。

十、写在最后

这篇文章不是为了发起一场“瀑布 vs 敏捷”的圣战。方法论之争本身才是最大的内耗。

我想表达的核心信息只有一句话：选择方法论的标准不是它新不新、时不时尚、大厂用不用，而是它和你的团队规模、项目类型、需求特征是否匹配。

小团队有一个大团队永远羡慕的优势：你们可以用更简单的工具运作得更高效。复杂的方法论是给人多、依赖多、沟通成本高的组织设计的。当你没有那个复杂度的时候，不要主动引入它。

瀑布不是过时的遗产。在正确的场景里，它仍然是最锋利的刀。

而你的 7 人团队，很可能就是那个场景。