当Gene Kim，Jez Humble和Nicole Forsgren发表《加速：精益软件和DevOps的科学：建立和扩展高性能技术组织》时，我感到非常兴奋。 他们的最后一本书《 DevOps手册》为实现DevOps的价值流奠定了一条可重复的道路。
我不知道对Accelerate会有什么期望，但是我希望作者能再次令我高兴。 这篇评论包括我的想法，要点，最后是对谁最合适的建议。 如果您只是对建议感兴趣，请跳到最后。
DevOps与高性能之间存在手工波动的相关性，这种相关性往往会随着市场的蓬勃发展而出现。 Accelerate的目标是通过演示构建高性能IT组织背后的科学，以事实代替事实。
高性能意味着更快地交付更多价值。 换句话说，提供更高质量的功能会更频繁地更改。 该书涵盖了团队如何从承诺到生产实现这一目标。 本书省略了整个软件开发过程。
- 第十九剑客评论
- 我梦见不死圣诞节的评论
- 书评：一个设备-iPhone的秘密历史（2017）
- 朱莉·墨菲（Julie Murphy）的《雷蒙娜·蓝（Ramona Blue）》
- 您的书改变了我的生活：#haikureview Bob Boilen的《你的歌改变了我的生活》
第1部分介绍了发现。 第2部分记录了科学。 第三部分是从ING转型的案例研究。 附录中也有摘要。
我在《 DevOps手册》之后阅读了Accelerate。 感觉就像是《 DevOps手册》的重要附录。 鉴于同一位作者使用大致相同的数据讨论同一主题，这不足为奇。 一般来说，第一部分没有任何新的结论或突破性的启示。 感觉像Accelerate为DevOps实践的支持者提供了更多的弹药。
Accelerate致力于衡量软件交付性能。 既然感觉这是一个模糊的问题，就好像它是高绩效的一部分，但是由于多种原因，要比较团队之间的绩效是一个挑战。 他们的度量通过直接可观察的度量和推断的度量来解决这些问题。 他们将软件交付性能分为四个指标：
- 提前期：从提出请求的客户到满足要求所需的时间。
- 部署频率：频率是批次大小的代理，因为它易于测量并且通常具有较低的可变性。 换句话说：批次越小，部署频率越高。
- 平均恢复时间（MTTR）：考虑到预期的软件故障，衡量团队从故障中恢复的速度更加有意义。
- 变更失败百分比：整个过程中质量的替代指标
我敢肯定，对于这些指标中的每个指标，最好的价值是什么。 显然，绩效较高的团队可以更快地满足客户的需求，同时可以更频繁地满足客户的要求，可以更快地从故障中恢复，并减少故障。 Accelerate为所有指标中的高，中和低绩效者提供价值。
这套指标及其周围的讨论对我来说是值得付出的代价。 我已经分享了度量标准，但没有讨论它们之间为什么以及如何相互关联的问题，这就是本书的目的，而作者的工作要比我能做的更好。
加速覆盖范围不止这四个指标。 我发现组织结构分析很有趣，尤其是因为它是可衡量的并且与其他积极指标相关。 还有关于领导力和员工满意度的信息。 我没想到会讨论员工满意度，但是数据显示这些指标上的良好价值与更少的倦怠相关。 精疲力尽的任何人（包括我在内）都知道这很可怕，应该避免。
我在努力获得工程学工作的满意感时，还为作为工程经理的团队创造了令人满意的工作环境。 我的操作模式是尝试每天提供有用的信息。 这样，您每天就能完成一些有用的事情。 Accelerate的发现证实了我的方法。 很高兴知道有比提供比萨饼和啤酒更好的长期解决方案。
Accelerate解决了《 DevOps手册》中的领导差距。 直到阅读其他材料，我才意识到差距。 《 DevOps手册》没有解决领导和组织支持的重要性。 我很高兴看到在Accelerate中讨论了此问题以及支持数据。
响应能力的这种巨大提高并不以牺牲稳定性为代价，因为这些组织发现其更新导致故障的速度只是其表现较差的同行的几分之一，而且这些故障通常在一小时内得到解决。 他们的证据驳斥了您必须在速度和稳定性之间进行选择的双峰IT观念-相反，速度取决于稳定性，因此良好的IT惯例可以同时为您提供。
最后，我们可以一劳永逸地说，您在速度和质量之间没有选择。 这只是使组织朝着DevOps价值流发展的斗争中的一种弹药。 如果您仍在战斗中，请将此内容带给您的团队。
从数据中可以看出，这个故事的寓意是：只要领导层提供一致的支持（包括时间，行动和资源），每个团队和每个公司都可以改善软件交付，这表明了对改进，只要团队成员致力于工作即可。
所有IT公司（包括那些“顽固的企业”）都可以改善这四个指标。 书中还有更多内容。 没有技术表演的人，只有人。
有趣的是，主要由质量检查人员或外包方创建和维护的自动化测试与IT性能无关。
如果您正在这场战斗中，请把这个带到您的团队中。 我已经亲身体验了这一手，所以现在我身边有了数据。 书中还有另一个相关的观点，即拥有一个外部变更批准委员会（CAB）与IT绩效负相关。 关键是您可能认为改善性能的事情充其量会造成辛劳，而最糟糕的是会损害性能。
即使使用打包的软件和“旧式”大型机系统，也可以实现这些特性-相反，如果忽略这些特性，采用部署在容器上的最新Whizzy微服务架构并不能保证更高的性能。
由于团队采用技术或体系结构来实现IT性能，因此这段话让我发笑（除了马丁·福勒（Martin Fowler）在前言中写的“伪装成科学的胡说”）。 实际上，没有发现特定技术与IT性能之间存在关联。 实践是所有与技术正交的问题。
加速是一本容易阅读的书，您可以在4到5个小时内完成。 阅读Kindle上的图形和表格令人沮丧，以至于改用Kindle for MacOS。 您可以在Kindle上识别它们，但是在更好的屏幕上它会容易得多。 表格和图表在文本中进行了讨论，因此您（就像我一样）可以在看不清它们的情况下进行修改。
我向决策者推荐这本书，让他们想知道如何提高组织的IT绩效。 如果您喜欢统计信息和相关性，那么Accelerate就是通过应用技术和组织惯例来提高IT性能的有力理由。 但是，如果您更喜欢案例研究和个人经验，您将一无所获。 授予部分3致力于此内容，但并未与研究结果相结合。
我还向所有试图说服领导者尝试DevOps实践的人推荐这本书。 数据证明了这一点。 而且，高绩效者和低绩效者之间的差距正在扩大，因为高性能会变得更好，而低绩效者则不会。 尽早将这本书推上指挥链。
如果您已经决定转向DevOps，并且需要有关如何达到该水平的指南，那么我不推荐这本书。 《 DevOps手册》非常适合，并且可以利用更多的第一手经验和实施模式来借鉴相同的数据。
如果您对软件工程充满热情并且对如何改进流程感到好奇，那么您可能会喜欢Accelerate。
附言：我很喜欢这些评论，希望你也喜欢。 如果您希望我复习一本书，请在评论中让我知道。
