评估任务分解方法的实施效果，需要同时看两类指标：过程指标反映团队是否按方法稳定执行，结果指标反映执行之后交付是否发生变化。判断方法是否有效，应以同一团队、同类可执行工作项在实施前后的同口径对比为主。任务数量只说明规模，不能单独作为有效性证据。
要点总览（TL;DR）
- 评估任务分解方法要同时看两类指标：过程指标判断团队有没有按方法稳定执行，结果指标判断执行后交付是否变化。
- 过程指标包括工作项粒度分布、验收标准填写率、依赖标注率、分解完成时点、重开与返工比例，每项都要写明分子、分母、时间窗和单位。
- 结果指标包括计划达成率、周期时间、缺陷逃逸率、跨角色等待时长和返工工时占比，应与同一团队、同类工作项的实施前后同口径对比。
- 任务数量只反映规模，分解变细会让数量上升，不能单独作为方法有效的证据；结论要建立在过程与结果指标同向变化并有定性证据解释的基础上。
- 评估至少覆盖两个完整迭代，缺失值单列、分母为零记为不适用，不同团队之间各自与自身基线对比，不做直接横比。
评估目标：先明确要验证什么
评估对象是任务分解方法在团队中的执行情况与产出变化，而不是某一次分解动作完成得好不好。把“方法是否有效”拆成两个可验证的判断问题：团队有没有按方法做、做得是否稳定；按方法做之后，交付结果有没有改善。前者由过程指标回答，后者由结果指标回答。
开始取数前，先写一份评估目标说明，至少包含四项内容：
- 评估对象：哪个团队、哪类可执行工作项、覆盖哪些角色。
- 对比基线：实施前同一团队、同类工作项、同一长度的时间窗，例如实施前两个迭代对比实施后两个迭代。
- 时间窗：基线与评估窗口的起止日期，以及指标统计按工作项创建时间还是完成时间归属。
- 判断问题清单：例如“验收标准填写率是否提升”“计划达成率是否改善”“周期时间是否缩短且返工未上升”。
这份说明的作用是防止评估过程中不断更换口径。任务数量可以写进背景，用来描述规模变化，但不应出现在有效性结论的依据里。任务拆得更细，数量自然增加，这本身不说明方法有效。
指标与范围：过程指标和结果指标各看什么
指标清单要能复算，每个指标都写明分子、分母、时间窗和单位。范围限定在可执行工作项，即团队直接排期、领取和交付的最小工作单元；项目交付范围的WBS编制、需求分解与需求层级管理属于另外的管理动作，不纳入本文指标。
过程指标：方法有没有被执行
| 指标 | 计算口径 | 时间窗与单位 |
|---|---|---|
| 工作项粒度分布 | 按预估工时或故事点分档（如≤1天、1–3天、>3天），统计各档工作项数占全部工作项的比例 | 评估窗口内完成的工作项；百分比 |
| 验收标准填写率 | 填写了可核验验收标准的工作项数 ÷ 应填写验收标准的工作项总数 | 评估窗口内创建或进入开发的工作项；百分比 |
| 依赖标注率 | 标注了前置或外部依赖的工作项数 ÷ 实际存在跨角色或跨团队依赖的工作项数 | 评估窗口内的工作项；百分比 |
| 分解完成时点 | 工作项完成分解的日期与迭代开始（或承诺）日期的差值，统计中位数与分布 | 按迭代统计；天 |
| 重开与返工比例 | 被重开或退回修改的工作项数 ÷ 评估窗口内完成的工作项数 | 评估窗口；百分比 |
结果指标：交付有没有变化
| 指标 | 计算口径 | 时间窗与单位 |
|---|---|---|
| 计划达成率 | 承诺范围内按期完成的工作项数 ÷ 承诺范围内的工作项总数 | 按迭代统计；百分比 |
| 周期时间 | 工作项从进入开发到完成的时间，统计中位数与85分位 | 评估窗口内完成的工作项；天 |
| 缺陷逃逸率 | 上线后发现的缺陷数 ÷（上线前发现缺陷数 + 上线后发现缺陷数） | 与评估窗口对应的发布批次；百分比 |
| 跨角色等待时长 | 工作项在等待评审、等待联调、等待验收等状态停留的时长合计，统计中位数 | 评估窗口内完成的工作项；小时或天 |
| 返工工时占比 | 返工任务登记工时 ÷ 评估窗口内总登记工时 | 评估窗口；百分比 |
两类指标要成对使用。过程指标单独改善，说明团队在执行方法，交付是否受益还需结果指标佐证；结果指标改善而过程指标没有变化，则要检查改善是否来自其他因素，例如人员变动、需求减少或发布节奏调整。
数据口径与证据：从哪里取数、如何保证可比
取数来源以工作项记录为主：工作项的类型、预估、验收标准字段、依赖关系字段、状态流转时间、评审记录和缺陷记录。状态流转时间决定周期时间和等待时长能否算准，因此评估前要确认状态定义在基线与评估窗口内保持一致，中途改过状态机的团队需要按变更日期分段统计。
可比性处理集中在三点。第一，工作项类型、团队、迭代或时间窗在前后两个窗口保持一致，混入不同团队或不同类型的工作项会让对比失去意义。第二，按工作项规模分层，例如按预估工时分成小、中、大三档分别对比，避免前后窗口的工作项构成差异被误读为方法效果。第三，缺失值单列：未填写验收标准、未标注依赖的工作项按缺失统计，不默认视为合格；分母为零时该指标记为“不适用”并注明原因，不参与汇总，也不以零代替。
定性证据作为补充，包括分解评审记录、迭代复盘纪要、依赖协调记录。它们用来解释数字背后的原因，例如某迭代周期时间上升是因为外部依赖未及时响应，而不是分解粒度问题。定性证据不替代定量指标，两者出现矛盾时以同口径数据为准，并把矛盾本身列为待查项。
当工作项记录、状态流转和字段填写都集中在同一套工作项管理工具中时，取数会省去大量对齐工作。以ONES为例，工作项的类型、字段、状态流转和评审记录在同一处留存，评估时可以按团队、迭代和时间窗筛选工作项，导出验收标准、依赖关系与状态变更时间，用于计算上述指标。字段是否填写、状态何时变更都能追溯到具体工作项，缺失值也能按工作项逐条核对，而不是靠人工补录。
计算与评估步骤：从取数到结论的操作顺序
按以下顺序完成一次评估，每一步都留下可复查的记录：
- 锁定基线与评估窗口：确定前后两个时间窗的起止日期，固定工作项范围（团队、类型、是否包含缺陷类工作项），导出工作项清单并留存快照。
- 逐项计算：按指标定义表计算过程指标与结果指标，每个指标记录分子、分母、时间窗和单位；分母为零的指标标注“不适用”。
- 同口径对比：将基线与评估窗口的同一指标并列，必要时按工作项规模分层再比一次，观察改善是否集中在某一档。
- 交叉验证：检查过程指标与结果指标是否同向变化。过程指标未改善而结果指标改善时，需要给出解释，例如样本量小、外部因素变化，或指标本身受发布节奏影响。
- 形成结论与待验证假设：结论只写数据支持的部分，例如“验收标准填写率从62%升至88%，同期缺陷逃逸率从9%降至5%”；无法归因的部分写成待验证假设，安排下一个观察周期继续跟踪。
评估频率建议与迭代节奏对齐，至少覆盖两个完整迭代再下结论，单迭代数据受需求波动影响较大。
例子：一个迭代周期的指标计算示范
以下数字仅用于演示公式与解读方式，不代表任何通用达标线。
设定：同一团队，基线为实施前两个迭代，评估窗口为实施后两个迭代，工作项范围均为该团队承诺范围内的可执行工作项。基线共40个工作项，评估窗口共52个工作项。
过程指标计算
- 验收标准填写率：基线32 ÷ 40 = 80%；评估窗口48 ÷ 52 ≈ 92.3%。
- 依赖标注率：基线实际存在依赖的工作项10个，标注6个，6 ÷ 10 = 60%；评估窗口实际存在依赖14个，标注12个，12 ÷ 14 ≈ 85.7%。
- 重开与返工比例：基线5 ÷ 40 = 12.5%；评估窗口4 ÷ 52 ≈ 7.7%。
结果指标计算
- 计划达成率：基线承诺36个、按期完成27个，27 ÷ 36 = 75%；评估窗口承诺45个、按期完成38个，38 ÷ 45 ≈ 84.4%。
- 周期时间：基线完成工作项的中位周期为6.5天，评估窗口为5.8天；同时看85分位，基线14天、评估窗口13天，说明改善主要来自中位数附近的工作项。
如何解读任务数量增加
评估窗口工作项从40个增至52个，数量上升30%。如果只看数量，容易得出“分解更充分、产出更多”的结论。但数量增加可能来自需求变多或拆分更细，与交付改善无关。本例中计划达成率提升约9个百分点、周期时间中位数缩短0.7天，同时验收标准填写率和依赖标注率上升、返工比例下降，过程与结果同向变化，才构成方法执行改善的初步证据。若数量增加而计划达成率、周期时间均未改善，更可能说明分解粒度变细但依赖管理没有跟上，需要回到过程指标查找原因。
解读与限制：指标能说明什么、不能说明什么
单个指标不能代表方法整体有效。验收标准填写率上升，只说明填写动作被执行，不能推出交付质量提升；周期时间缩短，也可能来自需求变小或评审流程简化。结论应建立在过程指标与结果指标同向变化、且有定性证据解释的基础上。
指标改善与方法之间的因果关系需要交叉证据支持。同口径前后对比能排除一部分干扰，但人员调整、需求结构变化、发布节奏改变仍可能同时发生。评估报告应写明这些因素，并把无法排除的部分列为待验证假设，而不是直接归因于分解方法。
任务数量只反映规模。分解粒度变细会让数量上升，粒度变粗会让数量下降，两者都不直接说明方法有效或无效。把数量作为结论依据，容易把拆分动作本身当成成果。
不同团队、不同工作项类型之间不宜直接横比。各团队的工作项定义、状态机和需求来源不同，横向比较会把口径差异当成能力差异。跨团队参考时，应各自与自身基线对比，再比较变化方向。
设定观察周期，避免短期波动被当作结论。建议至少覆盖两个完整迭代，并在结论中注明观察窗口；若指标在下一个周期回落，应重新检查执行稳定性，而不是沿用上一次结论。
常见问题
团队刚开始实施任务分解方法，第一个迭代的数据能用来下结论吗？
不建议。单迭代数据受需求波动、人员请假和发布节奏影响较大，指标容易失真。建议至少覆盖两个完整迭代再形成初步结论，并在报告中写明观察窗口的起止日期。如果第一个迭代就出现明显异常，例如验收标准填写率骤降，可以把它当作执行问题及时纠正，但不宜据此判断方法整体是否有效。
过程指标改善了，结果指标没有变化，应该怎么处理？
这种情况说明团队在执行分解动作，但交付尚未受益，需要继续排查。先检查结果指标的时间窗是否足够长，周期时间和缺陷逃逸率往往滞后于过程改善；再按工作项规模分层，看改善是否只集中在某一档；最后结合评审记录和复盘纪要，确认是否存在外部依赖、需求变更等干扰因素。把无法解释的部分写成待验证假设，安排下一个观察周期继续跟踪，而不是直接宣布方法无效或有效。
验收标准填写率的分母怎么定？没有验收标准的工作项算不算合格？
分母应是评估窗口内应填写验收标准的工作项总数，通常包括进入开发或承诺范围内的工作项，纯事务性、无需验收的工作项可以事先约定排除并写明理由。未填写验收标准的工作项按缺失统计并单列，不默认视为合格。如果分母为零，该指标记为“不适用”并注明原因，不参与汇总，也不以零代替，否则会拉低或虚高整体比例。
不同团队的工作项定义不一样，能不能直接比较谁的分解方法效果更好？
不宜直接横比。各团队的工作项粒度、状态机、需求来源和统计口径不同，直接比较会把口径差异当成能力差异。可行的做法是每个团队先与自身实施前的基线对比，观察变化方向和幅度，再在口径说明一致的前提下参考其他团队的变化趋势。跨团队比较时，应同时列出工作项类型、时间窗和分母定义，让读者能判断数据是否可比。
评估取数时，工作项记录分散在多个表格和工具里，怎么保证口径一致？
先固定一份取数清单，写明每个指标的数据来源字段、统计时间归属（按创建时间还是完成时间）和筛选条件，然后从同一批工作项记录中导出数据，避免不同来源混算。状态流转时间要确认基线与评估窗口内状态定义一致，中途改过状态机的按变更日期分段统计。当工作项的类型、字段、状态流转和评审记录集中在同一套工作项管理工具中时，可以按团队、迭代和时间窗筛选并导出，缺失字段逐条核对，减少人工补录带来的口径偏差。
