技术债像滚雪球，小团队若放任不管，很快会拖慢交付速度。本文分享一套轻量方法：用看板可视化债务，用迭代节奏限制新增，让技术债可控而非清零。
为什么小团队更容易积累技术债
小团队资源有限，常为赶需求走捷径：硬编码、跳过测试、文档缺失。这些短期决策长期累积，导致修改成本指数上升。更糟的是，债务不可见，没人主动偿还。
看板：让技术债显性化
看板的核心是可视化工作流。为技术债单独设置泳道或标签（如 tech-debt），每张卡片描述具体债务、影响和预估修复成本。例如：
- 卡片：用户服务硬编码数据库连接
- 影响：换环境需改代码，部署风险高
- 预估：2 小时
每日站会时，团队能直观看到债务堆积情况。建议限制“进行中”的债务卡片数量（WIP），避免同时修复过多。
迭代节奏：给技术债固定配额
每个迭代（通常 1-2 周）预留固定比例的时间处理技术债。常见做法：
- 20% 规则：每个迭代拿出 20% 的工时偿还债务，剩余 80% 做新需求。
- 债务冲刺：每 4-6 个迭代安排一个短冲刺，集中清理高优先级债务。
关键是把债务任务纳入迭代计划，而不是“有空再做”。
控制新增债务：定义完成标准
预防比偿还更重要。团队需明确“完成”的定义，例如：
- 代码通过静态检查
- 核心逻辑有单元测试
- 关键接口有文档注释
- 无已知严重缺陷
当新需求不满足标准时，要么拒绝，要么创建债务卡片并记录。这样新增债务变得可见且有成本。
实践流程示例
- 需求进入看板“待办”列。
- 开发中若发现捷径，立即创建债务卡片，标注影响和预估。
- 迭代计划会预留 20% 容量给债务卡片，按优先级排序。
- 每日站会检查债务泳道，确保不超 WIP 限制。
- 迭代回顾时统计债务增减，调整配额。
常见误区
- 追求零债务：不现实，目标是控制增速。
- 债务卡片过大：拆成 2-4 小时可完成的小任务。
- 只还不防：忽略完成标准，债务会更快回流。
小结
看板让债务可见，迭代配额让偿还有节奏，完成标准抑制新增。小团队无需复杂工具，一块物理白板或 Trello 即可开始。坚持几个迭代后，你会看到交付速度更稳定，紧急救火减少。