代码关联完整率和遗漏率是一对互补指标：完整率统计“应关联的代码变更中，已关联到有效工作项的比例”，遗漏率统计同一分母中未关联或关联无效的比例，两者相加为100%。口径设计的关键在于把代码变更拆成可计数的原子对象，明确哪些变更需要追溯、关联是否有效、统计窗口如何统一，再用抽样核验校准自动统计结果。
要点总览（TL;DR）
- 两个指标共用同一分母：分母是纳入追溯范围的代码变更单元总数，完整率分子为有效关联数，遗漏率分子为未关联或关联无效数，两者之和为100%。
- 分母只纳入需要追溯的变更，纯格式调整、依赖升级、自动生成代码等无业务含义的变更按版本化规则排除；统计单元按合并请求或按提交二选一，全组织统一。
- 分子要校验关联有效性：工作项存在、状态有效、类型与指向正确，填写了关联字段不等于真实可追溯。
- 计算后必须抽样人工核验，校准自动统计的误判偏差；分母为零或样本过小时报告原始计数，不写0%或100%。
- 指标反映关联覆盖率，不直接等于代码质量或交付质量，团队间比较需先统一口径与变更构成。
评估目标：完整率与遗漏率要回答什么问题
这两个指标回答一个具体问题：一次代码变更能否回溯到它服务的需求、缺陷或任务。研发团队在发布前需要确认某个需求对应的代码是否都已合入，在复盘缺陷时需要找到引入问题的变更及其关联工作项。当关联关系缺失时，追溯链条断裂，发布范围确认和问题定位都会依赖人工回忆。
评估对象是代码变更单元与业务工作项之间的对应关系。代码变更单元指一次提交或一个合并请求，业务工作项指需求、缺陷、任务等有明确编号和状态的工作项。代码库接入配置、分支策略、评审合入规则属于工程规范范畴，不在本指标评估范围内；这些规则会影响变更的产生方式，但指标本身只统计关联关系的覆盖情况。
指标用途有三个方向。发现关联遗漏：定位哪些团队、仓库或变更类型经常缺少关联。定位薄弱环节：按仓库、团队、变更类型下钻，找到遗漏集中的位置。支撑发布追溯：在版本发布前确认该版本涉及的变更是否都能对应到工作项，为发布范围确认提供依据。三个用途都指向同一件事——让代码变更与业务工作项之间的对应关系可统计、可核查。
指标与范围：分母、分子和统计单元怎么定
两个指标共用同一分母，这是口径一致的基础。分母是统计周期内纳入追溯范围的代码变更单元总数，分子分别是已有效关联的变更数和未关联或关联无效的变更数。单位统一为“个变更单元”，不使用百分比之外的复合单位。
| 指标 | 公式 | 分子 | 分母 | 单位 |
|---|---|---|---|---|
| 关联完整率 | 有效关联变更数 ÷ 应关联变更总数 × 100% | 已关联到有效工作项的变更单元数 | 纳入追溯范围的变更单元总数 | 百分比，附分子分母原始计数 |
| 关联遗漏率 | 未关联或关联无效变更数 ÷ 应关联变更总数 × 100% | 未填写关联或关联判定无效的变更单元数 | 同上，与完整率完全一致 | 百分比，附分子分母原始计数 |
统计单元需要在全组织统一选择，常见两种。按提交统计粒度最细，能反映每一次代码写入的关联情况，但容易受压缩提交、临时提交影响，数字波动大。按合并请求统计更贴近业务变更，一个合并请求通常对应一个完整的功能点或修复，适合按版本或迭代评估。按变更行统计适合评估代码量维度的覆盖情况，但行数受重构和格式化影响，解释成本较高。多数团队选择按合并请求作为主口径，按提交作为辅助下钻口径，两者不混用在同一张报表里。
分母只纳入需要追溯的变更。以下变更可以排除：纯格式调整（如统一缩进、换行符）、依赖版本升级、自动生成的代码（如构建产物、代码生成器输出）、仅修改配置且无业务含义的提交。排除规则必须写入口径文档并版本化，每次调整排除项时记录生效时间，避免历史数据因规则变化而不可比。
时间窗按周或按版本固定。按周统计适合持续观察趋势，按版本统计适合发布前确认。跨窗口的变更以合入时间为准归属，一个合并请求只计入其合入时间所在的窗口，避免重复计数。如果团队同时使用周和版本两种窗口，需要在报表中标注口径，不直接比较两种窗口下的数值。
数据口径与证据：关联有效性如何判定
分子统计的是“有效关联”，填写了关联字段只是第一步。有效关联需要同时满足三个条件：关联的工作项存在且编号可查；工作项状态有效，即未关闭为无效状态或被删除；工作项类型与指向正确，缺陷修复应关联缺陷，功能开发应关联需求或任务，关联到无关工作项不计入有效。
计算所需字段包括：变更标识（提交哈希或合并请求编号）、提交人或合入人、关联工作项ID、关联方式（提交信息中的工作项编号、代码平台关联、手动补充关联）、合入时间、变更类型标记（用于排除项识别）。关联方式影响数据可信度，提交信息中手写的编号可能拼写错误，平台关联通常更可靠，口径文档中可对关联方式分级，但分级不改变有效性判定标准。
数据来源通常是代码平台与工作项平台的接口数据。采集时按统计窗口拉取变更清单和关联记录，与工作项状态做匹配。缺失值分两类处理：变更记录缺少关联字段，计为未关联；关联字段存在但工作项无法查询，计为关联无效并单独标记，便于后续排查是数据同步问题还是真实遗漏。无法判定的变更（如关联方式不明且工作项状态无法确认）单独列出，不计入分子分母，但在报表中披露数量，避免分母被隐性缩小。
自动统计只能判断字段和状态，无法判断关联是否“指向正确”。抽样人工核验是必要的证据补充：每个统计周期抽取一定比例的已关联变更，由熟悉业务的人确认工作项与变更内容是否匹配。抽样比例和判定标准写入口径说明，核验结果用于校准自动统计的偏差，不直接修改原始数据。
计算与评估步骤：从取数到出结论
按以下顺序执行，每一步的产物都可以被下一环节复核。
- 确定统计周期与变更清单。选定周或版本作为窗口，从代码平台拉取窗口内所有合入的提交或合并请求，形成变更清单，记录总数和合入时间分布。
- 清洗排除项并标记无法判定项。按口径文档的排除规则剔除纯格式、依赖升级、自动生成代码等变更，记录排除数量；对关联字段缺失或工作项无法查询的变更单独标记，形成三个集合：应统计、已排除、无法判定。
- 计算完整率与遗漏率并交叉校验。在应统计集合内，按有效性规则划分有效关联和未关联或无效关联，分别计算两个比例，确认两者之和为100%，分子分母计数与清单总数对得上。
- 抽样核验校准自动统计偏差。从有效关联中抽取样本人工确认指向是否正确，从遗漏中抽取样本确认是否确实未关联，统计误判率，评估自动统计结果的可信区间。
- 按团队、仓库、变更类型下钻定位。在总体数字之外，按维度拆分查看遗漏集中在哪里，结合抽样核验结果判断是流程问题、工具问题还是数据同步问题。
在关联关系的日常管理上，ONES Project 可通过 Code Integration 应用支持代码集成，并在项目内监控交付数据；工作项本身承载需求、缺陷、任务的状态与类型信息，为有效性判定提供数据基础。团队可以把关联动作放在提交或合并请求环节完成，把统计和下钻放在项目视图里按迭代或版本查看，减少代码平台与工作项平台之间的人工对账。具体关联字段和报表配置以实际启用的应用和项目模板为准。
例子：一个迭代周期的完整率与遗漏率计算
假设某迭代周期内合入的合并请求共120个。按排除规则剔除纯格式调整6个、依赖升级4个，排除合计10个，应统计变更总数为110个。其中已关联且工作项存在、状态有效、类型匹配的为92个；未填写关联的14个；填写了关联但工作项已删除或类型不匹配的4个，合计未关联或无效18个。
| 项目 | 数量 | 说明 |
|---|---|---|
| 合入合并请求总数 | 120 | 统计窗口内全部合入 |
| 排除数 | 10 | 纯格式6个、依赖升级4个 |
| 应统计变更总数（分母） | 110 | 120 − 10 |
| 有效关联数（完整率分子） | 92 | 工作项存在、状态有效、类型匹配 |
| 未关联或无效数（遗漏率分子） | 18 | 未填写14个、关联无效4个 |
| 关联完整率 | 83.6% | 92 ÷ 110 |
| 关联遗漏率 | 16.4% | 18 ÷ 110 |
两个比例相加为100%，分子计数92加18等于分母110，校验通过。如果抽样核验发现92个有效关联中有5个指向了错误的工作项，则真实完整率约为79.1%，自动统计高估了约4.5个百分点，这个偏差应记录在报表附注中。
分母为零或样本过小时，不计算百分比，直接报告原始计数并标注“样本不足”。例如某仓库本周只有3个合并请求且全部排除，应统计数为0，此时完整率无定义，报表显示“本期无可统计变更”，不写0%也不写100%。不同统计单元的结果会有差异：同一批工作若按提交统计，可能因压缩提交导致提交数远少于合并请求数，完整率的分母和分子都变化，数值不可直接与按合并请求的口径比较，切换口径时需重新计算基期数据。
解读与限制：指标能说明什么、不能说明什么
完整率和遗漏率反映的是关联覆盖率，说明代码变更在多大程度上能对应到业务工作项。它不直接反映代码质量，也不等于交付质量；一个完整率100%的版本仍可能有严重缺陷，只是缺陷能被追溯到对应工作项。把完整率当作质量结论使用，会混淆追溯能力和工程质量两个不同问题。
关联字段填写不等于真实可追溯。提交信息里写了一个工作项编号，可能指向错误的需求，也可能工作项早已关闭。自动统计只能验证存在性和状态，指向正确性依赖抽样核验。没有校准环节的完整率数字，适合做趋势观察，不适合做精确结论。
团队间比较需要统一口径和变更构成。一个团队合并请求少而每个请求包含大量变更，另一个团队提交频繁且每次变更很小，两者的遗漏率不能直接比较。比较前应确认统计单元、排除规则、时间窗一致，并说明各自变更构成的差异。指标适合作为改进起点：先看总体遗漏率，再下钻到具体仓库和变更类型，结合抽样结果判断是关联习惯问题、工具入口不顺手还是数据同步延迟，然后针对性调整流程。把它作为考核的唯一依据，容易诱导为了填字段而关联，反而降低数据可信度。
常见问题
统计单元选按提交还是按合并请求，两种口径能混用吗？
两种口径可以并存，但不能混在同一张报表里直接比较。按提交粒度最细，能反映每次代码写入的关联情况，但压缩提交、临时提交会让数字波动；按合并请求更贴近业务变更，一个请求通常对应一个完整功能点或修复，适合按版本或迭代评估。常见做法是以合并请求为主口径，按提交作为下钻辅助口径。切换口径时需要重新计算基期数据，否则趋势线会失真。
排除规则调整后，历史数据还能和当期比较吗？
可以比较，前提是把排除规则写入口径文档并版本化，记录每次调整的生效时间。规则变化后，历史数据按旧规则统计、当期按新规则统计，两者分母构成不同。稳妥的做法是在规则变更时用新规则回溯重算一段历史基期，或者在报表中标注规则版本，跨版本比较时只做趋势参考，不做精确结论。
自动统计显示完整率很高，还需要人工抽样吗？
需要。自动统计只能验证关联字段是否存在、工作项是否存在且状态有效，无法判断关联是否指向了正确的工作项。提交信息里写了一个编号，可能对应错误的需求，也可能关联到无关任务。抽样核验从有效关联中抽取样本，由熟悉业务的人确认工作项与变更内容是否匹配，统计误判率后评估自动结果的可信区间。抽样比例和判定标准应写入口径说明，核验结果用于校准，不直接修改原始数据。
某个仓库本期变更全部被排除，完整率该怎么报？
分母为零时完整率无定义，报表显示“本期无可统计变更”，报告原始计数并标注样本不足，不写0%也不写100%。写0%会被误读为全部遗漏，写100%会被误读为全部关联，两种写法都会误导判断。样本过小时同样处理，直接给计数，不计算百分比。
遗漏率能不能直接用于团队绩效考核？
不建议作为唯一考核依据。指标反映的是关联覆盖率，团队间变更构成不同，合并请求少而单次变更大的团队与提交频繁的团队，遗漏率不能直接比较。作为考核指标还容易诱导为了填字段而关联，反而降低数据可信度。更合适的用法是作为改进起点：先看总体遗漏率，再按仓库、团队、变更类型下钻，结合抽样结果判断是关联习惯、工具入口还是数据同步的问题，然后针对性调整流程。
