单个项目里同时存在固定里程碑和探索性交付时，划分瀑布与迭代的依据可以归结为两个变量：需求与方案的不确定性有多高、交付节奏是否被外部固定节点约束。本文按“先判断、再拆分、后复核”的顺序，给出四步划分流程、角色分工、一个完整示例和一张方法适配表，帮助项目负责人把方法选择落到可执行的工作项上。
要点总览（TL;DR）
- 判断依据是两个变量：需求与方案的不确定性高低、交付节奏是否被外部固定节点约束；两者交叉形成四类组合，分别对应瀑布、迭代、迭代产出加瀑布验收、短周期瀑布或看板式推进。
- 划分按四步走：切阶段、拆工作项、逐项标注不确定性与交付节奏、按规则分配方法，最终产出方法适配表，每行写明方法、负责人、交付物和评审节点。
- 固定节点只约束该节点本身的验收方式，节点内部方案待验证的部分可以拆出来用迭代推进，在节点前汇总为符合验收要求的成果。
- 方法分配由项目负责人主持维护，产品负责人判定需求侧不确定性，技术负责人判定方案不确定性，质量角色确认节点合规要求；阶段门、迭代评审和里程碑前检查时复核，按预设触发条件调整。
- 划分完成后用检查清单核对：方法归属完整、瀑布阶段有阶段门、迭代有周期与增量定义、衔接点有交接物和责任人、适配表有维护人和复核时点。
先判断：哪些阶段该用瀑布，哪些该用迭代
方法选择的判断对象是阶段和工作项，判断依据是两个维度。第一个维度是不确定性，指需求范围、验收标准和实现方案在阶段开始时是否已经清楚。分级可以简化为三档：低，需求和方案已确认，变更预计很少；中，需求大致清楚但方案存在若干待验证选项；高，需求方向明确但范围与做法需要边做边收敛。第二个维度是交付节奏，指该部分是否被外部固定节点约束。分级同样用三档：硬节点，合同、合规、外部验收或上线窗口已经锁定日期；软节点，内部希望的时间点，可以协商；无固定节点，按团队节奏推进。
两个维度交叉后，可以形成一张默认方法选择表。表格给的是默认结论，实际分配时仍需结合工作项粒度判断。
| 不确定性 | 交付节奏 | 默认方法 | 推进方式 |
|---|---|---|---|
| 低 | 硬节点 | 瀑布 | 按阶段门推进，需求、设计、开发、测试、验收依次完成，节点前完成评审与交付物归档 |
| 高 | 需要频繁反馈、无硬节点 | 迭代 | 固定周期交付可用增量，每个周期结束做评审，根据反馈调整下一周期范围 |
| 高 | 硬节点 | 迭代产出、瀑布验收 | 节点内部用迭代推进探索，节点前按瀑布要求完成验收材料与评审 |
| 低 | 快节奏、频繁小批量交付 | 短周期瀑布或看板式推进 | 把瀑布阶段压缩为短周期，或用看板管理连续流转，按批次完成验收 |
判断时最容易混淆的一点，是把固定节点等同于整个阶段都要用瀑布。合同约定的验收日期、合规检查点、外部上线窗口，约束的是该节点本身的验收方式和交付物要求；节点内部的工作仍可能包含方案待验证的部分，这部分可以拆出来用迭代推进，在节点前汇总为符合验收要求的成果。反过来，一个阶段整体不确定性低，也不意味着必须拉长周期，交付节奏快时用短周期瀑布或看板式推进更合适。
操作步骤：把单个项目拆成可分配方法的工作单元
划分从项目整体逐层下沉到工作项，共四步。每一步都有明确产出，前一步的产出是后一步的输入，完成标志用于判断是否可以进入下一步。
第一步：按交付物和里程碑切分阶段
输入是项目目标、合同或立项文件中的关键日期、主要交付物清单。动作是以交付物完成为边界，把项目切成若干阶段，每个阶段对应一个可验收的成果和至少一个里程碑。输出是阶段清单，写明阶段名称、起止时间、交付物、关联里程碑。完成标志是每个阶段都能回答“这个阶段结束时交付什么、由谁验收”。
第二步：把阶段拆到工作项或工作包粒度
输入是阶段清单。动作是对每个阶段做工作分解，拆到可以独立分配负责人、独立估算、独立判断完成状态的程度。探索性强的部分拆到能在一个迭代周期内验证的粒度，确定性高的部分可以按专业分工拆成工作包。输出是工作项清单，每项写明所属阶段、交付物、预估工作量。完成标志是没有工作项同时跨两个阶段，也没有工作项大到无法判断进度。
第三步：逐项标注不确定性与交付节奏
输入是工作项清单。动作是对每个工作项标注两个标签：不确定性取低、中、高；交付节奏取硬节点、软节点、无固定节点。标注时写明判断理由，例如“方案有两个候选架构未验证”标为高，“合同约定 6 月底提交检测报告”标为硬节点。输出是带标注的工作项清单。完成标志是每个工作项都有两个标签和一句理由，且同一阶段内允许出现不同标注。
第四步：按规则分配方法并形成方法适配表
输入是带标注的工作项清单和第一步的判断规则表。动作是逐项套用规则确定方法，再把同一阶段内的方法归属汇总，识别阶段内部的方法组合和衔接点。输出是方法适配表，字段包括：阶段、工作项、不确定性、交付节奏、采用方法、负责人、交付物、评审节点。完成标志是表中每一行都有方法归属和负责人，每个瀑布阶段有阶段门，每个迭代有周期长度和增量定义。
| 阶段 | 工作项 | 不确定性 | 交付节奏 | 方法 | 负责人 | 交付物 | 评审节点 |
|---|---|---|---|---|---|---|---|
| （填写） | （填写） | 低/中/高 | 硬节点/软节点/无固定 | 瀑布/迭代/混合 | （填写） | （填写） | 阶段门/迭代评审/里程碑检查 |
角色与交付物：谁来判断、谁来确认、谁跟踪
方法划分涉及四类角色。分工的核心是让不确定性判断由最接近信息的人做出，让固定节点的合规要求由承担验收责任的角色确认，项目负责人负责汇总和持续维护。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目负责人 | 主持四步划分，汇总方法适配表，组织复核，跟踪方法执行情况 | 阶段清单、方法适配表、复核记录 | 划分启动时主持，阶段门和迭代评审时复核 |
| 产品/需求负责人 | 判定需求侧不确定性，给出迭代的验收标准和优先级 | 需求不确定性标注、迭代验收标准、增量范围说明 | 第三步标注前提供判断，迭代评审前确认验收标准 |
| 技术负责人 | 判定方案不确定性，评估瀑布阶段的技术评审点和技术风险 | 方案不确定性标注、技术评审点清单、技术风险说明 | 第三步标注前提供判断，阶段门评审时出具技术结论 |
| 职能或质量角色 | 确认固定节点的合规与验收要求，明确交付物格式和检查项 | 节点验收要求清单、合规检查项 | 第一步切分阶段时提供节点约束，里程碑检查时执行确认 |
交接的关键在于标注结果要留痕。产品和技术负责人给出的不确定性判断应附理由，质量角色给出的节点要求应写明依据，项目负责人据此维护方法适配表。方法适配表是单一事实来源，任何方法调整都先改表再改计划，避免口头约定与计划脱节。
示例：一个含固定里程碑与探索性交付的项目怎么划分
以下为演示情景，用于说明划分过程，不代表特定行业或团队的真实项目。某企业内部系统升级项目，合同约定 9 月底完成外部验收并提交合规检测报告，这是硬节点；项目同时包含一个数据迁移方案待验证的模块，候选方案有两种，尚未确定哪种满足性能要求。
阶段与工作项拆分结果
按交付物切成三个阶段：阶段一为需求确认与方案设计，阶段二为系统开发与数据迁移，阶段三为验收准备与交付。阶段二内部拆出工作项：迁移方案验证、迁移脚本开发、业务功能开发、集成测试。阶段三拆出：合规检测、验收材料编制、外部验收。
逐项标注与方法分配
| 阶段 | 工作项 | 不确定性 | 交付节奏 | 方法 | 交付物 | 评审节点 |
|---|---|---|---|---|---|---|
| 阶段一 | 需求确认 | 低 | 软节点 | 瀑布 | 需求规格说明书 | 阶段门：需求评审 |
| 阶段一 | 总体方案设计 | 中 | 软节点 | 瀑布 | 方案设计文档 | 阶段门：设计评审 |
| 阶段二 | 迁移方案验证 | 高 | 无固定节点 | 迭代 | 验证报告、选定方案 | 迭代评审：每两周一次 |
| 阶段二 | 迁移脚本开发 | 中 | 硬节点 | 迭代产出、瀑布验收 | 脚本、迁移记录 | 阶段门：迁移演练验收 |
| 阶段二 | 业务功能开发 | 低 | 硬节点 | 瀑布 | 功能模块、单元测试报告 | 阶段门：开发完成评审 |
| 阶段二 | 集成测试 | 低 | 硬节点 | 瀑布 | 测试报告 | 阶段门：测试通过 |
| 阶段三 | 合规检测 | 低 | 硬节点 | 瀑布 | 检测报告 | 里程碑检查 |
| 阶段三 | 验收材料编制与外部验收 | 低 | 硬节点 | 瀑布 | 验收材料、验收记录 | 里程碑：外部验收 |
衔接点与评审安排
阶段二内部存在两处衔接。第一处是迁移方案验证的迭代产出向迁移脚本开发的交接：迭代评审确认选定方案后，输出验证报告和方案说明，作为脚本开发的输入，脚本开发负责人参加该次评审确认可执行性。第二处是脚本开发向迁移演练验收的交接：迭代按周期产出脚本和迁移记录，在阶段门前汇总为演练结果，由技术负责人和质量角色按瀑布验收要求检查。阶段门评审同时检查迭代产出的完整性和瀑布交付物的合规性，两类材料在同一评审中确认。
这类“同一项目内既有阶段门又有迭代评审”的安排，需要在同一项目空间里同时承载计划、里程碑和迭代。ONES 的项目计划支持按目标、交付物或项目阶段分解工作并设置任务依赖，用里程碑标记重要时间点和决策点；项目计划中可以关联迭代和研发任务，便于项目经理在同一视图中掌握两类推进方式的进度。方法适配表本身可以作为项目文档维护，评审记录随工作项留存。
执行中的复核与调整：什么时候改方法
方法分配需要随项目信息变化复核。复核分固定时点和触发式调整两类，前者按计划执行，后者由具体信号触发。
固定复核时点有三个：阶段门评审时，检查本阶段方法执行情况并确认下一阶段分配；迭代评审时，检查迭代内工作项的不确定性是否已下降；里程碑前检查时，确认硬节点交付物是否齐备、方法组合是否仍支撑节点要求。
调整触发条件可以预设为以下几类：
- 不确定性下降：某工作项经过验证，方案已确定、需求已冻结，可从迭代转为瀑布，纳入阶段门管理，减少评审频次。
- 需求频繁变更：瀑布阶段内出现持续的需求调整，说明原判断偏低，应把该部分拆出转为迭代，用固定周期收敛范围。
- 节点变更：外部节点日期调整或验收要求变化，需要重排阶段划分和方法归属，重新确认硬节点范围。
- 迭代持续无法产出可用增量：说明工作项粒度或验收标准有问题，先调整拆分方式，再判断方法是否合适。
调整时先更新方法适配表，记录调整原因、影响的工作项、对计划和交付物的影响，再同步修改项目计划中的依赖和里程碑。调整权限归项目负责人；涉及硬节点验收要求变化的，需质量角色确认；涉及需求范围变化的，需产品负责人确认。调整记录保留在表中，作为后续复盘的依据。
完成检查：混合划分是否可执行的验收项
划分完成后，用以下清单逐项核对。全部满足，说明划分结果具备执行条件；存在未满足项，回到对应步骤补充。
| 检查项 | 合格标准 | 核对方式 |
|---|---|---|
| 方法归属完整 | 每个阶段和工作项都有明确的瀑布、迭代或混合归属，无空白项 | 逐行检查方法适配表 |
| 瀑布阶段有阶段门 | 每个瀑布阶段写明阶段门名称、评审人、验收标准 | 对照阶段清单检查 |
| 迭代有周期与增量定义 | 每个迭代写明周期长度、每周期可交付增量的内容和验收方式 | 检查迭代评审安排 |
| 衔接点明确 | 瀑布与迭代之间的每个交接点都有交接物、接收方和确认时点 | 检查方法适配表的评审节点列 |
| 角色到位 | 每项工作有负责人，不确定性标注有判断人和理由 | 检查负责人列与标注记录 |
| 维护机制存在 | 方法适配表有指定维护人，固定复核时点和调整触发条件已写入项目计划 | 检查复核记录模板与计划中的检查点 |
清单核对通过后，方法适配表即可作为项目执行的基准。执行中按复核时点检查，按触发条件调整，保持表与计划一致，混合划分才能持续支撑固定里程碑与探索性交付并存的局面。
常见问题
固定验收节点已经锁定，节点内部还能用迭代推进吗？
可以。固定节点约束的是该节点本身的验收方式、交付物格式和检查项，节点内部的工作仍可能包含方案待验证、需求需收敛的部分。做法是把这部分拆成独立工作项，用固定周期迭代推进，每个周期产出可用增量并做评审，在节点前把迭代成果汇总为符合验收要求的材料，按瀑布要求完成阶段门或里程碑检查。需要注意两点：迭代的验收标准要提前对齐节点要求，避免最后汇总时返工；迭代产出向节点验收的交接物和确认时点要写进方法适配表。
工作项拆到什么粒度才适合分配方法？
判断标准是能否独立分配负责人、独立估算、独立判断完成状态。探索性强的部分拆到能在一个迭代周期内验证的粒度，例如“验证迁移方案 A 与方案 B 的性能表现”而不是笼统的“数据迁移”；确定性高的部分可以按专业分工拆成工作包。另外要求没有工作项同时跨两个阶段，也没有工作项大到无法判断进度。粒度不合适会直接影响方法判断：拆得太粗，一个工作项里既有确定部分又有探索部分，只能整体标为高不确定性，方法选择就失真了。
迭代跑了几轮一直产不出可用增量，应该改方法还是改拆分？
先检查拆分方式和验收标准，再判断方法是否合适。常见原因是工作项粒度太粗、验收标准没有提前定义、或者迭代内混入了依赖外部确认的事项。处理顺序是：把工作项拆细到单周期可完成，明确每个周期的增量内容和验收方式，清理迭代内的外部阻塞。调整后仍无法产出可用增量，再考虑该部分是否本就不适合迭代，例如需求已冻结、方案已确定，可以转为瀑布纳入阶段门管理。这个判断由项目负责人主持，产品和技术负责人给出意见，调整结果记入方法适配表。
瀑布阶段执行中出现持续的需求变更，怎么处理？
持续变更说明原判断偏低，应把受影响的部分从瀑布阶段拆出转为迭代，用固定周期收敛范围，而不是在阶段门内反复变更基线。操作上先识别变更集中的工作项，评估其对阶段门交付物的影响，再由项目负责人更新方法适配表，记录调整原因和影响范围，同步修改项目计划中的依赖和里程碑。涉及需求范围变化的需产品负责人确认，涉及硬节点验收要求变化的需质量角色确认。如果变更只影响个别工作项且范围可控，也可以保留瀑布框架，在阶段门评审时集中处理变更请求。
方法适配表应该由谁维护，多久复核一次？
由项目负责人维护，作为方法归属的单一事实来源，任何方法调整先改表再改计划。复核分固定时点和触发式调整：固定时点包括阶段门评审、迭代评审和里程碑前检查，分别检查本阶段方法执行情况、迭代内不确定性是否下降、硬节点交付物是否齐备；触发式调整由具体信号启动，例如不确定性下降、需求频繁变更、外部节点日期调整、迭代持续无法产出可用增量。调整记录写明原因、影响的工作项和对计划交付物的影响，保留在表中作为复盘依据。
