缺陷积压清理可以按“先定口径、再分拣、后分批修复验证、最后建防回流机制”推进。它适合存量缺陷已经影响排期、验证资源或版本判断的团队，关键条件是先统一“什么算积压”和台账字段，再逐条分类处置，避免把清理做成一次性突击。下文给出从口径、分拣到关闭检查的落地步骤。
要点总览（TL;DR）
- 先统一积压判定口径与台账字段，明确超期未关闭、长期挂起、待验证滞留三类情形的时间阈值，清理期间保持不变。
- 按严重程度、影响范围、复现状态和业务价值把存量缺陷分成立即修复、限期修复、合并或降级、关闭归档四类，每类指定责任人和时限。
- 按严重程度、模块或版本划分批次，修复后由指定验证人复测，验证不通过退回再修复，关闭以验证通过并记录结论为准。
- 清理启动时明确提交人、模块负责人、开发、验证人、项目或质量负责人、跟踪人的职责与交付物，争议由项目或质量负责人裁决。
- 批次结束用积压总数、超期数量、待验证滞留数量核对完成情况，并通过入口把关和定期盘点防止再次堆积。
先统一积压口径：哪些缺陷算积压、按什么字段分拣
清理缺陷积压的第一步是统一判定标准。不同角色对“积压”的理解常常不同：开发认为已排期的缺陷不算积压，测试认为待验证超过一周就是滞留，项目负责人则关注超期未关闭的数量。口径不统一，后续分拣和统计都会失真。建议先明确积压的判定情形，再固定台账字段，让每一条缺陷都能被同一套规则识别。
积压判定口径
积压判定应覆盖三类情形，并为每类设定可核对的时间条件：
- 超期未关闭：缺陷创建后超过约定修复时限仍未关闭，时限可按严重程度分档设定，例如严重缺陷超过3个工作日、一般缺陷超过10个工作日。
- 长期挂起：缺陷处于挂起、待定或等待外部条件状态超过约定周期，且没有明确的恢复条件和责任人。
- 待验证滞留：开发已提交修复，但缺陷停留在待验证状态超过约定天数，验证资源未及时投入。
三类情形的时间阈值需要结合团队发布节奏确定，并在清理启动前由项目负责人、质量负责人和测试负责人共同确认。阈值一旦确定，清理期间保持不变，避免边清理边改标准。
台账必备字段
缺陷台账是分拣的工作底稿，字段应保证每条缺陷可定位、可判断、可追责。建议至少包含以下字段：
| 字段 | 用途 |
|---|---|
| 缺陷编号 | 唯一标识，便于引用和去重 |
| 严重程度 | 分档依据，决定修复优先级和时限 |
| 影响范围 | 判断涉及用户、模块或版本的广度 |
| 复现状态 | 区分稳定复现、偶现、无法复现 |
| 所属模块 | 用于按模块分批和指定负责人 |
| 责任人 | 当前处理人，避免无主缺陷 |
| 创建时间与最近更新时间 | 计算超期和滞留时长 |
| 当前状态 | 识别待验证、挂起等滞留情形 |
字段缺失的缺陷应先补齐再进入分拣，否则分类判断缺乏依据。清理范围和时间窗口同样需要明确：是按全部未关闭缺陷清理，还是限定某个版本、某几个模块或某个时间区间内创建的缺陷。范围越小，首批清理越容易完成并形成示范。
口径确认后应以书面形式固化，例如形成一页清理说明，列明积压判定条件、字段清单、清理范围和责任人，由参与角色确认后作为分拣依据。在工具层面，这套台账可以直接落在缺陷工作项上，ONES 支持通过工作项字段和状态记录缺陷的责任人、严重程度与更新时间，便于按口径筛选出积压清单。
分拣与分类处置：把存量缺陷分成四类并定处理规则
分拣的目标是让每条缺陷都有明确去向，而不是逐条讨论修复方案。建议按严重程度、影响范围、复现状态和业务价值四个维度判断，将存量缺陷分成立即修复、限期修复、合并或降级、关闭归档四类，并为每类指定责任人和时限。
四类处置规则
| 类别 | 判定条件 | 处置动作 | 责任角色 | 时限 |
|---|---|---|---|---|
| 立即修复 | 严重程度高、影响核心功能或大量用户、可稳定复现 | 纳入当前批次优先修复，修复后立即安排验证 | 模块开发负责人 | 当批完成 |
| 限期修复 | 影响有限但业务价值明确，或影响特定场景用户 | 排入后续批次，明确修复版本和时间点 | 模块开发负责人 | 按批次计划 |
| 合并或降级 | 与已有缺陷重复、影响轻微、可由其他缺陷修复覆盖 | 合并到主缺陷或降低严重程度，保留记录 | 分拣评审人 | 分拣当场 |
| 关闭归档 | 无法复现且长期无新信息、需求变更导致失效、环境问题已排除 | 补充关闭原因后关闭，保留可检索记录 | 提交人或验证人 | 分拣当场或补充确认后 |
重复缺陷应合并到信息最完整的主缺陷，并在被合并记录中注明关联编号，避免丢失提交人反馈。无法复现的缺陷不宜直接关闭，先确认是否缺少复现环境或步骤；补充信息后仍无法复现且超过约定观察期的，可按关闭归档处理并注明原因。需求变更导致失效的缺陷，应关联变更说明后关闭，便于后续追溯。
分拣的组织方式
分拣建议以评审会形式集中进行，参与人包括项目或质量负责人、模块开发负责人和测试验证人。会前由跟踪人按口径导出积压清单并补齐字段，会上逐条确认分类、责任人和时限，会后形成分拣结果清单。清单应包含缺陷编号、分类结论、责任人和计划完成时间，作为后续批次执行的输入。争议条目当场无法达成一致的，由项目或质量负责人裁决并记录理由。
分批修复与验证跟踪：每批怎么排、谁修、谁验、何时关闭
分拣完成后，存量缺陷按批次进入修复和验证。批次划分可以按严重程度优先，也可以按模块或版本排期：按严重程度排有利于先消除高风险项，按模块排有利于集中熟悉代码的开发人员处理，按版本排则便于与发布计划对齐。首批建议控制规模，确保能完整走完修复到关闭的流程。
修复环节
修复的输入是分拣结果清单中属于当前批次的缺陷；动作包括开发确认复现、定位原因、提交修复并填写修复说明；输出是状态变更为待验证的缺陷记录。修复说明应写明修改内容和影响范围，便于验证人确定复测重点。完成标志是该批次所有立即修复类缺陷均进入待验证状态。
验证环节
验证人由测试负责人按模块指定，优先选择熟悉该模块的测试人员。复测内容包括原缺陷的复现步骤、修复说明中提到的关联影响点，以及必要的周边功能抽查。通过标准应在分拣时约定，例如原步骤不再复现、关联功能无新增异常。验证通过后由验证人将缺陷置为已关闭，并记录验证结论。
退回与状态流转
验证不通过时，缺陷退回开发并注明失败原因和复现信息，状态回到处理中，重新进入修复环节。退回次数较多的缺陷应在批次复盘中单独标记，判断是否需要补充信息或调整分类。状态流转建议固定为：新建→已确认→处理中→待验证→已关闭，挂起状态需填写挂起原因和恢复条件。关闭条件统一为验证通过并记录结论，避免仅凭开发口头确认关闭。
在批次执行过程中，缺陷状态、责任人和验证结论需要被持续记录，ONES 的工作项状态流转和操作记录可以承载修复、待验证、关闭等节点，跟踪人按状态筛选即可看到当前批次的滞留项。
角色与交付物分工：谁负责分拣、修复、验证和进度跟踪
清理过程涉及多个角色，职责不清会导致缺陷无人认领或验证长期滞留。建议在清理启动时明确每个角色在分拣、修复、验证、关闭节点上的动作和交付物。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 缺陷提交人 | 补充复现步骤和环境信息，配合确认无法复现缺陷 | 完整的缺陷描述与复现信息 |
| 模块负责人 | 认领本模块缺陷，安排修复优先级 | 模块修复排期与修复说明 |
| 开发人员 | 复现、定位、修复并提交待验证 | 修复记录与影响范围说明 |
| 测试验证人 | 按标准复测，给出通过或退回结论 | 验证结论与复测记录 |
| 项目或质量负责人 | 确认口径、主持分拣、裁决争议、检查完成情况 | 口径说明、分拣结果、完成检查结论 |
| 进度跟踪人 | 维护积压清单，按节奏汇报批次进展 | 批次进度表与滞留项清单 |
进度跟踪建议按批次设置固定汇报节奏，例如每两日更新一次批次内各状态数量，每周汇总一次超期和待验证滞留项。跨角色争议集中在两类：是否降级和是否关闭。降级争议由项目或质量负责人结合影响范围裁决；关闭争议由验证人提供复测证据，提交人补充信息后仍无法复现的，按约定观察期后关闭。裁决结果应记录在缺陷记录中，便于后续复查。
一个清理批次的示例：从积压清单到关闭的完整走查
以下为演示情景，用于说明一次批次清理的完整过程，数据为示例设定。
某团队按口径导出积压清单，共40条未关闭缺陷，其中超期未关闭22条、长期挂起10条、待验证滞留8条。清理范围限定为当前版本涉及的两个核心模块，时间窗口为近三个月创建的缺陷。
分拣会上逐条确认：6条严重程度高且稳定复现的列立即修复；18条影响特定场景的列限期修复，排入下一批次；9条与其他缺陷重复的合并到主缺陷；7条因需求变更失效或补充信息后仍无法复现的关闭归档。剩余条目在会中补齐责任人和时限。
首批执行立即修复的6条：开发逐条复现并提交修复说明，状态变为待验证；测试验证人对其中5条复测通过并关闭，1条复测时原步骤仍偶现，退回开发并附复现视频。开发补充修复后再次提交，第二次复测通过关闭。批次结束时，6条全部关闭，待验证滞留清零，积压清单剩余34条，其中18条已进入下一批次排期。
该示例说明批次清理的关键在于：范围可控、分类有依据、退回路径清晰、每批结束有可核对的数据。
防回流与完成检查：清理结束后如何验证效果并避免再次堆积
清理是否完成，不能只看“处理了很多条”，而要用清理前确定的口径核对结果。建议在批次结束时逐项检查：积压总数是否降到约定目标，超期未关闭缺陷是否清零或进入明确排期，待验证滞留是否在约定天数内，挂起缺陷是否都有恢复条件和责任人。任一检查项未达标，应说明原因并纳入下一批次。
入口把关
防止再次堆积要从新缺陷进入环节控制。提交缺陷时应要求填写复现步骤、环境、严重程度和影响范围，信息不全的由提交人补充后再进入分拣。分派时效同样需要约定，例如新缺陷在一个工作日内指定责任人，避免在新建状态长期停留。
定期盘点与趋势观察
建议按固定节奏盘点积压情况，例如每周查看新增与关闭数量、超期数量和待验证滞留数量，每月回顾积压趋势。趋势观察关注三个指标：积压总量变化、平均关闭时长、退回重开比例。指标持续上升时，应检查分派时效或验证资源是否不足，而不是等到积压再次扩大才启动清理。
清理效果最终用数据验证：以清理前清单为基线，对比清理后的积压数量、超期数量和待验证滞留数量，并记录各批次关闭率。将这些数据与入口把关、定期盘点结合，缺陷积压清理才能从一次行动转为可持续的跟踪机制。
常见问题
清理范围应该先选全部未关闭缺陷，还是先限定一个版本或模块？
首批建议限定范围，例如某个版本涉及的核心模块或近三个月创建的缺陷。范围小，分拣和修复验证更容易完整走完，也能先形成可复用的分类规则和批次节奏。全部未关闭缺陷一起清理，分拣会耗时过长，验证资源也容易在批次中段滞留。范围确定后写入清理说明，清理期间不随意扩大。
无法复现的缺陷在清理时可以直接关闭吗？
不宜直接关闭。先确认是否缺少复现环境、步骤或数据，由提交人补充信息后再判断。补充信息后仍无法复现的，按约定观察期观察，超过观察期仍无新信息，可按关闭归档处理，并在记录中注明关闭原因和已尝试的复现条件，便于后续追溯。
验证不通过退回后，缺陷应该回到哪个状态、由谁继续处理？
验证不通过时，缺陷退回开发并注明失败原因和复现信息，状态回到处理中，由原开发或模块负责人继续修复。退回次数较多的缺陷应在批次复盘中单独标记，判断是否需要补充信息、调整分类或增加验证资源。再次提交后仍由原验证人复测，保持验证责任连续。
清理期间新提交的缺陷要不要一起纳入当前批次？
建议分开处理。当前批次以清理启动时导出的积压清单为输入，新提交缺陷走正常分派流程，避免批次范围不断膨胀。新缺陷中严重程度高、影响核心功能的，可由项目或质量负责人决定插入当前批次，并在批次进度表中单独标注，其余按入口把关要求补齐信息后进入常规排期。
清理完成后，怎么判断积压没有重新堆积？
以清理前清单为基线，按固定节奏观察三个指标：积压总量变化、平均关闭时长、退回重开比例。每周查看新增与关闭数量、超期数量和待验证滞留数量，每月回顾趋势。指标持续上升时，检查新缺陷分派时效和验证资源投入，及时调整，而不是等积压再次扩大再启动清理。
