瀑布、敏捷、混合怎么按项目不确定性选

项目该用瀑布、敏捷还是混合，关键看不确定性落在需求端还是实现端：需求与验收标准能提前锁定、变更代价高，瀑布更合适；需求方向清楚但细节要边做边验证，敏捷更合适；需求可锁定而实现路径待探索，或节点固定、内部需迭代，混合更合适。下面给出同口径对照、四问判断流程和混合切分方式。

要点总览（TL;DR）

• 先定位不确定性在需求端还是实现端：需求与验收标准能提前锁定、变更代价高，瀑布更合适；需求方向清楚但细节要边做边验证，敏捷更合适；需求可锁定而实现路径待探索，或节点固定、内部需迭代，混合更合适。
• 判断时同时看四项：需求与验收标准的可预先确定程度、技术方案与实现路径的成熟度、交付节点与合规约束、变更一次的成本与频率，单一维度不足以定方法。
• 四问结果冲突时，优先按变更成本和交付约束处理：节点不可移动就保留外层里程碑，把技术验证放入内层迭代，即采用混合。
• 混合方法要明确切分依据（按阶段、按模块或按层级），并统一需求基线、评审节点与状态口径，交接点写清输入物和责任人。
• 方法选定后以需求变更频率、周期交付可用成果比例、里程碑偏差作为复评信号，先在一个项目或模块小范围试运行再全面推行。

三种方法在不确定性上的分工

选择项目管理方法时，先定位不确定性出现的位置，比先看项目规模更有效。规模大的项目也可能需求清晰、路径成熟，适合按阶段推进；规模小的项目也可能技术路线未验证，需要短周期试错。方法的作用是让计划方式与不确定性的分布相匹配。

瀑布把项目划分为启动、规划、执行、监控和结项等阶段，前一阶段的产出作为后一阶段的输入。它适合需求与验收标准能在启动前写清、变更一次代价较高的项目，例如合同范围明确、需要按节点交付验收的业务系统建设。这类项目的风险主要来自执行偏差，阶段评审和基线对比能帮助及早发现进度与计划的偏离。

敏捷把交付切成短周期，每个周期产出可用的成果并接受反馈。它适合需求方向明确、但具体细节需要在使用中验证的项目，例如面向内部用户的工具或处于市场验证阶段的产品。前提是团队能按短周期交付可用成果，且干系人愿意持续参与评审。需求完全模糊、连方向都无法描述时，敏捷同样难以启动，需要先做小范围探索。

混合处理的是两端不一致的情形：需求可以锁定，但实现路径不确定，需要在固定节点内做技术验证；或者交付节点由合同、合规评审固定，内部执行仍需迭代调整。混合的价值在于把稳定性放在外层，把探索性放在内层，避免用一套节奏覆盖所有工作。

因此，判断顺序是先问不确定性在需求端还是实现端，再问交付节点和变更成本是否允许迭代。项目规模、行业属性可以作为辅助参考，单独使用不足以得出结论。

按不确定性选方法的同口径对照

把三种方法放在同一组维度上比对，能减少“感觉适合”带来的偏差。下表列出各维度的典型表现与前提条件；表中描述的是常见情形，具体项目仍需结合实际取值判断。

对照维度	瀑布	敏捷	混合
需求清晰度	启动前可写清范围与验收标准	方向明确，细节在迭代中细化	整体范围可锁定，部分模块待明确
技术方案成熟度	实现路径成熟，团队有类似经验	路径需在短周期内验证	核心路径成熟，探索性部分单独迭代
交付节奏约束	按阶段节点推进，节点间依赖强	固定周期交付，节奏由团队维持	外层里程碑固定，内层按短周期交付
变更成本	变更需走评审，代价高	变更被纳入下个周期，代价相对可控	基线内变更受控，探索区允许调整
验收方式	阶段评审加最终验收	每个周期评审可用成果	里程碑验收加迭代演示并行
干系人参与方式	关键节点参与评审与签字	持续参与，定期反馈优先级	高层看里程碑，业务方参与迭代评审

维度取值组合指向不同结论：需求清晰度高、技术成熟度高、变更成本高，三项同时成立时瀑布最稳妥；需求清晰度中等、技术成熟度低、团队能稳定输出可用成果，敏捷更合适；需求清晰度高而技术成熟度低，或交付节点不可移动而内部需要试错，混合更匹配。若需求清晰度低且变更成本也低，可以先以探索性迭代明确需求，再决定后续采用哪种方式。

表中未给出具体阈值，例如“变更成本高”在不同组织中的含义不同，需要结合合同条款、架构耦合程度和上线审批流程判断。干系人参与意愿也属于需要实际确认的项，不能仅凭项目类型推定。

用四个问题判断项目该用哪种方法

把维度转成问题，可以让启动会上的讨论有共同依据。建议按顺序回答以下四问，并记录结论与依据。

1. 需求与验收标准能否在启动前写清？能写清到可评审、可验收的程度，说明需求端不确定性低；只能写出方向、细节需要在使用中确认，说明需求端不确定性高。
2. 技术方案与实现路径是否成熟？团队做过同类项目、关键依赖已验证，视为成熟；存在未验证的技术选型、性能指标或外部接口，视为不成熟。
3. 是否存在不可移动的交付节点或合规评审？合同约定日期、监管报备、上线窗口属于硬约束；内部希望尽早交付但不涉及外部承诺，约束强度较低。
4. 变更一次的成本与频率如何？变更涉及架构调整、合同重谈或大范围回归测试，成本高；变更集中在局部功能、可随下个周期发布，成本低。

映射规则可以简化为：四问结果都指向确定时选瀑布；需求端不确定、路径也需探索，且团队能短周期交付时选敏捷；需求端确定而路径不确定，或节点固定而内部需迭代时选混合。若结果互相冲突，例如需求清晰但技术路径未验证，同时交付节点不可移动，优先按变更成本和交付约束处理：节点不可移动则保留外层里程碑，把技术验证放入内层迭代，即采用混合。

边界情形需要单独说明：需求清晰、路径成熟但变更频率很高，说明业务环境变化快，瀑布的阶段评审会成为瓶颈，可考虑在固定节点下采用短周期交付；需求模糊且变更成本极高，例如涉及强合规的系统改造，应先通过需求澄清和原型验证降低不确定性，再进入正式阶段，避免直接套用任一方法。

混合方法怎么切分瀑布与敏捷

混合最容易被误用成“两套流程同时跑”。有效的混合需要先确定切分依据，再明确交接点，否则会出现需求两处维护、状态口径不一致的问题。

按阶段切分：前期立项、范围确认、合同与验收走瀑布式阶段评审，开发执行段按短周期迭代。适合需求整体可锁定、但开发过程中需要频繁验证的项目。交接点设在开发启动评审，进入迭代前冻结需求基线。

按模块切分：需求稳定的模块按计划一次交付，探索性强的模块单独组队迭代。适合一个项目中同时存在成熟业务和新技术验证的情形。切分后需要统一需求编号和状态定义，避免同一需求在两个流程中各有一套进度。

按层级切分：里程碑、合同节点和对外承诺按固定计划管理，团队内部按短周期安排任务和交付。适合交付节点由外部约束决定、内部工作方式需要灵活调整的项目。管理层看里程碑偏差，团队看周期内完成情况。

三种切分方式都需要统一三件事：需求基线在何处冻结、评审节点由谁参加、工作项状态如何定义。混合不等于两套流程并行，交接点要写清输入物和责任人，例如迭代产出的可用成果在里程碑评审前完成集成验证。切分过细会增加协调成本，模块数量多、依赖关系复杂时，优先采用按阶段或按层级切分。

方法选定后的落地与调整

方法确定后，需要落到具体的工作项类型、阶段划分和评审节点上，否则方法只停留在文档里。瀑布项目应明确阶段名称、每阶段的准入准出条件和评审责任人；敏捷项目应明确周期长度、待办列表管理方式和每周期演示安排；混合项目则要同时定义外层里程碑和内层迭代计划，并说明两者的对应关系。

在工具承载上，ONES 提供敏捷、瀑布、通用任务协同等多种项目模板，支持用项目计划创建工作分解结构、设置任务前后置依赖，并用里程碑标记重要时间点，还可设置计划和里程碑基线，对比计划与执行的偏差。对于同一项目中瀑布阶段与迭代计划并存的组织方式，可以按项目分别选择模板，再通过统一的需求、任务、缺陷和里程碑管理保持状态口径一致；具体配置需结合团队实际流程确定。

方法不是一次选定后长期不变。建议把以下信号纳入复评：需求变更频率是否明显高于启动时的估计；每个周期产出的可用成果比例是否稳定；里程碑偏差是否持续扩大。不确定性下降时，可以收窄迭代范围、延长评审间隔，逐步向阶段化管理过渡；不确定性上升时，应扩大探索区间，增加验证性交付，必要时把部分模块从瀑布切分出来单独迭代。

复评周期可与里程碑评审或季度规划对齐，每次复评记录判断依据和调整动作，便于后续项目参考。

适配场景与选择建议

需求稳定、验收标准严格、变更一次代价高的项目，例如合同范围明确的系统建设或合规改造，选瀑布。启动前把范围和验收标准写清，按阶段评审推进，用基线对比控制偏差。

需求方向明确、需要快速验证、团队能按短周期交付可用成果的项目，例如内部工具建设或新产品探索，选敏捷。保持干系人持续参与，用每周期演示收集反馈并调整优先级。

交付节点固定但实现路径不确定的项目，例如有明确上线窗口、同时包含新技术验证的项目，选混合。外层按里程碑管理，内层按迭代推进，交接点写清需求基线和评审责任。

方法选择以不确定性位置为主判据，项目规模和行业属性作为辅助参考。同一组织内不同项目可以采用不同方法，不必统一为一种流程。全面推行前，建议先在一个项目或一个模块小范围试运行，观察需求变更频率、周期交付情况和里程碑偏差，再根据实际效果调整切分方式和评审节奏。

常见问题

需求在启动时只能写清方向，但交付节点由合同固定，该用哪种方法？

这种情形属于需求端不确定、交付约束又强，单用瀑布或单用敏捷都不贴合。可行做法是采用混合：外层按合同节点和里程碑管理，把范围确认、验收和对外承诺放在固定计划里；内层把需求细化、原型验证和功能开发放进短周期迭代，每个周期产出可评审的成果。

需要提前做两件事：一是在里程碑评审前完成需求基线的冻结，明确哪些内容进入本期交付；二是约定变更走哪条路径，合同范围内的调整在迭代内消化，超出范围的走变更评审。若需求方向本身也无法描述，应先安排小范围探索，再决定后续节奏。

技术方案已经成熟，但业务方变更频繁，还适合用瀑布吗？

技术成熟只说明实现端不确定性低，变更频繁说明需求端在持续变化。这种情况下瀑布的阶段评审容易成为瓶颈，每次变更都要走完整评审，响应速度跟不上业务节奏。

可以保留固定节点作为对外承诺，把内部执行改为短周期交付，让变更进入下个周期处理，即采用混合或偏迭代的方式。判断依据是变更的成本：如果变更集中在局部功能、可随周期发布，迭代方式更顺畅；如果变更涉及架构调整或合同重谈，仍需要阶段评审来控制，只是评审频率可以提高。

混合方法中瀑布部分和迭代部分的需求状态怎么保持一致？

关键是先统一口径再切分。切分前确定三件事：需求编号规则、状态定义（如待评审、已确认、开发中、已验收）、评审节点的责任人和输入物。切分后，无论需求走瀑布阶段还是迭代计划，都使用同一套编号和状态，避免同一需求在两处各有一套进度。

交接点要写清：迭代产出的可用成果在里程碑评审前完成集成验证，验证结果回写到同一个需求记录上。模块数量多、依赖复杂时，切分过细会增加协调成本，优先按阶段或按层级切分。

项目进行到中途，不确定性明显下降，需要换方法吗？

不必整体更换，可以先调整节奏。不确定性下降时，可以收窄迭代范围、延长评审间隔，逐步向阶段化管理过渡；反之不确定性上升，应扩大探索区间，增加验证性交付，必要时把部分模块从瀑布切分出来单独迭代。

复评信号包括需求变更频率是否明显高于启动时的估计、每个周期产出的可用成果比例是否稳定、里程碑偏差是否持续扩大。复评周期可与里程碑评审或季度规划对齐，每次记录判断依据和调整动作，便于后续项目参考。

同一组织内不同项目可以用不同方法吗？

可以。方法选择以单个项目的不确定性位置为主判据，项目规模和行业属性作为辅助参考，不必把全部项目统一为一种流程。需求稳定、验收严格的项目按瀑布推进，需要快速验证的项目按迭代推进，节点固定而路径待探索的项目采用混合。

不同方法并存时，需要在组织层面统一需求编号、状态定义和评审记录方式，否则跨项目汇总进度会出现口径差异。全面推行前，建议先在一个项目或一个模块试运行，观察需求变更频率、周期交付情况和里程碑偏差，再根据实际效果调整。