39 lines
1.9 KiB
Markdown
39 lines
1.9 KiB
Markdown
|
# Sprint 模式与吞吐事故：125 张 TD 碎片的教训
|
|||
|
|
|
|||
|
|
> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
|
|||
|
|
> `core/rules/workflow-routing.md`（filing.sprint-mode 开关）与
|
|||
|
|
> `core/rules/ticket-lifecycle.md`（registry-first 登记）。
|
|||
|
|
|
|||
|
|
## 背景
|
|||
|
|
|
|||
|
|
某组织在 2026-08 冲刺期发现：技术债务工单（TD）队列在数周内膨胀到
|
|||
|
|
125 张碎片工单，日均新建约 9.4 张，而 8 月之前的关闭数为零。冲刺结束
|
|||
|
|
时只能靠一次 115 张的批量清理来"清场"——清理本身又消耗了本该用于交付
|
|||
|
|
的评审与验证容量，当周交付产能接近清零。
|
|||
|
|
|
|||
|
|
## 事故链
|
|||
|
|
|
|||
|
|
1. **逐票立案的默认**：每个验证阶段发现的债务候选都独立开票——
|
|||
|
|
一次全量测试巡检就能产出十余张"发现票"。
|
|||
|
|
2. **冲刺压力下无人认领**：冲刺目标压在交付票上，TD 票无人认领、
|
|||
|
|
无人在意，队列只进不出。
|
|||
|
|
3. **批量清场反噬产能**：清场动作本身走完整管线（评审、验证、归并），
|
|||
|
|
一次性吃掉数天产能。
|
|||
|
|
|
|||
|
|
## 机制沉淀（已入 Core）
|
|||
|
|
|
|||
|
|
- **registry-first（TD 登记册）**：发现先落登记行（Tier-1 形态的廉价
|
|||
|
|
台账行），被排期或认领时才升票为独立工单——见
|
|||
|
|
`core/rules/ticket-lifecycle.md` §登记册。
|
|||
|
|
- **sprint-mode 显式降档**：冲刺期由负责人翻转
|
|||
|
|
`filing.sprint-mode` 开关，登记行照写（零丢失），独立工单创建冻结
|
|||
|
|
至开关回落后按正常认领升票——见 `core/rules/workflow-routing.md`
|
|||
|
|
§立案降档。HIGH/MEDIUM 行不受自动回收触碰。
|
|||
|
|
|
|||
|
|
## 教训
|
|||
|
|
|
|||
|
|
- 队列的吞吐健康比单票的完整流转更重要：登记行的"零丢失 + 延迟升票"
|
|||
|
|
优于"即时立案 + 无限堆积"。
|
|||
|
|
- 降档必须是**显式开关 + 显式负责人**，不能靠"冲刺期间大家少开点票"
|
|||
|
|
的纪律约定——纪律约定在压力下必然失效。
|