我为《加速》一书撰写的序言

几年前，我读到了一份报告，报告中说：“我们现在可以自信地断言，高 IT 绩效与强大的业务绩效相关联，有助于提高生产力、盈利能力和市场份额。”当我读到类似的话时，我通常会毫不犹豫地把它扔进垃圾桶，因为这通常是伪科学冒充科学的标志。然而，这一次我犹豫了，因为这是“2014 年 DevOps 状态报告”。其中一位作者是 Jez Humble，我的同事和朋友，我知道他对这种胡说八道同样过敏。（虽然我不得不承认，另一个让我没有扔掉它的原因是我在 iPad 上阅读它。）

所以我给 Jez 发了邮件，想了解这句话背后的原因。几周后，我和他以及 Nicole Forsgren 通了电话，她耐心地向我解释了他们的推理。虽然我对他们使用的方法并不精通，但她说的足以让我相信他们确实进行了一些真正的分析，远远超过我通常看到的，即使是在学术论文中。我饶有兴趣地关注了随后的 DevOps 状态报告，但也越来越感到沮丧。这些报告给出了他们工作的成果，但从未包含 Nicole 在电话中向我解释的说明。这极大地损害了他们的信誉，因为几乎没有证据表明这些报告是基于仅仅是猜测。最后，我们这些看到幕后真相的人说服 Nicole、Jez 和 Gene 通过写这本书来揭示他们的工作方法。对我来说，这已经等了很久了，但我现在很高兴能得到一本我真正推荐的书，它可以作为一种看待 IT 交付效率的方法，一种不仅仅基于少数分析师零散经验的方法。

他们描绘的图景令人信服。他们描述了有效的 IT 交付组织如何将代码从提交到主线到在生产环境中运行的时间缩短到大约一个小时，而较差的组织则需要几个月的时间才能完成这一过程。因此，他们每天更新软件很多次，而不是每隔几个月更新一次，从而提高了他们利用软件探索市场、应对事件以及比竞争对手更快地发布功能的能力。这种对响应能力的巨大提升并没有以稳定性为代价，因为这些组织发现他们的更新导致故障的频率远低于表现较差的同行，并且通常在不到一个小时内就能修复。他们的证据反驳了双模 IT 的观点，即你必须在速度和稳定性之间做出选择，相反，速度取决于稳定性，因此良好的 IT 实践可以让你两者兼得。

所以，正如你所料，我很高兴他们将这本书投入生产，并且将在未来几年里不遗余力地推荐它。（我已经在演讲中使用了草稿中的很多内容。）但是，我确实想提出一些注意事项。他们很好地解释了为什么他们对调查的方法使它们成为他们数据的良好基础。然而，它们仍然是捕捉主观感知的调查，我想知道他们的样本群体是否反映了整个 IT 世界。当其他团队使用不同的方法能够证实他们的推理时，我会对他们的结果更有信心。这本书已经包含了一些这样的内容，例如谷歌关于团队文化的著作提供了进一步的证据来支持他们关于 Westrum 生成性组织文化在有效的软件团队中发挥的重要作用的判断。这样的进一步工作也会让我不那么担心他们的结论证实了我大部分的倡导——确认偏差是一种强大的力量（虽然我主要在其他人身上注意到它;-）。我们还应该记住，他们的书重点关注 IT 交付，即从提交到生产的过程，而不是整个软件开发过程。

但是，这些疑虑虽然存在，但并不应该分散我们对这本书主要内容的注意力。这些调查以及对它们的仔细分析，为可以显著改善大多数 IT 组织的实践提供了最好的理由。任何运营 IT 部门的人员都应该认真研究这些技术，并努力利用它们来改进他们的实践。任何与 IT 部门合作的人员，无论是内部人员还是来自像我们这样的 IT 交付公司，都应该寻找这些实践，以及与之相伴的持续改进的稳定计划。Forsgren、Humble 和 Kim 描绘了 2017 年有效 IT 的样子，IT 从业人员应该利用它作为地图，加入高绩效者行列。

---