利息支付是什么
债务的利息通常以交付速度呈现：同一类需求在不同模块的实现耗时差异，就是利息最直接的读数。它的价值在于把「代码质量」翻译成业务能理解的语言——不是「这里很乱」，而是「这个模块每次要多花两天」。把观察记录到迭代回顾里，偿还诉求才排得进排期。
基本信息
| 观察指标 | 同类需求耗时差、返工次数、缺陷密度、发布受阻次数 |
|---|---|
| 记录方式 | 迭代回顾中标注「债务拖累」项及其耗时 |
| 决策依据 | 连续多个迭代拖累的模块进入偿还计划 |
| 表达方式 | 用工时与次数说话，避免主观评价 |
怎么收集利息证据
- 按模块统计同类需求的实际工时，找出明显偏离平均的模块
- 记录返工次数：同一个需求被退回重做的频次
- 记录发布受阻：因为该模块的兼容问题导致不能发布
- 记录绕行成本：为了不动老逻辑而额外写的适配代码工作量
- 在回顾会上用一句话总结：本迭代哪个模块拖慢了交付，代价多少
回顾记录示例
回顾记录示例
本迭代：
- 需求 A（新模块）：1.5 天完成
- 需求 B（旧报表模块）：4 天，其中 2 天用于绕过历史兼容逻辑
→ 报表模块债务拖累 ≈ 2 天/次
→ 历史三个迭代同类需求平均拖累 1.5-2.5 天
→ 结论：进入下季度偿还候选，先补口径测试再拆模块利息证据的类型
| 证据 | 采集方式 | 说服力 |
|---|---|---|
| 同类需求耗时差 | 任务工时对比 | 高，直接对应交付 |
| 返工次数 | 需求退回记录 | 高，暴露返工根源 |
| 缺陷密度 | 缺陷单按模块统计 | 中，需排除业务复杂度影响 |
| 绕行工作量 | 适配代码的提交量 | 中，说明维护成本 |
| 发布受阻 | 发布记录与原因 | 高，关联对外承诺 |
凭感觉说「被债务拖累」无法比较也无法说服：一旦没有记录，偿还诉求就只能靠嗓门。哪怕只记「模块、需求、多花的天数」三列，也足以支撑一次排序讨论。
归类不能过宽：把正常的学习曲线、一次性的环境搭建、需求本身变更都算进债务拖累，会让决策失真。判断标准是「同样的需求再做一次，成本还会不会同样高」。