维护 Definition of Done（DoD）的持续投入由四类活动构成：检查项维护、评审执行、质量返工和配套支撑。本文以迭代为基本核算周期，把各项投入统一折算为人时，并区分团队已知事实与演示用假设，帮助你把 DoD 维护纳入预算与资源安排。
要点总览（TL;DR）
- 维护 DoD 的持续投入分四类：检查项维护、评审执行、质量返工、配套支撑，统一折算为人时/迭代后可与返工节省直接对照。
- 投入产出用净投入产出比和回收周期两个指标衡量；首期常为负值，应看多个迭代的累计净节省，而非单迭代结果。
- 测算前把团队人数、迭代长度、条目数等事实项与返工率、单条维护耗时等假设项分开标注，假设参数可替换才能复算。
- 团队规模、迭代长度、条目变更频率、缺陷密度和评审执行到位程度最影响结果，建议用区间测算而非单一数字。
- 工时、缺陷、验收核对和条目变更分别从看板工时日志、缺陷工单、测试执行记录和文档版本历史取数，缺失时用抽样估算并标注来源。
维护范围与时间跨度怎么界定
核算 DoD 维护投入，先要划清哪些活动算在内。范围过宽会把整个迭代管理的成本都算进来，范围过窄又会漏掉返工和培训这类真实消耗。建议以 DoD 条目本身为圆心，把围绕它发生的维护、核对、返工和支撑活动纳入核算，其余相邻工作单独归口。
统计周期以迭代为基本单位，便于与评审执行频率对齐；季度汇总用于观察趋势和做预算。迭代长度不一致时，先折算成“人时/迭代”，再按季度迭代数汇总，避免直接相加造成口径混乱。
| 类别 | 纳入项 | 排除项及归口 |
|---|---|---|
| 检查项维护 | DoD 条目的复核、增删、版本记录 | — |
| 评审执行 | 每次迭代按 DoD 核对验收结果的工时 | Sprint 评审会议的组织流程归迭代管理 |
| 质量返工 | 条目未达成引发的返工与缺陷处理 | 与 DoD 无关的常规缺陷修复不计入 |
| 配套支撑 | DoD 文档承载、培训、跨团队对齐 | Sprint 规划、执行、回顾归迭代管理；Product Backlog 维护归需求池管理 |
| 统计周期 | 以迭代为单位，按季度汇总 | — |
| 计量单位 | 人时/迭代；工具费用按席位与计费周期 | — |
这张表的作用是让不同团队用同一把尺子统计。若某团队把回顾会上的 DoD 讨论也计入维护，需要单独标注，否则跨团队对比时会出现口径差异。
持续投入包含哪些成本和资源项
把投入拆成可计量的成本项，才能落到责任角色和发生频率上。四类成本项的性质不同：检查项维护是低频但需要判断力的工作，评审执行是每迭代固定发生的工作，质量返工是波动最大的工作，配套支撑则随团队规模和协作复杂度变化。
| 成本项 | 具体活动 | 单位 | 责任角色 | 发生频率 |
|---|---|---|---|---|
| 检查项维护 | 复核条目是否仍适用、增删条目、记录版本变更 | 人时/次 | Scrum Master 或技术负责人牵头，团队参与 | 每季度或条目触发变更时 |
| 评审执行 | 按 DoD 逐条核对迭代产出与验收结果 | 人时/迭代 | 产品负责人、测试、开发共同参与 | 每迭代 |
| 质量返工 | 条目未达成导致的返工、缺陷定位与修复 | 人时/迭代 | 开发与测试 | 随缺陷发生，按迭代归集 |
| 配套支撑 | DoD 文档撰写与维护、新成员培训、跨团队对齐会议 | 人时/季度 | Scrum Master、团队负责人 | 文档随变更更新；培训按人员变动；对齐按需 |
需要提醒的是，质量返工既是投入项，也是衡量 DoD 是否有效的观察对象。返工人时高，可能说明条目设置过严或执行不到位；返工人时持续走低，则可能说明 DoD 已内化为团队习惯。核算时把它单列，不要和维护工时混在一起。
口径与假设怎么设定
测算能否复算，取决于事实项和假设项是否分开标注。团队人数、迭代长度、参与评审的角色数量属于已知事实，直接采用；返工率、单条维护耗时、培训频次往往缺少现成数据，需要设为可替换的假设参数，并注明来源是历史均值、抽样估算还是经验判断。
| 参数 | 类型 | 示例取值 | 来源与替换方式 |
|---|---|---|---|
| 团队人数 | 事实 | 8 人 | 按实际团队填写 |
| 迭代长度 | 事实 | 2 周 | 按实际迭代周期填写 |
| DoD 条目数量 | 事实 | 12 条 | 按当前清单统计 |
| 单条维护耗时 | 假设 | 0.5 人时/条/季度 | 演示假设，可用历史工时替换 |
| 评审执行工时 | 假设 | 4 人时/迭代 | 演示假设，可用工时日志替换 |
| 返工率 | 假设 | 迭代总工时的 8% | 演示假设，可用缺陷与返工记录替换 |
| 人力成本单价 | 假设 | 按团队实际人时成本折算 | 不给出具体金额，按内部口径填写 |
| 工具费用 | 事实/待查 | 按席位与计费周期计 | 以实际合同为准，标注币种与税费口径 |
工具费用涉及席位数量、计费周期、币种和税费，这些口径要在预算表中逐项写明，避免把不同币种或含税与不含税的数字直接相加。本文不给出具体报价，实际金额以团队合同为准。人力成本统一按人时折算，便于与返工节省在同一单位下对照。
投入产出怎么算：计算模型与预算框架
把四类投入放在同一模型里，才能回答“这些投入值不值”。投入侧按人时加总，产出侧主要看返工减少带来的人时节省，交付可预测性提升作为辅助判断，不强行折算成金额。
投入侧公式：
迭代总投入（人时）= 检查项维护人时 ÷ 季度迭代数 + 评审执行人时 + 返工人时 + 配套支撑人时 ÷ 季度迭代数
产出侧公式：
返工节省（人时/迭代）= 基线返工人时 − 当前返工人时
净投入产出比 = （返工节省 − 迭代总投入）÷ 迭代总投入
回收周期（迭代数）= 一次性投入 ÷ 每迭代净节省
下面用一组演示数值说明算法，数值均为假设，与任何真实报价无关：
| 项目 | 演示数值 | 说明 |
|---|---|---|
| 检查项维护 | 12 条 × 0.5 人时 = 6 人时/季度，约 0.9 人时/迭代 | 按每季度 6.5 个两週迭代折算 |
| 评审执行 | 4 人时/迭代 | 演示假设 |
| 质量返工 | 10 人时/迭代 | 按迭代总工时 8% 估算 |
| 配套支撑 | 8 人时/季度，约 1.2 人时/迭代 | 含文档与培训 |
| 迭代总投入 | 约 16.1 人时/迭代 | 四项相加 |
| 基线返工 | 18 人时/迭代 | 维护前的历史均值假设 |
| 返工节省 | 8 人时/迭代 | 18 − 10 |
| 净投入产出比 | 约 −0.50 | （8 − 16.1）÷ 16.1，首期可能为负 |
这组数值说明一个常见情况：DoD 维护的收益不会在第一个迭代就覆盖全部投入，尤其是配套支撑和检查项维护带有一次性成分。评估时应看多个迭代的累计净节省，而不是单迭代结果。若返工节省随迭代稳定上升，回收周期会明显缩短。
哪些因素最影响结果：敏感因素
投入产出比对几个变量特别敏感，做预算时用区间测算比给单一数字更稳妥。以下因素按影响方向列出，具体区间需团队用自身数据填充。
| 敏感因素 | 影响方向 | 测算建议 |
|---|---|---|
| 团队规模 | 人数增加会抬高评审与对齐工时，但分摊后人均维护成本可能下降 | 按 5–15 人区间分别测算 |
| 迭代长度 | 迭代越短，评审执行频率越高，单位时间投入上升 | 按 1 周、2 周、4 周三档对照 |
| DoD 条目数量与变更频率 | 条目越多、变更越频繁，维护工时越高 | 按条目数上下浮动 30% 做区间 |
| 缺陷密度与返工率 | 返工率越高，DoD 的潜在节省空间越大，投入产出比越容易转正 | 按历史返工率上下浮动测算 |
| 评审执行到位程度 | 执行不到位会让返工节省落空，投入却照常发生 | 用验收核对完成率作为调节系数 |
其中评审执行到位程度最容易被低估。条目写得再细，如果核对流于形式，返工不会减少，投入产出比会持续为负。预算中应为评审执行留出真实工时，而不是假定它“顺手就做了”。
数据从哪里取：取数方法与记录方式
测算要能复算，数据来源必须固定。各项投入和产出分别对应不同的记录载体，建议在迭代节奏中同步采集，避免事后回忆补填。
| 数据项 | 来源 | 更新频率 |
|---|---|---|
| 维护与评审工时 | 迭代看板、工时日志 | 每迭代 |
| 返工与缺陷数据 | 缺陷记录、返工工单 | 实时记录，按迭代归集 |
| 评审执行结果 | 验收核对记录、测试用例执行结果 | 每迭代 |
| 配套支撑投入 | 培训记录、文档版本记录、对齐会议纪要 | 按发生时间 |
| DoD 条目变更 | 文档版本历史 | 每次变更 |
数据缺失时，可用历史均值或抽样估算替代，并在假设表中标注估算方法和覆盖范围。例如返工工时没有单独记录，可按缺陷工单的修复耗时抽样估算，再乘以缺陷数量。估算值要标明是估算，不能与实测值混在同一列直接比较。
在工具承载上，ONES 敏捷研发管理方案把需求、研发、测试放在同一流程中，需求评审时可对验收标准达成一致，测试未通过的用例可转为缺陷并指派修复，迭代回顾可借助工时日志等报表复盘进度、质量与成本偏差。这些记录正好对应上表中的工时、缺陷和验收数据来源，便于按迭代归集后复算投入产出。DoD 条目本身及版本变更，可用 ONES Wiki 沉淀为团队知识库，保留维护痕迹。
把范围、成本项、假设、公式、敏感因素和取数方法固定下来，DoD 维护就从一项“感觉在做”的工作变成可预算、可复盘的管理投入。建议先用一个季度的真实数据校准假设，再据此安排下一周期的资源。
常见问题
DoD 条目应该多久复核一次，变更频繁会不会推高维护成本？
复核频率与变更频率需要分开看。复核可以按季度固定进行，检查条目是否仍适用；变更则由触发条件驱动，例如引入新的测试类型、合规要求变化或连续多个迭代出现同类返工。变更越频繁，维护工时越高，因此建议在变更前评估影响范围，把同类调整合并到一次版本更新中，减少反复修改带来的记录成本。
评审执行工时经常被低估，预算时怎么留出合理空间？
评审执行是每迭代固定发生的活动，按参与角色和核对条目数估算比凭经验拍数更可靠。可以先统计一个迭代中实际参与验收核对的人数和耗时，再乘以迭代数。若团队把核对分散在日常工作中，容易漏记，建议在迭代看板上为验收核对单独记录工时，避免这部分投入被隐含在其他任务里。
返工减少的收益怎么和 DoD 维护投入对应起来，避免把无关缺陷算进去？
关键是界定返工口径：只统计因 DoD 条目未达成而引发的返工与缺陷处理，与 DoD 无关的常规缺陷修复单独归集。取数时可从缺陷记录中按来源或关联条目筛选，再按迭代汇总。基线返工取维护前的历史均值，当前返工取维护后的实际值，两者口径一致才能相减得出节省。
团队规模变化后，原来的测算结果还能直接用吗？
不能直接沿用。人数增加会抬高评审与跨团队对齐工时，但维护和文档类投入在更多人之间分摊后人均成本可能下降，两个方向的影响需要重新测算。建议按实际人数所在的区间重新代入公式，并同步更新假设表中的团队人数和参与评审角色数量，保持事实项与当前组织一致。
没有完整的工时和缺陷记录时，测算还能做吗？
可以做，但要标明估算成分。常见替代方法包括：用缺陷工单的修复耗时抽样估算返工工时，再乘以缺陷数量；用历史均值替代缺失的维护耗时；用验收核对完成率作为评审执行到位程度的调节系数。估算值应与实测值分列标注，并在下一周期用真实数据校准，逐步替换假设参数。
