技术债偿还策略

决定花多少产能还债 vs 功能，及如何组织偿还使其持久。

为什么

两个失败模式是不还债（代码库腐烂到每个功能 3 倍耗时）和只还债（不发东西业务死）。偿还策略找可持续中间：固定产能比例（通常 20%）给债，排进每 sprint 使其真发生。策略还防常见反模式"债 sprint"— 一季度修一切，这从不发生因为业务总要功能。把偿还分散到 sprint 作稳定鼓点才真缩债，因为复利反向工作：每次还解锁下个功能，更快，释放更多产能给下次还。

何时使用

债已识别排序时。策略定一次然后每 sprint 践行。

如何做

1. 定产能分配：sprint 点的 20% 给债（可配，但绝不 0）
2. 每 sprint 从优先债待办的立即还桶拉
3. 每偿还限时：若债项超估 2 倍则停并重估
4. 把偿还与它解锁的功能配对 — "还 D2 使功能 X 快 2 倍" 建认同
5. 跟踪债燃尽图：总债项 / 总估时随时间
6. 每季度调 %：债在长则升；稳且功能饿则降
7. 绝不把债清零"庆祝" — 无债代码库意味着你不欠新债，即你不发

示例

# 带 20% 债分配的 sprint 规划
Sprint 42 产能：80 点
- 功能：64 点（80%）
- 债：  16 点（20%）<- 不可协商

# 从立即还桶拉的债工单：
- D7  认证绕过测试     （2 点）
- D2  支付测试覆盖     （5 点）
- D11 提取 user repo   （8 点）
- D14 删死 flag        （1 点）
共：16 点债

# 债燃尽（sprint review 跟踪）
Sprint 40：47 项 / 120h 剩
Sprint 41：44 项 / 108h 剩（-12h）
Sprint 42：40 项 /  95h 剩（-13h）<- 趋势：降

# 偿还与解锁功能配对（sprint review 中）：
"还 D11（提取 user repo）-> 功能 '多租户' 原 8 点现 3 点"

常见问题

⚠每 sprint 0% 债分配因"功能紧急" — 债长到功能 3 倍耗时且无人知为何。
⚠计划的"债季度"永不到 — 业务总有更急功能，债永延。
⚠还债不量解锁效果 — 领导见成本不见收益，故砍分配。

最佳实践

✓每 sprint 固定 %（起 20%）给债 — 不可协商、排定、非"有空时"。
✓每次偿还与它解锁的功能配对并量化提速 — 向领导证 ROI。
✓每 sprint review 跟债燃尽图 — 降势维持策略；平势触发更高 %。