2024年AI加速软件交付测评：效率提升的真相与局限

在软件开发的漫长旅程中，我们似乎总在追逐同一个幻影：速度。从敏捷到DevOps，再到平台工程，每一次变革的号角都吹响着“更快交付”的承诺。如今，人工智能（AI）成了最新的“翻跟斗”。但如果我们停下来思考，会发现一个被反复忽略的真相：速度本身从来不是目的地，它只是通往某个更重要目标的路径旁，一块容易让人分心的路标。

这让人想起一个关于选择的比喻。假设你去动物救助中心，想领养一只狗作伴。陪伴，是核心诉求。但工作人员却极力推荐一只猎豹，理由仅仅是它跑得比任何狗都快。这个场景听起来很荒谬，对吗？然而，许多组织在引入AI时，恰恰在做着类似的事情：只盯着“速度”这一项指标，却忽略了软件交付真正应该服务的核心目标。

速度从来都不是目标

我们其实早就该从“敏捷”运动的演变中吸取教训。当敏捷退化为仅仅追求迭代速度和故事点产出时，它的灵魂就已经丢失了。提升效率的首要意义，在于更早地获取反馈。关键在于，当你发现那个精心设计的新功能用户根本不买账时，你能多快停下来。

尽早终止一个糟糕的想法，意味着能节省大量资源，并迅速转向更有潜力的方向。没有人应该致力于用最快的速度堆砌最多的功能。历史一再证明，功能膨胀和频繁但无意义的变更，最终会让用户对产品心生反感。

看看微软Word和谷歌文档的例子。Word无疑是功能最强大的文字处理软件，但如今还有多少人专门启动它呢？更多人转向了功能看似“简陋”的谷歌文档。这背后是多种因素的合力：或许谷歌选对了真正吸引人的核心功能，或许更少的功能带来了更流畅的体验。但不可否认，在浏览器中无缝协作这一亮点，足以让用户做出选择。市场数据很能说明问题：Word目前约占3.9%的市场份额，而谷歌文档占到了9.6%。如果认为这仅仅是价格问题，那可能正说明你身处一个只片面追求“交付速度”的环境，已经远离了“打造用户真正珍视的软件”这一初心。

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

当软件行业的领导者们再次高举“为提速而采用AI”的大旗时，这份宣言需要被审慎审视。回顾过去一二十年，同样的剧本已经上演多次：为追求速度而进行敏捷转型、推行DevOps、打造内部平台。然而，在投入大量精力后，成果往往寥寥。这本身就表明，他们宣称的对“速度”的渴望，可能并不真实。

当然，谁都希望自己的团队能贴上“DORA精英绩效”的标签。但如果没有对更频繁交付所带来的根本性成果——即用户反馈——产生真正的兴趣，那么追求速度的动力就是空洞的。任何一位带领团队经历了多次以“速度”为名的折腾，如今又宣称AI将最终实现这一目标的领导者，或许都需要先面对一个事实：问题可能不在工具，而在目标本身。

反馈节拍器

将关注点从“速度”转移到“反馈”上，会让整个软件交付流程的节奏发生根本改变。让反馈循环成为流程的节拍器，以此设定工作节奏，能为处理反馈留出关键空间，从而实现敏捷思想的核心：快速调整方向。

那些以反馈定调的组织和团队，会主动识别并消除打乱节奏的障碍。他们设计团队架构，以最小化、精心管理的依赖关系来工作。他们简化审批流程，让团队能自主决定部署时机，同时确保能完整观测部署后的效果。

DORA模型及其涵盖的生成性文化、变革型领导力、精益产品管理和持续交付，并非偶然的创造，而是数十年实践沉淀的结晶。践行这些的团队确实拥有交付速度，但这并非他们采纳这些实践的初衷。他们真正追求的，是获得高频、高质量的反馈，从而弄清楚到底应该构建什么。

Elite团队的实践

有一个来自大型医疗保健企业的软件团队案例，我们姑且称其为Elite团队。他们开发的患者管理和急诊分诊软件，属于安全关键型系统，直接关乎生命健康。

在变革之前，他们的患者管理系统每六个月发布一次，而决策支持系统的测试周期长达两周，若发现问题还需额外两周。如此循环，直到某个版本通过测试。

即便在这样的背景下，通过一项为期六个月的计划，他们成功将可部署版本的创建周期缩短至每三小时一次。关键不仅在于引入了强大的技术实践（如实例化需求的可执行规范），更在于大刀阔斧地删减了那些拖沓低效的官僚式审核环节。

成果是显著的：他们与一家新的医疗保健服务商达成合作，需要在两周内交付一个关键的决策管理API。他们安全地做到了，并最终赢得了一份价值约250万美元的合同。

这个案例说明，如果组织没有先梳理投产路径并做出根本性改变，那么任何工具——包括AI——都无法带来期望的交付速度。否则，引入AI只会重蹈Scrum、DevOps和平台工程的覆辙：热闹一阵，收效甚微。

当下最重要的事情，是梳理从代码提交到生产部署的价值流，并修复其中断裂的环节。该怎么做并无神秘之处，Da ve Farley和Jez Humble在《持续交付》一书中早已揭示了路径。

你为什么采用人工智能？

所以，当考虑引入AI时，或许应该重新审视那个标准答案：“为了提升效率、加快进度”。如果你认真对待软件开发，不妨明确地将核心优先事项定义为：获取频繁的反馈和实现决策的敏捷性。

那些已经通过持续交付等实践平衡了吞吐量与稳定性的团队，对“单纯提速”的执念反而更低。他们更愿意将精力投向更有价值的机会。以下就是几类值得探索的方向：

更小的团队规模。我们过去常常在团队规模上妥协，因为业务等不及一个小团队慢慢开发。但“人月神话”的警示犹在耳边：向延误的项目增加人手，只会让它延误更久。大多数团队将规模控制在6到12人（“两张披萨”团队），这已是权衡沟通复杂度后的务实选择，但并非理想状态。

如今，AI或许能让我们重新构想“一张披萨”甚至更小规模的团队。让具备高度自主性、基于松耦合组件工作的小型团队成为可能，这或许是释放AI在软件开发中价值的有力方式。

打造更具格局的产品。最后，与其用AI更快地开发同样的软件，不如用它赋能团队去挑战更具愿景的产品。可能是推进以往不敢启动的全球化布局，也可能是将那些萦绕心头却始终理不清思路的功能构想，借助AI快速原型的能力进行验证和探索。

无论如何，起点都应该是更大力度的优化软件交付流程和部署流水线。务必打通反馈闭环，并像使用节拍器一样，让它来主导工作节奏。当这些基础打好后，再引入AI，你所追求的目标将远比“单纯提速”更有价值，也更具想象空间。