迭代目标达成情况用哪些指标衡量

衡量迭代目标达成情况，需要先把迭代目标拆成可核验的承诺项，再用一组互补指标分别回答“承诺做完没有、做完的质量如何、过程是否偏离、未完成部分怎么处理”。核心指标包括迭代承诺完成率、目标达成率、范围变更率、缺陷与返工比例，以及未完成项的重新评估结论。这些指标只有在分母、时间窗和缺失值处理事先约定后，才能在不同迭代之间比较。

要点总览（TL;DR）

• 衡量迭代目标达成，先把目标拆成目标项与承诺项两层清单，再计算五类互补指标：迭代承诺完成率、目标达成率、范围变更率、缺陷逃逸比例、未完成项重新评估率。
• 每个指标都要事先约定分子、分母、时间窗和缺失值规则：承诺项以迭代启动评审确认的清单为分母，中途变更单独记录，分母为零时记为不适用而非0。
• 判定档位分全部完成、核心目标完成、部分完成需重评估三档，评估时点统一放在迭代结束评审会，阈值参考团队历史基线并在迭代启动前公布。
• 完成率高可能来自承诺项定得少，范围变更率高会让完成率失真，指标需并列解读，作为诊断信号而非绩效结论。
• 未完成工作需逐项重新评估并给出顺延、拆分、取消或转待办的结论，不默认自动结转到下一迭代。

评估目标：先定义“达成”指什么

“迭代目标达成”本身是一个模糊表述。同一个迭代，产品负责人可能认为核心功能上线即算达成，研发负责人可能认为全部承诺项关闭才算达成。评估之前需要把判定对象和判定档位固定下来，否则后续指标没有稳定的分母来源。

建议把迭代目标分成两层。第一层是目标项，指本次迭代希望实现的业务或交付结果，例如“完成订单模块的支付链路改造并支持两种支付方式”。第二层是承诺项，指团队在迭代计划会议上确认要完成的工作项，通常对应需求、任务或缺陷修复条目。目标项回答“为什么做这个迭代”，承诺项回答“这个迭代具体交付什么”。两层都要有清单，指标才有可核验的对象。

达成判定可以分三档，评估时点统一放在迭代结束评审会上，迭代中途的进度数据只用于过程跟踪，不用于最终判定。

判定档位	判定条件	典型情形
全部完成	承诺项全部完成，目标项全部达成	迭代按计划交付，无范围变更或变更已闭环
核心目标完成	目标项中的核心项达成，承诺项有少量未完成但已重新评估	次要需求顺延，核心业务目标已可验收
部分完成需重评估	核心目标项未达成，或未完成承诺项占比明显	关键链路未交付，需要重新排期和调整下个迭代目标

这张对照说明的作用是：每个目标项和承诺项在评审时都有明确归属，后续计算完成率时不会出现“算不算完成”的争议。哪些目标项属于核心项，应在迭代启动时标注，避免评审时临时调整标准。

指标与范围：五类互补指标及各自回答的问题

单一指标无法完整描述达成情况。完成率高可能来自承诺项定得少，目标达成率高可能掩盖范围频繁变更。下面五类指标分别承担不同判断任务，建议同时计算、并列解读。

指标	公式	分子	分母	单位	时间窗	回答的问题
迭代承诺完成率	已完成承诺项数 / 承诺项总数 × 100%	迭代结束评审时状态为已完成的承诺项	迭代启动评审确认的承诺项总数	百分比	迭代起止日期内	承诺的工作做完了多少
目标达成率	已达成目标项数 / 迭代目标项总数 × 100%	评审确认达成的目标项	迭代启动时确认的目标项总数	百分比	迭代结束评审时点	业务或交付目标实现了多少
范围变更率	（迭代内新增承诺项数 + 移除承诺项数）/ 初始承诺项数 × 100%	迭代期间新增与移除的承诺项合计	迭代启动时的初始承诺项数	百分比	迭代起止日期内	迭代范围偏离初始计划的程度
缺陷逃逸比例	迭代发布后发现的缺陷数 /（迭代内发现缺陷数 + 发布后发现缺陷数）× 100%	迭代发布后由用户或下游环节发现的缺陷	该迭代相关缺陷总数	百分比	发布后约定观察期内	交付质量是否守住
未完成项重新评估率	已重新评估的未完成项数 / 未完成项总数 × 100%	评审中给出处理结论的未完成项	迭代结束时未完成的承诺项总数	百分比	迭代结束评审时点	未交付部分是否被认真处理

缺陷逃逸比例需要额外约定观察期，例如发布后两周内。观察期长度不同，比例不可直接比较，因此同一团队应保持口径稳定。返工比例可作为辅助指标，用迭代内因缺陷或需求理解偏差而重新打开的工作项数除以已完成承诺项数，用于观察完成项的质量成本。

这五类指标的组合逻辑是：承诺完成率和目标达成率看结果，范围变更率看过程稳定性，缺陷逃逸比例看质量，未完成项重新评估率看收尾是否完整。任何一项单独拿出来都不足以判定达成档位。

数据口径与证据：分母、时间窗和缺失值怎么定

指标不可比，通常不是公式写错，而是分母和时间窗在迭代之间发生了变化。取数口径需要在团队层面固定成一份说明，每次评估按同一规则执行。

承诺项的分母以迭代启动评审确认的清单为基准。这份清单应在迭代计划会议上形成，包含工作项名称、负责人和验收标准。迭代中途新增或移除的承诺项单独记录变更时间和原因，计入范围变更率的分子，但不改动初始分母。这样完成率和范围变更率才能同时反映“做了多少”和“计划被改了多少”。

时间窗以迭代起止日期为准。跨迭代的工作项按实际归属迭代计入，一个工作项只在一个迭代中作为承诺项统计，避免重复计算。发布后缺陷的观察期从迭代发布日开始计算，观察期结束前不提前下结论。

缺失值处理遵循“不适用不等于零”的原则。某个迭代没有设定目标项时，目标达成率记为不适用，不按0%计入趋势图；没有未完成项时，未完成项重新评估率同样记为不适用。把不适用写成0会拉低历史均值，造成误判。

证据来源包括三类：迭代评审记录，用于确认目标项达成情况和未完成项处理结论；工作项状态变更记录，用于确定承诺项完成时点和范围变更；缺陷记录，用于统计迭代内缺陷和发布后缺陷。三类记录应在同一工作项管理环境中留存，评审时可直接对照，减少事后补记。

在工具承载层面，ONES 的迭代规划环节支持产品负责人按优先级将需求规划至迭代，并在迭代计划会议上与团队确认需求与验收标准，这为初始承诺清单提供了形成时点。迭代过程中团队通过敏捷看板管理任务状态，测试环节未通过用例可转换为缺陷提交至项目，状态变更和缺陷记录由此沉淀。迭代完成并发布后，团队可通过燃尽图、工时日志等报表复盘进度与质量偏差。这些记录对应上述三类证据来源，具体指标的计算口径仍需团队按本文规则约定。

计算与评估步骤：从取数到判定档位

评估可以按四步执行，每一步都有明确的产出物，便于复算和复核。

第一步，锁定初始承诺清单与目标项清单。从迭代计划会议记录中导出启动时确认的承诺项列表和目标项列表，标注核心目标项。同时整理迭代期间的范围变更记录，形成“初始清单+变更记录”两份数据。完成标志是两份清单的条目数与评审记录一致。

第二步，按公式逐项计算五类指标。先确定每个承诺项的最终状态和完成时点，再统计已完成数、未完成数、新增数、移除数、迭代内缺陷数和发布后缺陷数。逐项代入公式，保留计算底稿，记录每个数字对应的来源记录。完成标志是五项指标均有数值或不适用标记。

第三步，处理分母为零与数据不可比情形。承诺项总数为零时，承诺完成率记为不适用；目标项总数为零时，目标达成率记为不适用；初始承诺项数为零时，范围变更率记为不适用。若某迭代的缺陷观察期尚未结束，缺陷逃逸比例标注为“待定”，不参与当期档位判定。若团队中途更换了统计口径，应在评估记录中注明，该迭代数据不与旧口径迭代直接比较。

第四步，按预设阈值映射到达成档位，并记录未完成项重评估结论。阈值在迭代启动前确定，可参考团队近几个迭代的历史基线。例如核心目标项全部达成且承诺完成率不低于团队基线，可判为全部完成或核心目标完成；核心目标项未达成，则进入部分完成需重评估档位。每个未完成项都要给出处理结论：顺延至下个迭代、拆分后重新排期、取消或转为待办。完成标志是评审记录中每个未完成项都有结论和责任人。

例子：一个迭代的指标计算演示

以下为演示情景，数据为假设值，用于展示公式代入和档位判定过程。

某迭代启动时确认承诺项20项、目标项4项，其中核心目标项2项。迭代期间新增承诺项3项、移除1项。迭代结束评审时，已完成承诺项17项，未完成3项；4个目标项中达成3项，未达成的1项属于核心目标项。

指标	代入计算	结果
迭代承诺完成率	17 / 20 × 100%	85%
目标达成率	3 / 4 × 100%	75%
范围变更率	（3 + 1）/ 20 × 100%	20%
缺陷逃逸比例	假设迭代内缺陷12个、发布后观察期内发现3个，3 /（12 + 3）× 100%	20%
未完成项重新评估率	假设3个未完成项均已给出结论，3 / 3 × 100%	100%

解读这组数据：承诺完成率85%看起来不低，但范围变更率达到20%，说明初始计划在执行中发生了明显调整，完成率需要结合变更情况看。目标达成率75%，且未达成的是一项核心目标项，按预设档位应判为“部分完成需重评估”，而非“核心目标完成”。未完成项重新评估率100%，说明3个未完成项都已明确处理方式，例如其中2项顺延至下个迭代、1项拆分后重新排期，收尾环节完整。

如果该团队预设的档位规则是“核心目标项全部达成才可判为核心目标完成”，那么本例的判定结论就是部分完成需重评估，下个迭代需要优先安排未达成的核心目标项。这个例子也说明，单看85%的完成率会高估达成情况。

解读与限制：指标能说明什么、不能说明什么

这些指标是诊断信号，用于定位迭代执行中的问题，不能直接作为个人或团队的绩效结论。解读时需要注意以下几点。

• 高完成率不等于目标有价值。承诺项定得少、定得容易，完成率自然高。需要把承诺完成率和目标达成率并列看，目标项是否达成才反映业务结果。
• 范围变更率高时，完成率会失真。新增承诺项会稀释完成率，移除承诺项会抬高完成率。范围变更率超过一定水平时，应优先讨论计划稳定性，而不是追问完成率高低。
• 不设通用达标线。不同团队、不同迭代类型的历史基线差异很大，阈值应结合本团队近几个迭代的数据确定，并在迭代启动前公布，避免事后调整标准。
• 缺陷逃逸比例受观察期影响。观察期未结束时该指标待定，不能拿不完整数据与其他迭代比较。
• 未完成工作需重新评估，不默认自动结转到下一迭代。每个未完成项都应有明确结论：顺延、拆分、取消或转待办。重新评估率低，说明收尾环节缺失，下个迭代的计划可信度也会受影响。
• 指标反映的是承诺与结果之间的关系，不解释原因。完成率下降可能是需求拆分过粗、依赖未就绪或人员变动，需要结合评审记录和过程数据进一步分析。

把五类指标放在一起，配合固定的分母、时间窗和缺失值规则，团队就能对每个迭代给出一致的达成判定，并把未完成部分的处理落到下一个迭代的计划中。

常见问题

迭代中途新增的需求，应该算进承诺完成率的分母吗？

不建议改动初始分母。承诺完成率的分母以迭代启动评审确认的清单为基准，中途新增或移除的承诺项单独记录变更时间和原因，计入范围变更率的分子。这样完成率反映“初始承诺做了多少”，范围变更率反映“计划被改了多少”，两个指标可以并列解读。如果把新增项直接并入分母，完成率会随计划调整而波动，跨迭代比较就失去意义。

团队第一次做这套度量，阈值应该怎么定？

先积累两到三个迭代的实际数据，再确定阈值。第一轮评估可以只计算指标、记录结果，不急于判定档位；等有了历史基线，再在迭代启动前公布档位规则，例如“核心目标项全部达成且承诺完成率不低于近三个迭代中位数”判为核心目标完成。阈值一旦公布，同一评估周期内不因结果好坏临时调整，否则档位判定会失去可比性。

缺陷逃逸比例的观察期还没结束，当期评估怎么处理？

把该指标标注为“待定”，不参与当期档位判定，其余四类指标照常计算。观察期结束后补录发布后发现的缺陷数，再回填该迭代的缺陷逃逸比例。需要注意的是，不同迭代的观察期长度应保持一致，否则回填后的数据也不可直接比较。如果团队刚调整过观察期口径，应在评估记录中注明，新旧口径的迭代分开看趋势。

未完成项重新评估率是100%，是否说明迭代收尾没问题？

只能说明每个未完成项都给出了处理结论，不能说明结论合理。评估时还要看结论的质量：顺延项是否进入下个迭代的候选清单、拆分项是否有明确的拆分依据、取消项是否记录了原因。如果结论普遍是“顺延”而没有重新排期，下个迭代的承诺清单会持续膨胀，计划可信度下降。重新评估率适合与范围变更率、下个迭代的承诺完成率一起观察。

这些指标可以直接用于个人绩效考核吗？

不建议直接使用。承诺完成率、目标达成率受需求拆分粒度、依赖就绪情况和迭代类型影响，单看数值高低无法区分执行问题与计划问题。更合适的做法是把指标用于迭代回顾，定位具体偏差，例如范围变更集中在哪类需求、缺陷逃逸来自哪个环节，再把改进动作落到下个迭代的计划和验收标准上。绩效评价需要结合角色职责和过程贡献另行设计。