判断一个迭代的目标是否达成，依据是迭代开始时写下的可核验承诺，包括目标结果、范围、质量门槛和时间窗；在迭代结束时用同一口径复算，再给出达成、部分达成或未达成的结论。本文按目标分类、指标口径、计算步骤和解读限制展开，并说明未完成项应逐条重新评估，不默认自动结转。
要点总览（TL;DR）
- 判定对象是迭代开始时确认的目标承诺，包括目标结果、范围、质量门槛和时间窗，迭代结束时用同一口径复算。
- 四类目标分别度量：结果类看目标结果达成率，范围类看承诺项完成数与变更数，质量类看验收通过率与遗留缺陷，时间类看是否在迭代时间窗内交付。
- 每个指标在迭代开始前写清分子、分母、统计时间窗和单位；分母为零标注不适用，缺失数据标注待补，不用估算值填充。
- 结论分达成、部分达成、未达成三档，逐项标注后汇总，并写明未达成项清单。
- 未完成项逐条重新评估，给出继续、拆分或关闭的结论，不默认自动结转。
评估目标：这次判定要回答什么问题
判定对象是本迭代开始时确认的目标承诺，而不是团队的长期绩效。这个区分决定了取数范围：只看本迭代计划中写明的目标结果、承诺交付项、质量门槛和交付时间窗，迭代之外的需求池变化、跨迭代的技术债清理、人员成长等，都不进入本次判定的分子分母。
判定结论主要服务三个用途：一是复盘本迭代的实际交付情况，形成可对照的事实记录；二是作为下个迭代计划的输入，让排期建立在真实完成能力上；三是为未完成项提供重新评估的依据，决定继续、拆分、降级还是关闭。
为避免结论被误用，判定过程需要明确不承担的任务：不做个人绩效排名，不把某一个指标当作全部结论，也不在迭代结束后临时追加或修改目标。判定问题清单可以写成三行：本迭代承诺了什么、每项承诺按什么口径核验、结论将用于哪个决策。这三行在迭代开始时填好，结束时只做复算。
指标与范围：四类目标承诺与对应指标
迭代目标通常混合了结果、范围、质量和时间四类承诺，用单一的完成率衡量所有目标，容易把“做了很多事”误读为“目标达成”。更稳妥的做法是先给每个目标归类，再为每类目标选对应指标。
| 目标类型 | 典型承诺 | 对应指标 | 单位与判定方向 |
|---|---|---|---|
| 结果类 | 某个业务或技术结果达到约定水平 | 目标结果达成率 = 实际结果 ÷ 目标值 | 百分比，达到约定阈值即为达成 |
| 范围类 | 本迭代交付指定的若干需求或功能项 | 承诺项完成数、承诺项总数、迭代内变更数 | 个，完成数等于承诺数且无未评估变更为达成 |
| 质量类 | 交付物通过验收，缺陷控制在约定范围 | 验收通过项数、遗留缺陷数、返工项数 | 个或百分比，按约定门槛判定 |
| 时间类 | 在迭代时间窗内完成交付 | 实际交付日期与迭代结束日期的关系 | 日期，交付日期不晚于迭代结束日为达成 |
范围边界需要提前说清：只评本迭代承诺的目标，不把需求池梳理、框架方法讨论、下个迭代的预研算进本次判定。若某个目标同时具备结果和范围属性，例如“上线某功能并达到约定使用量”，应拆成两条分别判定，避免一条结论掩盖另一条未达成。
数据口径：分子、分母、时间窗与缺失值
口径的作用是让迭代开始和结束时的计算方式保持一致。每个指标都应写清公式、分子、分母、统计时间窗和单位，并约定分母为零与数据缺失时的处理方式。口径表建议在迭代计划会上随目标一起确认。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 缺失或为零处理 |
|---|---|---|---|---|---|
| 目标结果达成率 | 实际结果 ÷ 目标值 | 迭代结束时的实际结果 | 迭代开始时约定的目标值 | 迭代起止日至结果统计截止日 | 结果数据未就绪时标注“待补”，不用估算值填充 |
| 承诺项完成率 | 完成数 ÷ 承诺项总数 | 状态为已完成并通过验收的承诺项 | 迭代开始时锁定的承诺项 | 迭代起止日 | 无承诺项时该指标不适用 |
| 范围变更数 | 迭代内新增、移除或替换的承诺项计数 | 变更项逐条记录 | 不设分母，单列统计 | 迭代起止日 | 无变更记为零，并注明“无变更” |
| 验收通过率 | 验收通过项数 ÷ 提交验收项数 | 通过验收的项 | 本迭代提交验收的项 | 迭代起止日 | 未提交验收时该指标不适用 |
| 遗留缺陷数 | 迭代结束时未关闭的缺陷计数 | 未关闭缺陷逐条计数 | 不设分母，按约定门槛比较 | 迭代结束日快照 | 缺陷数据缺失时标注，不按零处理 |
| 时间达成 | 实际交付日期与迭代结束日期比较 | 实际交付日期 | 迭代结束日期 | 迭代时间窗 | 未交付时记为未达成，并注明原因类别 |
迭代中途的范围变更需要单独处理：新增项计入变更数，是否计入承诺项分母取决于变更是否经过确认。经过确认纳入本迭代的，计入分母并同步更新承诺基线；未经确认的，只记变更数，不改变原分母。这样既保留原始承诺的可比性，也能反映范围波动的真实情况。
数据来源应固定为迭代计划记录、工作项状态和验收记录三类。工作项状态以迭代结束时的快照为准，避免复盘期间继续改动状态导致口径漂移。缺失数据一律标注“待补”或“不适用”，不用估算值、不用平均值填充，也不把缺失当作零。
计算与判定步骤：从取数到三档结论
判定按固定顺序执行，保证不同人复算得到相同结果。判定标准必须在迭代开始前约定，迭代结束后只做对照，不临时调整阈值。
- 锁定承诺基线。取出迭代开始时确认的目标清单，逐条记录目标类型、指标、目标值和判定标准，形成基线表。基线表一经确认，迭代中只允许通过变更记录追加，不直接覆盖原值。
- 按口径表逐项取数。对每个指标按公式取分子和分母，记录数据来源和取数时点。范围变更单独列出，注明是否经过确认。
- 逐项判定。每项标注“达成”“未达成”或“不适用”。分母为零或数据缺失的项标为不适用或待补，不强行给出达成结论。
- 汇总三档结论。全部承诺项达成且无未评估变更，判为达成；核心承诺达成、存在少量未达成项或已评估的变更，判为部分达成；核心承诺未达成，判为未达成。汇总时写明未达成项清单和每项的实际值。
三档结论的规则建议在迭代开始时就写进目标记录，例如明确哪些承诺属于核心项、部分达成的未达成项数量上限是多少。规则越具体，复盘时的争议越少。
在取数环节，如果团队使用 ONES，迭代计划会上确认的需求与验收标准可以通过子任务拆分并跟踪，测试用例未通过可转为缺陷提交，迭代进度可通过看板与燃尽图查看，回顾阶段可结合燃尽图、工时日志等报表核对进度与质量偏差。这些记录可以作为上述口径表的取数来源，具体报表形态和统计维度以团队实际配置为准。
例子：一个迭代的判定演算
以下为演示情景，用于说明计算过程，数字为假设值。
某迭代周期两周，开始时确认四项承诺：结果类目标为“新功能上线后一周内活跃使用率达到 30%”；范围类承诺交付 8 个需求项；质量类要求“提交验收项验收通过率不低于 90%，遗留严重缺陷为 0”；时间类要求“全部承诺项在迭代结束日前交付”。
迭代结束时取数如下：新功能上线一周后活跃使用率为 24%，目标结果达成率为 24% ÷ 30% = 80%，未达到约定的 100%。范围方面，8 个承诺项中完成并通过验收 6 项，承诺项完成率为 6 ÷ 8 = 75%；迭代中经确认新增 1 项、移除 1 项，变更数为 2，新增项计入分母后分母为 9，完成率调整为 6 ÷ 9 ≈ 66.7%，同时保留原始口径 75% 作为对照。质量方面，提交验收 7 项，通过 6 项，验收通过率为 6 ÷ 7 ≈ 85.7%，低于 90% 门槛；遗留严重缺陷 1 个，未满足门槛。时间方面，6 个完成项均在迭代结束日前交付，2 个未完成项跨过迭代结束日，时间类判定为部分达成。
汇总判定：结果类未达成，范围类未达成，质量类未达成，时间类部分达成，整体结论为未达成。未完成项处理建议：2 个未完成需求逐条重新评估，分别给出“下个迭代继续”“拆分后分批交付”或“关闭”的结论并记录理由；新增项按同样方式评估。未完成项不默认自动结转到下个迭代，避免承诺在迭代之间无声累积。
解读与限制：结论能说明什么、不能说明什么
达成率的高低同时受目标难度和范围变更影响。目标定得保守，达成率高并不说明交付能力强；迭代中大幅缩减范围，完成率好看也可能掩盖了原承诺未兑现。解读时应把目标值、变更数和完成数放在一起看，而不是只看一个百分比。
单指标不能代表全部目标。结果类指标反映业务效果，范围类指标反映交付数量，质量类指标反映交付可靠性，时间类指标反映节奏稳定性，四类指标合看才能形成完整判断。任何一类缺失，都应在结论中注明“该项不适用”，而不是用其他指标替代。
未达成不等于团队能力问题。判定结论需要区分三类因素：目标设定是否合理、是否存在外部依赖未就绪、执行过程是否有可改进环节。这个区分应在复盘讨论中完成，判定表本身只记录事实和数值，不承担归因结论。
结论的用途是下个迭代的计划输入和未完成项的重新评估依据。把单次迭代的达成率直接当作绩效结论，或把部分达成简化为失败，都会让后续的目标设定趋于保守，反而削弱判定的参考价值。保持口径稳定、逐项记录、结论分档，迭代目标判定才能真正成为可复算的管理动作。
常见问题
迭代目标在迭代中途调整过，判定时应该用哪个版本的目标？
以迭代开始时确认的承诺基线为准，中途调整通过变更记录追加，不直接覆盖原值。经过确认纳入本迭代的变更项，计入承诺项分母并同步更新基线；未经确认的变更只记变更数，不改变原分母。这样判定时既能保留原始承诺的可比性，也能反映范围波动的实际情况。
结果类指标的数据在迭代结束时还没出来，结论怎么给？
把该项标注为“待补”，不用估算值或历史平均值填充，也不按零处理。汇总结论时说明该项数据未就绪，其余指标照常判定。等数据出来后按同一口径补算，再更新该项的达成结论。如果结果数据的统计周期本身跨越迭代结束日，应在迭代开始时就把统计截止日写进口径表。
部分达成和未达成之间的界线怎么划，才能减少复盘争议？
界线要在迭代开始前写进目标记录，例如明确哪些承诺属于核心项、部分达成允许的未达成项数量上限。常见做法是：核心承诺全部达成且无未评估变更判为达成；核心承诺达成、存在少量未达成项或已评估变更判为部分达成；核心承诺未达成判为未达成。规则越具体，复盘时越少临时争论。
团队用 ONES 管理迭代，判定所需的取数能在哪些环节完成？
迭代计划会上确认的需求与验收标准，可以通过子任务拆分并跟踪；测试用例未通过可转为缺陷提交，研发与测试共同关注修复进度；迭代过程中通过敏捷看板管理任务状态，用燃尽图查看进度；迭代完成并发布后，可结合燃尽图、工时日志等报表核对进度与质量偏差。这些记录可以作为口径表的取数来源，具体报表形态和统计维度以团队实际配置为准。
判定结论能不能直接用于个人绩效考核？
不建议。判定对象是本迭代的目标承诺，不是个人产出。达成率受目标难度、范围变更和外部依赖影响，单次迭代的结论不足以支撑对人的评价。把判定结果直接当成绩效结论，会让后续目标设定趋于保守，反而削弱这套方法的参考价值。结论更适合作为下个迭代的计划输入和未完成项重新评估的依据。
