版本规划回答“这个版本交付什么、为什么现在做”，迭代计划回答“接下来一到四周由谁先做哪几件事”。两者衔接的核心是一条可追溯的分解链：版本目标拆成范围条目，范围条目进入迭代待办，迭代产出回填版本进度，再用固定的评审节奏和变更规则控制范围进出。本文按职责边界、六维度对照、分解步骤、变更规则和场景选择展开，适用于需要把版本承诺落到迭代执行的研发团队。
要点总览（TL;DR）
- 版本规划确定这个版本交付什么、为什么现在做；迭代计划确定接下来一到四周由谁先做哪几件事，两者通过“版本目标—范围条目—迭代待办—进度回填”的分解链衔接。
- 六个衔接维度中，范围粒度和进度回填最容易出问题：范围条目要拆到可估算、可分工，迭代结束要把完成状态回填到版本条目。
- 范围变动走明确路径：新增、移出、降级由版本负责人审批，迭代内插单按影响程度上报，获批后一次完成版本清单、迭代待办和通知的同步。
- 评审分两层：版本评审看承诺与整体进度，迭代评审看执行与质量；两层检查项不同，不能互相替代。
- 落地按三步走：先统一范围条目写法与验收标准，再建立迭代结束回填版本进度的固定动作，最后引入变更规则和两层评审。
两种计划的职责边界与衔接断点
版本规划与迭代计划处在不同决策层级。版本规划面向外部承诺和阶段性目标，确定一个版本要解决哪些问题、覆盖哪些用户场景、在什么时间窗口交付；迭代计划面向团队执行，把近期可完成的工作分配到具体的人和周期。两者边界清晰，衔接才稳定。
版本规划的典型输出包括版本目标、范围清单、优先级和时间窗口。版本目标应说明该版本要达成的业务结果或用户价值；范围清单列出纳入版本的需求或功能条目；优先级标明哪些必须交付、哪些可以延后；时间窗口给出计划发布的时间段和关键里程碑。迭代计划的典型输出包括迭代目标、待办条目、责任人和验收口径，其中验收口径要能让团队在迭代结束时判断工作是否完成。
常见断点有三类。第一，版本范围没有拆到可执行粒度，范围条目停留在“支持某能力”这类描述，迭代计划会上无法估算和分工。第二，迭代内临时插单频繁，版本承诺被不断稀释，团队对版本目标失去感知。第三，版本进度靠口头同步，版本负责人看到的完成情况与迭代实际状态不一致，导致对外沟通失真。
| 对照项 | 版本规划 | 迭代计划 |
|---|---|---|
| 回答的问题 | 这个版本交付什么、为什么现在做 | 接下来一到四周由谁先做哪几件事 |
| 输出物 | 版本目标、范围清单、优先级、时间窗口 | 迭代目标、待办条目、责任人、验收口径 |
| 时间跨度 | 通常覆盖一个版本周期，可跨多个迭代 | 通常为一到四周，按固定节奏滚动 |
| 负责人 | 版本负责人或产品负责人牵头，跨角色共同确认 | 迭代负责人或团队负责人牵头，团队共同承诺 |
| 变更权限 | 范围进出需版本层评审确认 | 迭代内调整由团队按规则处理，影响版本承诺时上报 |
同口径对照：版本规划与迭代计划的六个衔接维度
把两种计划放在同一组维度下对照，可以看清差异出现在哪里、接口应该设在哪里。以下六个维度贯穿后文的分解步骤和变更规则。
| 维度 | 版本规划的处理方式 | 迭代计划的处理方式 | 接口要求 |
|---|---|---|---|
| 时间跨度与滚动方式 | 按版本周期设定时间窗口，随版本评审滚动更新 | 按固定迭代长度滚动，每个迭代重新确认待办 | 版本时间窗口要能容纳整数个迭代，迭代边界与版本里程碑对齐 |
| 范围粒度与拆分层级 | 范围条目到可验收的功能或需求层级 | 待办条目到可估算、可分工的任务或子任务层级 | 每个范围条目在进入迭代前完成一次拆解，拆解结果可回溯到版本条目 |
| 优先级来源与排序依据 | 依据版本目标、用户价值和业务窗口排序 | 依据依赖关系、团队容量和近期风险排序 | 迭代排序不得改变版本优先级结论，只能调整同一优先级内的先后 |
| 责任角色与决策权限 | 版本负责人对范围进出做最终判断 | 团队对迭代内执行顺序和分工负责 | 明确谁可以提出范围变更、谁批准、谁同步版本视图 |
| 变更触发与审批路径 | 新增、移出、降级均需版本层评审 | 迭代内插单按影响程度分级处理 | 影响版本承诺的变更必须回到版本评审，不能只在迭代内消化 |
| 进度可见性与回填方式 | 按范围条目统计完成情况，形成版本进度 | 按待办条目和工时统计迭代进度 | 迭代结束后把完成状态回填到对应版本条目，定期复核剩余范围 |
六个维度中，范围粒度和进度回填最容易出问题。范围粒度决定迭代计划会能否开出可执行的待办；进度回填决定版本负责人能否在不打断团队的情况下掌握真实进展。把这两点作为接口设计的重点，其余维度围绕它们配套即可。
从版本目标拆到迭代待办的操作步骤
分解链可以按四步执行，每一步都有明确输入和产出，完成后进入下一步。
第一步：把版本目标写成可验收的版本范围条目。输入是版本目标和业务背景，动作是把目标转化为若干条范围条目，每条写明要解决的问题、验收标准和优先级。产出是一份范围清单，条目数量控制在版本周期内可管理的范围内。验收标准要具体到可以判断“完成”或“未完成”，避免使用“优化体验”这类无法验收的表述。
第二步：按依赖与价值把范围条目排入迭代序列。输入是范围清单和迭代日历，动作是识别条目之间的依赖关系，结合价值高低确定先后顺序，把条目分配到各个迭代。产出是版本范围与迭代的对应关系。排序时先处理有外部依赖或前置条件的条目，避免后期因依赖未就绪而阻塞。
第三步：在迭代计划会上确认容量、责任人与验收口径。输入是当前迭代对应的范围条目，动作是团队评估容量、拆分任务、指定责任人，并对验收口径达成一致。产出是迭代待办和迭代目标。这一步的关键是团队共同承诺，而不是由版本负责人单方面派发。在 ONES 的敏捷研发方案中，产品负责人可以按需求优先级把待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审需求；对需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续跟踪。对于功能复杂的需求，还可以用子工作项拆解并关联研发和测试任务，把需求、研发、测试环节串联起来。
第四步：迭代结束后把完成情况回填版本视图并复核剩余范围。输入是迭代实际完成情况，动作是逐条更新对应版本条目的状态，统计版本完成比例，复核剩余范围是否仍能在时间窗口内完成。产出是更新后的版本进度和调整建议。ONES Project 提供任务工时统计和任务持续时间估算，并通过看板、燃尽图等工具呈现当前进度，团队可以据此核对迭代产出；版本层级的进度汇总则需要在版本评审中按范围条目逐项确认。
| 步骤 | 输入 | 动作 | 产出 |
|---|---|---|---|
| 第一步 | 版本目标、业务背景 | 写成可验收的范围条目，标注优先级 | 版本范围清单 |
| 第二步 | 范围清单、迭代日历 | 识别依赖，按价值排序并分配到迭代 | 范围与迭代对应关系 |
| 第三步 | 当前迭代范围条目 | 评估容量、拆分任务、确认验收口径 | 迭代待办与迭代目标 |
| 第四步 | 迭代实际完成情况 | 回填状态、统计完成比例、复核剩余范围 | 版本进度与调整建议 |
衔接中的变更规则与评审节奏
范围变动是两种计划冲突的主要来源。处理原则是：变更可以发生，但必须走明确路径，并同步更新版本视图和迭代待办。
| 变更类型 | 触发条件 | 审批人 | 对版本与迭代的影响 |
|---|---|---|---|
| 新增范围 | 出现必须在本版本交付的新需求，或外部承诺变化 | 版本负责人，必要时联合业务方 | 评估是否替换同优先级条目；未获批准不进入迭代 |
| 移出范围 | 条目价值下降、依赖无法满足或容量不足 | 版本负责人 | 从版本清单移除并记录原因，释放的容量用于剩余条目 |
| 降级 | 条目仍需要但可延后到后续版本 | 版本负责人与产品负责人 | 调整优先级和时间窗口，迭代待办同步移除或后移 |
| 迭代内插单 | 生产问题、紧急缺陷或临时任务 | 迭代负责人按预设规则处理，影响版本承诺时上报版本负责人 | 占用迭代容量，需说明被挤出的条目及其对版本的影响 |
评审节奏建议分两层。版本评审按版本周期或固定节点召开，检查版本目标是否仍成立、范围完成情况、剩余风险和时间窗口是否可行。迭代评审在每个迭代结束时召开，检查迭代目标达成情况、待办完成质量和验收口径执行情况。两层评审的检查项不同，版本评审看承诺与整体进度，迭代评审看执行与质量。
范围变更获批后，同步动作要一次完成：更新版本范围清单和优先级，调整对应迭代的待办条目，通知受影响的研发、测试和业务方，并在下一次评审中复核调整后的计划是否仍然可行。同步动作拖延，版本视图和迭代待办就会脱节，后续进度判断失去依据。
适配场景与选择建议
不同团队的需求波动和交付节奏不同，衔接方式应有所侧重。下表按场景给出建议。
| 场景 | 应强化的环节 | 具体做法 |
|---|---|---|
| 需求波动大、版本周期长 | 变更规则与版本评审 | 设置明确的范围冻结节点；新增需求走版本评审，用替换而非叠加的方式控制总量；版本评审频率不低于每月一次 |
| 迭代短、交付频繁 | 分解粒度与进度回填 | 范围条目拆到可在一个迭代内完成的粒度；每次迭代结束当天完成版本状态回填，避免积压 |
| 跨团队协作 | 接口与同步机制 | 明确各团队在版本范围中的责任边界；约定统一的条目状态口径和同步时间点；版本评审邀请各团队代表参加 |
落地顺序建议分三步。第一步，先统一范围条目的写法和验收标准，让版本规划和迭代计划使用同一套语言。第二步，建立迭代结束回填版本进度的固定动作，先保证进度可见，再谈优化。第三步，引入变更规则和两层评审，把范围进出纳入受控流程。每一步都可以用一个版本周期验证：第一步看迭代计划会是否能直接开出待办，第二步看版本进度与实际完成是否一致，第三步看范围变更是否都有记录和审批。
验证方式以可观察结果为准：版本评审时能否说清每个范围条目的状态和剩余风险，迭代计划会上能否不再反复讨论版本目标，变更发生后版本视图与迭代待办是否在同一个评审周期内对齐。这三点成立，说明衔接机制已经运转起来。
常见问题
版本规划已经定好，迭代计划会上团队说容量不够，应该先砍范围还是先延时间？
先判断缺口来自哪里。如果范围条目本身拆得不够细、估算口径不一致，先补拆解和估算，再谈取舍；如果容量确实不足，优先在版本内调整：把同优先级中价值较低的条目移出或降级到后续版本，保持版本时间窗口不变。只有剩余范围属于必须交付的核心承诺、且无法通过替换消化时，才考虑调整时间窗口，并由版本负责人对外沟通。
无论哪种处理，都要记录调整原因，并在下一次版本评审中复核调整后的计划是否仍然可行。
迭代进行到一半，业务方要求插入一个紧急需求，版本负责人和迭代负责人分别该做什么？
迭代负责人先按预设规则评估影响：插入会占用多少容量、哪些已排条目需要后移、是否影响本迭代目标。如果影响仅限于迭代内部、不改变版本承诺，由迭代负责人处理并记录。如果会挤出版本范围内的条目或影响版本时间窗口，必须上报版本负责人，由版本负责人判断是否替换同优先级条目或调整范围。
获批后，同步动作一次完成：更新版本范围清单、调整迭代待办、通知受影响的研发测试和业务方。只在迭代内消化、不回填版本视图，是版本进度失真的常见原因。
版本周期长、迭代短，版本评审和迭代评审的节奏怎么安排才不重复？
两层评审的检查项不同，节奏可以错开。迭代评审在每个迭代结束时召开，检查迭代目标达成情况、待办完成质量和验收口径执行情况，输出是迭代产出和遗留问题。版本评审按版本周期或固定节点召开，检查版本目标是否仍成立、范围完成情况、剩余风险和时间窗口是否可行，输入来自各迭代回填的进度。
版本周期较长时，可以在版本中期增加一次轻量检查，只看范围完成比例和关键依赖，不重复迭代评审的执行细节。这样版本负责人能及时发现问题，团队也不必为同一批工作开两次内容相同的会。
跨团队协作时，版本范围条目由谁维护、状态口径怎么统一？
版本范围清单由版本负责人统一维护，各团队负责自己承接条目的拆解和执行。状态口径要在版本启动时约定，例如“未开始、进行中、已完成、已移出”各自的判定条件，避免一个团队认为完成、另一个团队认为仍在验证。
同步时间点也要固定：各团队在迭代结束后按约定时间回填状态，版本负责人汇总后在版本评审上核对。跨团队条目存在依赖时，在范围清单中标注前置条目和交付方，依赖未就绪的条目提前在版本评审中暴露，而不是等到迭代计划会才发现。
团队目前版本规划和迭代计划各做各的，从哪一步开始改最有效？
从统一范围条目的写法和验收标准开始。这一步成本最低，收益最直接：迭代计划会能否直接开出待办，取决于版本范围条目是否拆到了可估算、可分工的粒度。写法统一后，再建立迭代结束回填版本进度的固定动作，让版本负责人能看到真实进展。
前两步稳定运行一个版本周期后，再引入变更规则和两层评审。验证方式看可观察结果：迭代计划会是否不再反复讨论版本目标，版本进度与实际完成是否一致，范围变更是否都有记录和审批。
