缺陷延期判定是什么
缺陷延期（Deferred）指已确认成立、但决定不在当前版本修复、推迟到后续版本处理。延期不是关闭也不是忽略：需要写清推迟理由、影响面、计划修复版本、复审时间点与责任人，并由产品、开发、测试共同确认。没有复审机制的延期等于石沉大海，后续版本很容易继续漏掉。
基本信息
| 判定要素 | 影响面、触发概率、有无规避方案、修复成本与收益 |
|---|---|
| 常见理由 | 优先级不足、依赖上游修复、技术方案未定、等待需求澄清 |
| 必备记录 | 延期原因、影响范围、计划版本、复审日期、责任人 |
| 审批角色 | 产品确认业务影响可接受，开发与测试评估技术影响 |
| 复审机制 | 按版本定期回扫延期清单，到期未处理自动升级提醒 |
| 工具落点 | 缺陷系统中单独状态或标签，与关闭严格区分 |
典型使用场景
- 版本节奏紧张：缺陷成立但影响局部，产品评估后同意随下个版本修复。
- 依赖外部条件：等待上游服务或第三方修复，当前无法独立解决。
- 技术方案待定：改动面大且方案未评审通过，先记录在案避免遗忘。
- 低概率边界场景：发生概率极低且有文档规避手段，进入待办池排队。
- 资源排期：修复工作超出本迭代容量，与产品协商后延后并写清风险。
- 版本收尾盘点：统一检查延期清单，逐条确认状态与计划。
延期与关闭的区别
| 处理方式 | 含义 | 记录要求 | 后续动作 |
|---|---|---|---|
| 延期 Deferred | 确认问题存在但不在当前版本修 | 原因、影响、计划版本、复审日期 | 到期复审，跟踪计划版本 |
| 关闭 Closed | 已修复并验证或判定不属于缺陷 | 验证结论或判定依据 | 问题再现时重新打开 |
| 无法复现 | 证据不足暂时搁置 | 复现尝试记录、环境信息 | 补充证据后重开 |
延期与降低优先级不同：优先级说的是排队顺序，延期决定的是是否出现在当前版本的修复清单里。
到期复审要落进流程：把延期清单加入版本收尾检查，否则没有人会主动想起它。
对用户可见的影响要同步进已知问题清单，避免支持团队在上线后被用户问住。