人工智能无法加速软件交付

速度从来不是真正的目标

我们以前经历过这些。敏捷运动曾经是追求更早获取反馈、更快调整方向的利器，但如今许多组织只留下了“速度”这个空洞的口号。速度本身从不是目标：提升工作效率的首要意义是为了更早获取反馈——当你发现新功能未能吸引用户时，可以立即停止开发，避免浪费资源。微软Word曾是文字处理软件的霸主，但如今谷歌文档凭借更少的功能和协作便利性抢占了9.6%的市场份额。单纯追求功能膨胀和变更速度，只会让用户反感你的产品。真正有价值的是打造用户重视的软件，而非一味求快。

为了速度而采用人工智能缺乏可信度

软件行业的领导者有着一贯的作风：他们曾宣称为了追求速度而进行敏捷转型、采用DevOps或平台化改造，但耗费大量精力后并未取得显著成果。这充分说明他们并不像声称的那样渴望速度——他们或许想给自己的履历贴上一枚“DORA精英绩效”徽章，却对更频繁交付带来的用户反馈毫无兴趣。如今他们又用同样的叙事兜售人工智能：引入AI能加速代码编写。然而，AI工具虽能加速局部代码生成，但整体交付速度并未提升。企业系统充斥着老代码、复杂依赖和架构混乱，AI难以理解全局上下文，反而可能生成更多错误代码，徒增返工。

反馈节拍器才是核心

当你看重反馈而非速度，反馈循环就会主导软件交付的节奏。以这个节拍设定工作节奏，能为你留出处理反馈的关键余地，做到敏捷理念的核心——快速调整方向。把反馈当作节拍器的团队会主动消除打乱节奏的工作：规划团队架构以减少依赖，简化变更审批流程，确保团队自主决定上线部署并能观测实际效果。DORA模型及其包含的生成式文化、变革型领导力、精益产品管理与持续交付流程并非偶然，而是数十年实践的沉淀。践行这些理念的团队固然有交付速度，但他们的初衷是获取高频、高质量的反馈，从而找准真正需要构建的内容。

Elite团队的180万美元奇迹

一家大型医疗保健企业旗下的软件团队主营病患管理与急诊分诊业务，起初每六个月发布一次病人管理系统，决策支持系统的测试周期长达两周，若发现问题还要再加两周。即便如此，他们通过一项为期六个月的工作计划，引入了实例化需求的可执行规范，同时剔除了流程缓慢、效率低下的官僚审核环节，最终实现了每三小时创建一个可部署的软件版本。当与一家新医疗保健服务商达成合作时，对方需要决策管理API接入网站系统——他们在两周内安全交付了可用API，并促成了一份价值180万美元（相当于现在的250万美元）的合同。这个案例表明：如果你没有梳理出投产路径并修复损坏的环节，引入任何新工具（包括AI）都只能重蹈Scrum、DevOps、平台工程的覆辙。

你的组织准备好迎接AI了吗？

许多公司发现，现有基础设施无法充分利用AI驱动的开发工具。常见的瓶颈包括拉取请求审核、安全合规检查、环境配置等，这些环节并未因AI而加速。而初级开发人员在使用AI后交付速度更快，但出错时却无法调试——他们缺乏系统思维，难以理解AI生成代码的上下文。如果你认真对待软件开发，就应该转变说辞：频繁反馈和决策敏捷性才是核心优先事项。那些已经通过持续交付解决了吞吐量与稳定性权衡的团队，对单纯追求速度的执念更低，更愿意挖掘更有价值的机会。比如，缩小团队规模——传统“两张披萨”团队（6-12人）实际上偏大了，只是妥协的结果。有了AI，应当考虑打造“一张披萨”团队甚至更小。你当下能做的最重要的事情就是梳理从代码提交到生产部署的价值流，开始修复那些损坏的部分。正如Dave Farley和Jez Humble在《持续交付》中所揭示的：做出改变并无神秘可言，关键在于行动。