项目里既有合同或上线日期锁定的里程碑，又有方案尚未确定的探索性模块时，把整支团队统一按瀑布或统一按迭代推进，往往两头都不合适。可行的做法是先按“交付承诺是否已经锁定”把工作项分成两类，锁定部分按阶段推进并设阶段门，探索部分按固定时箱迭代收敛，再用统一的里程碑日历和接口规则把两者接起来。下面给出一套可以在项目启动会上直接填写和使用的适配规则。
要点总览（TL;DR）
- 先按交付承诺是否锁定分类：验收标准和时点已冻结的工作走瀑布并设阶段门，目标明确但方案未定的探索内容走固定时箱迭代。
- 制定规则分五步：识别固定里程碑、识别探索性交付、指定推进方式与评审节奏、定义衔接机制、形成一页适配表并约定变更升级路径。
- 衔接靠三条规则：里程碑日历作为共同时间基准，迭代增量满足验收标准明确、评审通过、变更记录完整才进入承诺范围，未确认内容留在迭代待办。
- 角色职责要写清：项目负责人裁定分类争议，阶段门评审人把关放行，迭代负责人维护待办与增量说明。
- 规则落地后用检查清单核对分类依据、里程碑确认、时箱冲突、评审人和变更路径，并在每个里程碑节点复核适配表。
混合适配规则的核心答案与制定步骤
混合适配规则的实质是一份分类与衔接约定：它回答每个工作项走哪条路径、由谁判定、什么时候向里程碑交付什么。规则不必写成长篇制度，一页适配表加上几条评审与变更约定即可运行，关键是判据清楚、接口明确、有人裁定争议。
制定过程按以下五步推进，每步都有明确输入和产出：
- 识别固定里程碑。输入是合同、上线计划、监管要求或对外承诺。动作是逐个列出里程碑的交付物、验收标准、时点和不可移动的约束条件。输出是一份里程碑清单，作为后续分类的基准。
- 识别探索性交付。输入是需求清单和方案成熟度评估。动作是标出目标明确但实现路径未定、需要用户反馈才能收敛的内容，写明不确定性来源（技术可行性、用户偏好、外部接口未定等）和计划采用的验证方式（原型、试用、数据验证）。输出是探索性工作项清单。
- 为两类工作指定推进方式与评审节奏。锁定工作按阶段划分，每个阶段结束设阶段门，按检查项确认交付是否达标；探索工作按固定时箱迭代，每个迭代结束时演示可运行增量。输出是推进方式对照说明，写清阶段划分、迭代长度和各自的评审节点。
- 定义衔接机制。明确迭代增量在什么条件下可以进入里程碑承诺范围，未确认内容如何留在迭代待办中，跨类依赖如何提前约定。输出是接口规则和阶段门检查清单。
- 形成一页适配表并约定变更升级路径。把工作项、分类结论、判据依据、负责人、对应里程碑节点填入同一张表；写明范围变更由谁提出、谁评估、谁批准、记录在哪里。输出是适配表和变更升级路径说明。
一页适配表可采用如下结构，项目启动时填写，里程碑节点复核：
| 工作项/阶段 | 分类结论 | 判据依据 | 负责人 | 对应里程碑节点 | 评审方式 |
|---|---|---|---|---|---|
| 示例：核心交易接口开发 | 瀑布 | 验收标准已冻结，外部系统联调时点固定 | 接口负责人 | M1 上线前联调完成 | 阶段门评审 |
| 示例：新用户引导流程 | 迭代 | 目标明确，交互方案需用户反馈验证 | 产品负责人 | M1 前提供可用增量 | 迭代演示 |
划分判据：哪些阶段和工作项走瀑布、哪些走迭代
分类的对象是工作项和阶段，团队或部门不整体贴标签。同一个团队可以同时承担锁定交付和探索任务，判断依据只看这项工作本身的承诺状态和不确定性程度。以下四个维度可作为主要判据：
| 判据维度 | 瀑布适用情形 | 迭代适用情形 | 边界处理 |
|---|---|---|---|
| 交付承诺 | 合同、监管或对外公告已锁定交付物和时点 | 承诺的是目标或效果，交付形态可调整 | 同一里程碑内拆分：锁定部分进承诺范围，其余进迭代待办 |
| 验收标准明确度 | 验收标准已书面冻结，可逐条核对 | 验收标准需通过原型或试用逐步明确 | 先冻结可冻结的部分，剩余标准在迭代中补充并记录 |
| 需求变更成本 | 变更涉及硬件、外部接口或合规审批，成本高 | 变更主要影响软件内部实现，成本可控 | 按变更影响面判定，影响外部依赖的部分走阶段门 |
| 外部依赖与合规要求 | 存在前置的外部联调、认证或审批节点 | 依赖主要在团队内部，可并行验证 | 外部依赖节点固定，内部探索围绕该节点排布迭代 |
典型走瀑布的情形包括：合同或监管锁定的交付物、硬件采购与外部系统联调等前置阶段、验收标准已经冻结的里程碑。这类工作一旦返工代价高，适合按阶段推进、逐段确认。
典型走迭代的情形包括：目标明确但方案未定的探索性交付、需要用户反馈才能收敛的需求、技术路线需要小步验证的模块。这类工作的价值在于尽早暴露问题，固定时箱和可演示增量比详细的前期计划更有效。
边界情形最常见的是同一里程碑内既有锁定交付又有探索内容。处理方式是拆分：把里程碑交付物中已确认的部分列为承诺范围，探索内容作为支撑该里程碑的候选增量，在迭代中验证，确认后再纳入承诺范围。拆分结论要写进适配表，注明依据，避免后续争议。
角色分工与各环节交付物
混合规则能否执行，取决于分类争议有没有人裁定、阶段门有没有人把关、迭代待办有没有人维护。角色可以兼任，但职责要写清楚。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 项目负责人 | 维护适配表与里程碑日历，裁定分类争议，组织里程碑节点复核 | 适配表、里程碑日历、复核记录 |
| 里程碑负责人或阶段门评审人 | 按检查项确认阶段交付是否达标，决定是否放行进入下一阶段 | 阶段门评审记录、放行结论 |
| 迭代负责人 | 管理迭代待办、时箱和增量演示，维护未确认内容清单 | 迭代待办、迭代增量说明、演示记录 |
| 职能角色（开发、测试、业务等） | 提供锁定交付物的输入与验收证据，参与探索内容的验证 | 阶段交付物、验收证据、验证结论 |
交付物清单建议统一存放并与工作项关联：适配表记录分类结论和依据；里程碑日历记录各节点时点和依赖；迭代增量说明记录每个迭代交付了什么、哪些内容尚未确认；阶段门评审记录记录检查项结果和遗留问题。四类记录构成后续变更评估和复盘的基础。
衔接机制：迭代增量如何对接固定里程碑
两类工作各跑各的，混合方法就会退化成两套互不相干的流程。衔接的核心是三条规则：共同时间基准、增量准入条件、未确认内容隔离。
里程碑日历作为共同时间基准。迭代时箱围绕里程碑节点排布，例如在里程碑前预留一个专门用于集成和验收的迭代，避免迭代节奏与交付节点冲突。里程碑日期调整时，同步调整相关迭代的排布，并在适配表中记录调整原因。
迭代增量进入承诺范围需要满足条件。建议设定三条准入条件：验收标准已明确并书面记录；增量经过演示或评审通过；变更记录完整，能追溯到提出人和批准人。三条同时满足才纳入里程碑承诺范围，缺一条则继续留在迭代待办中。
未确认内容不占用承诺范围。探索内容在确认前只作为候选增量管理，不写入里程碑交付物清单，也不计入承诺完成度。这样可以避免承诺范围被不断膨胀的探索内容稀释，也让阶段门评审有稳定的判断基准。
阶段门评审时按以下清单逐项检查：
- 承诺交付物完成度：对照里程碑交付物清单逐项核对，未完成项注明原因和补救计划。
- 探索内容收敛情况：已确认进入承诺范围的增量有哪些，仍在验证的内容距离结论还差什么。
- 风险与变更记录：本期新增或关闭的风险、范围变更是否都有记录和批准。
- 跨类依赖状态：锁定工作对探索模块的接口约定是否兑现，探索结论是否影响已冻结的验收标准。
跨类依赖应提前约定：锁定阶段需要探索模块提供什么接口或结论、最晚什么时候提供、提供不了时的替代方案。依赖到期未兑现时，按变更升级路径处理，由项目负责人评估是否调整里程碑范围或时点，而不是在阶段门评审时临时协商。
这些规则落到工具上时，可以把工作项按分类打上标记，用里程碑视图跟踪承诺交付物和阶段门结论，用迭代视图管理待办和增量说明，评审记录与工作项关联保存。ONES 支持工作项状态跟踪、里程碑管理和评审记录留存，适合承载这类分类标记与节点复核；具体配置方式按团队现有流程设定即可。
示例：一个里程碑加探索交付的混合项目如何落地
以下为演示情景，用于说明适配表的填写和运行方式，不对应具体企业案例。
情景设定。某系统计划在 6 月底完成一次对外上线（里程碑 M1），交付物包括核心交易接口和后台管理功能，验收标准已与业务方书面确认。同一项目中还有一个新用户引导模块，目标是提升首次使用完成率，但交互方案尚未确定，需要小范围试用后收敛。
按判据拆分并填入适配表。核心交易接口涉及外部系统联调，验收标准已冻结，变更成本高，归为瀑布，按接口设计、开发、联调三个阶段推进，每个阶段结束设阶段门。后台管理功能验收标准明确，归为瀑布。新用户引导模块目标明确但方案未定，归为迭代，按两周一个时箱推进，每个迭代结束演示可运行版本。适配表中同时注明：引导模块的结论若影响上线范围，需在 M1 前四周的评审中提出。
迭代排布与里程碑对应。从项目启动到 M1 共安排若干迭代，最后一个迭代专门用于集成和验收准备，不再承接新的探索内容。每个迭代的增量说明中标注该增量是否具备进入 M1 承诺范围的条件。
阶段门评审时的检查与调整。接口联调阶段门评审时，评审人对照检查清单确认联调完成度、遗留缺陷和引导模块的接口依赖状态。若引导模块的试用结论显示需要额外接口，评审记录中注明影响范围，由项目负责人决定是否将其纳入 M1 或推迟到下一里程碑。
范围变更的升级处理。假设试用中发现引导流程需要新增一个后台配置项，属于 M1 承诺范围内的功能变更。提出人填写变更说明，迭代负责人评估工作量，里程碑负责人评估对上线时点的影响，项目负责人批准后更新适配表和里程碑交付物清单，并在下一次阶段门评审中复核。未获批准的内容留在迭代待办中，不进入承诺范围。
规则落地后的完成检查
适配规则制定完成后，用以下清单逐项核对，全部通过才视为可执行：
- 每个工作项都能归入瀑布或迭代，适配表中写有判据依据，没有“待定”项长期悬置。
- 里程碑交付物、验收标准和时点已书面确认，相关方已知悉。
- 迭代时箱与里程碑日历无冲突，里程碑前的集成与验收时间已预留。
- 阶段门检查项和评审人已明确，评审记录有固定存放位置。
- 变更升级路径已约定，包含提出、评估、批准和记录四个环节的责任人。
- 适配表在项目启动时完成填写，并在每个里程碑节点复核更新。
检查中发现缺口时，优先补齐判据依据和衔接规则，再进入执行阶段。规则运行一个里程碑后，结合阶段门评审记录复盘一次分类是否准确、接口是否顺畅，按需调整迭代长度或阶段划分，使适配规则随项目进展保持可用。
常见问题
探索性内容在迭代中验证通过后，是否必须纳入当前里程碑的承诺范围？
满足准入条件后可以纳入，是否纳入由项目负责人结合里程碑剩余时间和影响面决定。准入条件通常包括验收标准已书面明确、增量经过演示或评审通过、变更记录完整可追溯。若纳入会影响已冻结的交付物或上线时点，应先按变更升级路径评估，再更新适配表和里程碑交付物清单；未获批准的内容继续留在迭代待办中，不计入承诺完成度。
固定里程碑的日期因外部原因调整时，混合规则需要同步改哪些内容？
先更新里程碑日历，再检查围绕该节点排布的迭代时箱是否仍然成立，重点看里程碑前预留的集成与验收迭代是否被压缩。随后在适配表中记录调整原因，复核跨类依赖的提供时点，并通知阶段门评审人更新检查安排。若调整导致部分锁定工作无法按原阶段划分完成，应重新评估这些工作项的分类依据，而不是直接沿用原结论。
同一工作项在项目中途从探索转为锁定，分类结论怎么处理？
以书面确认的验收标准和时点为依据重新判定，并在适配表中保留原分类、变更原因和批准人。转为锁定后，该工作项按阶段推进并纳入阶段门评审；此前迭代中已完成的增量作为阶段输入，尚未确认的部分继续留在迭代待办。分类变更涉及里程碑交付物清单时，同步更新清单并通知相关方，避免承诺范围与适配表不一致。
团队规模较小、角色由一人兼任时，混合规则还能执行吗？
可以执行，前提是职责分离在记录上体现。兼任时仍要区分三种动作：分类裁定、阶段门放行、迭代待办维护，并在评审记录中写明每次判断的依据，避免同一人既提出变更又直接批准。若确实无法分离，可约定变更批准需另一名相关方会签，或在里程碑节点复核时集中检查分类与变更记录。
阶段门评审发现探索内容收敛不及预期，应该调整里程碑还是调整迭代安排？
先判断该探索内容是否在里程碑承诺范围内。不在承诺范围内的，通常调整迭代安排：缩短时箱、增加验证手段或缩小探索目标，承诺交付物按原计划推进。在承诺范围内且影响交付的，由项目负责人评估两种选项：调整里程碑范围或时点，或在迭代中补充资源加快收敛。无论哪种选择，都要在评审记录中写明结论、影响范围和后续复核节点。
