选择瀑布、敏捷还是混合，关键是把“不确定性”拆到具体位置：需求与验收标准能否提前定清、技术路径是否验证过、变更是否频繁、外部节点是否刚性。本文用同一组维度对照三种方法，并给出按项目条件选择、拆分和落地执行的判断方式。
要点总览（TL;DR）
- 先定位不确定性来源：需求与验收标准是否清晰、技术路径是否验证、变更与反馈速度、外部节点是否刚性、不确定性集中在整体还是局部。
- 需求清楚、变更少、验收以阶段评审或合同节点为主的项目倾向瀑布，用阶段计划、WBS和里程碑保持计划与责任边界清晰。
- 需求需边做边澄清、能小批量交付并持续获得反馈的项目倾向敏捷，以迭代为单位排序需求、评审增量并调整下一轮计划。
- 整体范围与关键节点固定、部分模块需迭代探索的项目适合混合：确定部分按阶段推进，不确定部分按迭代推进，并在项目计划中关联两类工作。
- 方法选定后设置变更频次、里程碑偏差、迭代验收情况等观察信号，据此调整方法或拆分边界。
先判断不确定性落在哪里
方法选择的起点是识别不确定性来源。同一个项目可能同时存在“需求清楚但技术没验证”“技术成熟但验收标准模糊”等情况，判断时要分别看，不能笼统地给项目贴一个“不确定”标签。
建议从五个特征逐项判断，并为每个特征标注高、中、低，再对照方法倾向：
| 判断特征 | 高不确定性表现 | 低不确定性表现 | 方法倾向 |
|---|---|---|---|
| 需求清晰度与验收标准 | 需求需要边做边澄清，验收标准随反馈调整 | 范围、交付物和验收口径可在启动前确定 | 高→敏捷；低→瀑布 |
| 技术方案与关键路径 | 关键技术未验证，方案存在多条候选路径 | 技术路线成熟，关键路径可提前排定 | 高→敏捷或混合；低→瀑布 |
| 变更频率与反馈获取速度 | 干系人反馈频繁，变更来源多且来得快 | 变更少，反馈周期长或以合同节点为准 | 高→敏捷；低→瀑布 |
| 合同、合规与外部节点 | 外部约束少，交付节奏可内部调整 | 合同节点、合规审查、外部验收时间刚性 | 刚性→瀑布或混合 |
| 不确定性分布范围 | 整体范围本身模糊，方向需要探索 | 整体范围固定，仅个别模块需要探索 | 整体→敏捷；局部→混合 |
这张表的作用是定位不确定性，而不是直接给出结论。实际项目中，如果需求清晰度低、外部节点又刚性，说明项目同时具备敏捷与瀑布的约束条件，应优先考虑混合，而不是在两种方法之间二选一。
判断时还要区分“已知的未知”和“未知的未知”。前者例如某个接口性能尚未验证，可以通过一次技术验证迭代解决；后者例如用户对新产品形态没有明确预期，需要小批量交付来逐步澄清。前者适合在计划中安排验证任务，后者更适合用迭代节奏推进。
三种方法在同口径下的差异对照
瀑布、敏捷、混合的差别，本质上是“在什么时点确定范围、以什么节奏交付、如何处理变更”的差别。用同一组维度对照，可以避免把方法差异理解成工具或仪式的差异。
| 对照维度 | 瀑布 | 敏捷 | 混合 |
|---|---|---|---|
| 范围与计划确定时点 | 启动和规划阶段集中确定范围、进度与交付物 | 整体方向确定，具体范围按迭代逐步细化 | 整体范围与关键节点前期固定，局部模块范围在迭代中细化 |
| 交付节奏与验收方式 | 按阶段交付，阶段评审或合同节点验收 | 小批量、短周期交付，每个迭代可验收增量 | 确定部分按阶段验收，探索部分按迭代验收 |
| 变更处理方式 | 通过变更控制流程评估影响后调整计划 | 在迭代边界内接纳变化，按优先级重排待办 | 刚性部分走变更流程，探索部分在迭代内调整 |
| 角色与决策方式 | 项目经理主导计划与协调，阶段决策集中在评审点 | 产品负责人决定优先级，团队自主安排迭代内工作 | 整体计划由项目负责人把控，模块内由对应负责人决策 |
| 文档与可视化要求 | 阶段文档、计划基线、评审记录较完整 | 以轻量文档和可视化的待办、看板为主 | 整体层面保留阶段文档与里程碑，模块层面使用迭代看板 |
| 对不确定性的适应方式 | 通过前期分析和变更控制降低不确定性影响 | 通过短周期反馈快速修正方向 | 把不确定性隔离在局部模块，用迭代消化 |
从对照可以看出，瀑布把不确定性尽量前移到规划阶段处理，适合能够提前分析清楚的项目；敏捷把不确定性分散到每个迭代中处理，适合反馈能及时获得的项目；混合则是在整体计划框架内划出一块可迭代的区域，让两种处理方式并存。
需要说明的是，三种方法在文档和评审上的差异是程度差异，不是有无差异。瀑布项目同样需要可视化的进度视图，敏捷项目同样需要保留必要的决策记录，区别在于文档的详略和产生时点。
瀑布、敏捷、混合的适配场景与选择建议
把判断表和对照表结合，可以形成条件式选择建议。以下条件同时成立时，方法倾向比较明确：
明确指向瀑布的项目条件
- 目标、范围和交付节点较明确，且需要按计划推进，例如合同交付、合规改造、基础设施升级等场景。
- 验收标准可以提前写清，验收以阶段评审或合同节点为主。
- 技术路线成熟，关键路径上的任务依赖关系清楚，可以提前排出前后置顺序。
- 变更频率低，或者变更必须经过正式评估，不适合在过程中频繁调整。
这类项目按启动、规划、执行、监控和结项等阶段推进，用工作分解结构把交付物拆到可执行的任务，用里程碑标记关键决策点，能让计划、验收和责任边界保持清晰。
明确指向敏捷的项目条件
- 需求需要边做边澄清，用户或业务方能够在短周期内给出反馈。
- 可以小批量交付，每个迭代结束时能产出可评审的增量。
- 技术方案存在多条候选路径，需要通过实际构建来验证。
- 外部刚性节点较少，交付节奏可以根据反馈调整。
这类项目适合以迭代为单位组织工作，把需求拆成待办项，按优先级排序，在每个迭代结束时评审增量并调整下一轮计划。判断敏捷是否适用，重点看反馈能否及时到达团队，而不是看团队是否熟悉某种框架。
指向混合的典型情形及拆分方式
混合适用于整体范围与关键节点固定、但部分模块需要迭代探索的项目。典型情形包括：合同规定了总交付时间和验收节点，但其中某个业务模块的需求需要与用户反复确认；硬件或平台部分技术路线确定，配套软件的功能范围需要逐步澄清；合规审查时间固定，但审查涉及的流程细节需要试运行后调整。
拆分时按“确定性”划边界：
- 确定部分按阶段推进，设置里程碑和阶段评审，作为整体计划的骨架。
- 不确定部分按迭代推进，每个迭代产出可评审的增量，迭代结果回填到整体计划中。
- 在项目计划中把迭代作为阶段下的工作单元关联起来，让里程碑日期与迭代节奏同时可见。
- 明确两类工作的交接点，例如迭代产出的方案通过评审后，才进入下一阶段的实施。
同一项目内不同模块采用不同方法时，边界要落在交付物和责任人上，而不是落在团队习惯上。每个模块应明确由谁决策、按什么节奏验收、变更走哪条路径，避免出现“计划按瀑布、执行按敏捷、验收无人负责”的空档。
选择后需要验证和调整的信号
方法选定后不是一劳永逸。可以设置几个观察信号：变更频次是否明显高于预期、迭代产出的增量是否被真正验收、里程碑偏差是否持续扩大、返工是否集中在同一类需求上。如果变更频繁但当前按瀑布推进，说明前期范围假设不成立，应考虑把相关模块转为迭代推进；如果迭代评审长期无法给出有效反馈，说明敏捷的反馈前提不具备，应回到阶段计划加评审的方式。
用工作项与阶段状态把选定的方法落到执行
方法确定后，需要在管理工具中把阶段、迭代、工作项状态和评审交接承载下来，否则方法选择只停留在文档里。以 ONES 为例，ONES Project 为敏捷、瀑布流等项目制软件研发提供工具支持，适配需求管理、任务管理、缺陷管理、迭代管理等场景，并提供敏捷、瀑布、通用任务协同等多种项目模板，可用于初始化对应方法的项目结构。
落地时可以按以下方式组织：
- 阶段与迭代并存：混合项目用项目计划承载整体阶段和里程碑，用迭代承载不确定模块的工作；确定部分的任务挂在阶段下，探索部分的任务挂在迭代下，两者通过关联关系对应到同一项目。
- 工作项类型对应方法：瀑布项目以阶段任务、交付物、评审任务为主，强调前后置依赖；敏捷项目以需求、迭代任务、缺陷为主，强调优先级和迭代归属。工作项类型的选择应与验收方式一致。
- 状态对应推进节奏：阶段任务的状态反映计划执行情况，迭代任务的状态反映迭代内进度。状态流转规则应能回答“这个工作项现在卡在谁那里、下一步交给谁”。
- 评审与变更留痕：阶段评审记录、迭代评审结论、变更申请与影响评估都应作为工作项或记录保留，便于后续追溯方法执行是否符合预期。
- 按两种节奏查看进展：整体层面按里程碑查看阶段完成情况，模块层面按迭代查看增量产出，两个视图的数据来源保持一致。
在瀑布项目计划中，可以用项目计划创建工作分解结构，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点；混合项目中，把迭代与阶段计划关联，可以让确定部分的节点和探索部分的节奏在同一项目中对照查看。方法落地后，再用变更频次、里程碑偏差、迭代验收情况等信号检验选择是否合适，必要时调整拆分边界。
常见问题
项目同时存在需求模糊和合同节点刚性，应该选哪种方法？
这类项目通常更适合混合，而不是在瀑布和敏捷之间二选一。做法是把合同节点、合规审查等刚性要求作为整体计划的骨架，按阶段设置里程碑和评审；把需求需要反复澄清的模块划出来，按迭代推进，每个迭代产出可评审的增量，再把结果回填到整体计划中。
拆分边界要落在交付物和责任人上：每个模块明确由谁决策、按什么节奏验收、变更走哪条路径。边界清楚了，两种节奏才能在同一项目里并存而不互相干扰。
团队不熟悉敏捷框架，还能选敏捷方法吗？
判断敏捷是否适用，重点看反馈能否及时到达团队、能否小批量交付可评审的增量，而不是看团队是否熟悉某种框架。如果用户或业务方能在短周期内给出有效反馈，即使团队缺少敏捷经验，也可以从较短的迭代周期和简单的待办排序开始，逐步建立节奏。
反过来，如果迭代评审长期拿不到有效反馈，说明敏捷的前提不具备，应回到阶段计划加评审的方式，而不是靠增加仪式来维持形式。
混合项目里，迭代和阶段计划如何对应到同一套进度视图？
常见做法是在项目计划中把迭代作为阶段下的工作单元关联起来，让里程碑日期与迭代节奏同时可见。整体层面按里程碑查看阶段完成情况，模块层面按迭代查看增量产出，两个视图的数据来源保持一致。
在 ONES 中，瀑布项目计划可用「项目计划」创建工作分解结构、设置任务前后置依赖，并用里程碑标记重要时间点、事件或决策点；混合项目把迭代与阶段计划关联，便于对照查看确定部分的节点和探索部分的节奏。
方法选定后，出现哪些信号说明需要调整？
可以观察几类信号：变更频次是否明显高于预期、迭代产出的增量是否被真正验收、里程碑偏差是否持续扩大、返工是否集中在同一类需求上。
如果变更频繁但当前按瀑布推进，说明前期范围假设不成立，可考虑把相关模块转为迭代推进；如果迭代评审长期无法给出有效反馈，说明敏捷的反馈前提不具备，应回到阶段计划加评审的方式。调整时优先改拆分边界和验收方式，再考虑整体切换方法。
同一项目内不同模块采用不同方法，验收责任怎么划清？
关键是让每个模块的验收方式与工作项类型、状态流转保持一致。阶段任务按阶段评审或合同节点验收，迭代任务按迭代评审验收增量，两类工作项的完成标准分别写清。
同时明确交接点，例如迭代产出的方案通过评审后才进入下一阶段实施。这样能避免出现计划按瀑布、执行按敏捷、验收无人负责的空档。
