敏捷转型失败？缺的不是流程，是工程实践

一、当“完美 Scrum”撞上生产事故，我意识到问题不在流程

2023 年第四季度，我接手了一个让我半年内掉了不少头发的大规模敏捷转型诊断项目。一家 600 人规模的金融科技公司，Scrum 流程跑了两年，站会、评审、回顾一个不少，Jira 里的 Sprint 燃尽图画得比教科书还漂亮。但他们的生产环境在 11 月连续崩了三次，最长一次宕机 7 小时，直接损失超过 800 万。

CTO 找我聊的时候，开场白我至今记得：“我们是不是敏捷流程还不够好？要不要把 SAFe 也加上？”

我花了两周时间翻遍了他们 80 多个代码仓库，查了 CI/CD 流水线的配置，看了他们所谓的“自动化测试”用例，又跟 12 个开发团队挨个做了结对编程观察。结论跟流程一点关系都没有。他们缺的根本不是更精细的 Sprint 规划、更严格的 Definition of Done，而是最基本的工程实践能力。单元测试覆盖率平均不到 15%，没有一张测试用例是真正在验证业务逻辑的；代码提交完全靠人工 Code Review，没有静态分析、没有安全扫描；部署流程里有 14 个手动审批节点，发布一次至少折腾三天。

这才是真正的病灶。流程可以把问题暴露出来，但解决不了这些问题本身。流程是骨架，工程实践才是肌肉和神经系统。骨架再漂亮，没有肌肉和神经，照样是瘫的。

二、核心结论：敏捷不是管理问题，是技术能力问题

这篇文章我要给一个可能很多管理层不太爱听的结论：敏捷转型失败，绝大多数情况下不是流程设计得不够好，而是团队不会写可测试的代码、不会做持续集成、不会搞基础设施即代码、不会把安全左移到开发阶段。

我最近三年参与了 21 家中大型企业的敏捷转型评估，其中 19 家的“转型失败”被业务部门定义为“交付速度没提上来”或者“质量更差了”。深入排查之后，16 家的核心问题集中在工程实践层面。只有 2 家是流程本身出了大问题，比如站会开成了汇报会、Sprint 周期选了四周这种明显错误的配置。剩下那 1 家是组织政治问题，不在技术讨论范围内。

这里给一个我反复验证过的判断框架：敏捷转型的成败，80% 取决于工程能力基线，20% 取决于流程适配度。如果你的工程能力基线没达标，上任何流程框架都只是在给烂代码装一个漂亮的壳。

所谓的工程能力基线，在我这里至少包括五个支柱：自动化测试体系、持续集成与持续交付管道、基础设施即代码与可观测性、代码质量与安全左移、模块化架构与解耦能力。这五项缺了任何一项，敏捷流程跑起来都会变形。

三、我看到的真实战场：当“站会”变成唯一的工程仪式

先给你们还原一个我非常熟悉的场景。这是一家 300 人的 SaaS 企业，PingCode 的客户，做企业级项目管理工具的，当然 PingCode 自己也是这个赛道，所以他们用的是 PingCode Agile 模块管理自己的研发流程。

2022 年我刚接触这家公司的时候，他们的 COO 告诉我：“我们敏捷已经跑了一年半了，Scrum Master 都考证了，但版本发布周期反而从 6 周拉长到了 10 周。”我进去一看，问题一目了然。

1. 测试自动化率为零，回归测试靠人堆

他们的 QA 团队有 27 个人，每个 Sprint 结束时，这 27 个人要花整整四天做手工回归测试。我问 QA 总监为什么不搞自动化，他的回答很诚实：“开发不写单元测试，接口测试用例也没人维护，我们用 Selenium 录的 UI 脚本全 brittle 了，三个月就全废。”

没有底层测试金字塔的支撑，UI 自动化是纸糊的。这是我反复强调的一个观点。测试金字塔大家都听过，从上到下是 UI 测试、Service/API 测试、单元测试。但真正落地的团队少之又少。这家公司的测试分布是这样的：UI 测试占 70%，API 测试占 20%，单元测试占 10%。而且那 10% 的单元测试还是项目启动时写的，后来新功能都没补。

正确的分布应该倒过来：单元测试占 70%，API 测试占 20%，UI 测试占 10%。不是绝对的数字，但比例关系不能反。反了，你的回归测试成本就是指数级增长。

2. 集成痛苦到极致，因为没人管模块边界

另一个更致命的问题是架构层面的。他们的核心产品有 11 个微服务，听起来挺现代的对吧？但实际上这 11 个服务之间有 43 对点对点接口依赖，而且没有定义任何服务间契约。一个服务改了数据结构，另外三四个服务跟着炸。这不是微服务，这是分布式单体，比单体还难维护。

这种情况下，任何流程改进都没用。你在 Sprint 里规划得再清楚，到了集成测试阶段一样崩。因为他们没有消费驱动契约测试，没有 API 版本管理策略，甚至连最基本的接口文档都是过期的。开发人员靠口口相传和翻代码来理解依赖关系。

3. 部署流程中的“人工审批马拉松”

他们的部署流程是这样的：开发提交代码 → Tech Lead Review → 部门经理 Review → QA 环境手动部署 → QA 测试 → 安全团队手动扫描 → 运维手动配置生产环境 → 再次安全审批 → 发布窗口等待 → 生产部署。一共 9 个手动步骤，平均耗时 62 小时。

这种部署流程本身就是反敏捷的。敏捷的核心原则之一是“可工作的软件是首要的进度度量标准”，你让可工作的软件在审批链里躺三天，还有什么敏捷可言？

但根源不是审批的人故意卡流程，而是工程能力不够。因为自动化测试覆盖率低，安全扫描没集成到 CI 管道里，配置管理没做成代码化，所以审核人员只能靠人工方式来控制风险。这是典型的工程能力缺失倒逼出官僚流程的案例。

四、拆解那些披着“敏捷外衣”的工程误区

基于我这些年踩过的坑和帮别人填过的坑，我总结了五个最具迷惑性的误区。这些误区都有一个共同特点：表面上是在执行敏捷流程，实际上是在用流程掩盖工程能力的不足。

1. 把“站会”当成了敏捷本身

Daily Standup 是 Scrum 里最容易执行的一个仪式，也最容易变成形式主义。很多团队以为站会开了就是敏捷了，结果站会变成了每个人花三分钟给 Scrum Master 汇报工作，剩下的 27 分钟大家一起发呆。站会的目的是同步信息、暴露阻塞、协调行动，不是为了站而站。

但更深层的问题是：如果团队没有看板、没有实时更新的任务状态、没有自动化的进度度量，站会就成了唯一的信息同步渠道，当然会变得冗长低效。工程实践好的团队，站会通常不超过 10 分钟，因为大部分信息在看板上已经一目了然。

2. 认为 Story Point 估得准就能按时交付

我跟很多 PMO 聊过，发现一个普遍焦虑：Story Point 估算不准怎么办？要不要引入 Planning Poker 的变体？要不要用 T-shirt sizing？这些精力全投错了地方。

Story Point 本身就不是精确估算工具，它是相对估算工具，用来辅助 Sprint 规划的。交付能不能按时，决定性因素不是估得准不准，而是团队有没有能力快速响应变更、有没有自动化测试支撑重构、有没有持续集成保证主干健康。一个工程能力强的团队，估算偏差 30% 也能通过技术手段消化掉；工程能力弱的团队，估算再准也是空中楼阁。

PingCode 在服务 100 人以上研发组织的时候，我观察到他们的估算功能更多被用来做偏差趋势分析，而不是追求单次估算的精确度。看三个 Sprint 的估算偏差趋势，比盯着一个 Sprint 的 Story Point 纠结有用得多。

3. 把 Code Review 等同于质量保障

很多技术管理者对 Code Review 有一种宗教般的信仰，觉得只要 Code Review 严格，代码质量就有保障。但现实是，人工 Code Review 的缺陷发现率平均只有 15% 到 30%，而且极度依赖 Reviewer 的个人经验和精力状态。

真正的质量保障体系应该是三道防线：静态代码分析自动拦截低级问题 → 自动化测试验证业务逻辑 → 人工 Code Review 聚焦架构设计和业务实现的合理性。把三道防线缩减成一道人工 Review，等于把质量责任全部压在几个 Tech Lead 的眼睛上，既不安全也不可持续。

4. 以为上微服务就是架构现代化的全部

我见过太多团队把“拆成微服务”当成架构现代化的终极目标，结果拆完了发现比单体更难维护。微服务不是银弹，它解决的是组织扩展性问题，但前提是你的工程能力撑得住分布式系统的复杂性。

更可怕的是，有些团队在拆微服务的同时完全没有配套的工程基础设施，没有服务发现、没有链路追踪、没有配置中心、没有统一日志、没有灰度发布能力。这种微服务架构就是一场运维灾难。我见过一个团队拆出 24 个微服务之后，故障定位时间从分钟级变成了小时级，因为日志散落在 24 个地方，出了问题要一个个排查。

5. 迷信“自组织团队”，却不给工程能力建设时间

“自组织团队”是敏捷宣言里的核心理念之一，但很多管理者把它理解成了“你们自己想办法搞定，我只要结果”。自组织的前提是团队具备足够的工程能力和决策权限。你不给团队时间做自动化测试建设、不给预算做基础设施升级、不给空间做技术债偿还，然后说“你们要自组织交付”，这不是授权，这是甩锅。

我在一个 200 人的研发组织里做过一个实验：给其中一个 8 人团队每 Sprint 留出 20% 的时间专门做工程改进，包括补单元测试、优化 CI 管道、做代码重构。三个 Sprint 之后，这个团队的交付吞吐量提升了 37%，缺陷逃逸率下降了 52%。而旁边那个“一切照旧”的团队，指标纹丝不动。这两个团队走的是同一套 Scrum 流程。

五、我的判断逻辑：工程成熟度才是敏捷的隐藏变量

在帮企业做敏捷诊断的这些年，我慢慢形成了一套自己的判断框架，我管它叫工程成熟度基准线模型。这个模型的核心思想很简单：敏捷流程的有效性不是独立存在的，它有一个工程成熟度的临界点。低于这个临界点，流程跑得越狠，团队越痛苦。

我把工程成熟度分成五个层级，每个层级对应不同的敏捷流程适配方式。

1. 五个工程成熟度层级

Level 0 – 手工作坊：没有自动化测试，没有 CI，部署靠 FTP 或者手动拷贝，代码没有版本管理或者只有名义上的 Git 仓库。这个阶段上任何敏捷流程都是空转。

Level 1 – 基础自动化：有 Git 做版本管理，有基础 CI 能跑编译，有少量单元测试但不成体系，部署有脚本但没做成管道。这个阶段的团队可以尝试 Kanban，降低在制品数量，但不适合跑 Sprint 迭代。

Level 2 – 工程可重复：CI/CD 管道成型，自动化测试覆盖率达到 40-60%，有代码静态分析，基础设施部分代码化。Scrum 的基本框架可以跑起来，但 Sprint 周期建议拉长到三周以上。

Level 3 – 工程可信任：测试金字塔完整，CI/CD 高度自动化，安全扫描左移集成，可观测性覆盖全面。这个阶段可以高效运行 Scrum 或者大规模 Scrum，Sprint 周期可以缩短到一到两周。

Level 4 – 工程卓越：持续部署常态化，混沌工程落地，团队具备全栈工程能力，技术债管理成体系。可以灵活选择 Scrum、Kanban 或者混合模式，甚至可以探索诸如 Continuous Delivery 原生模式这种更激进的交付方式。

2. 诊断工程成熟度的四个关键指标

我不会拿一大堆花里胡哨的指标去压团队，诊断工程成熟度我只看四个核心数据：

（1）变更失败率，生产部署导致服务降级或故障的比例。低于 5% 是及格线，低于 1% 是优秀。

（2）变更前置时间，从代码提交到生产部署完成的时间。超过 1 天说明 CI/CD 管道有严重瓶颈，超过 1 小时说明还有优化空间，控制在 10 分钟以内是高绩效团队的标志。

（3）平均恢复时间，从故障发生到服务恢复正常的时间。低于 1 小时是及格线，低于 10 分钟是优秀。这个指标直接反映可观测性和运维自动化水平。

（4）测试覆盖率与逃逸率，不是单纯看覆盖率数字，而是结合缺陷逃逸率一起看。单元测试覆盖率 80% 但缺陷逃逸率居高不下，说明测试在刷覆盖率数字，没在测业务逻辑。真正的工程成熟度，是覆盖率稳定且逃逸率持续走低。

3. 为什么先搞流程后搞工程是顺序错误

很多企业转型的路径是这样的：先请咨询公司导入 Scrum 或者 SAFe，搞一年流程，发现不行，再回头补工程实践。这个顺序本身就是错的。因为敏捷流程会把工程问题放大。迭代周期从三个月压缩到两周，你的手工测试扛得住吗？在制品数量降低，要求每个任务更快流转，你的 CI/CD 跟得上吗？每日构建的精神内核是“每次提交都触发构建”，你的管道能撑住一天几十次构建吗？

正确的顺序应该是工程能力先达标，再上流程强度。先花三到六个月把自动化测试、CI/CD 管道、代码静态分析、基础设施代码化这些硬骨头啃下来，然后再把 Sprint 周期从四周缩短到两周，把发布频率从月级提升到周级甚至日级。这样的路径，团队不会崩，管理者也不会觉得“敏捷没用”。

六、PingCode 自己的实践：从工程底座反推流程设计

PingCode 服务的中大型客户里，研发组织规模大多在 150 人到 800 人之间，这些客户面临的核心挑战跟我们讨论的主题高度吻合，流程跑到一定程度就遇到天花板，天花板的高度由工程能力决定。

我观察过 PingCode 团队自己的研发实践，也跟他们的技术负责人有过深入交流。他们走的路跟我的工程优先理念完全一致。

1. 自动化测试体系先于功能开发

PingCode 有一个我特别认同的策略：新功能开发之前，对应的测试基础设施必须先就位。不是写完代码再补测试，而是先定义接口契约、写好契约测试和关键路径的单元测试骨架，然后再开始写实现代码。这是一种变体的 TDD，但不那么教条，它不强求每个方法都先写测试，但要求每个用户故事的关键验收条件必须自动化。

这个策略带来一个直接效果：PingCode 的回归测试时间从 2021 年的 6 小时压缩到了 2024 年的 22 分钟。22 分钟是什么概念？喝杯咖啡的时间，整个回归测试就跑完了，CI 管道里绿灯亮起，开发人员可以放心合并代码。

2. CI/CD 管道的安全左移实践

在服务金融和能源类客户的过程中，PingCode 把安全扫描、合规检查全部集成进了 CI/CD 管道，而不是放在上线前的最后一道关卡。具体做法是这样的：

（1）每次代码推送触发 SAST（静态应用安全测试），检查 OWASP Top 10 漏洞、SQL 注入、XSS 等常见安全问题。扫描结果直接反馈在 Pull Request 的评论里，开发者在合并之前就能修。

（2）依赖项漏洞扫描自动化，每次构建时对比 NVD 数据库，发现有已知漏洞的依赖项立即阻断构建，并给出修复建议。

（3）容器镜像签名与准入控制，未经签名的镜像无法部署到生产集群，从根本上杜绝了“手动改了一下生产配置”这种高危操作。

这套实践的效果是：安全缺陷在生产环境被发现的比例从 23% 降到了 0.7%，安全团队的审批时间从平均 3 天变成了零，因为安全验证已经自动化了，不需要人工审批。

3. 从流程度量到工程度量

PingCode 做研发度量有一个我很欣赏的转变：早期他们的度量体系偏流程向，Sprint 完成率、Story Point 燃尽曲线、团队速率。最近两年，他们把度量重心大幅向工程指标倾斜。现在他们的核心度量仪表盘里，流程指标只占 30%，工程指标占了 70%。

工程指标包括：变更前置时间、部署频率、变更失败率、平均恢复时间，也就是经典的 DORA 四大指标。再加上测试覆盖率趋势、代码异味密度、技术债占比、CI 管道失败率。这些指标组合在一起，能真实反映一个团队的工程健康度，而不是“看起来敏捷”。

七、行动指南：不同阶段的团队该怎么建工程底座

上面讲的很多是高阶实践，对于处于不同工程成熟度阶段的团队，行动优先级是完全不同的。我按照我自己的五级模型，给出分阶段的行动建议。

1. Level 0 团队：先止血，再谋发展

如果你现在的团队还在手工作坊阶段，别想着一步登天。当下最重要的是做三件事：

（1）把所有代码纳入版本管理。如果还有代码在某个人的电脑上或者共享文件夹里，今天就去推到一个 Git 仓库里。不要求分支策略多复杂，main 分支直接提交也没关系，先让代码有版本、可追溯。

（2）搭建一个最基础的 CI 服务器。用一个 Jenkins 实例或者托管服务，只做一件事：代码推送触发编译。编译通过给绿灯，编译失败给红灯并通知提交者。就这么简单，但这是自动化的起点。

（3）写一张清单：手工部署的每一步是什么。把这些步骤文档化，然后从中找到最容易出错的那一步，优先做成脚本。不用一口气全自动化，先解决最疼的那个点。

这个阶段的团队不建议跑任何正式的 Scrum 流程，老老实实跑看板，把在制品限制在 3-5 个，先让工作流稳定下来。

2. Level 1 团队：打地基，建骨架

当你的团队已经有了基础自动化，下一步的核心任务是：把自动化测试推上正轨、把部署管道化、把基础设施代码化。

（1）自动化测试从高风险模块入手。不需要追求全量覆盖率，先去识别系统中改动最频繁、故障影响最大的 20% 模块，把这部分模块的单元测试和接口测试补到 80% 以上覆盖率。Pareto 原理在这里完全适用，20% 的测试覆盖能挡住 80% 的回归风险。

（2）部署管道一口气串起来。从代码提交开始，经过编译、单元测试、代码扫描、打包、部署到测试环境，这条链路全程自动化。不允许任何“手动把包拷贝到服务器上”的操作。

（3）基础设施即代码从环境一致性开始。测试环境和生产环境的配置差异是无数故障的根源。用 Terraform 或者 Ansible 把环境配置管起来，确保所有环境的创建是可重复、可审计的。

这个阶段可以开始尝试 Scrum，但 Sprint 周期建议放长到三到四周，给团队留出磨合工程习惯的时间。

3. Level 2 到 Level 3 团队：提效率，降债务

当 CI/CD 管道已经稳定运行、自动化测试形成体系之后，关注点要从“有没有”转向“好不好”。这个阶段的核心是：缩短反馈循环、主动管理技术债、提升可观测性。

（1）追求十分钟以内的 CI 反馈。如果一次代码推送之后要等半小时才能看到构建结果，开发的心流早就断了。优化构建速度，并行执行测试、使用构建缓存、拆分为增量构建，让构建快到开发不会切走注意力。

（2）把技术债登记到待办列表。不是口头上说“下个 Sprint 还”，而是让技术债像功能需求一样被估算、排优先级、分配资源。每个 Sprint 固定 15%-20% 的容量专门用于偿还技术债。

（3）可观测性三件套：日志聚合、分布式追踪、指标监控。出问题以后不要靠人肉翻日志，从 SLI/SLO 反推哪里出了问题，用分布式追踪定位瓶颈，用结构化日志还原现场。这个能力到位了，平均恢复时间才能跨入分钟级。

4. 不同团队规模的差异化策略

工程实践的落地节奏也跟团队规模强相关。我这里给出三个阶梯的策略差异：

（1）15-50 人初创团队：轻量化优先。不用上 Kubernetes，Serverless 或者托管容器服务足够；不用自建监控体系，SaaS 化的 APM 开箱即用。但自动化测试和 CI/CD 不能省，这两项是底线，越早建立越好。

（2）100-300 人成长型组织：标准化优先。这个规模最容易出现的问题是“每个团队各搞一套”，12 个团队 12 种 CI 工具、8 种部署方式。必须建立工程实践的统一基线，统一的 CI/CD 平台、统一的测试框架、统一的代码规范引擎、统一的部署工具链。PingCode 服务这个规模段的客户时，最强调的就是“用平台能力统一工程基线”。

（3）500 人以上大型组织：平台化与自服务优先。这个规模下不能让每个团队自己去搭建 CI/CD 管道，必须有一个内部开发者平台或者工程效能平台，让团队在平台上自服务创建管道、申请资源、查看度量。平台团队的核心职责不是替业务团队操作，而是让业务团队能自助地高效操作。

八、取舍与权衡：工程实践不是不计成本的完美主义

我一直在强调工程实践的重要性，但我绝不是说每个团队都应该不计成本地追求工程完美。工程实践的投入需要算经济账，不同阶段有不同的取舍。

1. 自动化测试覆盖率不是越高越好

我见过有团队把“单元测试覆盖率 100%”当成绩效指标，结果开发花大量时间写低价值的测试，测 getter/setter、测框架代码、测永远不会出问题的工具方法。这种覆盖率是刷出来的，不仅没提升质量，反而增加了维护负担。测试的核心价值在于“失败时有信息量”，不是“覆盖率数字好看”。

我的经验是：核心业务逻辑模块追求 80%-90% 的分支覆盖率，工具类和胶水代码 30%-50% 足够，UI 和配置类代码可以不纳入单元测试覆盖统计。好钢用在刀刃上，测试资源投在改动频率最高、业务影响最大的代码上。

2. 微服务不是默认选项

对于 50 人以下的团队或者业务逻辑高度内聚的系统，模块化单体是一条严重被低估的架构路径。把代码按业务领域拆成模块，模块间定义清晰接口，部署时打包成一个单体，运维成本远低于微服务，但工程收益接近，因为模块边界清晰，可以独立测试、独立重构。等业务规模真正撑到需要独立部署和独立扩展的时候，再把模块拆成独立服务，这个演进路径平滑得多。

3. 不同业务的工程投入弹性

银行核心交易系统和内部 OA 系统的工程要求当然不能一样。我用一个简单的决策矩阵来判断工程投入的适宜程度：

这个矩阵帮团队避免两个极端：一是在内部工具上过度工程化，浪费资源；二是在核心交易系统上工程投入不足，酿成事故。

九、给技术管理者的最后建议

如果你是一位 CTO、VP of Engineering 或者技术总监，正在推动或者被要求推动敏捷转型，我有几句掏心窝子的话想跟你说。

第一，不要再让你的团队在没有工程底座的情况下硬啃流程变革。流程变革会放大每一个工程短板，让团队的痛苦加倍。先把单元测试补上、把 CI/CD 管道跑通、把部署自动化、把代码扫描集成进去，这些事花三到六个月就能见效，而且效果是永久性的。然后再上 Sprint 缩短、发布频率提升这些流程层面的改变，你会发现阻力小得多。

第二，用 DORA 指标替代 Sprint 完成率作为转型的核心度量。Sprint 完成率能告诉你计划执行得怎么样，但不能告诉你软件交付能力强不强。DORA 四大指标，部署频率、变更前置时间、变更失败率、平均恢复时间，才是衡量软件交付能力的金标准。把这两个维度的指标都摆在仪表盘上，但做决策的时候优先看 DORA。

第三，把 20% 的研发容量永久分配给工程改进。不是“这个季度没事干了我们做做自动化”，而是每个 Sprint、每个季度、每年都固定投入 20% 做工程改进。这个投入的回报是复利式的，今年把 CI 从 30 分钟优化到 10 分钟，你的 50 个开发每天就多出 1000 分钟的专注时间，每年多出 4000 个小时。这个账很好算。

第四，不要被“敏捷转型”这个词绑架。敏捷是手段，不是目的。目的是可持续地高质量交付对用户有价值的软件。如果你的工程实践到位了，就算你跑的流程看起来没那么“标准敏捷”，比如你没有严格执行 Scrum 的所有仪式，你的交付能力一样可以很强。相反，如果工程实践稀烂，流程再标准也救不了你。

工程实践不是敏捷的附属品，它是敏捷能够运转起来的物理定律。没有物理定律支撑，飞得越高，摔得越惨。

现在，打开你的 CI/CD 仪表盘，看看上一次生产部署花了多长时间。如果超过一小时，今天就去开会吧，不是再搞一次流程优化研讨会，而是拉上你的技术骨干，讨论怎么把那个管道的瓶颈打掉。那才是真正能让敏捷转型落地的事情。