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 行不受自动回收触碰。
|
||
|
||
## 教训
|
||
|
||
- 队列的吞吐健康比单票的完整流转更重要：登记行的"零丢失 + 延迟升票"
|
||
优于"即时立案 + 无限堆积"。
|
||
- 降档必须是**显式开关 + 显式负责人**，不能靠"冲刺期间大家少开点票"
|
||
的纪律约定——纪律约定在压力下必然失效。
|