单项目该用瀑布、混合还是敏捷，取决于需求与验收标准的确定程度、变更频率和交付节奏，而不是团队偏好。本文按“判断特征—形成方案—落实角色—试点验证”的顺序，给出可直接执行的判定表、操作步骤和完成检查清单，适用于单个项目的管理方法选择。
要点总览（TL;DR）
- 方法选择先看三个维度：需求与验收标准能否冻结、变更来自哪里、干系人按里程碑还是按周期验收；三者组合决定瀑布、混合或敏捷的倾向。
- 需求清晰、变更少、集中验收的项目适合瀑布；整体范围清楚但部分模块需验证的项目适合混合，稳定部分走阶段、不确定部分走迭代；需求持续变化、需要频繁交付可用成果的项目适合敏捷。
- 选定方法后要形成一份方法方案，写明阶段与迭代划分、评审点、变更处理路径和阶段边界复核安排，否则方法只停留在方向层面。
- 混合方法的关键是两类变更走两条通道：合规、接口类变更进阶段评审，验证反馈类变更进迭代待办，互不打断。
- 方案定稿前逐项核对需求标注、评审点对应、变更路径、角色到人和试点指标，并在第一个阶段边界或迭代评审时复核方法是否仍然匹配。
先判断项目属于哪一类：方法选择的核心答案
方法选择的实质，是判断项目的不确定性落在哪里。不确定性低，计划可以一次做准，阶段推进更省沟通成本；不确定性集中在部分环节，就只对这部分保留迭代；不确定性贯穿全程，才需要以迭代和频繁交付为主。判断时按以下三个维度依次过一遍，结论通常就会收敛。
三个判断维度
- 需求与验收标准确定度：需求清单能否在启动阶段基本冻结，验收标准能否写成可核对的条目。能冻结、可核对的比例越高，越倾向阶段式推进。
- 变更频率与来源：变更主要来自外部合规、合同或上游接口，还是来自用户反馈与方案验证。前者适合纳入阶段评审统一处理，后者需要迭代吸收。
- 交付节奏与干系人参与方式：干系人期望按里程碑集中验收，还是希望每隔一段时间看到可用成果并参与反馈。集中验收对应阶段评审，持续反馈对应迭代评审。
项目特征判定表
| 特征组合 | 典型表现 | 方法倾向 |
|---|---|---|
| 需求与验收标准清晰，变更少且可预期，按里程碑集中验收 | 合同交付、合规改造、基础设施升级 | 瀑布 |
| 整体范围清楚，但部分模块或算法需要验证后才能定稿；变更集中在少数环节 | 含新建模或新流程的系统建设、产品化项目中的探索模块 | 混合 |
| 需求持续变化，需要频繁交付可用成果，干系人深度参与反馈 | 面向终端用户的产品迭代、市场验证型项目 | 敏捷 |
| 需求清晰但交付节奏要求高频，或需求模糊但验收节点刚性 | 两类特征冲突 | 先拆分：稳定部分走阶段，冲突部分单独设迭代，按混合处理 |
方法选择不是一次定终身。项目进入阶段边界或迭代评审时，应复核三个维度是否发生变化：原本不确定的模块验证完成后，可以并入阶段推进；外部条件突变导致需求大面积调整时，应重新评估是否扩大迭代范围。复核结论要记录在案，作为后续阶段安排的依据。
选择方法的操作步骤：从项目特征到方法方案
判定表给出方向，落地还需要一份写明阶段划分、评审点和变更处理方式的方法方案。以下四步按顺序执行，每步都有明确的输入、动作、输出和完成标志。
步骤一：梳理需求清单与验收标准
输入：需求文档、合同或任务书、已有验收口径。动作：逐条列出需求，为每条标注“确定”或“不确定”，确定项写出可核对的验收标准，不确定项写明待验证的问题和验证方式。输出：带确定度标注的需求清单。完成标志：每条需求都有标注，不确定项都有对应的验证问题，没有空白项。
步骤二：评估变更来源与频率
输入：需求清单、历史变更记录、干系人访谈。动作：按来源归类变更，区分可纳入阶段评审统一处理的变更（如合规口径调整、上游接口变更）和需要迭代吸收的变更（如用户反馈引发的方案调整），并估算各类变更的大致频率。输出：变更来源分类表。完成标志：每类变更都指明了处理通道，即走阶段评审还是走迭代待办。
步骤三：确定交付节奏与评审节点
输入：需求确定度标注、变更分类表、干系人验收期望。动作：确定项目分几个阶段或几个迭代，每个阶段或迭代的起止时间、交付物和评审节点；确定部分按阶段设置里程碑评审，不确定部分按固定周期设置迭代评审。输出：阶段与迭代划分表，含评审节点清单。完成标志：每个交付物都挂在某个阶段或迭代下，每个评审节点都有明确的评审对象和参与角色。
步骤四：形成方法方案
输入：前三步的输出。动作：写成一份单项目方法方案，内容包括：方法结论及判定依据、阶段与迭代划分、评审点安排、变更处理路径（谁提出、谁评审、记录在哪里、结论如何回写计划）、阶段边界的复核安排。输出：方法方案文档。完成标志：方案经项目干系人确认，变更路径能对应到具体责任人和记录位置。
角色分工与各阶段交付物
方法方案能否执行，取决于每个角色是否清楚自己在哪个节点交付什么。以下职责按单项目设置，可根据团队规模合并兼任，但职责本身不宜空缺。
| 角色 | 方法选择阶段 | 执行阶段 |
|---|---|---|
| 项目经理 | 组织特征评估，起草方法方案，确认评审点 | 维护阶段与迭代计划，组织评审，跟踪变更结论回写 |
| 需求负责人 | 完成需求确定度标注与验收标准编写 | 管理需求变更来源，判断变更走阶段评审还是迭代待办 |
| 技术负责人 | 评估不确定模块的验证方式与工作量 | 对技术方案变更给出影响判断，确认迭代产出的可用性 |
| 质量与评审角色 | 确认验收标准可核对，评审点覆盖关键交付物 | 在评审点核对交付物与验收标准，出具评审结论 |
三种方案下阶段交付物的差异主要体现在颗粒度和频次。瀑布方案的交付物按阶段成组产出，如需求规格、设计说明、测试报告，每个阶段结束集中评审；混合方案中，稳定部分沿用阶段交付物，不确定部分按迭代产出可验证的原型、试验报告或功能增量，迭代评审通过后再并入阶段交付物；敏捷方案的交付物以迭代增量为主，每个迭代结束产出可用的功能切片，评审以演示和反馈为核心。变更请求的处理责任统一归需求负责人受理和分类，技术类变更由技术负责人评估影响，评审结论由项目经理记录并回写计划，质量角色在评审点核对变更是否已体现在交付物中。
示例：一个需求部分不确定的项目如何选混合方法
以下为演示情景，用于说明从特征判断到方案落地的完整过程，不代表特定行业案例。
项目背景与特征
某业务系统升级项目，合同范围包括数据迁移、核心流程重构和一个智能推荐模块。数据迁移与流程重构的需求和验收标准在启动阶段可以冻结，变更主要来自上游系统接口调整；推荐模块的效果依赖真实数据验证，验收标准只能给出方向性指标，需要多轮试验才能定稿。干系人要求按季度里程碑汇报整体进度，同时希望每月看到推荐模块的验证结果。
判定为混合方法的依据
项目整体范围清楚，交付节点刚性，符合阶段推进的条件；但推荐模块的需求与验收标准确定度低、变更来自验证反馈，需要迭代吸收。两类特征并存，按判定表归入混合：稳定部分按阶段推进，不确定模块按迭代推进，阶段边界复核迭代结论是否可以并入。
阶段划分、迭代安排与评审点
- 阶段一（第1—2月）：完成数据迁移方案与流程重构设计，里程碑评审确认设计基线。
- 阶段二（第3—5月）：数据迁移实施与流程重构开发，期间推荐模块并行开展三个为期四周的迭代，每个迭代结束做验证评审，输出试验报告。
- 阶段三（第6月）：推荐模块定稿并入整体交付，集中验收。里程碑评审覆盖全部交付物。
评审点分两类：里程碑评审由项目经理组织，干系人参加，核对阶段交付物；迭代评审由需求负责人组织，技术负责人和质量角色参加，核对验证结论是否支持进入下一迭代或并入阶段。
执行中的变更处理
项目中期上游接口调整，影响数据迁移的字段映射。该变更由需求负责人受理，归入“可纳入阶段评审”一类，提交阶段二的中期评审，结论回写迁移计划，不打断推荐模块的迭代节奏。推荐模块在第二个迭代中发现原定指标不可达，需求负责人将其转为迭代待办，在第三个迭代调整验证方案，迭代评审确认后更新验收标准。两类变更走不同通道，互不干扰，这是混合方法在该项目中的主要价值。
用协作工具承载方法落地：阶段、评审与变更的记录
方法方案写在文档里，执行时容易走样，常见原因是阶段、评审点和变更结论散落在不同地方。把这三类信息固定到协作平台的工作项和记录中，方案才具备可追踪性。
阶段划分与评审点可以落到工作项状态和里程碑上：每个阶段或迭代对应一组工作项，状态按方案中的节点设置，里程碑标记评审时间点和决策点。ONES 瀑布项目管理解决方案支持用项目计划创建工作分解结构，按目标、交付物或项目阶段分解计划，并用里程碑标记重要时间点、事件或决策点，这与上文阶段划分表的落地方式一致。ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并采用组件化设计，可根据项目需要定义项目类型与相关组件，适合承载同一项目中阶段与迭代并行的混合安排；具体配置范围以实际产品版本为准。
变更请求需要独立记录：提出人、变更内容、影响评估、评审结论、回写后的计划调整，逐项留痕，并与受影响的阶段或迭代工作项关联。阶段交付物和评审证据按阶段归档，评审结论与交付物放在同一记录下，便于阶段边界复核时直接调取。这样，方法方案中的每个评审点和变更路径都能在工具中找到对应位置，复核时不必依赖个人记忆。
完成检查：方法选择是否可执行的核对项
方案定稿前逐项核对，任一项不满足，说明方法选择还停留在方向层面，需要补做对应步骤。
- 需求清单中每条需求都已标注确定或不确定，不确定项写明了验证问题与验证方式。
- 验收标准可核对，质量角色已确认关键交付物的验收口径。
- 阶段或迭代划分与评审点一一对应，每个交付物都挂在某个阶段或迭代下。
- 变更处理路径明确到受理人、评审人、记录位置和结论回写方式，阶段评审与迭代吸收两类通道都已指定。
- 角色职责落实到具体人员，项目经理、需求负责人、技术负责人、质量与评审角色均无空缺。
- 阶段边界的复核安排已写入方案，明确复核时间和触发条件。
- 试点范围与验证指标已确定，例如先在一个阶段或两个迭代内试运行，以评审按时完成率、变更结论回写及时率作为验证指标。
核对通过后即可按方案执行，并在第一个阶段边界或迭代评审时做一次方法复核，根据实际变更情况调整阶段与迭代的比例。
常见问题
项目启动时需求看起来很清楚，执行到一半却频繁变更，应该改方法吗？
先判断变更的性质再决定是否调整。如果变更集中在少数模块，且来自验证反馈或用户意见，可以把这些模块从阶段推进中拆出来，改为按固定周期迭代，其余部分保持阶段推进，整体转为混合方法。如果变更来自外部合规或上游接口，且仍可通过阶段评审统一处理，则维持瀑布，只需在评审点增加变更影响评估。
调整的时机建议放在阶段边界或迭代评审，避免中途频繁切换节奏。调整结论要记录在案，并同步更新方法方案中的阶段划分与变更路径。
混合方法中，阶段评审和迭代评审的结论冲突时以哪个为准？
两类评审的对象不同，通常不会直接冲突：阶段评审核对阶段交付物是否达到验收标准，迭代评审核对不确定模块的验证结论是否支持进入下一迭代或并入阶段。出现分歧时，以阶段评审的验收结论为准，因为它对应合同或项目整体的交付承诺；迭代评审的结论作为输入，用于调整后续迭代的验证方案。
为避免反复，可在方法方案中预先写明：迭代产出并入阶段交付物前，需经质量角色确认验收口径，再由项目经理在阶段评审中确认。
团队规模较小、一人兼任多个角色时，角色分工表还需要保留吗？
需要保留，但可以合并到人。角色职责的价值在于明确每个节点的受理人、评审人和记录人，避免变更无人受理或评审结论无人回写。小团队中项目经理可兼需求负责人，技术负责人可兼质量核对，但每项职责仍要落到具体姓名，并在方法方案中写明。
合并兼任时要注意一个限制：变更的提出与评审结论确认不宜由同一人完成，至少保留一次独立核对，否则变更记录容易流于形式。
试点验证方法是否匹配时，应该看哪些指标？
试点范围建议先覆盖一个阶段或两个迭代，指标围绕方法方案能否被执行来选，例如评审是否按计划时间完成、变更结论是否在规定时间内回写计划、阶段交付物是否在评审前齐备。这些指标反映的是流程运转情况，比交付速度更适合用来判断方法是否匹配。
试点结束后做一次复核，若评审频繁延期或变更回写滞后，先检查评审点设置和变更路径是否合理，再考虑调整阶段与迭代的比例。
方法方案确定后，在协作工具中至少要固定哪些记录？
至少固定三类记录：阶段与迭代的划分及对应工作项、评审点及其结论、变更请求从提出到回写的完整链路。ONES 瀑布项目管理解决方案支持用项目计划创建工作分解结构，按目标、交付物或项目阶段分解计划，并用里程碑标记重要时间点、事件或决策点；ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并采用组件化设计，可根据项目需要定义项目类型与相关组件，具体配置范围以实际产品版本为准。
记录固定的目的是让阶段边界复核时能直接调取证据，不必依赖个人记忆。工具选型本身不构成方法选择的依据。
