敏捷开发，技术债务越欠越多

一、先讲一个反常识的结论

很多团队把Scrum当成加速器，但数据告诉我另一个故事：Sprint跑得越快的团队，技术债务往往堆得越高。这不是Scrum的问题，而是管理制度和工程实践之间的结构性裂缝。

去年我在一个200人规模的SaaS团队做敏捷成熟度评估，他们的Sprint准时交付率做到了87%，Burndown Chart漂亮得像教科书。但当我翻看SonarQube数据时愣住了，代码重复率31%，圈复杂度超过20的方法有1400多个，核心支付模块的单元测试覆盖率只有12%。CTO苦笑说：“每三个Sprint我们就要拿出一个来填坑，但这个填坑Sprint永远被业务需求挤掉。”

这不是孤例。过去四年，我参与过17个声称在做Scrum的团队诊断，其中14个存在显著的技术债务积累问题。如果把技术债务比作信用卡账单，这些团队都在还最低还款额，利息越滚越多，本金纹丝不动。

核心结论很简单：技术债务不会因为你在跑Scrum就自动消失，它只会在每个Sprint的Deadline压力下被系统性地忽略。如果你不在流程里设计还款机制，债务只会累积。

二、债务累积的真实场景是什么样

1. Sprint Planning里的“沉默合谋”

我见过太多次这样的场景：Product Owner把一堆P0需求堆在Sprint Backlog里，开发团队估算Story Point时面露难色，但没有人说“这个Sprint我们需要留20%的时间处理上次留下的坑”。为什么不说？因为说出来就会被追问：“哪些坑？严重到什么程度？不修会怎样？”而这些问题，在需求评审的压力下，没有人能快速给出让对方信服的答案。

于是团队沉默着接受了不合理的Sprint容量。这种沉默不是懒惰，而是一种系统性的决策瘫痪，技术债务的抽象性和延迟性让它永远吵不过“下周要上线的支付功能”。

2. Daily Standup的信息过滤

Daily Standup按理说是暴露问题的窗口，但在有债务压力的团队里，Standup变成了“报平安大会”。开发人员会说“昨天在改那个Bug，今天继续”，但不会说“我在改的这个Bug之所以要花三天，是因为三个月前为了赶进度，这模块连接口都没抽象，现在改一行要测半个系统”。

信息被过滤了两次：第一次是开发人员自己觉得说了也没用，第二次是Scrum Master听到后不知道该怎么量化成风险上报。当技术问题无法被翻译成业务风险语言时，它在决策层眼里就不存在。

3. Sprint Review的认知偏差

Sprint Review演示的是“做完了什么”，不是“欠下了什么”。当一个Sprint结束时，团队展示的是新增的功能、修掉的Bug、上线的页面。但没有人展示：新增了3个应该被重构的方法、有2个模块的依赖关系变得更混乱、数据库里多了4张没有文档的临时表。

这些“欠下的东西”就像房间里的灰尘，每天落一层你看不出来，但三个月不打扫，你连窗户都推不开。

4. Retrospective的走过场

Retrospective本应是发现和解决这类问题的最后一道防线。但现实情况是，因为技术债务量化困难，Retro会议上提的通常是“某个需求不清晰”“测试环境不稳定”这类具体事件，而不是“我们过去三个月的代码可维护性在系统性下降”。

我在某金融科技团队看他们连续6个月的Retro记录，“提升代码质量”被提了4次，但每次的Action都是“加强Code Review”。6个月后，他们的Code Review覆盖率从60%升到了85%，但核心模块的技术债务评分反而下降了。因为Code Review只能拦住新债务，还不了旧债。

三、拆解关于技术债务的常见误区

1. “我们有Code Review，不会欠债”

这是我听过最多的一个误区。Code Review是流动岗哨，它能拦住明显的烂代码，但它拦不住架构层面的妥协。比如为了赶Sprint，团队决定“先在这个Service里加个if-else分支处理新业务，下个Sprint再拆”，Code Review时这段代码可能写得挺规范，变量命名也清楚，但它在架构上把两个不该耦合的业务逻辑焊在了一起。

Code Review在微观层面有效，在宏观层面基本失灵。技术债务的大部分本金不在代码行里，而在模块边界、数据流转、依赖方向上。

2. “重构随时可以做，不用专门排期”

这个想法就像“我随时可以去健身，不用专门排时间”，结果永远不会去。我在PingCode服务的客户里做过一个小调查：问开发人员“上次主动做大范围重构是什么时候”，超过70%的人答案是“记不清了”或“上一个项目”。

原因是多重的：重构不产生业务增量，Product Owner没动力排；重构有风险，出了Bug要担责；重构的收益是长期的，但Deadline是今天的。在缺乏制度性保障的情况下，理性个体不会优先做重构。

3. “敏捷就是快，慢下来就不是敏捷了”

这句话害了很多人。敏捷不是快，是可持续的节奏。Scrum Guide里明确写了“可持续的步伐”，但被很多团队选择性忽略。当一个团队连续多个Sprint在“冲刺”，它不是在跑敏捷，是在跑马拉松当短跑，心肺迟早要爆。

我在一个电商团队见过极端情况：连续11个Sprint超额交付，团队自我感觉良好。第12个Sprint，一个促销需求上线后，订单系统挂了6小时。事后复盘，根因是一个一年多前为了快而硬编码的促销规则判断逻辑，后续堆了17层if-else，没有人敢动。那6小时的损失，是他们过去一年省下的所有“快”的代价。

4. “技术债务是技术问题，跟业务没关系”

这是最大的认知偏差。技术债务归根结底是业务风险。债务越高，市场响应速度越慢，故障率越高，人员流失越严重。这些最终都落在业务指标上。问题是，大部分组织用“上线时间”来衡量开发效率，而不是“从需求提出到稳定交付的全周期时间”。前者鼓励借债，后者暴露债务。

四、我的判断逻辑：怎么识别团队是否在“借债开发”

1. 看需求交付周期的趋势

我用的核心指标不是Sprint内的交付率，而是需求的端到端交付周期，从PO提出需求到该需求在线上稳定运行的天数。健康的敏捷团队，这个周期应该是稳定或缓慢缩短的。如果连续3个月在变长，说明有什么东西在拖慢整个链条。

在PingCode的一个制造业客户那里，我拉取了他们半年的需求周期数据，发现单个Story的开发时间其实在缩短（2.3天降到1.9天），但“联调+测试+修复”阶段的时间从3.1天拉长到了6.7天。这就很典型，开发没变慢，但代码的耦合度高到联调和测试已经扛不住了。

2. 看“改动影响面”的变化

我会问一个很直接的问题：“改一个订单状态的枚举值，需要动几个文件？”在架构清晰的系统里，答案应该是1到2个。在我评估过的一个债务严重的系统里，答案是11个。因为同一个枚举值被11个模块各自import了一份，没有统一的Domain层。

这就是技术债务的可量化信号，改动影响面越大，债务越重。很多团队没有度量这个指标，但你问问团队里最资深的开发，他凭直觉就能告诉你答案。

3. 看技术讨论在Sprint Planning里的占比

健康的Sprint Planning，技术讨论占20%到30%，讨论怎么设计、怎么拆分、怎么跟现有模块衔接。在被债务压迫的团队，这个比例降到10%以下，因为“设计有什么用，反正那个模块已经烂了，怎么接都是打补丁”。

当一个团队不再认真做Sprint级别的技术设计，说明他们对代码的可维护性已经丧失信心。这种习得性无助，是技术债务最昂贵的隐性成本。

4. 看P1 Bug的根因分布

我把线上故障分为两类：新引入的Bug和“老代码引发的故障”。追踪一个团队半年的P1故障数据，如果老代码引发的比例在上升，说明系统里堆积的定时炸弹在增多。我服务的一个物流平台，某季度5个P1故障中4个的根因是两年前的代码逻辑，当时为了赶上线写得草率，两年没人敢碰，最终自己炸了。

五、具体案例：PingCode 帮助一个金融SaaS团队量化债务

这个客户是给银行做信贷系统的，150人左右的研发团队，跑了两年Scrum。表面运转良好，但CTO总觉得不对劲，团队人数从80人涨到150人，交付吞吐量并没有翻倍，反而单个需求的交付周期从9天拉长到了16天。

我们用PingCode做了一次全流程的诊断，重点不是看他们的Sprint完成情况，而是做三件事：

• 需求颗粒度回溯：把过去6个月完成的Epic和Story拉出来，看哪些Story是“新功能”，哪些是“修复/优化/重构”。结果发现，被标记为“优化”的Story占比从第一个月的8%涨到了第六个月的31%。团队在用越来越多的Sprint容量填以前的坑，但标签打的都是“优化”，没人意识到这是还债。
• 测试阶段耗时追踪：PingCode的数据面板显示，测试环境的平均等待时间在过去半年里涨了4倍。原因是每次部署都要跑全量回归，因为没有人能说清改了A模块会不会影响B模块。
• 代码提交与Story的关联分析：通过PingCode与GitLab的集成数据，我们发现“一个Story改动超过15个文件”的情况在半年里增加了3倍的频次。这说明模块边界在崩塌。

诊断结果很明确：这个团队每个Sprint都背着隐形债务在跑，越跑越重。他们不是不努力，是整个度量体系只奖励“做完Story”，不惩罚“欠下债务”，激励完全错位。

后续他们用了三个Sprint周期做调整：第一个Sprint拿出40%的容量做核心模块重构，第二个Sprint把基础设施的自动化测试补齐，第三个Sprint重新定义了Sprint Backlog的容量计算规则，把技术债务显性化为具体的Story Point。三个月后，单需求交付周期从16天降回到11天。

六、在不同阶段应该怎么做

1. 债务尚轻的阶段：建立度量基线

如果你现在还没感觉到痛，这是最好的窗口期。我建议立即做三件事：

• （1）建立一组技术债务的可视化指标：不是SonarQube的代码规范分，而是业务视角的指标，改动影响面系数、模块间耦合度趋势、测试运行时间变化、部署频率与失败率的趋势。这些数据比代码扫描工具更能说服非技术决策者。
• （2）在每个Sprint Backlog里固定预留“技术健康度缓冲”：我一般建议初期预留15%的容量，不需要大张旗鼓，就在估算时把这部分容量预留出来，专门用于小范围重构、补充测试、文档更新。不要让这15%变成可被挤占的缓冲，在Sprint Planning时明确标记为受保护Story。
• （3）用PingCode的多级需求管理功能把技术债条目化：创建一个“技术债务”史诗，下面拆成具体的Story和Task，像管理业务需求一样管理债务。给它们分配优先级、Story Point、验收标准。只有当技术债务在Backlog里“看得见”，它才有可能被排进Sprint。

2. 债务中度的阶段：启动“还款Sprint”

当你的团队已经出现以下信号：每次上线都紧张、测试回归耗时超过开发耗时、新人Onboarding周期超过两个月，你需要专门的还款周期了。

• （1）每4个业务Sprint之后，排一个“技术改进Sprint”：这个Sprint不做任何新功能，只做三件事：偿还优先级最高的技术债务、提升自动化测试覆盖率、修复架构层面的耦合问题。刚开始推这个制度的时候，业务方一定会反弹。你需要准备好数据，过去几个Sprint有多少时间花在“联调排坑”上，上线后有多少Hotfix，故障导致的业务损失是多少。
• （2）给技术债务定级：我用的分级方法很简单，P0是“已经影响线上稳定，随时可能炸”，P1是“三个月内会影响交付速度”，P2是“影响可维护性但暂不致命”。还款Sprint优先清P0，P0清完再看P1。不要同时打三场仗，合并清理，聚焦效果。
• （3）用燃尽图追踪债务：就像追踪Sprint待办一样追踪技术债务的清理进度。在PingCode里，我会创建一个技术债务的看板，把每个还款任务可视化。当团队看到“债务燃尽图”往下走的时候，那种正反馈比任何说教都有用。

3. 债务重度的阶段：止损与重构并行

如果情况已经严重到“核心系统没有人敢动”“每次上线都是赌博”“老员工离职后没有人能接”，你需要承认一个现实：继续在现有架构上Scrum只会加速恶化。

• （1）划定止损边界：不是所有模块都值得救。对于那种“从根上烂了、业务价值又在下降”的模块，策略是围栏隔离，用API Gateway或Facade模式把它包起来，接口保留，内部不再改，等业务时机成熟时整体替换。
• （2）新功能走新架构：所有新需求在一个相对干净的、按新架构设计的模块里开发，旧模块只做维护性补丁。这本质上是“并行运营”，旧的慢慢退出，新的逐步成长。痛苦的地方在于，新架构通常需要一个过渡层跟旧系统对接，这个过渡层本身就是额外的成本。但这笔成本不花，后面付出的故障成本更高。
• （3）争取组织层面的支持：重度债务本质上是组织层面的问题，不是技术团队自己能解决的。你需要拉着CTO、业务负责人一起，把债务的影响量化成业务指标，故障损失、响应延迟导致的商机损失、离职带来的招聘和培训成本。当一个问题的代价能用钱算清楚时，排期自然就有了。

七、不同场景下的决策取舍

1. 交付压力 vs 代码质量

现实不会给你完美选项。很多时候，PO带着老板的Deadline来跟你说“这个功能必须这周上”。这时候怎么办？

我的立场是：可以临时借债，但必须同时登记还款计划。当团队被迫走捷径时，比如不写测试、硬编码、复制粘贴一段逻辑，必须在同一个Sprint Planning里创建对应的“债务登记”Story，标记优先级和预估偿还成本，放进下一个Sprint的Backlog。

这个动作的核心不是技术管理，而是建立可追溯性。三个月后复盘时，如果发现Backlog里积压了40个债务登记条目而只还了3个，这就是跟业务方谈判的硬证据。没有这个登记动作，债务积累是不可见的，谈判时就只能谈“感觉它在变慢”，而不是“我们有具体债务在排队”。

2. 全栈重构 vs 渐进改进

很多技术负责人面临债务严重时会冲动想“推倒重来”。我理解这种冲动，但全栈重构的成功率低到你不愿意相信。我见过的案例里，推倒重来的项目有一半以上在重构期间业务需求照样涌进来，结果新架构还没稳定就被迫改需求方向，最后新的也变旧了。

我倾向于绞杀者模式：新功能走新架构，旧模块逐步替换。代价是过渡期维护两套代码的成本，但好处是业务不受影响，每次替换的规模可控，风险可控。你的目标不是“建一座完美的代码殿堂”，而是“让系统可维护地活下去”。

3. 人员流动与知识债务

还有一种债务比代码债务更隐蔽，知识债务。当团队里只有一个人知道某个核心模块怎么工作的时候，这个人在组织里的留任意愿决定了整个系统的稳定性。我见过因为一位核心开发离职，一个支付模块半年没人敢改的案例。这就是隐性知识没有沉淀成显性资产的后果。

解决知识债务，不是简单地写文档，文档也会过时。我建议的做法是在Scrum流程里嵌入一个规则：任何Story如果在同一个模块上连续做了超过三个Sprint，必须在完成后由开发者对另一个团队成员做一次“反向讲解”，由听的那个人来复述模块的关键设计决策。这比文档更有效，因为它检验的是“别人是否真的理解了”，而不是“文档是否被写出来了”。

4. 度量驱动的取舍

你衡量什么，就得到什么。如果你的Sprint度量只关注“完成的Story Point”，债务自然会堆积。我在PingCode的客户实践里，会推动团队在迭代概览页面同时拉两条线，一条是“已完成Story Point”，另一条是“技术债务条目剩余数”。这两条线必须放在同一个Dashboard上呈现。

这个做法的心理学效果很强：当Product Owner看到新功能交付线往上的同时，债务线也在往上，他会自己感受到矛盾。这种直观的视觉冲击，比任何技术论证都有说服力。

八、总结：真正的敏捷不是更快，是更可持续

回到这篇文章的起点，敏捷开发是不是在助长技术债务？我的答案很清晰：不是敏捷本身在助长债务，而是只追求速度而不设计还款机制的伪敏捷在助长债务。

Scrum Guide里写的三个支柱是透明、检视、调整。如果透明只针对“做完的需求”，不针对“欠下的债”，如果检视只看Burndown Chart，不看代码可维护性趋势，如果调整只在Sprint内做微调，不做结构性的还款安排，那这个Scrum就是半条腿走路。

我给所有正在跑Scrum的团队三句话：

1. 把技术债务当成一等公民放进Backlog。它不是技术细节，它是未来的交付成本。用史诗、特性、用户故事来管理它，用Story Point来估算它，用燃尽图来追踪它。
2. 在你感觉最不需要还款的时候，正是还款的最佳时机。等到系统已经千疮百孔再来还债，成本指数级更高，而且业务方已经失去耐心了。
3. 用业务语言讲技术债务。不要说“这个模块圈复杂度太高”，要说“如果我们现在不花两周重构它，下个季度每增加一个新功能就要多花三天联调，重复投入的研发成本远超这两周”。

下一步，我建议你做一件事：打开你的项目管理工具，看看过去三个月Backlog里有没有任何一个条目明确标注为“重构”或“技术改进”。如果没有，或者有但从没被排进Sprint，你已经知道问题在哪了。从现在这个Sprint开始，给技术债务分配真实的、受保护的容量。不需要多，15%就够。坚持三个Sprint，回头看数据，你会发现“快”和“稳”是可以同时提升的。

可持续的速度，才是真正的敏捷。