迭代计划是一套按固定节奏运转的管理机制，而不是一次排期会议。它从迭代目标与验收口径出发，结合团队真实容量筛选 Sprint Backlog，在规划会上确认任务拆分与负责人，再通过每日跟进、显式范围调整、评审与回顾形成闭环。本文按这条主线给出可执行的步骤、模板字段与检查清单，并说明 ONES 在目标、Backlog 与跟进记录上的承载方式。
要点总览（TL;DR）
- 迭代计划按六步固定顺序运转：定目标与验收口径、测算容量、筛选拆分 Sprint Backlog、开规划会确认、每日跟进与范围调整、评审回顾并处置未完成工作。
- 迭代目标写清对象、变化和验收方式，数量控制在1–3条；容量按人力、可用工时、请假培训和会议及支持性工作预留逐项测算，以目标能在容量内完成为收敛条件。
- Sprint Backlog 入选条目需满足目标相关、验收标准清晰、依赖已识别、粒度可在迭代内完成，并拆到可指派、可跟踪的子任务。
- 范围调整设置显式触发条件和审批人，同步记录对目标与容量的影响；未完成工作重新评估优先级、剩余工作量和依赖后再决定去向，不默认自动结转。
迭代计划的核心答案与操作步骤
迭代计划的完整流程可以拆成六步，顺序固定：定目标与验收口径、测算容量、筛选并拆分 Backlog、开规划会确认、迭代中跟进与调整、收尾评审回顾并处置未完成工作。每一步都要有明确输入、动作、输出和完成标志，否则计划会在执行中变成一份无人核对的清单。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定迭代目标 | 产品方向、上一迭代结论、待办列表中的候选需求 | 写出本迭代要达成的结果，并为每个目标写明验收口径 | 迭代目标（1–3条）及对应验收标准 | 团队能用自己的话复述目标，验收标准可被检验 |
| 2. 测算容量 | 团队成员名单、可用工作日、请假与培训安排、支持性工作 | 按人计算可用工时，扣除会议与支持性投入，汇总为团队容量 | 容量测算表 | 容量数字有计算过程，团队对可用工时口径一致 |
| 3. 筛选与拆分 Backlog | 候选需求、容量结果、依赖与风险信息 | 按目标相关性和验收清晰度筛选条目，拆成可指派任务并标注依赖 | Sprint Backlog | 每条任务有负责人、有估算、粒度可在迭代内完成 |
| 4. 开规划会 | 迭代目标、容量测算表、Sprint Backlog 草案 | 逐条确认范围、拆分、负责人与验收口径，处理分歧 | 确认后的迭代计划与会议结论 | 所有参会角色对范围与负责人无异议，结论有记录 |
| 5. 每日跟进与范围调整 | 任务状态、阻塞信息、燃尽情况 | 每日对齐进度与阻塞，范围变化走显式评审并记录影响 | 每日跟进记录、范围变更记录 | 阻塞有责任人和解决时限，变更均有记录 |
| 6. 评审、回顾与未完成处置 | 迭代成果、验收标准、跟进与变更记录 | 按验收口径验收，复盘过程并产出改进项，重新评估未完成工作 | 评审结论、回顾改进项、未完成工作处置表 | 改进项有负责人和时限，未完成事项有明确去向 |
迭代目标与容量测算的关系是约束关系：目标决定需要做什么，容量决定能做多少。先有目标再测容量，容易出现目标远超承载；先测容量再定目标，则容易退化成“有多少工时填多少活”。实际操作中两者交替校准，最终以“目标可在容量内完成”为收敛条件。
规划会需要产出的最小产物包括：确认后的迭代目标与验收口径、带负责人和估算的 Sprint Backlog、记录在案的依赖与风险、以及会议结论。缺少其中任何一项，后续跟进都会失去对照基准。
迭代目标与容量怎么定
迭代目标描述的是本迭代结束时可以观察到的结果，写法上建议包含对象、变化和验收方式三部分。例如“完成订单导出功能并对接测试环境，支持按时间范围导出，验收以测试用例全部通过为准”。空泛的“提升系统稳定性”无法在评审时检验，应改为具体的可验证结果。
目标数量控制在1–3条，每条都配验收口径。验收口径要写明由谁、依据什么、在什么条件下判定通过，避免评审会上临时解释标准。
容量测算的构成项包括：
- 人力：本迭代实际投入的成员及其角色，兼职成员按投入比例折算。
- 可用工时：迭代天数乘以每人每日有效工时，扣除会议、评审等固定占用。
- 请假与培训：已确定的休假、培训、出差安排，按人按天扣除。
- 支持性工作：线上问题处理、跨团队支持、例行运维等，按历史比例预留。
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 成员与角色 | 列出本迭代投入人员及角色 | 开发3人、测试1人、设计0.5人 |
| 迭代工作日 | 扣除节假日后的实际天数 | 10个工作日 |
| 每日有效工时 | 扣除会议后的专注工作时间 | 每人每日6小时 |
| 请假与培训扣除 | 按人按天列出 | 开发A请假1天，扣6小时 |
| 支持性工作预留 | 按历史比例或固定额度预留 | 预留总容量的15% |
| 可用容量合计 | 汇总为团队可承诺的工作量 | 约150小时 |
目标与容量的匹配判断看两点：Backlog 估算总量是否落在可用容量之内，以及关键路径上的任务是否集中在少数人身上。总量超出的部分应移出本迭代；集中在个别人身上的情况需要调整分工或拆分任务。
容量不足时，优先削减目标范围而不是压缩验收标准，把非核心条目退回待办列表并记录原因。容量明显过剩时，可以提前纳入下一优先级的需求，或安排技术债清理与文档补全，但同样要写入 Backlog 并指定负责人，避免形成无归属的“空余时间”。
Sprint Backlog 如何筛选与拆分
入选 Sprint Backlog 的条目需要同时满足四个条件：与迭代目标直接相关、验收标准清晰可检验、依赖关系已识别并有应对方式、粒度能在迭代内完成。只满足部分条件的条目应留在待办列表中继续细化，而不是带着模糊标准进入迭代。
任务拆分的粒度以“可指派、可跟踪、可在数天内完成”为准。需求层面的条目拆到设计、开发、测试等子任务，每个子任务有唯一负责人和估算。拆分过粗会导致每日跟进无法判断真实进度，拆分过细则会增加管理开销，通常以半天到两天的工作量为参考区间。
依赖与风险在拆分阶段就要标注：依赖哪个团队或哪个外部系统、预计何时可用、如果延迟影响哪些任务。风险项写明触发条件和备选方案，例如“第三方接口未按时提供时，先用模拟数据完成前端联调”。
| 字段 | 用途 |
|---|---|
| 条目编号与标题 | 唯一标识，便于跟进与评审引用 |
| 关联迭代目标 | 说明该条目支撑哪个目标 |
| 验收标准 | 评审时的判定依据 |
| 子任务与负责人 | 拆分后的可指派工作项 |
| 估算 | 工时或故事点，与容量口径一致 |
| 依赖 | 外部团队、系统或前置任务 |
| 风险与应对 | 触发条件与备选方案 |
| 状态 | 待开始、进行中、待验证、完成 |
拆分示例：需求“订单导出功能”拆为“导出接口设计与评审”“后端导出逻辑开发”“前端导出入口与参数校验”“测试用例编写与执行”四个子任务，分别指派给设计、后端、前端和测试负责人，其中“前端导出入口”依赖“导出接口设计与评审”完成，风险标注为接口字段变更可能引起的返工。
在 ONES 中，产品负责人可以按需求优先级把待办列表中的需求规划到对应迭代，并在迭代计划会议上与团队共同评审；就迭代需求与验收标准达成一致后，设计、研发、测试人员可以用子任务把需求拆开，便于后续处理和跟踪。
规划会怎么开：议程与角色分工
规划会的前置准备包括：迭代目标草案、容量测算表、按优先级排序的候选条目、以及已识别的依赖与风险。这些材料应在会前发给参会者，让会议时间用于确认和解决分歧，而不是现场收集信息。
| 环节 | 时间参考（以1小时会议为例） | 产出 |
|---|---|---|
| 目标与验收口径说明 | 10分钟 | 团队对目标理解一致 |
| 容量与排期说明 | 5分钟 | 确认可用容量口径 |
| 逐条评审候选条目 | 30分钟 | 确认范围、拆分与负责人 |
| 依赖与风险处理 | 10分钟 | 明确责任人与应对方案 |
| 结论确认与记录 | 5分钟 | 会议结论与待办事项 |
角色分工上，产品负责人负责说明目标、优先级和验收口径，对范围取舍做最终判断；迭代负责人组织会议、把控议程节奏、确认计划可执行并记录结论；开发人员负责评估技术可行性、完成任务拆分与估算、认领任务；测试人员参与验收标准的确认，提出测试前置条件和验证方式。
会议结论的确认方式建议采用逐条过审：每条进入迭代的条目当场确认负责人、估算和验收标准，有异议的条目要么当场解决，要么移出本迭代并记录原因。会议结束时由迭代负责人复述最终范围与目标，参会者确认无异议后形成书面结论。
每日跟进与范围调整机制
每日跟进看三件事：任务状态是否与计划一致、是否有阻塞、剩余工作量与剩余时间是否匹配。记录内容包括当日完成项、次日计划项、阻塞项及其责任人和解决时限。跟进以任务为单位，避免只汇报“进展顺利”这类无法核对的信息。
阻塞项的升级路径要事先约定：当日无法自行解决的阻塞，由迭代负责人当天协调；涉及跨团队资源或优先级冲突的，升级到产品负责人或相关管理者，并给出解决时限。阻塞记录保留在跟进记录中，直到关闭。
范围调整的触发条件包括：需求验收标准发生实质变化、外部依赖无法按计划提供、出现影响目标的线上问题。触发后由提出方说明原因和影响，产品负责人评估是否调整，迭代负责人记录变更内容、对目标和容量的影响，以及被替换或移出的条目。
| 记录类型 | 关键字段 |
|---|---|
| 每日跟进记录 | 日期、完成项、计划项、阻塞项、阻塞责任人、解决时限 |
| 范围变更记录 | 变更日期、变更条目、变更原因、提出方、审批人、对目标的影响、对容量的影响、被替换条目 |
变更对目标与容量的影响必须同步记录：新增条目要说明从哪部分容量中挤出，移除条目要说明目标是否随之调整。缺少这一步，迭代计划会在多次“小调整”后与实际执行完全脱节。
迭代执行期间，团队成员围绕迭代要完成的需求完成自己拆解的任务，并通过敏捷看板管理任务状态；每日站立会议可以借助看板可视化地对齐进度与风险、排除问题，燃尽图则用于观察剩余工作量与时间的匹配情况。
评审、回顾与未完成工作的重新安排
评审会按迭代开始时确认的验收口径逐条验收，参与方包括产品负责人、开发、测试以及需求相关方。验收结论分为通过、有条件通过和不通过三类，有条件通过需写明遗留条件和完成时限，不通过需说明原因并决定是否重新纳入后续迭代。
回顾会聚焦过程而非个人，产出可跟踪的改进项。每个改进项写明问题描述、改进动作、负责人和验证时间，数量控制在团队能在下一迭代内落实的范围内。改进项应在下一迭代的跟进中被检查，否则回顾会容易变成一次性讨论。
未完成工作的处置依据包括：原定优先级是否仍然成立、剩余工作量、依赖是否已具备、以及是否仍服务于当前产品目标。重新评估后有三种去向：进入下一迭代、退回待办列表等待重新排序、或取消并记录原因。
| 处置项 | 记录字段 |
|---|---|
| 未完成条目 | 条目编号、原定目标、已完成部分、剩余工作量 |
| 重新评估结论 | 优先级判断、依赖状态、处置决定（进入下一迭代/退回待办/取消） |
| 责任与时间 | 评估人、决定日期、进入下一迭代时的负责人 |
未完成事项进入下一迭代需要满足条件：仍与下一迭代目标相关、剩余工作量已重新估算并计入下一迭代容量、依赖已确认可用。不满足条件的条目退回待办列表重新排序，不默认自动结转。
迭代完成并发布后，可以召开全员回顾会，借助燃尽图、工时日志、持续集成报告等数据复盘进度、质量和成本偏差，讨论改进建议；回顾形成的经验可以用 ONES Wiki 沉淀为团队知识库，供后续迭代参考。
完整示例：一个两周迭代的计划与运行
以下为演示情景，用于说明各环节如何衔接，数据为示例值。
背景与目标：某研发小组共5人，包括3名开发、1名测试、1名设计（投入50%）。本迭代为两周共10个工作日，目标为“完成订单导出功能并上线测试环境”，验收口径为“导出功能覆盖按时间范围导出，测试用例全部通过，测试环境验证无阻断问题”。
容量测算：开发3人×10天×6小时=180小时，测试1人×10天×6小时=60小时，设计0.5人×10天×6小时=30小时，合计270小时；扣除开发A请假1天6小时、团队评审会议预留20小时、支持性工作预留15%（约37小时），可用容量约207小时。
Backlog 筛选结果：入选条目为导出接口设计与评审（16小时）、后端导出逻辑开发（60小时）、前端导出入口与参数校验（40小时）、测试用例编写与执行（48小时）、导出功能文档（8小时），合计172小时，落在容量之内。原候选中的“导出模板自定义”因验收标准未明确，退回待办列表。
每日跟进与一次范围调整：迭代第4天，测试提出导出文件在数据量较大时超时，属于验收标准内的性能问题，团队将“后端导出逻辑开发”剩余部分调整为分批导出方案，新增约12小时工作量。产品负责人评估后，将“导出功能文档”移出本迭代，容量影响记录为减8小时、增12小时，净增4小时，仍在容量余量内，变更记录同步更新。
评审与未完成处置：迭代结束时，导出功能通过验收，文档条目未完成。评审结论为通过，遗留条件为文档需在下一迭代第3天前补齐。回顾会产出两项改进项：性能类需求在规划阶段补充数据量级说明；文档任务与功能任务同步排期。未完成的文档条目经重新评估，剩余工作量6小时，与下一迭代目标相关，计入下一迭代容量后进入下一迭代，负责人不变。
完成检查：迭代计划是否可执行
在规划会结束和迭代启动前，用以下清单逐项核对。任何一项不满足，都应回到对应步骤补齐，而不是带着缺口进入执行。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 目标与容量一致性 | 迭代目标是否有验收口径；Backlog 估算总量是否在可用容量内；关键任务是否过度集中在个别人 | 每条目标可检验；总量不超容量；分工无明显单点 |
| Backlog 完整性与负责人 | 每条任务是否有负责人和估算；依赖与风险是否标注；粒度是否可在迭代内完成 | 无无主任务；依赖有应对方案；无跨迭代巨型任务 |
| 跟进与变更机制 | 每日跟进的时间、记录字段和阻塞升级路径是否约定；范围变更的触发条件和审批人是否明确 | 团队知道在哪里记录、找谁升级、谁有权批准变更 |
| 收尾与未完成处置 | 评审的验收口径和参与方是否确定；回顾改进项是否有负责人和时限；未完成工作的评估规则是否约定 | 评审有依据；改进项可跟踪；未完成事项不默认结转 |
清单核对完成后，迭代计划即可进入执行。执行过程中如发生范围调整，回到变更记录更新影响，并在下一次回顾中检查调整是否合理，让这套机制在多个迭代之间持续校准。
常见问题
迭代目标写了几条，但团队对验收口径理解不一致，怎么办？
验收口径的分歧通常来自判定主体和判定依据没有写清。可以在目标下补一行说明：由谁验收、依据哪些测试用例或检查项、在什么环境下判定通过。规划会上逐条复述目标并让测试人员确认验证方式，仍无法达成一致的条目先移出本迭代，避免带着模糊标准进入执行。
团队同时有多个项目，容量测算时怎么处理共享成员？
共享成员按实际投入比例折算工时，并在容量表中单独标注其在本迭代的可用天数。折算后如果关键任务仍集中在这名成员身上，需要在规划会上调整分工或拆分任务，把部分工作交给有条件的其他成员。共享成员的请假、支持其他项目的时间也应提前扣除，避免用名义工时排期。
迭代进行到一半，业务方要求插入一个紧急需求，应该走什么流程？
先由提出方说明紧急原因和期望时间，产品负责人评估该需求与当前迭代目标的关系，迭代负责人核算插入后对容量的影响。若决定纳入，需明确从现有范围中移出哪些条目或调整哪些验收标准，并记录变更日期、审批人和影响。若决定不纳入，记录原因并给出后续排期安排，让业务方有明确预期。
未完成的任务在下一迭代重新估算后工作量变大，还能直接进入下一迭代吗？
可以进入，但前提是重新估算后的工作量已计入下一迭代容量，且该任务仍与下一迭代目标相关、依赖已确认可用。如果重新估算后超出容量余量，应退回待办列表重新排序，或与下一迭代的其他条目做取舍。重新估算的结果和判断依据要写入未完成工作处置表，便于回顾时核对估算偏差。
回顾会产出的改进项很多，如何避免下一迭代无人落实？
把改进项数量控制在团队下一迭代能落实的范围内，每项写明改进动作、负责人和验证时间，并纳入下一迭代的每日跟进检查。验证时间到期时在跟进记录中确认结果，未完成的改进项说明原因并决定是否延续。回顾经验还可以用 ONES Wiki 沉淀为团队知识库，供后续迭代参考。
