混合项目里，进度百分比和迭代速率最容易取数，也最容易被当成全部结论。它们能说明“做了多少”，却难以回答“交付物是否被验收”“返工是否在增加”。本文给出一套分层度量方法：阶段层看里程碑与验收，迭代层看完成量与流动，结果层看质量与返工，并统一分母、时间窗和缺失值口径，让三类指标可以组合解读。
要点总览（TL;DR）
- 混合项目要同时看三层：阶段层看里程碑达成与交付物验收，迭代层看完成量与流动效率，结果层看缺陷、返工和需求变更。
- 单一进度或速率只反映“做了多少”，无法说明交付物是否被验收、返工是否在增加，只能当信号，不能当结论。
- 组合解读的前提是统一口径：分母区分计划项、承诺项、验收项，阶段与迭代分别按各自周期统计后再对齐。
- 判断顺序是先看阶段层是否达成，再看迭代层产出是否稳定，最后看结果层是否出现质量或返工异常。
- 速率类指标不宜跨团队直接比较，也不设通用达标线，应按项目自身历史基线判断趋势。
混合项目度量要回答什么问题
混合项目通常同时存在两类交付节奏：一类按阶段门推进，在需求确认、设计评审、开发完成、上线验收等节点交付文档、版本或可运行系统；另一类按迭代推进，团队在固定周期内完成一批需求或任务。度量要同时验证这两类产出，并回答三个问题：阶段成果是否按约定交付并被接收，迭代产出是否稳定且流动顺畅，交付结果的质量是否支撑后续阶段。
只看进度或迭代速率的盲区在于，它们都偏向“量”的维度。进度百分比可能来自计划完成时间与当前日期的比较，任务被标记完成并不等于交付物通过验收；迭代速率反映单位周期内完成的工作量，却无法区分完成项中返工占比、缺陷密度或需求变更带来的重复劳动。当进度正常而验收通过率下降、缺陷回流增加时，单看进度会给出过于乐观的判断。
度量结果主要服务于三类决策：阶段门是否具备进入下一阶段的条件，迭代节奏和在制品是否需要调整，质量与范围问题是否需要优先处理。评估目标可以整理为一张清单：
- 阶段交付目标：里程碑是否按基线达成，交付物是否完成评审与验收。
- 迭代产出目标：承诺项完成情况、流动效率和在制品是否处于可控范围。
- 质量与流动目标：缺陷、返工和需求变更是否在可接受范围内，是否影响后续阶段。
指标与范围：阶段层、迭代层、结果层怎么分工
分层的目的不是增加指标数量，而是让每类指标只回答自己擅长的问题。阶段层对项目整体范围和阶段门负责，迭代层对团队在固定周期内的产出负责，结果层对交付质量和变更影响负责。三层指标组合使用，才能覆盖“按计划交付”和“按节奏产出”两个侧面。
| 指标名称 | 所属层 | 回答的问题 | 不覆盖的内容 |
|---|---|---|---|
| 里程碑达成率 | 阶段层 | 计划里程碑中有多少按基线时间达成 | 交付物质量、团队投入效率 |
| 交付物验收通过率 | 阶段层 | 提交验收的交付物中一次通过的比例 | 未提交验收的工作、后续返工 |
| 迭代完成量 | 迭代层 | 迭代承诺项中实际完成的数量或工作量 | 完成项的质量、跨团队可比性 |
| 流动效率 | 迭代层 | 工作项处于活跃处理状态的时间占比 | 等待原因、优先级是否合理 |
| 在制品数量 | 迭代层 | 同一时点处于进行中的工作项规模 | 工作项难度差异、人员负载 |
| 缺陷密度或缺陷回流数 | 结果层 | 交付结果中缺陷的分布与回流情况 | 缺陷根因、组织能力评价 |
| 返工工作量占比 | 结果层 | 返工消耗的工作量占总工作量比例 | 返工是否由需求变更引起 |
| 需求变更次数或变更率 | 结果层 | 统计周期内需求范围调整的频次与幅度 | 变更合理性、客户价值判断 |
指标与项目范围要对应清楚。阶段层指标覆盖项目整体范围和阶段门，适合在阶段评审会上使用；迭代层指标覆盖单个团队或单个迭代，适合在迭代回顾中使用；结果层指标可以按阶段统计，也可以按迭代统计，用于判断质量趋势。跨范围组合时，要确认分母是否一致，例如阶段层用“计划里程碑数”作分母，迭代层用“承诺项数”作分母，两者不能直接相加。
数据口径与证据：分母、时间窗和缺失值怎么定
口径统一是组合解读的前提。分母要区分计划项、承诺项和验收项：计划项是阶段计划或项目计划中列出的工作，承诺项是迭代开始时团队确认承接的工作，验收项是实际提交验收的交付物。同一个指标换分母，结果含义会变化，因此报表中要固定分母定义并注明。
时间窗按阶段周期和迭代周期分别统计，再在对齐点上组合。阶段层指标以阶段起止日期为窗口，迭代层指标以迭代起止日期为窗口。当阶段跨越多个迭代时，先分别计算阶段窗口内的里程碑达成情况和各迭代的完成量，再在阶段评审时汇总，避免把不同周期的数据混在一个分母里。
| 指标 | 分子 | 分母 | 时间窗 | 单位 | 缺失值处理 |
|---|---|---|---|---|---|
| 里程碑达成率 | 按基线时间达成的里程碑数 | 计划里程碑总数 | 阶段周期 | 百分比 | 未到期里程碑不计入分母，单独标注 |
| 交付物验收通过率 | 一次验收通过的交付物数 | 提交验收的交付物数 | 阶段周期 | 百分比 | 未提交验收的交付物不计入分母，列入待办清单 |
| 迭代完成量 | 迭代内完成并符合完成定义的承诺项数 | 迭代承诺项数 | 迭代周期 | 项或人天 | 中途移除的承诺项单独记录，不混入完成数 |
| 流动效率 | 活跃处理时间 | 从开始到完成的周期时间 | 迭代周期 | 百分比 | 缺少状态流转记录的工作项标注为数据不足 |
| 返工工作量占比 | 返工工作项工时 | 同期总工时 | 阶段或迭代周期 | 百分比 | 未登记工时的返工项单独列出，不估算 |
定性证据与定量指标配套使用。评审记录说明交付物是否经过规定角色评审，验收单说明接收方是否确认，缺陷记录说明问题发现和关闭的时间。缺失值要如实记录，例如某迭代未登记工时，就在报表中标注“数据不足”，不用零值或平均值替代。ONES 的项目计划可以承载 WBS 和里程碑，项目计划中也能关联迭代和研发任务，为阶段层与迭代层取数提供同一项目下的记录基础；具体报表维度需要按项目实际配置。
计算与评估步骤：从取数到组合解读
计算按“先分层、再对齐、后组合”的顺序进行。每一步保留分子、分母和时间窗，保证结果可复算。
- 取阶段层数据：从项目计划中导出计划里程碑和基线时间，统计按基线达成的里程碑数，计算里程碑达成率＝按基线达成里程碑数÷计划里程碑总数×100%。交付物验收通过率＝一次验收通过数÷提交验收数×100%。
- 取迭代层数据：按迭代导出承诺项和完成项，计算迭代完成量＝完成并符合完成定义的承诺项数÷承诺项数×100%，同时记录完成项数绝对值。流动效率＝活跃处理时间÷周期时间×100%，在制品取迭代内每日进行中工作项的平均数或峰值。
- 取结果层数据：按同一时间窗统计缺陷回流数、返工工时和需求变更次数。返工工作量占比＝返工工时÷同期总工时×100%。
- 对齐时间窗：把阶段窗口内的各迭代完成量、流动效率按迭代列出，与阶段里程碑达成情况放在同一张评审表中，标注每个迭代对应的阶段位置。
- 组合判断：先看阶段层是否达成，再看迭代层产出是否稳定，最后看结果层是否出现质量或返工异常。三层都正常时，可以认为交付节奏基本可控；阶段层正常但结果层异常时，优先排查验收标准和返工来源；迭代层完成量高但结果层缺陷回流上升时，检查完成定义是否过宽。
分母为零或数据不可比时要单独处理。某阶段没有计划里程碑，里程碑达成率不计算，标注“本阶段无里程碑”；某迭代没有承诺项，完成量不计算。跨团队比较速率类指标时，先确认工作项估算口径、完成定义和迭代长度是否一致，不一致时只做趋势观察，不做横向排名。
一个混合项目的度量示例
以下为演示情景，用于说明计算方法，不代表真实项目数据。某系统升级项目分为需求确认、开发实施、上线验收三个阶段，开发实施阶段包含三个两周迭代。项目计划中设置 6 个里程碑，开发实施阶段提交验收的交付物为 10 项。
阶段层取数：6 个里程碑中 5 个按基线时间达成，里程碑达成率＝5÷6×100%≈83.3%。10 项交付物中 7 项一次验收通过，验收通过率＝7÷10×100%＝70%。
迭代层取数：三个迭代承诺项分别为 20、18、16 项，完成并符合完成定义的分别为 17、15、14 项，完成率分别为 85%、83.3%、87.5%。第二个迭代流动效率为 45%，在制品峰值为 9 项，高于前两个迭代的 6 项和 7 项。
结果层取数：开发实施阶段缺陷回流 12 个，返工工时 96 人时，同期总工时 1200 人时，返工工作量占比＝96÷1200×100%＝8%。需求变更 4 次，其中 3 次发生在第二个迭代。
组合解读：里程碑达成率 83.3% 说明阶段整体接近计划，但验收通过率 70% 提示交付物质量存在缺口；第二个迭代在制品峰值升高、流动效率偏低，同时需求变更集中发生，返工占比 8% 与缺陷回流 12 个相互印证。结论是进度信号正常，质量与范围信号偏弱，应优先检查第二个迭代的变更管理和验收标准，而不是继续提高迭代完成量目标。该示例适用于单项目、阶段与迭代并存的场景；跨项目汇总时需要重新统一分母和完成定义。
解读与限制：指标不能当因果保证
指标反映的是现象，不是原因。验收通过率下降可能来自需求理解偏差、评审标准变化或测试资源不足，单看数字无法区分。解读时应结合评审记录、缺陷记录和变更记录，把指标当作提问的起点，而不是绩效结论。
速率类指标不宜跨团队直接比较。不同团队的工作项拆分粒度、估算习惯和完成定义不同，完成量高低不能直接说明效率高低。比较应在同一团队的历史基线内进行，观察趋势变化。项目也不设通用达标线，里程碑达成率、验收通过率、返工占比的合理区间要按项目自身历史数据和阶段特点确定。
度量本身有成本。指标越多，取数和核对投入越大，团队也可能为了指标好看而调整记录方式。建议把指标控制在能支撑阶段评审和迭代回顾的最小集合，先保证分母、时间窗和缺失值口径稳定，再逐步补充结果层指标。ONES 的项目报表支持自定义数据范围和维度，可以作为承载分层指标的取数入口；报表口径仍需项目团队自行确认并保持一致。
常见问题
阶段跨越多个迭代时，里程碑达成率和迭代完成量应该怎么放在一起看？
先分别统计，再在对齐点汇总。阶段层指标以阶段起止日期为窗口，迭代层指标以迭代起止日期为窗口；阶段跨越多个迭代时，把阶段窗口内各迭代的完成量、流动效率按迭代逐条列出，与里程碑达成情况放在同一张阶段评审表中，并标注每个迭代对应的阶段位置。这样既保留迭代节奏的细节，也能在阶段门判断整体交付情况，避免把不同周期的数据混进同一个分母。
团队没有登记工时，返工工作量占比还能算吗？
缺少工时记录时，返工工作量占比不计算，在报表中标注“数据不足”，不用零值或平均值替代。可以先用可获得的替代证据支撑判断，例如返工工作项数量、缺陷回流数、缺陷从发现到关闭的时间，以及评审记录中记录的返工原因。等工时登记口径稳定后再补算占比，并把前后口径变化在报表中注明，避免趋势被口径调整干扰。
迭代完成量高、验收通过率低，应该先处理哪一头？
先查验收标准和完成定义。完成量高而验收通过率低，常见原因是完成定义过宽，工作项被标记完成时尚未满足验收条件。可以对照一次验收未通过的交付物，看问题集中在需求理解、评审角色缺位还是测试覆盖不足，再决定是收紧完成定义还是补充评审环节。此时继续提高完成量目标，通常只会放大返工。
不同团队的迭代速率能不能放在一张报表里排名？
不建议直接排名。不同团队的工作项拆分粒度、估算习惯、完成定义和迭代长度可能不同，完成量高低不能直接说明效率高低。跨团队使用时，先确认这些口径是否一致；不一致时只做趋势观察，比较同一团队自身历史基线的变化。确需横向对照，应改用口径更稳定的指标，例如流动效率和在制品规模，并说明统计范围。
指标数量控制在多少比较合适？
以能支撑阶段评审和迭代回顾的最小集合为准，没有统一数量标准。起步阶段可以每层保留一到两个核心指标：阶段层用里程碑达成率和交付物验收通过率，迭代层用完成量和在制品，结果层用缺陷回流数和返工占比。先保证分母、时间窗和缺失值口径稳定，再根据实际暴露的问题补充指标。指标越多，取数和核对成本越高，也越容易诱导团队调整记录方式。
