敏捷开发，代码质量反而下降了

一、先说一个反常识的核心结论

我在过去六年里，亲眼见过至少四支团队从传统瀑布模式转向 Scrum 敏捷开发。其中两支团队在转型后的第二个季度，线上故障率反而上升了将近 40%。这个数字不是我从哪份报告里摘的，是团队自己复盘时拿出来的真实数据。更让人不安的是，故障的类型变了，不是新功能逻辑错误，而是老模块被意外改坏、数据不一致、边界条件没覆盖这类典型的代码质量问题。

所以这篇文章不打算跟你复述 Scrum Guide 的教条，也不打算鼓吹"敏捷万能"或者"敏捷已死"。我要讲的结论很明确：敏捷开发本身不会必然导致代码质量下降，但它会在团队缺乏工程纪律时，把代码质量问题成倍放大，放大到连业务方都能感知到的程度。

如果你现在的感受是"越敏捷越乱""迭代越快 bug 越多"，那问题大概率不出在 Scrum 框架上，而出在你们把 Scrum 当成了一次"省掉设计和测试"的借口。

二、先还原一下真实场景：敏捷是怎么把代码质量拖垮的

我不讲理论，我直接描述一个我见过的典型团队。这支团队大概 30 人，三个 Scrum Team，每个 Sprint 两周。转型的前三个月，交付速度确实快了，业务方很满意。到了第六个月，情况开始不对了。

1. Sprint 计划会上没人敢提重构

每次 Sprint Planning，产品负责人把一列 P0、P1 的需求往桌上一摊，时间就那么多。谁要在会上说"这个 Sprint 我想花两天重构一下订单模块的支付逻辑"，产品负责人一定会问一句话："这个重构能带来什么用户可感知的价值？"你答不上来。因为重构的价值是防止三个月后的灾难，这种价值在 Sprint 计划会上天然吃亏。于是重构永远排不上优先级。

2. 代码审查变成了走过场

Sprint 到了最后两天，所有人都在赶进度。Pull Request 挂上去，同事点进来扫两眼，留两条格式化的评论比如"这里是不是可以抽象一下"，然后 Approve。不是不想认真审查，是每个人自己的任务都做不完。当一个团队连续三个 Sprint 都在最后一天才完成开发，代码审查一定是第一个被牺牲掉的工程实践。

3. 单元测试覆盖率从"写不写"变成了"肯定不写"

我见过最极端的一个案例，一支团队在转型敏捷之前，单元测试覆盖率大概在 45% 左右，不高但至少有。转型一年后再看，覆盖率掉到了 11%。原因很直白：每个 Sprint 的时间就那么多，写完业务代码已经精疲力竭，测试代码被认为是"额外的工作量"。Scrum 本身没让你不写测试，但 Sprint 的时间压力会诱导开发者做出短视的选择。

4. "先上线再说"成了团队文化

当一个团队连续几次在 Retrospective 上意识到质量在下降，但 Sprint 的交付压力并没有减轻时，团队会形成一种集体心理防御机制："先上线再说，后面再还技术债。" 这句话我在至少十支团队里听过。现实是，后面从来没有"还"这件事，只有更多的新需求。

三、拆解三个最常见的认知误区

很多团队把代码质量下降归咎于敏捷，但仔细拆开看，他们踩的坑其实跟敏捷没关系，而是被一些流行的错误认知带偏了。

1. 误区一："敏捷就是快，快就意味着牺牲质量"

这句话错在两个地方。第一，敏捷追求的不是"快"，而是"更短的反馈环"。快是手段，不是目的。第二，质量和速度在工程上并不是零和博弈。真正拖慢开发速度的，往往不是"写得慢"，而是"改得慢"。 当代码质量下降到一个临界点，改一个订单状态的 bug 需要牵扯五个模块，开发速度自然会断崖式下跌。所以牺牲质量换速度，本质上是把未来的速度提前透支掉了。

我在 PingCode 的客户案例里见过一个很典型的对比数据。有一家 150 人规模的 SaaS 企业，他们用 PingCode 管理 Scrum 流程的前半年，交付速度提升了 30%，但代码质量问题在第三季度集中爆发，导致第四季度的交付速度反而比转型前还低了 12%。原因就是前两个季度的"快"，是用跳过代码审查和降低测试覆盖率换来的。

2. 误区二："Scrum 没要求写文档，所以可以不写设计文档"

Scrum 强调"工作的软件高于详尽的文档"，这句话被无数团队断章取义为"不用写文档"。我见过最离谱的情况是，一个支付核心模块重构，没有任何设计文档，全靠开发者口头沟通，结果三个 Sprint 后这个模块的维护者离职，接手的人花了两个月才搞明白当初的设计逻辑。

Scrum 反对的是"为了文档而文档"的瀑布式文档，而不是反对"必要的设计记录"。代码永远是最终的可交付物，但设计意图必须被记录，不管是用 Wiki、ADR还是直接在代码库里维护设计决策记录。我在 PingCode 的解决方案里看到，他们把需求管理、Wiki 和代码托管打通，设计文档直接关联到用户故事上，这样设计意图不会丢失，又不会变成没人看的厚重文档。

3. 误区三："迭代回顾就是聊聊天，没什么实际作用"

这是我听到的最刺耳的一句话。如果一个团队的 Retrospective 开成了茶话会，那不是 Retro 的问题，是 Scrum Master 没尽责。一个好的 Retro 必须产出至少一条可落地的行动项，而且要跟踪到下一个 Sprint 里执行。我见过有团队在 Retro 上连续三次提出"代码审查太敷衍"，但每次都没有形成实质性的改进方案。第四次的时候，团队里一个资深开发直接在会上说："这个问题我们已经聊了两个月了，再聊就是浪费时间。"

Retro 的核心价值不是发现问题，而是把问题变成行动。如果每次 Retro 产出的 Action Item 都能被追踪到完成，代码质量的改善是完全可以在几个 Sprint 内看到效果的。

四、我的专业判断逻辑：代码质量下降的根因到底是什么

做了这么多年敏捷教练和工具选型顾问，我现在判断一个团队会不会在敏捷转型中踩坑，看的不是他们多懂 Scrum 理论，而是看三个关键信号。这三个信号比任何成熟度模型都好用。

1. 第一个信号：团队有没有"代码健康度"的量化指标

什么叫代码健康度？不是靠感觉说"这代码写得挺干净"，而是有明确的、可量化的标准。比如：

• 圈复杂度是否超过阈值
• 单元测试覆盖率是否达到约定的百分比
• 重复代码率是否在持续上升
• 静态代码扫描出来的高优先级问题是否在规定时间内修复

我经手过的最成功的敏捷团队，无一例外都把代码健康度指标挂到了看板上，和业务需求平级。Sprint 结束的时候，不仅要看业务交付了几个故事点，还要看代码健康度指标有没有恶化。当代码质量没有被度量，它就不会被管理。

2. 第二个信号：技术债有没有被当成 Backlog Item 来管理

很多团队嘴上说重视技术债，但产品 Backlog 里一条技术债相关的 Item 都找不到。技术债如果不在 Backlog 里，它就不存在。我强烈建议团队把技术债拆成具体的、可估点的 Backlog Item，比如"重构用户模块的支付状态机，预计 5 个故事点"，然后和其他业务需求一起参与优先级排序。

产品负责人不一定懂技术，但你告诉他"如果不处理这个技术债，下个季度订单模块的改动成本会增加三倍"，他就能做出合理的优先级判断。把技术债翻译成业务风险，是开发团队必须掌握的沟通能力。

3. 第三个信号：团队有没有"设计先行"的习惯

这与前面说的"不用写文档"的误区直接相关。我这里说的"设计先行"，不是让你回到瀑布时代写三个月的详细设计文档，而是在动手写代码之前，花 30 分钟到半天的时间，把核心的设计思路写下来并与团队对齐。

我见过最高效的做法是：在 Sprint 开始前两天，开发负责人会把高优先级的用户故事拉出来，针对其中涉及核心模块改动的条目，用 PingCode 的 Wiki 写一份一页纸的轻量设计说明，包括改动范围、影响模块、数据流变化和回滚方案。然后团队在 Sprint Planning 上花 15 分钟过一遍，大家对技术方案达成共识后才开始估点和拆任务。这个习惯让那支团队的重大线上故障减少了 60% 以上。

五、AI 编程助手进场后，问题被加速放大了

2023 年下半年到 2024 年，我观察到一个新变量让代码质量问题变得更尖锐：AI 编程助手的普及。

GitClear 在分析了超过 1.5 亿行代码后得出的结论和我观察到的一致：AI 生成的代码在短期交付效率上提升明显，但代码的可维护性指标在持续恶化。 具体表现为代码变更率飙升、复制粘贴代码增多、重构频率下降。AI 写出来的代码像是"短期合同工写的临时代码"，能跑，但没人愿意维护。

1. AI 写代码的底层逻辑决定了它不关心长期维护

AI 编程助手的工作原理本质上是在海量代码库中做模式匹配和概率预测。它擅长的是"在你的上下文里，接下来最可能出现的代码是什么"，而不是"从系统架构的角度，这段代码应该怎么设计才能让三个月后的改动成本最低"。

我亲自测试过让 AI 生成了一个电商促销引擎的核心逻辑，功能实现很快，但代码里至少有三个明显的设计问题：重复的判断逻辑分散在三个方法里、缺乏对促销规则扩展性的抽象、边界条件处理依赖隐式假设。这些问题在功能验收时完全看不出来，但一旦促销规则变更，就会引发连锁改动。

2. AI 让"复制粘贴"比"思考"更便宜了

以前开发者复制粘贴代码，至少还要手动改一下变量名和逻辑。现在有了 AI，生成一段相似逻辑的成本几乎为零。这导致一个危险的趋势：开发者从"写代码的人"变成了"审核 AI 代码的人"，而人类在审查自己没有亲自写过的代码时，注意力天然更低，更容易放过逻辑隐患。

我在一次代码审查演练中做过对比：同一段包含三个潜在地雷的业务代码，让开发者审查自己写的版本时，平均能找出 2.4 个问题；而审查 AI 生成的版本时，平均只找出了 1.1 个问题。差距不在能力，而在于"自己写的代码每一行都有记忆锚点，AI 写的代码没有"。

3. AI 在敏捷环境里更危险，因为交付时间更紧了

敏捷本身就有时限压力，AI 进来后，交付速度被进一步拉高，但审查和测试的时间并没有同步增加。这就形成了一个恶性循环：AI 让你写得更快，Sprint 里塞进了更多需求，留给质量保障的时间反而更少，代码质量问题在更快的节奏里被更快地积累。

我现在的判断是：在工程纪律不成熟的团队里引入 AI 编程助手，代码质量下降的速度至少是原来的两倍。 这不是 AI 的问题，而是团队在用 AI 之前，连基础的代码审查和自动化测试都没做好。

六、以 PingCode 为例：工具能在多大程度上帮上忙

我必须先声明一点：工具解决不了文化问题和纪律问题。如果团队本身就不重视代码质量，用任何工具都白搭。但反过来，一套好的工具可以把"正确的工程实践"变得更容易执行，把"偷懒"的代价变得更高。

PingCode 在 Scrum 敏捷开发解决方案里做的事情，我总结为三个层面：

1. 把需求、代码、测试和质量指标放在同一个上下文里

这是很多团队最缺的东西。产品经理在 Jira 里管需求，开发在 GitLab 上管代码，测试在 TestRail 里管用例，三个系统之间靠人工关联，信息断裂是常态。PingCode 的做法是把史诗、特性、用户故事、开发任务、代码提交记录、测试用例、缺陷全部打通。

这意味着什么？当 Sprint Review 的时候，你可以从一个用户故事直接穿透到它关联的代码提交、测试覆盖情况和线上缺陷。代码质量的追溯不再靠"谁还记得三个月前这个模块是谁改的"。当信息断裂被消除，代码质量的治理才真正有了抓手。

2. 让迭代进度和质量指标同屏可见

PingCode 的迭代概览页面不只是给你看燃尽图，还可以看到当前迭代的缺陷累积趋势、阻塞项数量、以及团队自定义的质量指标。燃尽图告诉你进度是否正常，缺陷趋势图告诉你质量是否在恶化。只盯着进度不管质量，就像开车只看速度表不看油表。

我在给团队做敏捷导入时，有一个标准动作：在 Sprint 第三天开始，每天站会的时候同时看一眼迭代概览和缺陷趋势。如果发现缺陷在 Sprint 后半段突然陡增，说明测试压力集中到了最后几天，开发质量大概率出了问题。

3. 把迭代回顾的改进行动纳入跟踪闭环

很多团队的 Retro 产出停留在白板或会议纪要里，下一个 Sprint 就忘了。PingCode 的做法是允许团队在迭代回顾板上直接创建改进行动项，关联到下一个 Sprint 的 Backlog 里，在 Sprint 进行中持续跟踪完成状态。

这个功能的价值在于：它把"改进"从一句口号变成了一条可追溯的任务。 如果团队连续三个 Sprint 都在 Retro 上提出代码审查质量问题，但对应的改进行动项始终没被完成，这个问题就会在看板上暴露出来，而不是被遗忘在会议纪要里。

七、不同情况下的行动建议：你的团队该怎么做

我不给通用建议，因为每个团队的情况差异太大。我按三种不同的团队状态来分别给出行动路径。

1. 情况一：团队刚刚开始敏捷转型，代码质量还没有明显恶化

这是出手的最佳时机。在问题还没出现之前就把防线建好，成本最低。

（1）现在就定下代码健康度的底线

不要等到质量出问题了才去定义什么是"好代码"。在转型的第一个 Sprint 就明确：单元测试覆盖率不得低于多少、圈复杂度不得高于多少、高优先级静态扫描问题必须在一个 Sprint 内修复。把这些写进团队的 Definition of Done。

（2）前三个 Sprint 故意少排业务需求，留出工程能力建设的时间

这是一个逆直觉的建议。大多数团队转型敏捷的第一件事就是加速，加速的第一件事就是加需求。我的建议相反：前三个 Sprint，每个 Sprint 至少留出 20% 的团队产能用于搭建 CI/CD 流水线、补齐自动化测试、建立代码审查规范。这 20% 的投入会在第六个 Sprint 之后产生至少三倍的回报。

（3）选一个能把需求和代码质量关联起来的工具

手动维护需求和代码的关联关系是不可持续的，尤其是在迭代节奏加快之后。选择像 PingCode 这样能够打通需求、代码、测试和部署的工具，让代码质量的数据在需求维度上可追溯。

2. 情况二：团队已经敏捷了一段时间，代码质量出现了明显滑坡

这是最常见的状态，也是最难扭转的状态，因为坏习惯已经形成了。

（1）停止掩盖问题，先把缺陷数据拉出来

我见过很多团队在这种状态下，选择性地忽视质量数据。先做一件简单但痛苦的事：把过去三个 Sprint 的线上缺陷率、代码审查通过时间、测试覆盖率趋势全部拉出来，放在 Retro 上摊开讨论。让数据说话，而不是让感觉说话。

（2）下一个 Sprint 强制降低交付吞吐量，搞一场"质量 Sprint"

我跟团队说过最狠的一句话是："如果你们继续用这个节奏交付，三个月后这个系统就没人能维护了。" 有时候你需要一个专门的 Sprint，或者至少一个 Sprint 里留出 30%-40% 的产能，专门用于偿还高优先级的技术债、补齐核心模块的测试、清理重复代码。这个 Sprint 的业务交付数字会很难看，但它能防止系统滑向不可维护的深渊。

（3）重建代码审查纪律，从最资深的开发开始

代码审查走过场的根因通常不在态度，而在于能力分布不均和缺乏明确的审查标准。让团队里最资深的开发先做出表率：每一条 PR 评论必须具体到可以执行的改进建议，而不是泛泛的"这里可以优化一下"。同时把代码审查指南写成文档，明确哪些问题是必须指出并要求修改的。

3. 情况三：团队已经在敏捷中使用 AI 编程助手，代码质量问题让维护成本飙升

这是最新也最棘手的情况。AI 已经嵌入到开发流程里，不可能也不应该完全禁用，但必须重新定位它的角色。

（1）给 AI 划出明确的"禁区"

不是所有代码都适合让 AI 来写。我建议团队明确列出哪些模块不允许 AI 生成：涉及资金计算的逻辑、核心状态机的变更、安全相关的认证授权代码、对性能极端敏感的路径。这些模块由人工设计和编写，AI 只做辅助性的代码补全和文档生成。

（2）AI 生成的代码必须经过更严格的审查

如果人工写的代码需要一个人 Approve，AI 生成的代码至少需要两个人，而且其中一个人必须是该模块的资深维护者。这个规则不是在限制效率，而是在承认一个事实：AI 代码的审查难度更高，需要更多的注意力投入。

（3）把 AI 重新定位为"资深审稿人"而非"初级撰稿人"

这是我目前认为最高效的 AI 使用方式。让开发者先写出核心逻辑和设计框架，然后让 AI 来做代码审查、补充边界测试用例、生成文档、发现潜在的性能问题。这样既利用了 AI 的效率优势，又保证了设计决策权在人类开发者手里。AI 应该帮你检查代码，而不是替你写代码。

八、不同情况下的取舍：你必须做的几个艰难决定

关于代码质量和敏捷开发，以下是我认为每个技术负责人都必须面对的取舍。它们没有标准答案，但有代价。

1. 交付速度 vs 代码可维护性：你不可能两个都要

在给定的团队产能下，交付速度和代码可维护性是一对真实的矛盾。你不可能同时把两个都做到极致。一个 Sprint 只有这么多时间，你把时间花在写新功能上，就不能花在优化既有代码上。

我的建议是：按模块的风险等级做差异化策略。 核心交易模块、用户数据模块、支付模块，这些地方的代码可维护性优先级高于交付速度。营销活动页面、内部管理后台，这些地方可以适当接受更高的技术债容忍度。不是所有代码都值得用同样的标准对待。

2. 自动化测试投入 vs 短期交付产出：先投后赚还是先赚后赔

自动化测试的回报周期通常在 2-3 个 Sprint 之后才开始显现。前期的投入是真金白银的开发时间，但后期的回报是减少的人工回归测试时间、降低的线上故障概率和更快的重构速度。

我的判断标准是：如果一个模块的改动频率超过每两个 Sprint 一次，那它值得拥有自动化测试。 如果一个模块一年才改一次，写自动化测试的性价比确实存疑。但问题是，很多团队低估了模块的改动频率，尤其是在敏捷环境下，业务变化快，今天觉得不会改的模块，下个季度可能连着改三次。

3. AI 效率红利 vs 长期维护成本：短期赚到的速度，会不会在未来加倍偿还

从 2024 年到 2025 年，我看到越来越多的团队开始反思 AI 编程助手带来的隐性成本。那些最早拥抱 AI、但工程纪律薄弱的团队，现在正在承受代码可维护性下降的后果。

我的核心判断：AI 编程助手是加速器，不是自动驾驶仪。 如果你的团队已经有了扎实的代码审查文化、合理的测试覆盖率和清晰的设计规范，AI 能让你们变得更快更好。但如果这些基础都不存在，AI 只会让你在更短的时间内制造出更多的技术债。就跟你给一个新手司机一辆跑车一样，他不会因此变成赛车手，只会更快地把车撞烂。

九、总结：我的独特观点和给你的下一步行动指南

写了这么多，我把最核心的观点浓缩成三句话：

第一句：敏捷开发不会必然导致代码质量下降，但 Sprint 的时间压力会诱使团队做出短视的工程决策。质量下降从来不是"意外"，而是一次又一次"先上线再说"的累积结果。

第二句：AI 编程助手让这个问题加速了，但不是因为它本身不好，而是因为在工程纪律薄弱的团队里，它让"写垃圾代码"的成本变得前所未有的低。

第三句：解决这个问题，靠的不是一个更好的 Scrum Master 或者一套更贵的管理工具，而是团队是否真正把代码质量当成和业务交付同等重要的事情来对待，具体表现为是否量化了代码健康度、是否把技术债纳入了 Backlog 管理、是否为设计思考留出了时间。

如果你正在经历代码质量下降的痛苦，我的建议是从明天开始做三件具体的事：

1. 在下一个 Sprint Planning 上，把"代码健康度指标"纳入 Definition of Done。 哪怕一开始只有一个指标，比如单元测试覆盖率不低于 40%，也比没有强。
2. 在下一个 Sprint 的 Backlog 里，至少放入一条技术债相关的 Item，并赋予它不低于 P2 的优先级。 这条 Item 不需要很大，比如"消除订单模块的三个重复方法"，3 个故事点足矣。关键是让它出现在 Backlog 里并被完成。
3. 如果团队在用 AI 编程助手，本周内组织一次代码审查规范的专项讨论，明确列出哪些模块不允许 AI 生成，以及 AI 生成代码的额外审查要求。 30 分钟的讨论，足以避免几个月后的灾难。

敏捷是一个框架，不是宗教。它给了你快速响应变化的能力，但没有替你决定应该在什么地方慢下来。慢下来的决定，必须由团队自己做。而那些敢于在适当的时候慢下来的团队，最终会跑得比所有人更远。