变更审批是软件交付瓶颈，AI加剧此问题。核心解决之道是小批量工作和简化审批，包括同行评审与自动化，以提高吞吐量、质量与合规性。
译自：Stop Wasting AI Investment on a Broken Change Approval Process
作者：Steve Fenton
变更审批几十年来一直是软件交付的制约因素。随着团队采用AI编码助手和代理，变更的数量、规模和复杂性正在让一个糟糕的问题变得更糟。
对于许多组织来说，对AI提高开发者生产力的投资未能产生有意义的回报，而基于委员会的审批往往是其中一个促成因素。如果组织不愿意简化其变更审批流程，那么在其他方面提高生产力的投资将完全是浪费。
简化的变更审批依赖于开发过程中的同行评审以及自动化，以便及早发现不良变更并阻止它们通过交付管道。
一个简单而关键的想法：小批量工作
现代软件交付的核心有一个简单的想法，它驱动着所有其他可以改善吞吐量、稳定性、质量和合规性的事情。这被称为“小批量工作”。这个想法如此简单，但许多组织却不予理会。
他们说：“也许小公司或初创公司可以小批量工作。但我们受到监管！”
认为监管要求大批量是无稽之谈。如果你审阅拟议的网络安全规则，你会发现小批量和短前置时间将是一个显著的合规优势。小批量在安全性、安全性和合规性方面远优于大批量。
大批量就像病毒。当软件交付管道的任何部分以大批量移动时，它会迫使整个管道的批量大小随之变大。这意味着你最终会得到一个与交付过程中最大批量相适应的管道。这通常是手动测试软件版本所需的时间或变更审批的节奏。
要小批量交付软件，你必须识别批量大小是在哪里设定的，并通过改进流程、自动化步骤和寻找最小化摩擦的方法来在该阶段减小它。这就是持续交付的强大之处。它鼓励测试成为一个持续的活动，并要求审批是交付管道的持续组成部分。
经过研究和经验证实
有大量的研究探讨了批量大小如何影响软件交付吞吐量、质量和风险。Google的长期运行的DORA（DevOps研究与评估）项目在其能力模型中包含了小批量和简化的变更审批。你可以看到它们是如何相互关联的，因为我们知道，如果变更审批流程缓慢而繁重，变更数量将不得不增加。
轻量级变更审批在Octopus Deploy的“通过持续交付实现合规”报告中得到了进一步细分，该报告将其定义为具有以下四种特质：
- 健康的审批链：当需要一系列审批时，它应该包括团队和直接经理的签署。
- 少量手动审批：拥有大量手动审批会在变更审批过程中造成复合延迟。
- 无跨团队委员会：变更审批委员会和小组是变更审批最糟糕的方法。
- 在部署/ITSM工具中捕获审批：在部署和ITSM（信息技术服务管理）工具中捕获审批可以减少审批摩擦。
轻量级变更审批与可靠的部署相结合，可以提高软件交付吞吐量，并实现治理、风险和合规目标。
尽管Fred Brooks，《人月神话》的作者，告诫我们没有银弹，但公平地说，软件交付被超自然怪物所困扰。这些怪物可以通过小批量这颗银弹有效驱逐。当你决定缩小批量大小时，你必须解决整个软件交付管道中的低效率问题，而变更审批就是徘徊在这片特定森林中的一个野兽。
尽管统计数据是小批量和轻量级变更审批的宝贵证据，但我们也有来自实践者三十年的经验来证实这一点。这些经验被Kent Beck（极限编程）、Dave Farley 和 Jez Humble（持续交付）、Mary 和 Tom Poppendieck（精益软件开发）以及David Anderson（看板）在许多软件方法中记录下来。
聚焦代码审查和AI
在更广泛的变更审批话题中，我们还有一个虽小但重要的代码审查问题。大型变更集、重量级代码审查流程、异步审查以及未能在签入前运行测试自动化都会降低交付速度。代码审查中的问题对软件交付性能有害，并削弱了像GitOps这样的方法的好处。
如果你使用AI在短时间内生成更多代码，现有的代码审查瓶颈将显著恶化。你可能会增加批量大小，引发一个恶性循环，导致更长的等待时间、更广泛的审查和显著的质量问题。当你需要等待更长时间才能收到审查反馈时，你会开始为每次审查积累更多变更，这会进一步放大问题。
在12月发布的“AI与人类代码生成状态报告”中，CodeRabbit分析了470个开源拉取请求，比较了AI生成的变更与人类所做的变更。AI犯的错误比开发者多1.7倍，且重大和关键错误的发生率更高。这意味着，随着我们增加代码审查的负担，它也变得更加关键。
许多组织正在通过添加像Gemini Code Assist或CodeRabbit这样的工具来加快代码审查以应对这一问题。这只是解决此类瓶颈的部分方案。添加工具是不够的，我们需要系统地思考约束。
商业管理大师Eli Goldratt曾说，你的系统中永远只能有一个约束。它是链条中最薄弱的环节，所以无论你对其他环节做什么，链条永远不会比那个最薄弱的环节更强。管理约束有五个聚焦步骤：
- 识别：你必须找到真正的瓶颈。
- 利用：从你所拥有的中获取最大价值。
- 从属：让其他一切都与瓶颈保持同步。
- 提升：投资于扩大瓶颈处的容量。
- 重复：因为瓶颈可能已经移动了。
如果你已将代码审查识别为瓶颈，你应该首先利用它。你必须确定如何最大化代码审查过程的价值。这可能就像在代码审查队列中优先处理最有价值的变更一样简单。
接下来，你通过将所有阶段的节奏设置为与处理代码审查的速度相匹配，从而使软件交付管道从属于代码审查。代码审查之后的阶段自然会受到限制，因为工作只有在审查完成后才能开始，所以你应该限制在代码审查之前的阶段引入工作，以匹配其速度。
如果开发人员由于在制品限制而无法开始新工作，他们或许可以承担一些代码审查工作量，整个系统也因此得到改善。
最后，你提升约束，这意味着提高完成代码审查的速度。你的首要任务应该是小批量工作，因为这意味着更小的代码审查，更容易理解和审查。
你还可以自动化许多任务，以减轻人工审查员的负担。你可以使用linting工具、自动化测试和静态分析，无需人工审查即可为开发人员提供更快的反馈。这意味着代码审查的范围更窄、更集中。用于总结和检查变更的AI代码审查工具在此阶段可能会有所帮助。
这五个聚焦步骤中的关键智慧在于，如果你跳过到提升阶段，你最终会自动做那些本可以在不投资的情况下移除或解决的事情。
这一切都与小批量有关
一切最终都回归到小批量工作。减小批量大小是改进的强大积极驱动力。当自动化能够实现按需部署的微小变更集时，它才变得有意义。小批量指导你的工具选择和流程改进，而产品、团队和组织绩效方面的结果将向你证明它是有效的。
当你审视你的变更审批流程时，你可能会认为以如此小的批量工作没有意义，因为每一个都需要召集整个变更审批委员会。实际上，当你能处理如此小、低风险的批量时，变更审批委员会就没有意义了。
