如何判断一个迭代的目标是否达成：口径、计算与解读

判断一个迭代的目标是否达成，核心是把迭代目标拆成可核验的承诺项——交付范围、验收标准、质量门槛和关键结果，再为每项设定判定口径，按“关键项优先”的规则汇总。本文给出一套可复算的判定方法，覆盖口径定义、计算步骤、完整示例和结论解读，适用于单个迭代结束时的目标验收。

要点总览（TL;DR）

• 判定迭代目标是否达成，先把目标还原为承诺交付范围、验收标准、质量门槛和关键结果四类承诺项，再逐项核对。
• 每项指标写清分子、分母、时间窗和数据来源；分母为零记为不适用，数据缺失记为证据不足，不默认通过。
• 汇总按关键项优先：关键项全部通过且非关键项在容忍范围内记为达成，关键项通过但有非关键项偏差记为部分达成，任一关键项未通过或证据不足记为未达成。
• 未完成的工作项重新评估优先级和必要性后再决定去向，不默认结转到下一迭代。
• 单次达成结论反映该迭代承诺兑现情况，使用时应标注范围变更与证据缺口，不宜直接当作团队绩效评价。

评估目标：迭代结束时到底要判定什么

迭代结束时的判定对象是“这个迭代承诺了什么、兑现了多少”，而非“团队这段时间做了多少事”。判定前先把迭代目标还原为四类构成：承诺交付范围（计划内要完成的需求或工作项）、验收标准（每项交付物被接受的条件）、质量门槛（缺陷、测试通过率等底线要求）、关键结果（若迭代设定了业务或技术指标，需明确目标值与统计方式）。这四类构成共同定义了一个迭代的“承诺清单”，判定就是逐项核对这张清单。

判定结论建议只取三种取值，避免模糊表述：

• 达成：全部承诺项通过，或关键项全部通过且非关键项的偏差在事先约定的容忍范围内。
• 部分达成：关键项通过，但存在未通过的非关键承诺项，且偏差超出容忍范围。
• 未达成：任一关键承诺项未通过，或关键项证据不足无法确认。

判定时点通常设在迭代结束的评审或回顾环节，参与角色包括迭代负责人（组织核对、汇总结论）、产品负责人（确认范围与验收标准是否兑现）、质量角色（提供测试与缺陷数据）。三方对同一份承诺清单各自核对负责的部分，结论由迭代负责人汇总并记录依据，避免由单一角色凭印象下结论。

指标与范围：把目标拆成可核验的承诺项

承诺项拆解按三类展开，每类配对应的判定指标和通过标准。拆解时以迭代计划阶段确认的内容为准，计划外新增的内容单独列出，不混入原承诺项的分母。

承诺项类型	示例承诺项	判定指标	通过标准（示例，需团队事先约定）
范围类	完成需求 A、B、C 的开发与提测	承诺工作项完成率 = 已完成并达到验收标准的工作项数 ÷ 承诺工作项总数	承诺工作项全部达到验收标准
质量类	提测版本无阻断级缺陷	遗留阻断/严重缺陷数；测试用例通过率 = 通过用例数 ÷ 执行用例数	阻断级缺陷为 0；用例通过率达到约定阈值
结果类	某项技术指标或业务指标达到目标值	指标实际值对照目标值，注明统计时间窗	实际值达到或超过目标值

统计范围需要在迭代开始时固定：纳入哪些工作项、哪些需求属于本迭代承诺、哪些是中途插入的紧急需求。中途插入的需求应单独标注来源和时间，判定时既不计入原承诺项的完成率分母，也不隐藏其占用的产能——可以在结论中附注“本迭代另处理紧急插入需求 N 项”，让读者理解承诺兑现的实际背景。范围在迭代中发生正式变更的，以变更评审后的版本作为判定基准，并保留变更记录。

数据口径与证据：分子分母、时间窗与来源

每项指标都要写清分子、分母、时间窗、单位和数据来源，保证换一个人也能复算出同样结果。以“承诺工作项完成率”为例：分子是状态为已完成且通过验收的工作项数，分母是迭代计划确认的承诺工作项总数，时间窗截至迭代结束日，单位为百分比，数据来源为工作项管理系统中的状态与验收记录。质量类指标同理，需注明缺陷的严重级别定义和统计截止时间。

两类边界情况要事先定规则：

• 分母为零：如本迭代没有安排结果类指标，该项记为“不适用”，不计入汇总，也不视为通过或未通过。
• 数据缺失：某项指标缺少可信数据时，单项判定记为“证据不足”，不得默认通过；证据不足的关键项按未通过处理，并在结论中说明缺口。

定性承诺项以证据形式判定，常见证据包括验收记录（谁在何时确认接受）、评审结论（评审会纪要中的通过意见）、演示结果（演示中确认的功能表现）。证据需能对应到具体承诺项，口头确认应补记为书面记录，否则视为证据不足。

计算与评估步骤：从单项判定到整体结论

判定按四步执行，顺序固定，便于复核：

1. 逐项计算指标：按上一节的口径，对每个承诺项算出指标值，写明分子、分母和时间窗，与通过标准并排呈现。
2. 单项判定：每项给出“通过 / 未通过 / 证据不足”三种结果之一，并附一句依据说明，例如“用例通过率 92%，达到约定 90% 阈值，通过”。
3. 汇总整体结论：先看关键项——任一关键项未通过或证据不足，整体记为未达成；关键项全部通过后，再看非关键项——全部通过记为达成，存在未通过项记为部分达成。关键项的界定应在迭代开始时确定，不能在判定时临时调整。
4. 记录未通过项与证据缺口：逐条列出未通过项、原因和缺失的证据，作为结论的附件，供后续复盘和未完成工作的处理使用。

这套流程的价值在于可重复：同一份承诺清单和同一批数据，不同人执行应得到相同结论。若两次判定结果不一致，通常说明口径未写清或数据来源不统一，应回到口径定义环节修正。

示例：一个迭代的达成判定演算

以下为演示情景，数据为虚构，仅用于说明计算方法。某迭代计划确认的承诺项为：完成需求 A、B、C（关键项）；阻断级缺陷为 0（关键项）；测试用例通过率不低于 90%（非关键项）；接口平均响应时间不超过 200ms（非关键项）。

承诺项	计算过程	通过标准	单项判定
需求 A、B、C 完成	3 项中 2 项通过验收，1 项（需求 C）开发完成但未通过验收 → 2 ÷ 3 ≈ 67%	3 项全部通过验收	未通过（关键项）
阻断级缺陷为 0	迭代结束日统计，遗留阻断级缺陷 0 个	0 个	通过（关键项）
用例通过率	执行用例 120 条，通过 114 条 → 114 ÷ 120 = 95%	≥ 90%	通过
接口响应时间	压测 3 轮取平均，实际 215ms	≤ 200ms	未通过

汇总：关键项中“需求 A、B、C 完成”未通过，按关键项优先规则，整体结论为未达成。结论附注：需求 C 未通过验收，原因是验收标准中的导出功能未实现；接口响应时间超出目标 15ms，属非关键项偏差，一并记录。

未完成工作的处理：需求 C 不默认结转到下一迭代，而是由产品负责人重新评估其优先级和必要性——若仍属高价值需求，补充验收标准后重新排入后续迭代；若业务优先级已下降，则退回需求池或关闭。接口性能问题作为技术债单独登记，明确责任人和处理时间。这样处理避免了“未完成项自动顺延”造成的迭代承诺虚高。

解读与限制：结论怎么用、哪里会失真

迭代达成结论反映的是该迭代承诺的兑现情况，不能直接等同于团队能力或绩效评价。一个迭代未达成，可能源于承诺本身定得过高、范围中途扩张或外部依赖延迟，这些因素与团队投入程度并不等同。把单次达成率当作绩效结论，容易诱导团队压低承诺、回避有挑战的目标。

使用结论时注意三类失真风险：

• 范围变更的影响：中途插入紧急需求或正式变更范围，会改变承诺基线。判定时应以变更后的基线为准，并在结论中标注变更次数和插入需求数量，否则完成率会被系统性低估或高估。
• 证据不足的表述：某项关键承诺缺少验收记录时，结论应写“证据不足，按未通过处理”，并说明缺口，而不是含糊地写“基本达成”。
• 指标与目标的距离：用例通过率、响应时间等指标通过，只说明对应门槛满足，不能推断业务结果一定实现；结果类指标达成，也不代表过程质量没有问题。判定结论应分项呈现，避免用单一数字概括整个迭代。

未完成工作重新评估而非默认结转，理由在于：结转会让下一迭代的承诺基数不断膨胀，掩盖真实的交付能力；重新评估则迫使团队在每次迭代开始时正视优先级，让承诺清单保持可信。判定结论和未通过项记录，正好为下一轮迭代计划提供输入。

在工具层面，这套判定依赖工作项状态、验收记录、缺陷与用例数据、迭代范围的完整留存。ONES 的敏捷研发管理方案支持在迭代计划阶段确认需求与验收标准，并通过子任务拆分需求以便跟踪；测试工程师可依据验收标准编写并执行用例，未通过用例可转为缺陷指派修复；迭代过程中团队通过敏捷看板管理任务状态，迭代结束后可借助燃尽图、工时日志等报表复盘进度与质量偏差。这些记录为逐项核对承诺项提供了数据基础，具体报表字段和统计方式以团队实际配置为准。

常见问题

迭代进行到一半发现原定承诺明显完不成，判定基准应该怎么处理？

先确认范围是否经过正式变更评审。若产品负责人和迭代负责人已就缩减或调整承诺达成一致并留下变更记录，判定以变更后的承诺清单为基准，同时在结论中标注变更时间和变更内容。若没有正式变更，原承诺清单仍是判定基准，结论按未达成或部分达成处理，并把范围问题写入未通过项说明。两种情况下都不要在判定时临时修改关键项的定义，否则结论失去可比性。

关键承诺项的验收记录缺失，但团队口头确认已经完成，能否判为达成？

不能直接判为达成。判定要求证据能对应到具体承诺项，口头确认应补记为书面验收记录后再判定；补记之前该项记为证据不足。关键项证据不足按未通过处理，整体结论记为未达成，并在附件中说明缺口和补证计划。这样处理是为了让结论可复核，也避免后续复盘时对“到底完成没有”产生争议。

中途插入的紧急需求很多，完成率被拉低，结论怎么写才不失真？

把紧急插入需求单独列出，标注来源和插入时间，不计入原承诺项完成率的分母，同时在结论中附注本迭代另处理紧急需求的数量。这样读者既能看到原承诺的兑现情况，也能理解产能的实际去向。若插入需求多到影响原承诺的可行性，应在结论中说明这一背景，并把“迭代容量评估”作为下一轮计划的改进点，而不是简单归因于执行不力。

结果类指标在迭代结束时还没到统计时间窗，判定该怎么写？

结果类指标需要事先约定统计时间窗。若迭代结束时时间窗未到，该项记为证据不足或待定，不提前判为通过。可以给出当前时点的中间数据作为参考，但整体结论中应注明该项尚未完成判定，待数据齐全后补充。若该结果类指标属于关键项，整体结论在补证前按未达成处理，避免用未完成的数据支撑达成结论。

判定结论和复盘会是什么关系，能不能合并成一次会议？

可以合并，但两件事的输出要分开。判定输出的是承诺清单的逐项核对结果和整体结论，复盘输出的是对进度、质量、成本偏差的原因分析和改进建议。建议在同一场迭代回顾会中先完成判定核对，再进入原因讨论，避免原因分析影响对事实的认定。ONES 支持在迭代完成后通过燃尽图、工时日志等报表复盘进度与质量偏差，这些数据可作为判定和复盘的共同依据，具体报表字段以团队实际配置为准。