混合式项目管理的阶段与迭代映射表，核心作用是把瀑布阶段的门禁条件与迭代产出放在同一行对齐，让阶段评审时能直接看到“这个阶段由哪几个迭代支撑、每个迭代交付了什么”。一张可用的表至少包含四组字段：阶段与迭代的标识、门禁条件、迭代产出、衔接信息。下面先给出可直接复制的空白表与治理清单，再逐组说明填写口径、必填取舍，并用一个阶段对应两个迭代的示例演示如何对齐填写。
要点总览（TL;DR）
- 映射表以“阶段—迭代”为行单位，至少包含四组字段：标识类、门禁类、迭代产出类、衔接类。
- 必填字段是门禁判定与产出追溯的最小集合：阶段与迭代标识、起止时间、阶段交付物、通过标准、责任人、迭代目标、可交付增量、验收结论、映射关系、状态。
- “映射关系”字段是阶段门禁与迭代产出对齐的关键，写明该迭代支撑阶段交付物的哪一部分，阶段评审时可直接顺着字段找到支撑产出。
- 维护节奏跟随两类评审：迭代评审后回填验收结论与状态，阶段门禁评审前核对门禁字段，评审后更新状态与日期并保存版本。
- 字段裁剪先保留必填项运行一个阶段，再按评审中实际被问到的问题补充选填字段，模板、说明、示例三处口径保持同步。
可复制空白映射表与治理清单
下面两张表可直接复制到文档或表格工具中填写。映射表以“阶段—迭代”为行单位：一个阶段对应几个迭代，就填几行，阶段级字段在每行重复填写，便于筛选和排序。治理清单按阶段或按项目填写，记录评审节奏与变更控制要求。
阶段与迭代映射表（空白表头）
| 阶段编号 | 阶段名称 | 迭代编号 | 迭代名称 | 起止时间 | 阶段交付物 | 评审方式 | 通过标准 | 责任人 | 迭代目标 | 需求范围 | 可交付增量 | 验收结论 | 映射关系 | 依赖与前置 | 风险与变更 | 状态 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
治理清单（空白表头）
| 治理项 | 适用阶段/迭代 | 角色与职责 | 评审节奏 | 变更控制要求 | 归档要求 | 备注 |
|---|---|---|---|---|---|---|
表格使用方式
- 先按阶段拆行：每个阶段先确定阶段编号与名称，再列出该阶段内的迭代，一个迭代占一行。
- 阶段级字段（阶段交付物、评审方式、通过标准、责任人）在同一阶段的多行中保持一致，避免同一阶段出现两套门禁口径。
- 迭代级字段（迭代目标、需求范围、可交付增量、验收结论）按迭代实际内容填写，验收结论在迭代评审后回填。
- 治理清单与映射表配套使用：映射表回答“填什么”，治理清单回答“谁来评、多久评一次、变更怎么走”。
映射表字段说明：每组字段回答什么问题
四组字段分别对应四个问题：这是哪个阶段和哪个迭代、阶段门禁凭什么通过、迭代实际交付了什么、阶段与迭代之间如何衔接。填写时按组理解口径，能减少同一字段在不同阶段被填成不同含义的情况。
| 字段组 | 字段名 | 含义 | 填写口径 |
|---|---|---|---|
| 标识类 | 阶段编号 | 阶段在项目计划中的顺序标识 | 用统一编码，如 P1、P2，与项目计划中的阶段划分一致 |
| 阶段名称 | 阶段的任务名称 | 使用团队通用叫法，如“需求与方案”“开发与验证”“上线与移交” | |
| 迭代编号 | 迭代的唯一标识 | 如 S1、S2，同一阶段内连续编号，跨阶段不重复 | |
| 迭代名称 | 迭代的主题或目标简称 | 用一句话概括本迭代重点，便于在评审会上快速识别 | |
| 起止时间 | 迭代的计划开始与结束日期 | 填写计划日期，实际日期可在验收结论或备注中补充 | |
| 门禁类 | 阶段交付物 | 阶段结束时必须产出的文档或成果 | 列具体交付物名称，如需求规格、设计说明、测试报告 |
| 评审方式 | 门禁的评审组织形式 | 如阶段评审会、文档会签、演示验收，写明形式即可 | |
| 通过标准 | 判定门禁通过的条件 | 写成可核验的条件，如“关键缺陷清零”“评审意见闭环” | |
| 责任人 | 对门禁结果负责的人 | 填角色加姓名，如“项目经理 张某”，避免只写部门 | |
| 迭代产出类 | 迭代目标 | 本迭代要达成的结果 | 用结果描述，避免只写“完成开发”这类过程表述 |
| 需求范围 | 本迭代纳入的需求条目 | 列需求编号或名称，范围变更时同步更新 | |
| 可交付增量 | 迭代结束时可供验收的成果 | 写可演示、可测试的增量，如“订单查询功能可用版本” | |
| 验收结论 | 迭代评审后的判定结果 | 填通过、有条件通过或不通过，有条件通过需写明遗留项 | |
| 衔接类 | 映射关系 | 阶段与迭代的对应方式 | 说明该迭代支撑阶段的哪部分门禁，如“支撑阶段交付物中的测试报告” |
| 依赖与前置 | 迭代之间的先后依赖 | 写前置迭代编号或外部依赖，如“依赖 S1 的接口定义” | |
| 风险与变更 | 影响门禁或迭代交付的风险及变更记录 | 记录风险描述、变更内容和影响范围，关联变更单号更佳 | |
| 状态 | 当前填写与执行状态 | 用统一状态词，如未开始、进行中、待评审、已通过 |
门禁条件与迭代产出的对应关系，靠“映射关系”字段显式写出。例如阶段交付物是测试报告，映射关系就写明哪几个迭代的增量进入测试、由哪个迭代产出报告初稿。这样阶段评审时，评审人可以先看门禁条件，再顺着映射关系找到支撑它的迭代产出，不需要在多个文档间来回查找。
必填与选填：哪些字段不能空
必填字段的判断依据是：缺少它，阶段门禁无法判定，或迭代产出无法追溯。其余字段按项目规模、评审严格程度和团队习惯选填。
| 类别 | 字段 | 取舍依据 |
|---|---|---|
| 必填 | 阶段编号、阶段名称、迭代编号、迭代名称 | 没有标识就无法定位行，也无法在评审中引用 |
| 必填 | 起止时间 | 门禁评审需要判断迭代是否按计划完成 |
| 必填 | 阶段交付物、通过标准、责任人 | 三者构成门禁判定的最小集合 |
| 必填 | 迭代目标、可交付增量、验收结论 | 用于证明迭代对阶段的支撑，验收结论在评审后必须回填 |
| 必填 | 映射关系、状态 | 映射关系是阶段与迭代对齐的核心，状态决定表格是否可用于跟踪 |
| 选填 | 评审方式 | 小团队可默认阶段评审会，规模扩大或涉及多部门时再填 |
| 选填 | 需求范围 | 需求条目已在需求池管理时可只填汇总口径 |
| 选填 | 依赖与前置 | 迭代间依赖简单时可省略，存在跨团队依赖时建议填写 |
| 选填 | 风险与变更 | 无变更时可留空，发生变更后必须补填 |
| 选填 | 更新日期 | 表格纳入版本管理后可省略，靠版本记录追溯 |
按项目规模调整时，可以遵循两条原则：一是阶段数量多、跨部门评审多的项目，保留全部字段并增加评审方式与依赖字段的填写要求；二是小规模、单团队的项目，可先保留必填字段运行一到两个阶段，再根据评审中实际被问到的问题补充选填字段。裁剪字段时不要删掉“映射关系”和“验收结论”，这两个字段一旦缺失，表格就退化为阶段计划和迭代计划的简单拼接。
填写示例：一个阶段对应两个迭代
以下示例为演示情景，用于说明填写方式，不代表任何真实项目数据。
示例背景设定
某项目分为“需求与方案”“开发与验证”“上线与移交”三个阶段。“开发与验证”阶段包含两个迭代：S1 完成核心模块开发，S2 完成集成测试与缺陷修复。阶段门禁要求测试报告通过评审、关键缺陷清零。
映射表填写内容
| 阶段编号 | 阶段名称 | 迭代编号 | 迭代名称 | 起止时间 | 阶段交付物 | 评审方式 | 通过标准 | 责任人 | 迭代目标 | 需求范围 | 可交付增量 | 验收结论 | 映射关系 | 依赖与前置 | 风险与变更 | 状态 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| P2 | 开发与验证 | S1 | 核心模块开发 | 3月1日—3月14日 | 测试报告、集成版本 | 阶段评审会 | 测试报告通过评审，关键缺陷清零 | 项目经理 张某 | 核心模块可联调 | REQ-01 至 REQ-08 | 核心模块联调版本 | 通过 | 支撑测试报告中的功能测试部分 | 依赖 P1 的需求规格 | 接口定义延期两天，已调整联调计划 | 已通过 | 3月15日 |
| P2 | 开发与验证 | S2 | 集成测试与修复 | 3月15日—3月28日 | 测试报告、集成版本 | 阶段评审会 | 测试报告通过评审，关键缺陷清零 | 项目经理 张某 | 集成测试完成，缺陷收敛 | REQ-01 至 REQ-10 | 可验收的集成版本与测试报告 | 有条件通过，遗留 2 个一般缺陷 | 支撑测试报告定稿与门禁评审 | 依赖 S1 的联调版本 | 新增 REQ-10，已走变更评审 | 待评审 | 3月29日 |
治理清单填写内容
| 治理项 | 适用阶段/迭代 | 角色与职责 | 评审节奏 | 变更控制要求 | 归档要求 | 备注 |
|---|---|---|---|---|---|---|
| 阶段门禁评审 | P2 | 项目经理组织，技术负责人与测试负责人参与 | 阶段结束前一周内召开 | 门禁条件变更需项目经理与技术负责人共同确认 | 评审纪要与测试报告归档至项目文档库 | 遗留缺陷需在纪要中列明处理计划 |
| 迭代评审 | S1、S2 | 迭代负责人组织，团队成员参与 | 每个迭代结束时 | 需求范围变更走变更评审，更新映射表需求范围字段 | 迭代验收结论回填映射表 | S2 有条件通过需跟踪遗留缺陷 |
示例与字段说明的一致性
示例中阶段级字段在 S1、S2 两行保持一致，门禁条件只写一次口径；迭代级字段按各自迭代填写，验收结论在评审后回填；映射关系字段分别说明两个迭代对阶段交付物的支撑部分，与字段说明中的填写口径对应。治理清单中的评审节奏与映射表状态字段联动：S2 状态为“待评审”，对应治理清单中迭代评审尚未完成。
调整与维护方法：让映射表随项目推进保持可用
映射表在项目启动时建立，在阶段评审和迭代评审两个节点更新。维护的重点是让字段口径稳定、变更可追溯，避免表格填完一次就搁置。
字段裁剪与扩展方法
- 裁剪：先保留必填字段运行一个阶段，评审后统计哪些字段从未被使用，再决定是否删除。
- 扩展：出现跨团队依赖时增加“依赖与前置”的填写要求；变更频繁时把“风险与变更”拆成风险描述与变更单号两列。
- 扩展字段时同步更新字段说明表，保证模板、说明、示例三处口径一致。
更新时点与责任人
- 项目启动时由项目经理建立表格并填写阶段与迭代标识。
- 每个迭代评审后由迭代负责人回填验收结论与状态。
- 阶段门禁评审前由项目经理核对门禁字段，评审后更新状态与更新日期。
- 发生需求或范围变更时，由变更提出人补充风险与变更字段，项目经理确认映射关系是否受影响。
版本与归档要求
- 映射表纳入项目文档库统一管理，每次阶段评审后保存一个版本。
- 归档内容包括映射表、治理清单和对应评审纪要，三者放在同一目录便于追溯。
- 项目结项时保留最终版本，作为后续类似项目的参考模板。
与阶段评审、迭代评审的衔接
阶段评审以映射表的门禁字段为检查清单，逐项核对交付物、通过标准和责任人；迭代评审以迭代产出字段为输入，回填验收结论。两类评审共用一张表，评审结论直接写入状态字段，减少重复记录。若团队使用 ONES 承载项目计划，可在项目计划中按阶段分解工作、用里程碑标记门禁节点，并把迭代与研发任务关联到项目计划中，让映射表中的阶段、迭代和状态有对应的计划与任务记录可查；项目模板可选择敏捷、瀑布或通用任务协同类型，按团队实际流程起步。具体字段配置与模板形态以实际使用版本为准。
常见问题
一个阶段对应多个迭代时，阶段级字段要不要每行重复填写？
建议每行重复填写。阶段编号、阶段名称、阶段交付物、评审方式、通过标准、责任人属于阶段级字段，在映射表中按行重复，可以让表格在筛选、排序和导出时保持完整，避免某一行脱离上下文后无法判断属于哪个阶段。重复填写时保持同一阶段多行内容一致，门禁口径只维护一套。若担心重复维护出错，可在表格工具中用公式或引用让后续行自动取首行值，但对外呈现仍保留完整字段。
迭代验收结论为“有条件通过”时，映射表里还需要记录什么？
除在验收结论字段写明“有条件通过”，还需在“风险与变更”字段记录遗留项的内容、数量和处理计划，并在治理清单的备注中标注跟踪责任人。遗留项关闭后回填关闭日期，状态字段从“待评审”或“进行中”更新为“已通过”。如果遗留项影响阶段门禁的通过标准，需在阶段评审前确认是否构成门禁例外，并按治理清单中的变更控制要求走确认流程。
项目进行中新增一个迭代，映射表怎么改才不影响已有记录？
在对应阶段下新增一行，沿用该阶段的阶段级字段，填写新迭代的编号、名称、起止时间与迭代目标，并在“依赖与前置”中写明与前后迭代的关系。已有行保持不变，仅在“映射关系”中补充新迭代对阶段交付物的支撑部分。若新增迭代改变了阶段门禁的通过标准或交付物范围，需同步更新阶段级字段的所有行，并在治理清单中记录这次调整的确认人与日期。
小团队字段裁到最少，哪些字段仍然建议保留？
即使团队规模小、评审流程简化，也建议保留阶段与迭代标识、起止时间、阶段交付物、通过标准、责任人、迭代目标、可交付增量、验收结论、映射关系和状态。这些字段构成门禁判定与产出追溯的最小集合。评审方式、需求范围、依赖与前置、风险与变更、更新日期可以按实际情况选填。裁剪时优先保留“映射关系”和“验收结论”，缺少这两项，表格就难以说明迭代如何支撑阶段门禁。
映射表和治理清单能否合并成一张表？
可以合并，但需要区分填写粒度。映射表按“阶段—迭代”逐行填写，治理清单按治理项或阶段填写，两者行数并不一一对应。合并时建议在映射表右侧增加治理相关列，仅在阶段首行填写评审节奏、变更控制与归档要求，其余行留空或标注“同上”。合并后表格列数较多，适合在表格工具中使用分组列或冻结列；若团队在评审会上需要分别查看，仍建议保留两张表并保持字段引用一致。
