跨越鸿沟：再析DevOps历程中的烟斗曲线

在之前的一篇文章《DevOps实施过程中的烟斗曲线》中，我们谈到，只有很少的企业能够以较快的速度跨越烟斗曲线的那个“鸿沟”，走上持续提升之路。那么，通常这些企业是如何跨越这个“鸿沟”的呢？

当某个组织说“我们要DevOps了”以后，会马上找来一批工具，再找一些DevOps工程师，将它的现有流程做成一系列的自动化步骤（比如自动提测，发通知邮件等）。此时，我们会得到了一些收益。当流程优化到一定阶段以后，我们会开始关注“测试提速”这个问题。于是，就会开始做一些自动化测试。

在做自动化测试时，遇到的第一个问题就是测试环境准备的自动化。解决这个问题之后，我们也会得到一些收益，这个收益的大小决定于原来这个环境准备工作到底有多“痛苦”！

当这一步准备好以后，测试人员可能就会开足马力写一些自动化测试了。最初的两个月里，大家觉得这个效果也还不错。然而，很快就会到达到上图中的第一个拐点。此时很多人还没有意识到，所以仍旧会按照现有的方式，由测试人员增加更多的自动化测试用例。一段时间以后，就会查到，效果不像早期那样明显提升了。

这个时候，常见的选择有两种，一是继续坚持这样做下去，很可能收益会下降。 另外一种做法是保持当前这种现状。也就是说，大部分企业会停留在该曲线上那段平台期的某一点上。

此时，DevOps的实施策略是“摘取伸手可得的苹果”。也就是：（1）别让变动太多，太大；（2）先找容易的事情做。如下图所示。

为什么这个曲线最开始有一个提升期？是因为流程自动化等工作减少了每个交付迭代中的事务性成本。从最终客户（用户）的视角来看，每个软件交付迭代包括两类活动，一是增值活动，另一类是非增值活动，也可以叫做事务性成本。这部分事务性成本是什么呢？例如，测试活动、迭代计划会议、站会等等。我们希望在保证交付质量水准的前提下，将这些事务性成本变得更低，从而增加更多的增值活动时间。当这些事务性成本降低后，我们的原有的交付周期中增值活动的时间就会变多。为了尽早地让用户使用我们的软件，我们此时可以将迭代交付周期进一步缩短。但缩短到一定程度以后，你很可能会发现，每一个短迭代周期中的增值活动和事务性活动时间的比例会再次恢复到原来水平，如下图所示。这会让团队非常得恼火，无论从上到下都非常得恼火。

为什么会这样呢？举个例子，持续交付模式需要较多的自动化测试用例。而测试工作通常是由测试部门承担的。测试部门有人力投入到自动化测试编写之上。而最初写的自动化测试都是端到端测试。随着端到端测试数量的增加，你会发现，维护这些测试用例需要很多的成本，很容易形成头重脚轻的情况，如下图所示。这个时候就会有人跳出来，挑战道：“你投入这么多自动化测试的成本，收益是什么？投入产出比值得么？” 这种场景通常会发生在平台期。这就是很难再走下去的原因之一。

端到端的自动化测试运行成本高，维护成本高，诊断成本也高。而很多组织的测试人员并不具备编写低层自动化测试用例的能力。即使具备低层自动化测试用例的能力，由于协作流程与组织文化等原因，也无法及时获得必要的信息，以提升低层测试用例的质量。那么，如何跨越这个鸿沟呢？

怎么强调度量都不过分。通常度量项有三种属性，包括它的可观察性、可行动性与时间性。时间性又分为引导性和滞后性，如下图所示。有一些指标是可直接观察获得的，但是无法对它直接采取行动。例如千行代码缺陷数量，它是可以直接统计并观察到的，但它也有滞后性，因为当你得到这个数据之时，它已经成为事实结果。与此同时，它也不具备可行动性，因为你无法采取哪些行动，直接降低这个指标。相反，你可能使用一些引导性指标来指引团队的行为，从而可能达成想要的结果，例如代码review的数量、代码规范检查标准等。

另一个例子是：从提测到上线前发现的缺陷数量，这个指标也是滞后性指标，因为得到这个指标的数据时，它已经是一个结果。与之相比，自测的测试用例数量可能就是一个引导性的指标，而且是一个可行动指标。我们假设：自测的用例数量增高后，提测后的缺陷会减少，但这两个指标之间的因果关系只是我们的推测，还有很多因素的影响。

软件工程中的一大难题就是“研发效率度量”。总会有人问，这个软件开发效率到底如何度量？我也一直没有发现一个非常有效的且业内可以达成完全一致的研发效率度量体系。但我认为，在众多的指标中，每一个度量指标都是意义的，但它对于你所在组织是否有效，就不一定了。这取决于组织能力、产品形态与人员技能水平。上图中，越靠近右侧的指标具有更多的过程引导性，而越靠近左侧的指标相对来说，就更多的是滞后性结果指标。两个指标之间的距离越大，离得越远，那么它们之间的直接相关性就越弱。而且，其中多个指标之间也会互相影响。

因此，在设计改进方案时，必须想清楚这些目标中，你到底要选择哪一组指标。当某一个指标发生变化以后，是否会引起其他指标的变化，预计这个影响有多大？另外，引导性指标通常会有延迟效应，它的作用需要一段时间后之后才可能传导至对应的滞后性指标，甚至因为距离太远而无法被察觉过。这些年积累的经验，我觉得可以从以下几个方面进行着手。

获取度量数据，需要一定的成本。假如当前没有任何准备的话，想要持续获得全面性数据，前期投入一定不小。因此，初期可以采用抽样法以较小成本获得一定量可信数据，以展开改进行动。但这种方式可能会有偏差，有一定的风险性。

另外，我还想提及另一个突破性关键点，即“寻求第二序改变”。有一本名为《改变》的书，该书中讲到了“问题的形成和解决的原则”。给我留下比较深刻印象的是，“第二序改变”可以引起更大的差异性结果。所谓第一序改变，就是指以系统本身结构不变为前提，对现状进行改变，通常这种改变并不会引起“质”的变化。要想带来“质”的变化，必须寻求第二序变化，即：通过对系统本身结构的改变而带来变化。

例如，改变自动化测试用例的使用者。在没有改变之前，自动化测试用例的使用者通常为测试人员。如果我们将它的使用者改为开发人员，此时，看待测试用例的视角，以及对测试用例的要求可能就完全不同。

通常为了让开发人员能够高效地利用这些自动化测试用例，改善开发人员的工作效率，这些自动化测试用例就必须符合四个原则，即：快、捷、信、时。

• “快”是指每一个自动化测试用例的运行速度必须非常快。

• “捷”是指：一定要保证开发人员能够非常便捷地一键运行其指定的测试用例集。

• “信”是指在测试运行完成之后，其结果是可信的。

• “时”是指用例准备的及时性。即当开发人员想要测试自己刚刚开发完成的功能时，最好自动化测试用例就已经准备好了。如果所有的测试用例仅仅是针对那些非常稳定的功能特性进行测试，那么它对当前开发任务的作用就没有那么明显了。

当自动化测试用例的使用者从测试人员改变为开发人员时，这就是一个“第二序改变”。为了完成这种改变，就必须改变原有的思考和工作模式。

为了达到这些要求，我们可能需要将一些测试用例的层次从最上层的端到端测试下移到系统集成测试、组件测试，甚至单元测试，如下图所示。这很可能会导致团队角色与职责的变化。因为这种变化打破了原有的工作流程与结构，就很可能带来新的改变。

这种改变可能就会改善我们的自动化测试状态，并向着良性的正三角形发展。

到目前为止，我们讨论的都是“软件交付领域”的内容，也就是《持续交付2.0》中所说的提升“快速验证环”的努力，即如何快速交付那些已经准备好的需求。然而，从产品的角度考虑，这个闭环并不是一个完整的闭环，因为准备好的需求并不是问题的起点。那么问题的起点在哪里呢？当然是在业务领域。我们开发软件，是为了解决某些业务问题。

因此，如果我们从更完整的视角看待问题，那么软件价值的交付应该是两个环的闭环模型，如下图所示。从“提问”开始，为什么要开发软件功能？做了它以后，我们期望对哪些指标产生怎样的影响，为什么我们认为会产生这种影响，这就是“锚定”。有多少种不同方法可以达成我们期望的改变，这就是“共创”。到底哪个方案是我们认为最有可能达成我们目标的方式，这就是“精炼”。然后才是“快速验证环”这才是一个真正的、完整的交付的环，从提问开始，真到问题是否得到解答为止。

对企业来说，更有意义的目标是业务目标。目前，很多IT组织并非以业务目标建立组织结构，而是以职能目标建立组织部门。为了能够更好地完成业务目标，企业就需要考虑如何围绕业务目标来组织资源。并没有哪一种组织结构是完美的，但围绕业务目标来组织团队通常都是适合的。

“组织墙”总会存在的，当我们打破不同职能部门之间的“墙”，同时也会建立“业务单元墙”。只要保证这种“墙”是容易打破并重建的，那么组织就是健康的。

只有这样，我们才能建立一个灵活而又强大的弹性组织，它由一系列小的业务单元组成，以就对市场的发展变化。需要强调的是，不仅仅那些直接服务于外部客户的组织是业务单元，服务于组织内业务单元的团队（例如基础设施服务）也应该按其服务的业务或内部客户不同而作为业务单元来对待。如何定义“业务单元”是一个复杂话题，因为其与企业内外部环境强相关。

当我们有众多业务单元时，这些小的业务单元之间要做到 “对齐”是一个巨大的挑战，尤其当业务单元之间存在协作时。现在业内经常提到的“中台”架构，似乎是对“小业务单元”相左。然而，事实上，这个“中台”也应该是由多个小业务单元构成，并要高度“对齐”的。

虽然，单一个体的效率最高（因为决策与行动一体化）。但是，个体的能量是有限的，所以我们仍旧需要高效沟通，以便“对齐”。就像技术架构中的微服务架构一样，需要将很多的小业务单元高效地串联起来，才能真正发挥这种多个小团队协作的优势。如果没有协调好这些业务单元，那么可能提升了单一业务单元的内部效率，但整体的价值产出并没有增速。

那么，如何”高效对齐“呢？一种可能的方式（并不是唯一的方式）是参考”阿米巴经营“。日本京瓷公司是生产陶瓷制品的公司，是典型的生产制造行业。它由稻盛和夫先生创办，并在经营过程中总结出了“阿米巴管理经营方式”。在2009年，稻盛和夫再次出山，成功运用这一管理工具，带领日航走出困境。日航是一家提供航空运输的服务性企业。他将由生产制造行业中总结的“阿米巴管理”也成功运用于服务性企业，将日航30000多名员工分成10人左右为一个最小经营单位的众多阿米巴，并让每个阿米巴作为独立经营核算，激活所有员工，让他们自己组织起来，为自己的目标工作。

要想完成这样的转变，必须从以下三个方面着手。一是软件架构，二是组织机制和，三是协作基础设施，如上图所示。由于时间关系，我就不再展开讨论。在《持续交付2.0》一书中完整地讲述了三个实践案例。根据组织规模、业务目标、产品形态的不同，这三个案例选择了不同的实现路径。如果你对它们感兴趣，可以参考《持续交付2.0》的最后三章。

在不改变系统结构的前提下，优化是容易进行的。但是，优化到一定程度以后，可能就需要寻找第二序改变，才能够”涅槃重生“，达到更上一层楼。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》， 限时特价！

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）