由 阿娇（Gillian） 撰写 。
最近，我们与DevOps研究与评估的创始人兼CTO，DevOps思想领袖，一些有关大规模交付软件的基础书籍的作者Jez Humble坐了下来。 Jez和他的合著者Nicole Forsgren和Gene Kim最近出版了他们的最新著作，《 加速：精益软件和DevOps的科学：建立和扩展高性能技术组织》 。 请继续阅读以了解Jez所说的书来预测60年代的DevOps文化，为什么对团队的冷嘲热讽是精疲力尽的标志，以及如何通过组织缓慢地推动变革。
Jez Humble：在过去四年中，Gene Kim，Nicole Forsgren和我本人与Puppet共同制作了《 DevOps状态报告》（今年我们与Google合作）。 我们一直在弄清楚如何衡量技术团队的绩效，以及预测绩效的因素是什么。 很多人说：“将所有这些汇总到一个地方真的很不错，并为您解释为什么我应该相信这一点，以及为什么这不仅仅是一些行业废话。”
因此，我们一直认为应该写一本书，然后马丁·福勒（Martin Fowler）在一次会议上遇见了妮可（Nicole），并告诉她如果她不这样做，他会去的。 妮可说：“哦，天哪！”于是我们坐下来写下来。
Accelerate涵盖了从持续交付的技术实践到文化，产品管理，人员管理和领导力的所有内容。 它讨论了重要的，不重要的，以及如何预测IT性能，软件交付性能，以有意义的方式衡量这些事情，以及最终它们如何影响组织绩效。
耶兹：这是一个很好的问题，坦率地说，这使我感到沮丧。 我放在书架上的其中一本书叫McGregor，写于1960年。
麦格雷戈（McGregor）谈论了这两种（实名不佳的）管理理论，即X理论和Y理论。
X理论说，你用胡萝卜和粘手的方式对待人。 Y理论说，您假设人们想尽自己最大的努力，并提供鼓励这样做的环境。
麦格雷戈说，经理们得到了他们所相信的。 因此，如果您认为胡萝卜和大棒是必要的，并且人们从根本上对他们的工作不感兴趣，那么人们将以这种方式行事。 而如果您认为人们从根本上想尽力而为，并以这种方式对待他们，他们就会表现得如此。
因此，这不是一个新主意，而是70年后，我们沿着采用曲线走了多远？ 因此，这不是我们要解决的新问题。
坦白说，处于一种我们发现自己处于后资本主义范式的环境中，并不能很好地促进这种转变。 因此，我认为DevOps是它的新版本。
就是说，我们有一些新模型和新数据显示出文化会影响性能，而新的做事方式也会影响软件交付。 因此，我们希望这些数据将有助于影响采用率，但这很难做到。
很难改变，而且我们的经济和组织的结构化方式正在朝着这个方向努力。
Jez：是的，很容易想到，如果您更改诸如工具之类的有形东西，或者对团队进行重命名，那么您将获得结果。
但是，这种方式行不通。 您还必须改变人们的工作方式。
这很难做到。 您如何平衡交付当前工作的压力，同时还要关注“嗯，我们实际上如何变得更好？”或“我们如何投资？”
具有讽刺意味的是，通过投资和变得更好，您实际上能够更快地完成工作。 我的意思是，这就是所谓的“加速”的原因之一，是因为做艰苦的工作来改善您的处事方式实际上会使您在处事上变得更好。 但是事实是您做事很糟糕，这使人们说：“哦，我们没有时间这样做，我们没有能力这样做。”
因此，这是一个经典的接球22。
我们的目标受众是那些说：“我们没有时间修复这个系统，我们只需要使用已有的东西。”为了说服他们，我们使用了数据，参数，图表以及简洁明了的方法。
耶兹：是的，这很有趣，因为您认为做得更好的惩罚将是更多的工作。 而且我觉得很愤世嫉俗。 从研究的角度来看，有趣的是，愤世嫉俗是倦怠的标志之一。 倦怠是我们在“加速”中实际衡量的事情之一，我们谈论的是可能影响倦怠的事情，其中一些是实践，而一些则是领导的影响。
而且我认为所有这些讨论都必须在我们都试图实现的相当人文主义的背景下进行。 领导者的工作就是说：“好吧，这是愿景，这是我们想要做的事情”，不仅是在我们想要如何销售客户方面，而且还在我们想要的组织类型方面建立。
而且我认为，如果您担心做得更好会导致您因为不再需要而被解雇，或者因此而遭受负面后果，那是一个真正的问题。 发生了 确保人们实际上并不担心这些结果是领导力的工作之一，因为这是确保没有任何事情会变得更好的好方法。
Jez：我是精益软件思想的早期采用者，而我们所讨论的很多东西不一定都是新的。 我想强调的是，如果您对此有所了解，就不会读这本书，整个世界都将倒置。 但是，肯定有一些我没有的东西，“啊哈”时刻，就像我曾经说过的“是！”时刻，我说：“我知道！”数据。
例如，类似的事情表明，高性能可以达到更高的吞吐量和稳定性。 我之所以如此大胆，是因为今天人们仍然认为，如果您要走得更快，就会创建不稳定，质量低下的系统。 但是精益软件是关于在这里实际上没有权衡的想法。 加快速度可以实现高质量和高稳定性，并且很高兴在数据中看到这一点。
另外，看到IT的高性能实际上会影响业务，这确实很棒。 看到我们多年来一直在谈论的许多实践实际上可以衡量地显着影响性能，这确实很棒。 我的一些个人肥皂盒是持续集成和基于主干的开发，并且在数据中非常清楚的是，这些做法会对性能产生重大影响。 因此，很多好消息。
耶兹（Jez）：首先，领导才能实现各种实践的实施，包括精益管理，产品管理，软件交付实践以及CI等。 这些反过来影响交付成果，影响文化成果，例如工作满意度和工作倦怠减少。 软件交付绩效会影响组织绩效。
人们可能会问：“没有领导层的支持，我能做到吗？”答案是，可以。但是，如果没有领导层的支持，坚持下去并使其在整个组织中传播将是非常困难的。 领导支持很重要，这确实与众不同。
但是，仅凭良好的领导能力还是不够的。 你必须努力。 2016年有一些有趣的数据，我认为这可以加强这一点。 当我们看到从低性能向中性能的转变时，除变更失败率外，一切都会变得更好，而变更失败率实际上对中等绩效者而言更高。 再说一次，数据并没有告诉我们为什么会这样，但是我们的假设是，人们正在尝试更快地完成相同的工作，而没有做实际改变组织过程的艰苦工作。
因此，您只需要做艰苦的工作。 流程改进无可替代，我要强调的是领导力。
耶兹：在某些时候，你必须对别人说不。 那很重要 在任何成功的组织中，都不会缺少工作要做，有人（可能是中层管理人员）必须能够说：“听着，我们将奉献一些能力来进行改进工作，这将意味着我们没有将100％的能力专门用于构建功能，这没关系。”因此，能够对人们说不，然后能够在组织的至少一部分上推动一致性的定义目标，并确保每个人都朝着同一方向努力。 我认为这两件事非常重要。
耶兹：是的，我认为那是绝对正确的。 我要特别对比的是，自上而下的另一种非常危险的通用工作方式是：“我们将立即更换整个组织。”而这通常会失败。 我认为这是“让我们在这里尝试一下，犯下很多错误，然后将其付诸实践，然后再尝试传播到组织的其余部分。”这是正确的，它只反映了组织如何运作。 在每个组织中，都有很多人想要尝试新的，闪亮的东西。 另一端有一群人，他们不会改变他们的工作方式，下地狱或高水位。 在那些或多或少厌恶变化的人之间存在某种曲线。
而且您不能一次更改整个组织。 您必须找到能够尝试新事物并使其成功的能力和兴趣的人员，然后按照您描述的方式进行迁移。
耶兹：所以，我非常相信某些人所说的狗食，但是我实际上并不喜欢狗食，所以我称之为喝我自己的香槟。
如果我要告诉别人做某事，我想确保自己在练习。 显然，自2004/2005年进入Thoughtworks以来，我一直在进行持续集成，实际上，我写的第一本书《 Continuous Delivery》中 ，我们有一台小的持续集成服务器，在其中我们使用了Ruby版本的CruiseControl。每次进行更改时，我们都会创建一个PDF，以便我们可以看到a）我们的文档有效，并且b）我们可以下载并阅读一些内容以证明我们在写什么。
因此，这次我们再次这样做。 而且技术稍有不同，因此我们使用GitHub来保留我们的书，我们使用markdown作为我们的格式。 我们使用CircleCI进行持续集成。
我们的想法是，每一章都是降价促销的文件，每当我们对其中一个文件进行更改时，我们都会将其提交到GitHub，CircleCI会选择它并创建一个包含HTML格式的整本书的网页， PDF版本，以便我们始终拥有最新版本。 因此，您知道，如果我们有审阅者或其他要向其展示的人，我们可以将他们指向那里。 我们已将HTML发布到Amazon上的S3存储桶，因此您只需转到网页即可始终查看最新版本。 所以，我的意思是，非常简单的内容，但这是始终了解您所在位置并以非常低摩擦的方式与他人共享的好方法。
我在2016年为美国联邦政府工作时首次开始使用CircleCI。 我对工具有很强的见解，并且很多人喜欢CircleCI。 入门非常容易，这就是我们选择它的原因。 而且我们在DORA使用CircleCI。 我们拥有一个可运行的平台，我们使用CircleCI来构建，测试和部署该平台。 我当然只能说些好话。
Jez：真正的想法是让任何人都觉得有趣。 反馈是，这是一本不错的简短书。 很明显。 如果您是敏捷专家，则可能找不到特别新颖的东西，但是您会获得强烈的验证意识，实际上，这是一种科学方法，可证明您一直在谈论的内容，如何使用它起作用，为什么起作用，以及它如何连接到该空间中的其他所有事物。 因此，我认为这是适合所有人的书。
归根结底，我们要做的是使事情反映人们的做事方式。 因为这就是研究表明有效的方法。 我们要使其正常。 理想情况下，我们希望做到这一点，以便人们阅读并说：“是的，显然每个人都这样做。 你在说什么？”再也没有人需要它了。 我们的工作将会完成。
最初于 2018 年8月30日 发布在 circleci.com 上。
