迭代执行跟踪要回答“这个迭代现在做到哪、还差什么、偏差怎么处理”，依据来自四类信息：迭代承诺、工作项实时状态、过程记录和可核对的产出证据。跟踪时以迭代开始时确认的目标、范围与验收标准为基准，逐项比对计划与实际；出现偏差要记录原因和处置，未完成工作重新评估后再决定去向，不默认结转到下一个迭代。
要点总览（TL;DR）
- 迭代执行跟踪的依据分四类：迭代承诺（目标、范围、验收标准）、工作项实时状态（状态、剩余工作量、阻塞）、过程记录（站会、评审、变更与决策）、产出证据（完成定义、测试与交付记录），四类缺一不可。
- 依据采集跟随迭代节奏：计划会锁定承诺基线并记录版本，站会更新状态与剩余工作量并登记阻塞，变更时记录原因、影响与决策人，迭代末按完成定义逐项核对证据并形成偏差清单。
- 执行成员提供状态与证据，迭代负责人汇总偏差并组织核对，产品负责人决定范围变更与未完成工作的去向，记录人维护变更与决策记录的可追溯性。
- 未完成工作需经产品负责人重新评估后再决定去向，不默认结转到下一轮迭代；偏差判断要有基线可比、有记录可查、有证据可核。
- 跟踪收尾前逐项检查：基线版本与变更记录一致、状态更新到最终状态、偏差均有原因与处置、未完成工作有重新评估记录、证据可被他人复核，未通过项作为阻断项处理。
迭代执行跟踪要盯住哪几类依据
跟踪依据可以按“承诺—状态—过程—证据”四层来准备。承诺类回答“本来要做什么”，状态类回答“现在做到哪”，过程类回答“中途发生了什么、谁做了决定”，证据类回答“做完的部分是否真的达到标准”。四类信息缺一类，跟踪结论就容易变成口头判断。
| 依据类别 | 具体内容 | 用途 | 更新时点 |
|---|---|---|---|
| 迭代承诺 | 迭代目标、范围清单、验收标准 | 作为比对基准，判断哪些工作属于本迭代承诺 | 迭代计划会结束时锁定，变更时追加版本 |
| 工作项状态 | 工作项状态、剩余工作量、阻塞标记 | 反映实时进展，识别停滞与风险 | 每日站会前后更新，状态变化即时更新 |
| 过程记录 | 站会记录、评审结论、变更与决策记录 | 解释偏差成因，保留决策依据 | 会议或决策发生时记录 |
| 产出证据 | 完成定义、测试结果、交付或演示记录 | 验证“已完成”是否成立，支撑验收 | 工作项进入待验收或完成状态时补齐 |
四类依据的作用不同，不能互相替代。状态看板显示“已完成”，仍需要测试结果或演示记录来证明符合验收标准；站会记录写了“受阻”，仍需要状态中的阻塞标记和剩余工作量来量化影响。迭代承诺则是判断范围是否被悄悄扩大的唯一基准。
在工具层面，这些依据需要有承载位置。以ONES为例，需求和相关任务可以规划至迭代并分配负责人，团队围绕工作项和迭代安排协同，及时了解任务状态与待处理事项；看板和燃尽图用于呈现当前进度，工时统计与报表可用于复盘进度、质量和成本偏差。承诺基线的版本化留痕、阻塞原因的结构化登记方式，需要团队在选型或配置时另行确认。
按迭代节奏采集与核对依据的步骤
依据采集要跟着迭代节奏走：开始时锁定基线，过程中持续更新，变更时留痕，结束时集中核对。每个动作都要有明确输入、做法、输出和完成标志，避免“会上说过了”成为唯一记录。
迭代开始：锁定承诺基线
- 输入：产品待办列表中已排定优先级的需求、团队对验收标准的讨论结果。
- 动作：在迭代计划会上确认本迭代目标、范围清单和每项工作的验收标准，形成基线并记录版本号或锁定时间。
- 输出：迭代承诺基线，含目标、范围、验收标准三部分。
- 完成标志：团队对范围与验收标准达成一致，基线有明确版本，后续变更可与之比对。
每日站会：更新状态与剩余工作量
- 输入：前一日的状态记录、当日工作计划。
- 动作：执行成员更新工作项状态和剩余工作量；遇到阻碍的，登记阻塞标记、阻塞原因和需要谁支持。
- 输出：当日状态快照、阻塞清单。
- 完成标志：看板状态与实际进展一致，剩余工作量有更新，每个阻塞都有责任人和预计解除时间。
迭代中变更：记录原因、影响与决策人
- 输入：变更请求或新出现的约束条件。
- 动作：记录变更内容、提出原因、对范围与进度的影响，由有决策权的人确认是否纳入本迭代。
- 输出：变更记录，含变更前后范围对比和决策结论。
- 完成标志：变更记录可追溯到决策人和决策时间，承诺基线同步更新版本。
迭代末：用完成定义逐项核对证据
- 输入：承诺基线、工作项状态、测试结果、演示或交付记录。
- 动作：按完成定义逐项核对每项工作，标记“达标”“有偏差”“未完成”，形成偏差清单。
- 输出：偏差清单，含偏差描述、证据、原因和初步处置建议。
- 完成标志：每项承诺工作都有核对结论，偏差均有对应证据支撑。
测试环节的证据尤其需要提前准备。测试工程师可以依据迭代需求与验收标准编写并执行测试用例，未通过的用例转为缺陷并指派修复，研发与测试共同关注测试情况和修复进度，这些记录构成迭代末核对的重要证据来源。
谁提供依据、谁核对、谁做处置决定
跟踪失效常见的原因是“大家都在跟，但没人对依据负责”。把提供、核对、决策三类职责分开，并明确各自交付物，跟踪才能从口头同步变成可追溯的记录。
| 角色 | 负责的依据 | 主要动作 | 交付物 |
|---|---|---|---|
| 执行成员（设计、研发、测试等） | 工作项状态、剩余工作量、阻塞信息、完成证据 | 及时更新状态，登记阻塞，提交测试或演示材料 | 状态记录、阻塞登记、测试结果或演示记录 |
| 迭代负责人 | 汇总后的状态与偏差信息 | 组织站会与迭代末核对，汇总偏差清单，推动阻塞解除 | 偏差清单、跟踪汇总记录 |
| 产品负责人 | 范围变更请求、未完成工作 | 判断变更是否纳入本迭代，决定未完成工作的去向 | 变更决策记录、未完成工作处置结论 |
| 记录人（可由迭代负责人兼任） | 站会记录、评审结论、变更与决策记录 | 维护记录完整性，确保可追溯到人和时间 | 会议记录、决策台账 |
职责划分要落到具体工作项上。执行成员对“自己负责的工作项状态是否真实”负责，迭代负责人对“偏差是否被完整识别”负责，产品负责人对“范围变化和未完成工作怎么处理”负责。记录人维护可追溯性，避免出现“变更做过但找不到谁批的”情况。
在ONES中，需求与任务可分配负责人并规划至迭代，任务状态通过看板管理，站会中可借助看板对齐进度与风险；迭代回顾时可结合燃尽图、工时日志等报表复盘偏差。这些环节为状态更新和偏差汇总提供了承载位置，决策记录与变更留痕的具体方式仍需团队按自身流程约定。
一个迭代跟踪的填写示例
以下为演示情景，用于说明依据如何支撑一次偏差判断与处置，不代表真实项目数据。
迭代承诺：某团队的两周迭代目标为“完成订单查询接口改造并上线”。承诺范围包括接口改造、回归测试、上线文档三项，验收标准为“查询响应时间不超过约定阈值，回归用例全部通过，上线文档经评审”。基线在计划会结束时锁定，版本记为V1。
过程记录：迭代第4天站会记录显示，接口改造因依赖的测试环境未就绪受阻，工作项标记阻塞，剩余工作量从3人天调整为5人天，阻塞责任人为环境管理员。第6天阻塞解除，但回归测试启动时间推迟两天。第8天产品负责人确认新增一项“兼容旧版查询参数”的需求，记录变更原因、影响（增加约2人天）和决策结论“纳入本迭代，上线文档同步补充说明”，承诺基线更新为V2。
迭代末核对：按完成定义逐项核对，接口改造与回归测试达标，测试结果和演示记录齐全；上线文档完成但未覆盖旧版参数说明，判定为“有偏差”；新增的兼容需求因时间不足未完成，判定为“未完成”。偏差清单记录了每项结论对应的证据位置。
处置结论：上线文档偏差由文档负责人在上线前补齐并重新评审；未完成的兼容需求经产品负责人重新评估，确认优先级仍高，但需重新估算工作量后放入下一轮迭代规划，不直接默认结转。处置结论、决策人和时间一并记入跟踪记录。
这个示例的关键在于：偏差判断有承诺基线可比，偏差成因有过程记录可查，完成结论有证据可核，未完成工作的去向有明确决策人。缺少任何一环，跟踪记录都会退化为进度描述。
跟踪完成前的检查项
迭代跟踪收尾前，用下面这份清单逐项判断。每项都给出通过标准，未通过的项目应作为阻断项处理，补齐后再宣布跟踪完成。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 承诺基线是否有版本且与变更记录一致 | 基线有明确版本，每次变更后版本同步更新，变更记录可对应 | 阻断：补齐版本与变更对应关系 |
| 状态与剩余工作量是否在迭代末完成更新 | 所有承诺范围内工作项状态为最终状态，剩余工作量已归零或标注 | 阻断：由执行成员补更新 |
| 偏差是否都有原因与处置结论 | 偏差清单中每项均有原因说明、处置动作和责任人 | 阻断：由迭代负责人组织补充 |
| 未完成工作是否经过重新评估 | 每项未完成工作有重新评估记录和去向结论，无默认结转 | 阻断：提交产品负责人决策 |
| 证据是否可被他人复核 | 测试结果、演示记录、评审结论可被非当事人查阅并理解 | 阻断：补充证据或说明 |
清单之外还有两项建议核对：一是阻塞记录是否闭环，每个阻塞都有解除时间或明确的后续安排；二是跟踪记录本身是否可检索，便于迭代回顾时引用。迭代完成并发布后，可结合燃尽图、工时日志等报表复盘进度、质量和成本偏差，并将改进建议沉淀到团队知识库，让下一轮迭代的承诺基线更可靠。
常见问题
迭代进行到一半，产品负责人要求加入新需求，承诺基线怎么处理？
把这次加入当作一次正式变更来处理，而不是口头同意。记录变更内容、提出原因、对范围与进度的影响，由产品负责人确认是否纳入本迭代，形成变更记录并同步更新承诺基线的版本。这样迭代末核对时，新增需求属于V2基线内的承诺，判断“完成”还是“未完成”才有依据；如果只做口头调整，迭代末容易出现范围说不清、偏差无法归因的情况。
工作项在看板上已经拖到“已完成”，还需要额外准备什么证据？
状态变化只说明执行成员认为工作已完成，是否达到验收标准仍要按完成定义核对。通常需要测试结果、演示记录或评审结论作为支撑，并且这些材料要能被非当事人查阅和理解。迭代末核对时，把状态与证据一起看：状态为已完成但证据缺失的，先标记为待补证据，补齐后再确认达标，避免“已完成”变成没有依据的结论。
迭代末发现部分工作没做完，直接放到下一个迭代继续做可以吗？
建议先重新评估再决定去向，不默认结转。重新评估的内容包括：这项工作当前的优先级是否仍然成立、剩余工作量是否需要重新估算、是否受已完成部分影响而需要调整范围。评估结论由产品负责人确认，并记入跟踪记录，说明是放入下一轮迭代规划、拆分后分批完成，还是暂缓。默认结转会让下一轮迭代的承诺基线在开始前就带着未核实的负担。
团队规模较小，角色分工可以合并吗？
可以合并角色，但要保留三类职责的区分：状态与证据的提供、偏差的汇总核对、范围变更与未完成工作的决策。小团队中迭代负责人常兼任记录人，产品负责人也可能参与执行，此时更需要在跟踪记录中写清每项结论由谁做出、何时做出。职责合并的风险是核对与决策落在同一人身上，偏差容易被淡化，可以用迭代末检查清单做一次独立核验。
阻塞在迭代末仍未解除，跟踪记录应该怎么写？
把阻塞作为独立事项记录，写清阻塞原因、影响的工作项、已尝试的解除动作、当前责任人和后续安排。未解除的阻塞会影响相关工作项的完成判断，这些工作项按实际情况标记为未完成，并进入重新评估流程。迭代回顾时可以引用这些阻塞记录，分析是环境、依赖还是资源问题，把改进建议沉淀下来，让下一轮迭代的计划更贴近实际。
