迭代管理围绕一个固定周期，把目标、容量、Sprint Backlog、每日跟进、范围调整、评审回顾和未完成工作重新安排串成闭环。落地时先按团队真实可用容量确定迭代目标，再把目标拆成可验收的Sprint Backlog；每日跟进只关注阻塞与偏差，范围调整走显式决策，评审看增量、回顾改机制，未完成工作重新评估后再决定去向，不默认自动结转。下文按步骤、角色、示例和检查清单展开。
要点总览（TL;DR）
- 迭代管理按六步闭环推进：定目标与容量、形成Sprint Backlog、每日跟进、范围调整、评审与回顾、未完成工作重新安排，每一步都要有明确产出。
- 容量按团队真实可用人日测算，扣除休假、会议和支持性工作，并与历史完成情况对照；迭代目标要写成可检验的一句话。
- 范围调整走显式决策：新增需求先进待办池，确需插入当前迭代时同步移出等量工作或调整目标，并记录决策依据。
- 评审看增量是否满足验收标准，回顾看协作机制并形成有负责人的改进项，两者分开进行。
- 未完成工作不默认结转，重新评估优先级、剩余工作量与下一迭代目标后再决定回到待办池、拆分或取消。
迭代管理闭环：核心步骤与每步产出
迭代管理的主线可以概括为六步：定目标与容量、形成Sprint Backlog、每日跟进、范围调整、评审与回顾、未完成工作重新安排。每一步都有明确的输入、动作、输出和完成标志，缺一环就容易出现“会开了、事没定”的情况。下表给出全周期步骤，团队可据此对照自己的迭代节奏逐项落实。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 确定迭代目标与容量 | 产品待办列表、上一迭代完成情况、团队人员可用时间 | 按真实可用人日测算容量，扣除休假、会议、支持性工作等非交付时间；结合历史完成情况选定本迭代目标 | 一句可检验的迭代目标、容量测算结果 | 目标能用一句话说清，容量有测算依据，团队对目标无异议 |
| 形成Sprint Backlog | 迭代目标、候选需求、验收标准 | 在迭代计划会上评审需求，对要完成的需求与验收标准达成一致，拆分到迭代内可完成的粒度并分配负责人 | 带验收标准和负责人的Sprint Backlog | 每个条目都能判断“完成与否”，总量与容量匹配 |
| 每日跟进 | Sprint Backlog、任务状态、看板 | 站会只对齐阻塞、偏差和风险；阻塞项明确责任人和解决时限 | 阻塞清单、进度偏差记录 | 阻塞有责任人和时限，偏差有应对动作 |
| 范围调整 | 新增需求、进度偏差、迭代目标 | 新增需求先进入待办池；确需插入当前迭代时，同步移出等量工作或调整迭代目标，并记录决策依据 | 范围变更记录、调整后的Sprint Backlog | 每次变更都有决策入口和记录，目标与容量重新对齐 |
| 评审与回顾 | 迭代增量、验收标准、过程数据 | 评审会检查增量是否满足验收标准；回顾会复盘协作机制与流程问题，形成改进项 | 评审结论、改进行动项及负责人 | 增量被确认或退回，改进项有负责人和跟进时间 |
| 未完成工作重新安排 | 未完成条目、剩余工作量、下一迭代目标 | 重新评估优先级与剩余工作量，判断是否仍符合下一迭代目标，再决定回到待办池、拆分或取消 | 重新安排后的待办列表 | 每条未完成工作都有明确去向和理由 |
容量测算是整个闭环的起点。以团队真实可用人日为基础，扣除休假、会议、支持性工作等非交付时间，再与历史完成情况对照，避免按名义人力满额排期。目标则要落到可检验的程度，例如“完成支付流程的退款申请与审核两个功能并通过验收”，而不是“推进支付模块”。
Sprint Backlog的形成依赖计划会上的需求评审。产品负责人按优先级把待办列表中的需求规划至对应迭代，团队共同确认要完成的需求与验收标准，再把需求拆分为设计、研发、测试等子任务，明确负责人，便于后续跟进时判断完成与否。
每日跟进的重点是阻塞与偏差。站会不必逐人汇报，而是围绕“哪些工作被卡住、哪些条目进度偏离计划、有哪些风险需要升级”展开。阻塞项要落到具体责任人和解决时限，否则容易在第二天重复出现。范围调整需要显式决策入口：新增需求先进待办池，确需插入当前迭代时，同步移出等量工作或调整迭代目标，并记录决策依据，避免迭代目标被悄悄稀释。
评审与回顾承担不同任务。评审看迭代产出的增量是否满足验收标准，决定接受还是退回；回顾看协作机制与流程问题，形成可跟进的改进项。两者产出不同，合并成一次会议容易两头都不到位。未完成工作不默认自动结转，是因为优先级、剩余工作量和下一迭代目标都可能已经变化，直接带入会挤占新目标的容量。正确做法是重新评估后再决定回到待办池、拆分还是取消。
在工具承载上，ONES 敏捷研发管理解决方案覆盖需求池管理、迭代规划、迭代开发、缺陷追踪、迭代进度跟进、迭代回顾等场景。产品负责人可在迭代规划中按优先级把需求规划至迭代，团队在计划会上评审需求与验收标准后，用子任务拆分需求；迭代过程中通过敏捷看板管理任务状态，在站会上对齐进度与风险，并用燃尽图评估研发效率。评审回顾阶段可结合燃尽图、工时日志等数据复盘进度与质量偏差，再用 ONES Wiki 沉淀经验。具体版本与套餐能力以实际开通情况为准。
迭代中的角色分工与交付物
迭代管理跑不动，常见原因不是流程缺失，而是职责空转：目标没人拍板、阻塞没人推动、改进项没人跟进。明确产品负责人、迭代负责人、开发团队和干系人在各环节的职责与交付物，能让每个动作都有承接人。下表按环节列出角色分工。
| 环节 | 产品负责人 | 迭代负责人 | 开发团队 | 干系人 |
|---|---|---|---|---|
| 规划 | 按优先级提出候选需求，确认迭代目标与验收标准 | 组织计划会，主持容量测算与目标对齐 | 参与需求评审，拆分任务并认领 | 提供业务背景与约束，确认目标方向 |
| 跟进 | 回应需求澄清，判断范围调整的必要性 | 主持站会，跟踪阻塞与偏差，推动升级 | 更新任务状态，主动暴露阻塞 | 按约定渠道了解进度，不直接插入需求 |
| 评审 | 确认增量是否满足验收标准，决定接受或退回 | 组织评审会，记录结论 | 演示增量，说明实现与遗留问题 | 参与验收，提出反馈 |
| 回顾 | 参与复盘，确认需求侧改进项 | 主持回顾会，汇总改进项并指定负责人 | 提出流程与协作问题，认领改进动作 | 按需参与，提供跨团队视角 |
交付物方面，产品负责人对迭代目标和验收标准负责，产出可检验的目标描述与需求验收条件；迭代负责人对节奏和阻塞负责，产出容量测算结果、站会阻塞清单、范围变更记录和回顾改进项；开发团队对任务状态和增量负责，产出拆分后的任务、更新的看板状态和可演示的增量；干系人对业务判断负责，产出验收反馈和优先级意见。
职责冲突时，先回到决策入口而不是在会上临时拉扯。目标与优先级冲突由产品负责人拍板，节奏与资源冲突由迭代负责人协调并升级，技术方案冲突由开发团队内部评审后给出结论。冲突处理结果要落到记录里，例如范围变更记录或回顾改进项，避免同一问题在下一个迭代重复出现。
示例：一个两周迭代的完整运行过程
以下为一个演示情景，用于说明上述步骤如何落地，团队规模与业务背景为示例设定，实际执行应结合自身情况调整。
某团队共6人，两周迭代共10个工作日。名义人力为60人日，扣除休假4人日、会议与支持性工作约8人日，真实可用容量约48人日。对照上一迭代实际完成约45人日，团队把本迭代目标定为“完成订单查询与导出两个功能并通过验收”，并按45至48人日的总量选取需求，留出少量缓冲。
计划会上，产品负责人按优先级提出候选需求，团队逐条确认验收标准，例如“导出功能支持按时间范围筛选，单次导出不超过1万条且格式正确”。确认后拆分为设计、开发、测试子任务并分配负责人，Sprint Backlog总量与容量匹配，完成标志是每条需求都能判断完成与否。
迭代进行到第4天，业务方提出一个紧急报表需求。团队没有直接插入当前迭代，而是先放入待办池，由产品负责人评估优先级。评估后确认该需求可延至下一迭代，本轮不调整范围；若确需插入，则按规则移出等量工作，例如把导出功能的非核心筛选条件延后，并记录决策依据。这个判断的关键是：范围调整要有入口、有记录、有等量置换，而不是靠口头答应。
迭代结束时，订单查询功能通过验收，导出功能因接口联调延迟未完成，剩余约3人日工作量。团队没有默认把它带入下一迭代，而是重新评估：该功能仍符合下一迭代目标，优先级不变，于是拆分为联调与验证两个条目回到待办池，并纳入下一迭代容量测算；同时把联调延迟的原因写入回顾改进项，指定负责人跟进接口对接机制。
迭代运行的完成检查
判断迭代管理是否真正跑通，可以按阶段逐项核对。以下清单给出检查项与通过标准，任一阻断项未通过，应先处理再进入下一阶段。
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 规划 | 容量是否按真实可用人日测算 | 扣除休假、会议、支持性工作后有测算依据，并与历史完成情况对照 |
| 规划 | 迭代目标是否可检验 | 目标能用一句话说清，团队对“做到什么算完成”无异议 |
| 规划 | Sprint Backlog是否可验收 | 每个条目有验收标准和负责人，粒度可在迭代内完成 |
| 跟进与调整 | 站会是否聚焦阻塞与偏差 | 阻塞项有责任人和解决时限，偏差有应对动作 |
| 跟进与调整 | 范围调整是否走显式决策 | 新增需求先入待办池，插入时有等量置换或目标调整，并有记录 |
| 评审回顾 | 评审是否检查增量 | 增量按验收标准确认接受或退回，结论有记录 |
| 评审回顾 | 回顾是否形成改进项 | 改进项有负责人和跟进时间，并在下一迭代检查落实 |
| 未完成工作 | 是否重新评估而非默认结转 | 每条未完成工作有明确去向和理由，纳入下一迭代容量测算 |
阻断项包括：迭代目标无法检验、Sprint Backlog缺少验收标准、范围调整无记录、未完成工作直接带入下一迭代而未重新评估。出现任一情况，应先补齐再推进，否则后续跟进和评审都会失去判断依据。完成条件则是上述检查项全部通过，且改进项已进入下一迭代的跟进范围。
这套检查清单适合在迭代结束前由迭代负责人组织自查，也可在回顾会上作为固定议题。团队规模、迭代周期和组织流程不同，检查项的细度可以调整，但容量测算、验收标准、范围决策记录和未完成工作重新评估这四项建议保留，它们是迭代闭环能否持续运转的关键支点。
常见问题
迭代目标定得比较宽泛，执行中会带来什么问题？
目标宽泛时，团队在计划会上难以判断哪些需求属于本迭代范围，每日跟进也缺少偏差判断的基准，评审时容易变成“做了不少事”的汇报。可检验的目标通常包含具体对象和完成条件，例如“完成退款申请与审核两个功能并通过验收”。如果目标一时写不细，可以在计划会上先明确“本迭代结束时能演示什么、由谁确认”，再据此收敛表述。
团队历史数据很少，容量测算怎么做才不至于拍脑袋？
缺少历史数据时，可以先按真实可用人日做保守估算，并在迭代结束后记录实际完成情况，逐步积累对照基准。测算时把休假、会议、支持性工作等非交付时间显式扣除，再留出少量缓冲。前几个迭代的重点是让测算口径稳定下来，而不是追求精确；口径一致后，容量与实际的偏差会逐渐收敛，排期才有可靠参照。
迭代中途插入紧急需求，除了移出等量工作还有别的处理方式吗？
常见处理有三类：一是放入待办池延至下一迭代；二是插入当前迭代并移出等量工作，保持总量与容量匹配；三是插入并调整迭代目标，同时向干系人说明哪些原定内容不再承诺。三种方式都需要记录决策依据和决策人。选择哪一种，取决于紧急需求与当前迭代目标的关系，以及团队剩余容量是否还有缓冲空间。
未完成工作重新评估后，什么情况下应该拆分或取消？
剩余工作量较大、无法在下一迭代容量内完成时，可以拆分为更小的条目分批安排；优先级已经下降、或需求本身因业务变化失去价值时，可以取消并记录原因。重新评估时要同时看三件事：该工作是否仍服务于下一迭代目标、剩余工作量是否准确、下一迭代容量是否还有空间。三条都满足再纳入，否则回到待办池等待重新排序。
迭代管理的检查清单需要每个迭代都完整执行一遍吗？
检查清单的作用是提供判断依据，执行细度可以随团队成熟度调整。容量测算、验收标准、范围决策记录和未完成工作重新评估这四项建议每个迭代保留，它们是闭环运转的关键支点；其余检查项可以按团队情况简化或在回顾会上轮换核查。清单本身也应随回顾改进项更新，避免长期停留在同一版本。
