本书全名为《加速：企业数字化转型的24项核心能力》，作者是DevOps领域的三位领军人物，观点是”DevOps实践和持续交付实践有助于企业提高绩效”。本书亦可作为DevOps实践手册，甚至可以指导DevSecOps等扩展领域。
核心观点
- DevOps首先是一种分治&解耦的技术组织结构，其次才是岗位、工具、流程、理念、哲学、文化等等不一而足；
- DevOps核心价值是，生产力随工程团队的规模线性提升、支撑公司业务快速扩张；
- 行业或业务发展减速后，DevOps的价值就会大打折扣，甚至会暴露出分工冗余、人效低下等问题 —— 每种理念都有它的时代局限。
- 关键名词：软件交付绩效、组织绩效，持续交付、精益产品和流程、精益管理、变革型领导力，以及倦怠感、部署之痛、工作满意度等员工感受维度
内容摘要
企业数字化转型的24项核心能力，全景框图如下。
DevOps的内容摘要，如下。
其它观点
以下观点，堪称洞见：
- 效率至上：卓越绩效的企业，不必以牺牲质量为代价、来换取交付效率。这是因为，通过提升交付效率、效率和质量可以兼得。效率提升，本质是生产力的进步、是实打实的硬发展。而生产力进步，为更先进的质量运营提供了技术基础，甚至生产力本身就是更先进的质量运营范式。所以我们经常能看到，以效率提升为目标的建设工作，往往出人意料的促成了质量飞跃，反之则不然。技术发展才是硬道理，运营次之。
- 官僚主义：官僚主义不是坏事。官僚主义的目标是，通过制度规则、消除任意性&保证公平；同时，规则是组织内的知识积累，规则是由领域专家制定的、规则也是高效的结构和流程(至少在创立之初是)。官僚组织中，规则面前人人平等，将规则应用于行政行为、可以确保公平。
- 利旧路线：可部署、可测试等关键架构特征，比容器化、微服务等架构实现细节更重要。《加速》的统计数据显示，拥有良好架构特征的老系统也能交付高绩效，这也印证了利旧路线的可行性。原文是，”系统类型与软件交付绩效之间没有显著的相关性。我们原本以为开发商业化套装软件、嵌入式系统等老项目的团队会有较低的绩效，而开发交互型系统或新项目的团队会有较高的绩效。然而统计数据显示，事实并非如此。这进一步强化了我们的观点：「关注架构特征比关注架构的实现细节更重要」。即使是套装软件和其它遗留的老系统，拥有良好的架构特征也并非不可能；相反，如果忽略了架构特征，即便使用了容器技术和微服务架构，也无法保证交付绩效”。
- 工具自主：工具选择是一项重要的技术工作，团队对工具的自主选择权有助于提高软件交付绩效、进而提高组织绩效。尽管如此，仍有一些需要标准化的地方，特别是架构和基础设施的配置，如标准化运维、安全左移、SOA等。一个理想的模式是，早期放开、以业务迭代为主，摸索完后再收紧、兼顾规范和效率；后期的收紧，是为了抽象中台、通过集中进一步优化边际效益。
- 多元组织：在性别或少数族裔等方面更具多样性的团队，往往表现更佳、绩效更高、业务成果更好。为了实现多样性，就必须有包容性。
以下观点，可以作为知识输入：
- 失败需求：失败需求指的是未能在第一时间做正确、而产生的额外工作需求，包括功能返工、逻辑漏洞、Bug修复等
- 软件选型：战略性软件必须自研，非战略性软件可以采购SaaS
- 轻量审批：采用轻量级的同行评审、来管理对生产环境的变更，而不必通过外部人员来审批所有变更。仅审批高风险变更不能提高软件交付绩效，同行评审(结对编程 DoubleCheck)或不审批 有利于提升交付绩效、外部审批(如经理审批)则会降低交付绩效。统计显示，外部审批更多是一种风险管理作秀，它与变更失败率无关，与前置时间、部署频率、平均恢复时间呈负相关。
- 组织绩效：组织绩效，即商业绩效，包括盈利能力、市场份额和生产力。非商业绩效，包括企业的产品和服务数量、运营效率、客户满意度、产品和服务质量，以及实现组织或任务目标的可能性。
- 病态度量：在具有病态和官僚文化的组织中，度量被作为一种控制工具，发起者会隐藏挑战现有规则、战略和权力结构的信息。正如Deming所说，哪里有恐惧、哪里就有错误的数字。