迭代管理要落到可重复的循环上：先定目标和范围，把需求拆成能在一个迭代内交付的工作项并排好优先级；迭代中按日推进、及时暴露阻塞；结束时做评审验收，未完成的工作逐项重新评估后再决定去向；最后用回顾把问题转成下一轮可跟踪的改进项。每个环节都要有负责人、输入、输出和完成标志，否则容易变成定期开会。下文按这条主线给出可直接照做的步骤、角色分工、示例和检查清单。
要点总览（TL;DR）
- 迭代管理按“启动—执行推进—评审验收—回顾改进”四个环节循环运行，每个环节都要有负责人、输入、输出和完成标志，否则容易退化为定期开会。
- 启动前把需求拆成能在一个迭代内完成并可验收的工作项，公开优先级排序依据，按容量确定承诺范围，计划会产出目标、工作项清单和验收标准。
- 执行期每日同步控制在15分钟量级，聚焦进展、计划与阻塞；阻塞当场指定责任人和时限，范围变更需满足准入条件并留痕。
- 收尾时逐项核对验收标准，未完成工作按价值、拆分粒度、阻塞原因逐项重新评估，再决定回到待办、拆分、关闭或进入下一迭代，不默认结转。
- 回顾产出两到三项有负责人、时限和验证方式的改进项，作为工作项进入下一迭代跟踪，并用完成检查清单和失效信号定期核对运行质量。
迭代管理的最小运行框架：一个迭代包含哪些环节
一个迭代由四个环节组成，顺序固定：启动、执行推进、评审验收、回顾改进。四个环节首尾相接，上一环节的输出就是下一环节的输入。判断框架是否成立，看每个环节是否都有明确的负责人和可检查的交接物，而不看会议开了几次。
| 环节 | 负责人 | 输入 | 输出 | 完成标志 |
|---|---|---|---|---|
| 迭代启动 | 产品负责人主持，迭代负责人组织 | 已排序的需求、团队容量、上一轮回顾改进项 | 迭代目标、承诺范围、拆分后的工作项、验收标准 | 团队对目标和范围达成一致，工作项均有负责人和验收标准 |
| 执行推进 | 迭代负责人 | 迭代计划、工作项状态 | 每日进展与阻塞记录、更新后的看板 | 阻塞项均有责任人和处理时限，进度可视化保持最新 |
| 评审验收 | 产品负责人组织，质量角色执行验收 | 已完成的工作项、验收标准 | 验收结论、未完成工作处置记录 | 每个工作项有明确的通过或不通过结论，未完成项逐项有去向 |
| 回顾改进 | 迭代负责人主持 | 进度、质量、成本数据，评审结论 | 改进项清单（负责人、时限、验证方式） | 改进项进入下一迭代跟踪，有验证方式 |
迭代周期按团队交付节奏确定，常见为一周或两周。周期一旦确定，就保持稳定，让团队形成固定的计划、验收和回顾节奏；频繁改动周期会让容量评估失去参照。环节之间的交接物要固定：计划产出交给执行，执行结果交给评审，评审结论和过程数据交给回顾，回顾改进项回到下一次启动。
迭代开始前：目标、范围与工作项怎么定
启动前的准备工作决定迭代能否顺利推进。核心动作是把模糊需求转成可排期、可验收的工作项，并让团队对承诺范围形成一致理解。
迭代目标的写法与数量
迭代目标描述这一轮要达成的业务结果，用一句话写清“为谁解决什么问题、达到什么状态”。一个迭代聚焦一到两个目标即可，目标过多会让优先级失去区分度。目标要能被验收：例如“完成订单退款流程上线，覆盖正常退款与部分退款两种场景”，比“优化退款体验”更容易判断是否达成。
需求拆分到可在一个迭代内完成的工作项
拆分以“一个迭代内能完成并可验收”为粒度。检查点包括：工作项是否有明确的验收标准；是否能在迭代周期内完成；是否依赖外部团队或未确定的前置条件；是否大到需要再拆成子任务。拆分后的工作项由设计、研发、测试人员各自认领子任务，便于后续跟踪。
优先级排序依据
排序依据要在计划会上公开说明，常用维度包括业务价值、用户影响范围、交付紧迫性和依赖关系。排序结果落到需求列表的顺序上，团队按顺序取用，避免会上临时争论。排序依据公开的好处是：范围需要调整时，团队能按同一口径判断取舍。
容量评估与承诺范围
容量评估参考上一迭代的实际完成量、本迭代成员可用时间（扣除休假、支持性工作）以及工作项的不确定性。承诺范围以容量为上限，留出一定余量应对插入事项。评估结果要在计划会上确认，而不是由个人单方面决定。
迭代计划会的议程与产出
- 会前：产品负责人准备好已排序的需求和验收标准，迭代负责人准备容量数据。
- 议程一（约10分钟）：说明迭代目标与优先级依据。
- 议程二（约30分钟）：逐项评审进入范围的需求，确认验收标准，团队拆分工作项和子任务。
- 议程三（约10分钟）：确认承诺范围与负责人，记录未纳入范围的需求去向。
- 产出：迭代目标、承诺工作项清单、每项负责人与验收标准、容量评估记录。
在研发管理工具中承载这些动作时，产品负责人可以按优先级把需求规划到对应迭代，在计划会上与团队共同评审，达成一致后用子任务拆分需求。ONES 敏捷研发管理方案覆盖了从需求规划到迭代跟踪的流程，具体配置按团队实际方案确定。
迭代进行中：日常推进、阻塞处理与范围变更
执行期的重点是让进展可见、让阻塞及时解决。日常动作要短而固定，异常处理要有明确规则。
每日同步的内容与时长
每日同步控制在15分钟量级，每人回答三件事：昨天完成了什么、今天计划做什么、有什么阻塞。讨论细节移到会后单独进行，避免同步会变成问题分析会。同步的产出是更新后的工作项状态和一份阻塞清单。
阻塞项的识别、上报与责任人
阻塞指工作项无法按计划推进的外部或内部障碍，例如依赖未就绪、环境不可用、验收标准不清晰。识别后当场指定责任人和处理时限，记录在阻塞清单上，次日同步时检查进展。迭代负责人负责推动阻塞闭环，超出团队权限的阻塞及时上报。
范围变更的准入条件与审批方式
中途加入的需求要满足准入条件才考虑纳入：是否影响本迭代目标、是否有可替换的等量工作、是否能在剩余时间内完成。满足条件的变更由产品负责人和迭代负责人共同确认，并同步调整承诺范围；不满足条件的进入待办列表，留待下一轮排序。变更记录要留痕，便于回顾时分析范围波动的原因。
进度可视化方式与更新频率
用看板呈现工作项状态，用燃尽图观察剩余工作量趋势。看板状态至少覆盖待处理、进行中、待验收、已完成；更新频率与每日同步一致，做到当天状态当天更新。燃尽图依赖任务和工时数据的持续录入，数据断档会让趋势失真。
ONES 的敏捷看板可用于每日站立会中对齐进度与风险，燃尽图可用来观察研发效率变化；测试环节中，测试工程师按验收标准编写并执行用例，未通过的用例可转为缺陷提交并指派修复。这些能力的具体字段口径以实际配置为准。
迭代收尾：评审、验收与未完成工作的处理
收尾阶段要回答两个问题：承诺的工作项是否达到验收标准；没有完成的工作项下一步去哪里。第二个问题需要逐项判断，不能默认全部结转到下一迭代。
迭代评审的参与角色与演示内容
评审由产品负责人组织，团队成员、质量与验收角色参加，必要时邀请需求提出方。演示内容围绕迭代目标展开：完成了哪些工作项、对应哪些验收标准、实际效果如何。演示以可运行的结果为准，不以文档描述代替。
验收标准与完成定义
验收标准在计划阶段就已确定，收尾时逐项核对。完成定义描述工作项“做完”的统一条件，例如代码已合并、测试用例已执行、文档已更新。验收结论只有通过和不通过两种，不通过的工作项要写明差距。
未完成工作的逐项重新评估
对每个未完成工作项，按以下依据判断：当前业务价值是否仍然成立；拆分粒度是否过大导致无法在一个迭代内完成；阻塞原因是否已消除；是否与其他工作项重复或已被替代。评估由产品负责人和迭代负责人共同完成，结论记录在处置记录中。
重新评估后的去向
- 回到待办列表：价值仍成立但优先级下降，重新参与排序。
- 拆分：粒度问题导致未完成，拆成更小的工作项。
- 关闭：价值已消失、被替代或不再需要。
- 进入下一迭代：价值高且阻塞已消除，纳入下一轮承诺范围并重新评估容量。
迭代收尾的记录与留痕
收尾记录包括：验收结论清单、未完成工作处置记录、范围变更汇总、关键阻塞及处理结果。这些记录是回顾会的输入，也是下一轮计划会的参考。
迭代回顾：把问题转成下一轮可执行的改进项
回顾的价值在于产出可跟踪的改进动作。会议讨论再充分，没有负责人和验证方式的改进项也无法落地。
回顾会议的输入数据来源
输入包括：燃尽图反映的进度偏差、工时记录反映的投入分布、缺陷数据反映的质量情况、范围变更记录、阻塞清单、评审结论。数据在迭代期间持续积累，回顾前汇总，避免凭印象讨论。
问题归类的维度
按流程环节归类（计划、执行、验收）、按问题类型归类（需求不清、依赖阻塞、质量波动、协作衔接）或按影响范围归类（团队级、项目级、组织级）。归类的作用是让同类问题集中讨论，避免逐条罗列。
改进项的负责人、时限与验证方式
每个改进项写清四要素：要改变的具体动作、负责人、完成时限、验证方式。验证方式要可观察，例如“下一迭代计划会前完成需求验收标准模板，计划会上试用一次并收集团队反馈”。改进项数量控制在团队能执行的范围内，通常两到三项。
改进项在下一迭代中的跟踪方式
改进项作为工作项进入下一迭代，在每日同步中检查进展，在下一轮回顾中验证效果。未完成的改进项要说明原因，避免无声消失。团队可将回顾结论沉淀到知识库，形成可复用的经验记录；ONES Wiki 可用于这类经验沉淀，具体使用方式按团队习惯安排。
角色分工与各环节交付物
迭代管理的角色边界要清楚，每个角色在四个环节中都有明确的参与点和交付物。
| 角色 | 启动 | 执行推进 | 评审验收 | 回顾改进 |
|---|---|---|---|---|
| 产品负责人 | 确定目标与优先级，主持计划会 | 处理范围变更申请，确认优先级调整 | 组织评审，确认验收结论 | 参与问题讨论，确认改进项优先级 |
| 迭代负责人 | 准备容量数据，组织计划会 | 主持每日同步，推动阻塞闭环 | 汇总完成情况，组织未完成工作评估 | 主持回顾会，跟踪改进项 |
| 团队成员 | 拆分工作项，认领任务 | 更新状态，上报阻塞 | 演示成果，配合验收 | 提出问题和改进建议 |
| 质量与验收角色 | 参与验收标准评审 | 按标准准备测试用例，执行测试 | 执行验收，提交缺陷 | 提供质量数据，参与原因分析 |
交付物清单包括：迭代目标与范围记录、工作项与验收标准、每日阻塞清单、范围变更记录、验收结论清单、未完成工作处置记录、回顾改进项清单。保管位置统一在团队共用的项目空间或知识库中，保证可追溯。
角色缺位时的替代安排：产品负责人缺位时，由熟悉业务需求的成员临时代理排序和验收确认，事后补确认；迭代负责人缺位时，由团队内指定一名成员主持同步和阻塞跟进；质量角色缺位时，验收标准由产品负责人和研发共同核对，测试执行可延后但不跳过。替代安排要提前约定，避免临时无人负责。
一个两週迭代的运行示例
以下为演示情景，用于说明各环节如何衔接，不代表特定团队的真实数据。
背景与目标：某研发团队采用两周迭代，本轮目标为“完成会员积分查询功能上线，覆盖积分余额与明细两个页面”。团队六人，上一迭代实际完成量为参照。
计划会确定的范围：产品负责人按优先级带入四项需求：积分余额页面、积分明细页面、积分数据接口、异常提示文案。团队评估容量后承诺前三项，异常提示文案留待下一轮。每项需求确认验收标准，研发和测试分别拆出子任务并认领。
执行期的阻塞处理：第五天，积分数据接口依赖的上游服务未按约定提供测试环境，研发在每日同步中上报。迭代负责人当场指定对接人，约定两天内解决；期间团队先推进两个页面的前端开发。第八天环境就绪，接口联调恢复。第十天，产品负责人收到一个紧急需求，评估后认为不影响本轮目标且无等量工作可替换，决定放入待办列表，未纳入本轮范围。
评审与未完成工作的重新评估：迭代结束，积分余额页面和明细页面通过验收；积分数据接口完成主体功能，但异常分支未覆盖，未通过验收。评估结论：接口价值仍成立，阻塞原因是测试环境到位晚导致时间不足，决定拆分为“接口主流程”和“异常分支处理”两个工作项，前者随本轮发布，后者进入下一迭代。
回顾产出的改进项：回顾会依据燃尽图和阻塞清单，识别出两个问题：外部依赖的环境准备没有提前确认；接口类工作项的验收标准未覆盖异常分支。改进项一：计划会增加“外部依赖确认”检查项，由迭代负责人负责，下一轮计划会前完成模板并在会上试用。改进项二：接口类需求拆分时补充异常分支的验收标准，由产品负责人负责，下一迭代评审时验证。两项改进进入下一迭代跟踪。
迭代管理的完成检查与常见失效信号
判断迭代管理是否做到位，可以逐项核对以下检查点，并观察是否出现失效信号。
迭代各环节的完成检查项
- 启动：迭代目标是否明确且数量受控；每个工作项是否有验收标准和负责人；容量评估是否有依据；计划会产出是否记录。
- 执行：每日同步是否按时进行并产出阻塞清单；阻塞项是否都有责任人和时限；范围变更是否有准入判断和记录；看板状态是否当天更新。
- 收尾：每个工作项是否有通过或不通过的结论；未完成工作是否逐项评估并记录去向；收尾记录是否完整。
- 回顾：改进项是否有负责人、时限和验证方式；改进项是否进入下一迭代跟踪；回顾输入数据是否来自迭代期间的记录。
判断迭代运行是否有效的观察指标
可观察的指标包括：承诺范围内工作项的完成比例、范围变更的次数和原因分布、阻塞项的平均处理时长、未完成工作中因拆分不当导致的比例、改进项在下一轮的完成情况。指标用于发现趋势，不用于考核个人。
常见失效信号
- 目标缺失：迭代没有明确目标，工作项只是需求的堆叠，评审时无法判断整体是否达成。
- 范围随意扩张：中途插入需求没有准入判断，承诺范围持续膨胀，团队长期处于未完成状态。
- 未完成工作默认结转：所有未完成项原样进入下一迭代，不评估价值和拆分问题，积压逐渐累积。
- 同步会变成汇报会：每日同步时间拉长、讨论细节，阻塞没有当场指定责任人。
- 回顾无产出：讨论热烈但没有改进项，或改进项没有负责人和验证方式。
发现失效信号后的调整动作
目标缺失时，下一轮计划会先确定目标再排工作项；范围扩张频繁时，收紧变更准入条件并记录每次变更的原因；未完成项默认结转时，在收尾环节强制逐项填写处置结论；同步会超时时，明确三问格式并限制时长；回顾无产出时，缩减讨论范围，聚焦两到三个可执行的改进项。调整动作在下一迭代验证效果，形成持续修正的循环。
常见问题
迭代周期定为一周还是两周更合适，中途可以调整吗？
周期按团队交付节奏确定，一周和两周都常见，关键是让计划、验收和回顾形成固定节奏。周期稳定后，容量评估才有可参照的历史完成量。若团队连续几个迭代出现大量未完成工作，或工作项普遍无法在一个周期内收口，可以在回顾会上提出调整周期，并在下一轮按新周期重新积累容量参照；频繁临时改动会让评估失去基准。
迭代进行中插入紧急需求，什么情况下可以纳入当前迭代？
先判断三个条件：是否影响本迭代目标、是否有可替换的等量工作、是否能在剩余时间内完成。三个条件都满足时，由产品负责人和迭代负责人共同确认，同步调整承诺范围并记录变更原因；不满足时放入待办列表，参与下一轮排序。把每次插入的原因记录下来，回顾时可以分析范围波动的来源，判断是排序口径问题还是外部协作问题。
未完成的工作项在什么情况下应该关闭，而不是放进下一迭代？
逐项评估时，如果业务价值已消失、需求被其他工作项替代、或原定场景不再需要，就应关闭并记录结论。价值仍成立但优先级下降的，回到待办列表重新排序；因粒度太大导致未完成的，先拆分再决定去向；价值高且阻塞已消除的，才纳入下一迭代承诺范围，并重新核算容量。关闭同样需要留痕，便于后续追溯决策依据。
团队规模较小、角色不全时，迭代管理怎么分工？
角色可以兼任，但职责要提前约定并写下来。产品负责人缺位时，由熟悉业务需求的成员临时代理排序和验收确认，事后补确认；迭代负责人缺位时，指定一名成员主持同步和阻塞跟进；质量角色缺位时，验收标准由产品负责人和研发共同核对，测试执行可以延后但不跳过。替代安排要在迭代启动时明确，避免出现无人负责的环节。
回顾会开得热闹但改进落不了地，问题出在哪？
常见原因是改进项写得太大或没有验证方式。把改进项收敛为具体动作，写清负责人、完成时限和可观察的验证方式，例如“下一迭代计划会前完成外部依赖确认清单，并在会上试用一次”。数量控制在团队能执行的两到三项，作为工作项进入下一迭代，在每日同步中检查进展，下一轮回顾时验证效果；未完成的改进项要说明原因，避免无声消失。
