迭代计划要解决两个问题：本次迭代承诺做哪些事，以及如何在周期内跟踪到交付。做法是先按历史数据和成员可用时间确定容量，再从已排序待办中选取范围，拆成带负责人、估算和验收标准的工作项，排定评审与发布节点，用每日同步处理偏差。下面按步骤、角色分工、填写示例和完成检查四部分展开，并在待办排序与工作项跟踪环节说明ONES的承载方式。
要点总览（TL;DR）
- 迭代计划先定容量再定范围：用最近几个迭代的实际完成量折算本次可承诺容量，扣除假期、培训和值班占用，再按优先级从已排序待办中选取承诺清单。
- 每个工作项要有负责人、估算和可核验的验收标准，拆分粒度以两到三天能完成并自测为宜，跨团队依赖要显式标注并确认对方交付时间。
- 产品负责人确认范围与优先级，迭代负责人测算容量、排定日历并跟踪偏差，开发与测试成员负责拆分、估算和完成定义。
- 迭代中期就要处理偏差：剩余工作量超出剩余时间时及时缩减范围或调整优先级并记录决定，未完成项在迭代结束时重新评估，不默认自动结转。
- 计划完成后用范围与容量匹配、工作项完整性、依赖标注、未完成项规则、评审复盘时点五项清单核对，迭代中期可再复查一次。
迭代计划的核心答案与操作步骤
迭代计划的产出是一份团队共同认可的承诺清单和一张迭代日历。承诺清单说明本次做哪些工作项、谁负责、怎样算完成；迭代日历说明交付、评审和发布分别发生在哪一天。以下五步按顺序执行，每一步都有明确的输入、动作、输出和完成标志，可以对照检查是否做到位。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定周期与容量 | 历史交付数据、成员可用工时、假期与会议占用 | 固定迭代长度（常见为1–2周），用近几个迭代的实际完成量折算本次可承诺容量，预留处理缺陷和临时支持的时间 | 本次可承诺容量，按人天或故事点表示 | 容量数字有历史数据支撑，团队对预留比例达成一致 |
| 2. 选取承诺范围 | 已排序的待办清单、条目间依赖关系 | 按优先级从高到低选取，累计估算不超过容量；对存在外部依赖的条目确认对方交付时间 | 迭代承诺清单 | 清单内条目估算合计在容量之内，依赖方已确认时间 |
| 3. 拆分工作项并设定验收标准 | 承诺清单中的每个条目 | 拆成可在数天内完成的工作项，指定负责人，补充估算和验收标准，写明完成定义 | 带负责人、估算、验收标准的工作项 | 每个工作项都有负责人和可核验的验收标准，无孤儿任务 |
| 4. 排定交付、评审与发布节点 | 工作项清单、团队日历 | 确定开发完成、测试通过、迭代评审、发布的时间点，倒推关键节点 | 迭代日历 | 评审和发布时间已进入团队日历，相关方已知悉 |
| 5. 每日同步与偏差处理 | 工作项状态、剩余工作量 | 每日用短会同步进展，更新剩余工作量，记录阻塞和风险，必要时调整范围 | 更新后的剩余工作量与风险记录 | 剩余工作量每日更新，风险有记录且有跟进人 |
第1步的容量测算容易流于形式。有效做法是取最近三个迭代的实际完成量作为基准，再扣除本次迭代已知的假期、培训和值班占用，得到一个偏保守的数字。容量偏保守，承诺兑现率才有保障；容量虚高，迭代中后期只能靠加班或砍范围补救。
第2步选范围时，优先级清单本身的质量决定计划质量。条目描述含糊、验收标准缺失的待办，即使优先级高也不宜直接进入承诺，应先补充信息或拆小。依赖关系要在这一步显式标注，尤其是需要其他团队提供接口、数据或环境的条目，对方交付时间未确认前，不宜按理想时间排入。
第3步拆分的粒度以“一个负责人能在两到三天内完成并自测”为宜。工作项过大，进度难以判断；过小，管理成本上升。验收标准写成可核验的句子，例如“提交订单后库存扣减正确，异常时给出明确提示”，比“完成订单功能”更容易在评审时判断。
第5步的偏差处理要有规则。剩余工作量明显超出剩余时间时，团队应在迭代中期就决定缩减范围或调整优先级，并把决定记录在迭代计划中。等到迭代结束才承认做不完，会让评审失去意义。
在工具承载上，ONES 可以把待办排序、工作项拆分、状态流转和迭代评审放在同一套项目数据里：产品负责人在需求侧维护优先级，迭代负责人在迭代视图中查看工作项和剩余工作量，每日同步时直接更新状态，评审时按迭代汇总完成情况。这样计划、执行和复盘引用的是同一份数据，减少表格与系统之间的反复搬运。
迭代计划中的角色分工与交付物
迭代计划涉及三类角色：产品负责人、迭代负责人（或项目经理）、开发与测试成员。分工的核心是每一步都有明确的责任人和可交接的产物，避免出现“计划有人定、执行无人跟”的情况。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 产品负责人 | 维护待办优先级，确认本次迭代范围，解释需求意图，参与验收 | 已排序的待办清单、迭代范围确认结论 | 迭代计划会前完成排序，计划会上确认范围 |
| 迭代负责人/项目经理 | 测算容量，组织计划会，排定迭代日历，跟踪剩余工作量与风险，主持评审与复盘 | 容量测算结果、迭代日历、风险记录、评审与复盘纪要 | 计划会前给出容量，迭代中每日更新，迭代结束组织评审 |
| 开发与测试成员 | 拆分工作项，给出估算，编写验收标准与完成定义，执行自测与联调 | 带负责人和估算的工作项、验收标准、测试结论 | 计划会上完成拆分与估算，迭代中按节点提交 |
产品负责人的关键动作是“确认范围”而非“宣布范围”。计划会上，产品负责人说明每个条目的业务价值和优先级依据，团队据此判断能否在容量内完成；出现分歧时，由产品负责人决定取舍，并把决定写进承诺清单。
迭代负责人的工作重心在容量测算和偏差跟踪。容量测算需要历史数据，偏差跟踪需要每日更新，这两件事都不适合在迭代末期补做。迭代负责人还负责在范围需要调整时组织决策，确保调整有记录、相关方知悉。
开发与测试成员的交付物是计划可执行的基础。估算由实际执行者给出，验收标准由提出方与执行方共同确认，完成定义（例如代码评审通过、自测通过、文档更新）在计划阶段就写清楚，评审时按同一标准判断，减少“做完了但不算完成”的争议。
一个迭代计划的填写示例
以下示例为演示情景，团队和业务背景为虚构，用于说明填写方式。
示例背景：某团队负责一个内部订单管理系统的迭代开发，迭代周期为两周，共5名成员。根据最近三个迭代的实际完成量，本次可承诺容量约为40人天，扣除一名成员两天培训后按38人天安排。
待办选取：待办清单中优先级最高的三条为“订单导出支持按时间筛选”“订单状态变更增加操作日志”“修复批量导入偶发失败”。前两条估算合计约20人天，第三条约8人天，剩余容量用于缺陷处理和技术支持。三条均进入本次承诺清单，其中“批量导入偶发失败”依赖运维团队提供日志权限，已确认对方在迭代第3天前开通。
拆分与验收标准：“订单导出支持按时间筛选”拆为三个工作项：导出接口增加时间参数（负责人甲，3人天）、前端筛选控件与校验（负责人乙，2人天）、联调与回归测试（负责人丙，2人天）。验收标准写为“选择起止时间后导出结果只包含该区间订单，起止时间颠倒时给出提示，空结果时导出空表并提示无数据”。“订单状态变更增加操作日志”拆为日志写入与查询页面两个工作项，验收标准写为“每次状态变更记录操作人、时间和变更前后状态，查询页面可按订单号检索”。
节点安排：第1天完成计划会与拆分确认，第7天完成开发自测，第9天完成联调与测试，第10天迭代评审，第10天下午发布。
未完成项处理：假设迭代结束时“批量导入偶发失败”因日志权限延迟未能定位原因。处理方式是：在评审会上说明未完成原因，由产品负责人重新评估优先级，团队判断是否需要重新拆分（例如先增加导入失败的重试机制作为临时方案），再决定是否放回待办并进入下一迭代的候选范围。未完成项不默认自动结转，避免待办清单中堆积长期未处理条目。
迭代计划的完成检查
计划制定完成后，用以下清单逐项核对。每一项都能给出明确答案，计划才具备可执行性；存在“待定”“回头再说”的条目，应在计划会上解决或明确处理时限。
- 范围与容量是否匹配：承诺清单的估算合计是否在容量之内，是否预留了缺陷处理时间，容量数字是否有历史数据支撑。
- 每个工作项是否完整：是否都有负责人、估算和可核验的验收标准，完成定义是否写明，是否存在无人负责的条目。
- 依赖与外部交付是否标注：跨团队依赖是否列出对方交付内容和时间，未确认的依赖是否有备选方案或调整范围的预案。
- 未完成工作的处理规则是否明确：迭代结束时未完成项由谁评估、按什么标准决定放回待办还是重新拆分，是否明确不默认自动结转。
- 评审与复盘时点是否排定：迭代评审、发布和复盘的时间是否进入团队日历，相关方是否知悉，评审的输入材料由谁准备。
这份清单也适合在迭代中期复查一次。范围、依赖或容量发生明显变化时，及时调整计划并记录调整原因，比在评审会上解释偏差更有价值。迭代计划的价值在于让团队对“这次做什么、做到什么程度”形成共同预期，并在执行过程中用同一份数据判断进展。
常见问题
迭代周期应该定多长，团队第一次做迭代计划怎么选？
常见做法是固定为1–2周，关键是周期稳定，便于用历史完成量测算容量。第一次做迭代计划时缺少历史数据，可以先按成员可用工时给出保守估算，运行两三个迭代后用实际完成量校准。周期过短会让计划会、评审等协调动作占比上升，周期过长则偏差暴露得晚，团队可根据交付节奏和需求变化频率选择，并在几个迭代内保持稳定再评估是否调整。
迭代进行到一半发现做不完，应该怎么调整？
在迭代中期就处理，不要等到评审会。做法是对比剩余工作量和剩余时间，由迭代负责人组织团队与产品负责人一起决定：缩减本次范围、调整条目优先级，或对某个工作项重新拆分。决定要记录在迭代计划中，并告知相关方。提前调整能让评审聚焦在已承诺范围的完成情况，也能避免把问题积压到下一个迭代。
未完成的工作项可以直接带到下一个迭代吗？
不建议默认自动结转。迭代结束时，未完成项应由产品负责人重新评估优先级，团队判断是否需要重新拆分或调整方案，再决定是否放回待办、进入下一迭代的候选范围。这样做的目的是避免待办清单里堆积长期未处理的条目，也让每次承诺的范围经过重新判断。若条目仍然重要，重新评估后进入下一迭代同样可行，区别在于它经过了显式决策。
需求优先级经常变，迭代计划还有意义吗？
有意义，但需要约定变更规则。迭代计划承诺的是本次周期内的范围，周期内新增的高优先级需求应走变更流程：由产品负责人说明理由，团队评估对当前承诺的影响，再决定替换哪一项或顺延到下一迭代。把变更决定记录下来，可以避免范围在无人察觉的情况下膨胀。优先级变化频繁的团队，可以把迭代周期适当缩短，让计划与变化的节奏更匹配。
用工具管理迭代计划时，哪些信息应该放在系统里？
建议把承诺清单、工作项负责人、估算、验收标准、状态和剩余工作量放在同一套项目数据中，让计划、每日同步和评审引用同一份记录。以ONES为例，产品负责人在需求侧维护优先级，迭代负责人在迭代视图中查看工作项和剩余工作量，每日同步时更新状态，评审时按迭代汇总完成情况，可以减少表格与系统之间的反复搬运。具体字段和视图配置可按团队习惯调整。
