在我成长的岁月里，我养过一只拉布拉多与惠比特混血犬，名叫巴克利。我们几乎形影不离。我在花园里挖洞时，它会在旁边嗅来嗅去。我在看书时，它会趴在我腿上，常常趴到我双腿发麻。当我们全家去森林散步时，它会跑在前面探路，再折返回来看看我们。在它欢快地来回奔跑间，它跑过的路差不多是我们的十倍。
狗最棒的一点在于，当你处境艰难时，你可以跟它们倾诉。它们是极好的倾听者，当无人理解你时，它们懂你。
如果我还要再养一只狗，陪伴会是我首要的理由。养狗的理由有很多，但对我而言，陪伴永远排在第一位。
现在想象一下，我去救助中心想要看看可领养的狗狗，而他们却想让我带一只猎豹回家，只因为它跑得比狗快得多。这就好比有些机构声称自己在用人工智能，却只狭隘地看重速度。
速度从来都不是目标
我们以前经历过这些。我们都应该为敏捷运动凋零成干瘪的空壳、只剩下单纯追求“速度”而感到惋惜。速度从来都不是最终目标。提升工作效率的首要意义是为了更早获取反馈。当你发现你令人惊叹的新功能并未让用户感兴趣时，可以立即停止开发。
如果你能尽早终止一个糟糕的想法，就能少浪费很多资源，并且能立即转向更好的思路。没有人应该一味追求用最多的功能、最快的变更速度来开发软件。当软件堆砌了过多功能，还为不断膨胀的功能列表频繁改动时，人们就会开始反感你所开发的产品。
微软的 Word 是当今最强大、功能最齐全的文字处理软件，但已经没什么人专门用它了。他们都在用功能少得多的谷歌文档。这说明谷歌选择的功能必定更具吸引力，或者说更少的功能让软件变得更易用。实际上，这是诸多细小因素共同作用的结果。有时候，一项真正亮眼的功能便能盖过所有其他的功能，而在浏览器中就能协作编辑谷歌文档的便捷性可能正是如此。
如果你在二十年前问别人，他们会告诉你微软 Word 在同类软件中拥有不可撼动的地位，但现在它只占有 3.9% 的市场份额，而谷歌文档占 9.6%（数据来源：https://6sense.com/tech/productivity/googledocs-vs-microsoftword）。如果你认为这种市场转变仅仅是定价问题，那你很可能正在为那种只片面追求速度的组织工作，因为你已经不再相信打造用户真正重视的软件这一理念了。
为了速度而采用人工智能缺乏可信度
软件行业的领导者有着他们的一贯作风，当他们宣称只为一味追求增速而采用人工智能时，这一点理应被审慎看待。你会发现，在过去十年或二十年里，他们曾宣布为追求速度而进行敏捷转型、采用 DevOps 或进行平台化改造。
他们在所有这些举措中耗费了大量精力却未取得显著成果，这充分说明他们并不像声称的那样渴望速度。当然，他们想给自己的工作履历贴上一枚“DORA 精英绩效”的徽章。但他们仍然没有真正的动力去提升速度，因为他们对那个更频繁交付的基本成果——用户反馈——并不感兴趣。
任何一位让团队以速度之名经历了这么多次折腾，现在又说人工智能将最终带来速度的领导者，都是在自欺欺人。
反馈节拍器
当你更看重反馈而非速度时，就会让反馈循环来主导整个软件交付流程的节奏。以这个节拍来设定节奏，能为你留出关键余地去处理反馈，并做到敏捷理念所倡导的核心：快速调整方向。
把反馈当作节拍器、为整体工作节奏定调的组织和团队往往能够主动找出并消除所有打乱节奏的工作。他们规划团队架构，以最小且经过精心设计的依赖关系来开展工作。他们简化变更审批流程，确保团队能够自主决定何时上线部署，同时也能完整地观测到部署后的实际效果。
DORA 模型及其包含的生成式文化、变革型领导力、精益产品管理与持续交付流程并非偶然被创造出来的，而是数十年深耕实践沉淀出的成果。践行这些理念的团队固然拥有交付速度，但这并非他们采纳这类文化与实践的初衷。他们真正追求的是获取高频且高质量的反馈，从而找准真正需要构开发什么。
Elite 团队的做法
Elite 团队是一家大型医疗保健企业旗下的软件团队。该机构主营病患管理与急诊分诊相关软件业务。放到安全关键行业来看，这类软件确实是能够直接关乎生死的。
他们每六个月发布一次病人管理系统，而决策支持系统的测试周期为两周，如果发现问题还要再加两周。如此循环往复，直到某个版本测试通过为止！
即便有着这样的过往，我们还是设法开展了一项为期六个月的工作计划，每三小时就能创建一个可部署的软件版本。我们遵循了一套非常强大的技术实践，但我们删减掉的内容或许比新增的更为重要。这种平衡来自于引入了实例化需求的可执行规范，同时剔除了流程缓慢、效率低下的官僚审核环节。
就成果来看，与一家新医疗保健服务商达成重要合作，对方需要提供决策管理 API，用于接入他们的网站系统。我们在两周内安全地交付了一个可用的 API，并促成了一份价值 180 万美元（相当于现在的 250 万美元）的合同。
如果你的组织还没有梳理出投产路径并做出类似的改变，那么没有任何方式能够实现你想要的交付速度。你会引入人工智能，就像当初引入 Scrum、DevOps 和平台工程一样，最终依旧收效甚微，和过往的结局别无二致。
你当下能做的最重要的事情就是梳理价值流，尤其是从代码提交到生产部署的流程，并开始修复那些损坏的部分。该做出哪些改变其实并无神秘可言。Dave Farley 和 Jez Humble 在他们合著的《持续交付：通过构建、测试和部署自动化实现可靠的软件发布》中已经揭示了其中的奥秘。
你为什么采用人工智能？
在此之前，你或许会说采用人工智能是为了提升效率、加快进度。倘若你认真对待软件开发这件事，我希望你能转变这种说法，并向身边的人明确表明：频繁反馈和决策敏捷性才是你的核心优先事项之一。
那些已经通过持续交付等实践解决了吞吐量/稳定性权衡的团队，对单纯追求速度的执念会更低。他们更愿意去挖掘更有价值的发展机会。最后，我想列举并建议几类这样的机会。
小团队更优。我们在这个问题上做出了妥协，因为我们需要的东西等不及一个非常小的团队来慢慢完成。我们可能会将团队规模扩大一倍，即使我们知道这样做并不会将所需的时间缩短一半。COCOMO 模型对这种收益递减规律有着精密的计算，不过 Fred Brooks 说得更令人印象深刻：向一个已经延误的项目增加人手只会让它延误得更久。
因此，大多数深知沟通与协调复杂度的软件团队都会把人数控制在 6 至 12 人的规模区间，也就是所谓的“两张披萨”团队。但这并非理想团队规模，其实还是偏大了。这只是权衡多方因素后做出的务实选择。如今有了人工智能，我们应当考虑打造“一张披萨”规模的团队，甚至更小。
具备高度自主性、基于松耦合组件开展工作的小型团队或许是释放人工智能赋能软件开发价值的有力方式。
我的最后一个建议是，与其只是更快地开发原有软件，人工智能或许能让你的团队去打造更具格局与愿景的产品。你可以着手推进以往迟迟不敢启动的全球化业务布局。你或许早就有一些功能构想，却始终无法梳理出清楚的思路，而借助人工智能快速搭建原型，你能够进行从前难以尝试的探索与实践。
无论如何，先从对软件交付流程与部署流水线进行更大力度的优化着手。务必打通反馈闭环，并像使用节拍器一样用它来把控整体节奏。做好这些之后，你在引入人工智能时便能追求远比“单纯提速”更有价值、更具想象空间的目标。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
