小批量，在追求速度的过程中常常被忽视，可以帮助组织应对新的情况或知识并改变方向。
译自 Speed Means Nothing Without Real Feedback，作者 Steve Fenton。
软件交付的重量级时代错误地将过多的价值放在活动上，而敏捷时代则过分强调速度。
速度近视意味着已知的好事，例如小批量，纯粹是从使团队更快这一角度来考虑的。小批量的其他好处被忽略了，在追求优化直线速度的匆忙中迷失了。
小批量消除了当您一次性引入过多变更时逐渐出现的复杂性纠缠。这可能很容易被认为是流程的必要部分，但它会占用宝贵活动的时间和精力。
当理查德·费曼被从洛斯阿拉莫斯实验室派往橡树岭国家实验室以提高高爆炸性铀储存的安全性时，一个关键因素是储存在一起的材料数量。在一个地方放置过多的材料可能会导致其自发爆炸。
软件团队需要了解这一原则也适用于变更。当变更过多时，危险的交互会在交付过程的每个阶段显现出来。合并变更、测试软件、修复发现的问题、升级数据存储和推出新版本，当您批量处理变更时，所有这些都会面临更高的风险。
软件可能不会真的爆炸，但一批工作的运动成本远高于单个变更的运动成本，并且呈超线性增长。想象一下，在一个条形图上拖动一个滑块，“有价值的工作”在左边，“返工和补救”在右边。批量大小会以越来越大的幅度将滑块向右移动。
小批量有很多技术优势，它们还有助于组织通过提供许多重新定向投资的机会来应对不断变化的条件和新知识。您可能比预期用更少的变更达到目标，从而允许您提前停止并转向新的目标。或者，您可能会意识到当前的方法行不通，从而允许您在预算用尽之前尝试不同的方法。
最重要的是，小批量可以让您更快地获得反馈。此反馈可确保您的投资和努力正在产生预期的影响。而这正是许多组织未能联系起来的部分——这给他们的目标带来了巨大的成本。
为了快速交付工作，组织并没有倾听反馈。多年来，聪明的人一直在说，要想跑得快，就得跑得慢。如果您没有时间在快速完成待交付功能列表的过程中关闭反馈循环，那么是时候发现“更快反而更慢”了，正如系统科学家、《第五项修炼》的作者彼得·圣吉所说。
DORA 研究项目也发现了这种放慢速度才能更快前进的概念。DevOps 状态报告在 2023 年引入了以用户为中心的团队的概念，并在 2024 年再次验证了这些发现。
以用户为中心的团队的超能力是，他们能够以较低的吞吐量实现最高水平的产品性能。高吞吐量团队可能能够更频繁地交付，但如果没有关键的反馈，他们就会创建低价值的功能。
成功的功能不仅仅是按时按预算交付的功能——或者非常快。它们是通过提高用户完成任务的能力来取悦用户的功能。当您可以交付高比例的成功功能时，您就不需要依赖于那些反复尝试的组织所需的变更量。