能走多远，取决于填坑的能力有多大
——云平台BG开发管理部
导语：在过去的十几年中，很多企业都想提高开发人员或者研发团队的生产效率，然而，业界并没有一种被公认的统一方法，来衡量这个指标。于是，这成了一个“死结”。大部分企业来衡量生产效率通常是从需求文档和需求分析开始。然而，如果你了解过持续交付，有可能就会发现，真正影响的业务效率的不只是软件开发过程，真正的源头是业务问题或业务解决方案。
每个业务团队尽管有不同的业务形态，但是几乎都有相同的诉求：需求能不能尽快的上线？本文将从持续交付演绎进程，浅谈一个好的持续交付需要综合考虑哪些关键因素，希望对大家有所帮助或启发！
这里没有任何马后炮套话，只有粗暴的干货。写大家看得懂、用得着、赚得到的文章是唯一宗旨！让我们一起重新定义研发！
…………………………………………………………………………
“You build it, you run it”！这是 Amazon 一年完成 5000 万次部署，平均每个工程师每天超过 50 次部署的核心秘籍。而这一切，都离不开各种自动化测试工具及高效的持续交付管道。
目前大部分互联网公司，尤其是新兴的创业公司，已经从传统的瀑布流模式变革到敏捷开发模式。随之而来的 DevOps 以及持续交付等概念，也成为当下异常火热的话题。大家的探讨常常离不开以下几个问题：
² 持续交付本质上是什么？它是如何提升开发效率的？
² 持续交付在技术实现上有哪些关键点？
² 从2010年国外就有持续交付的书出炉，10年过去了，持续交付现在使用的普及率怎么样？
² 持续交付适用于什么样的公司和团队？创业团队？大公司？做什么业务类型的公司？
² 团队规模不同，大团队和小团队在持续交付的应用上痛点在哪里？
² 老团队在转型持续交付的时候会遇到哪些阻力？
² 持续交付的应用是不是在团队中常见？从个人角度来说，学习持续交付的意义是什么？会不会自己学习了，团队不用，学了也没啥用？
1. 软件交付的演绎 |
1. DevOps
DevOps也是在2009年提出的。在那个年代，大部分人都认为软件开发是从需求文档和软件需求分析开始的，不过这样一个闭环，好像缺了点什么。
2. 传统软件项目开发：从代码提交到发布
20年多前，刚刚参与传统软件开发项目，当时很多做软件外包项目的公司，大概半年甚至一年发布一次，交付一次。此时，大家关注的是从代码提交到发布。这个阶段的最大的特点是，在软件的开发周期中，运维工作不是很多，生产变更也不多。
3. 互联网产品：从代码提交到技术监控
到了互联网时代，消费互联网产品所需的生产变更需求越来越多，而且越频繁。所以，技术监控越来越重要。所以，从代码提交到技术监控的开发周期更加闭环。2010年，很多传统软件公司会说：“敏捷开发，两周一个迭代，时间太短了，不适合我们。我们的系统很复杂，需要很多前期设计，还要按照评估模型的项目制来做”。而互联网公司会说：“敏捷开发，两周一次发布，太慢了，我们的发布要频率高得多。”
我们认为，当时持类似观点的两拨人都没有理解敏捷软件开发的工作模式，他们停留在望文生义的阶段，通常并没有进行（尽力）尝试。想跟大家说的是，那个时候，硅谷互联网产品研发的这种趋势和诉求已经非常明显了，就是需要快速迭代发布。
4. 持续交付1.0
从需求文档和计划排期做起点，到可以运行的软件，再部署到生产环境，到做监控系统这样的一个闭环，我把它叫做持续交付1.0，或者狭义的DevOps。也是现在大多数公司进行DevOps转型的重点工作。
5. 一万次实验法则
从2007年，开始关注硅谷的公司，收集了很多硅谷公司的工作方法和方式。其中与我们不太相同的一点是：他们更看重业务或者产品的试验（数据）驱动，即“一万次实验法则”。
大家也许听说过“一万小时定律”，它的主要意思是说：要成为某个领域的专家，需要刻意练习一万小时，一万小时的锤炼是任何人在某一技能上从平凡变成世界级大师的必要条件。
然而，贝索斯和扎克伯格在经营企业时，却遵从了另一个法则，即“一万次实验法则”。贝索斯说过“亚马逊的成功是每年、每月、每周、每天进行多次实验的结果。”而扎克伯格也说过类似的，“我最为自豪的事情之一是我们成功的关键在于测试框架。在任何时候，都不只有一个Facebook版本正在运行，而是一万个左右。”
这里说的测试框架不是JUnit 、Cucumber等，而是指一个生产线的试验框架。为了能够支撑这么多试验，必须有一个非常完善的试验框架。从这两位大佬说的话中，我们也可以意识到，变革的真正动力来自哪里呢？其实是来自业务的。
6. 持续交付2.0——双环模型
持续交付2.0双环模型中，它的起点并不是需求文档和计划排期，而是业务问题。你能提出什么样的业务问题，来驱动后续整个流程，这是非常关键的。俗话说，如果你能找到好的问题，那么这个问题就已经解决一半了。这些问题包括：客户在哪里？他遇到了哪些困难？他现在怎么解决这些问题？你的方案比当前优秀多少？
在这之后，我们如何验证这些问题的回答是否正确？如何衡量你找到了答案，如何衡量你的方案优秀？我们需要找到一把尺子来衡量。有了这把尺子之后，你再开始思考，在什么时间和场景找到他们，他的问题有多少种解决方案，如何收集每个方案的真实数据。只有这样，才能驱动你真正意识到：如果想达到这个标尺，自己有多少种方案去解决这个问题，此时，你才会真正的思考。
这两个环节分开来，前面的环是科学探索环（业务创新），后面的环是快速验证环（工程卓越）。快速验证环的唯一目标是快速且高质量的交付，让最终客户做验证。因为产品的价值是企业外部的用户决定的，并不是企业内部。
2. 持续交付2.0 |
“持续交付2.0”是一种产品研发管理思维框架。它将精益创业与持续交付1.0相结合，强调业务与IT间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实践，帮助企业以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。
对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有限的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。为了在VUCA环境中更快地了解海量用户，快速验证大量业务假设和解决方案，改变了业务探索的模式，并催生了软件研发管理模式的改变，两种模式相互促进，从而形成了软件产品研发管理的双环模式，即“持续交付2.0”。
它由两个相连的环组成：第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。
1. 探索环包含4个可持续循环步骤，分别是提问、锚定、共创和精炼。
（1）提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。
（2）锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。
（3）共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。
（4）精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。
2. 验证环也包含4个可持续循环的步骤，分别是构建、运行、监测和决策。
（1）构建：是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。
（2）运行：是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
（3）监测：是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
（4）决策：是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。
探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。它们之间相互促进，探索环产生的可行性方案规模越小，越能够提高验证环的运转速度；如果价值验证环能够提高运转速度，则有利于探索环尽早得到真实反馈，有利于快速决策，及时对前进方向进行验证或调整。
3. 持续交付2.0核心原则
“持续交付2.0”是指企业能够以可持续发展的方式，在高质量、低成本及无风险的前提下，不断缩短持续交付周期，从而与企业外部频繁互动，获得及时且真实的反馈，最终创造更多客户价值的能力。下面逐一介绍缩短持续交付环周期的4个核心工作原则。
1) 坚持少做
在咨询的过程中，最常听到的一句话就是：“我们最大的问题是人力不足。”无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证。
Moran在 Do It Wrong Quickly一书中写道：“Netflix认为，他们想做的事情中，可能有90%是错误的。”Ronny Kohavi等共同发布的文章“Online Experimentation at Microsoft”中也指出，在微软，“那些旨在改进关键指标而精心设计和开发的功能特性中，只有1/3左右成功地改进了关键指标”。正如当年Mike Krieger（Instagram的联合创始人兼CTO）被问及“5个工程师如何支持4000万用户”时所说的那样——“少做，先做简单的事情”。
2) 持续分解问题
复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法，并各自独立发布给用户。
3) 坚持快速反馈
当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。
4) 持续改进并衡量
无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。
某数据公司就曾因无度量数据，而无法提出有效改进方向的情况。该系统是一个数据标注志愿者招募考试系统。虽然它被分成多个迭代，每个迭代都发布了很多功能，但是，由于没有实现产品人员所关注的数据收集与统计分析功能，使得团队仅知道人们可以使用这个系统完成工作，却无法知道是否能够高效完成工作，也很难提出下一步的产品优化方向。
以上就是持续交付2.0的双环模型，我叫它持续交付2.0管理框架。“框架”就说明它并不是无懈可击，只要执行就保证成功。框架只是给你一种思维模式，提升一定的成功概率。借用之前说到的，一个业务问题，不是只有一种解决方案，而是有很多种，可能都可以成功。至于你选哪一种，只有你自己决定，没人能替你做决定。
4. 组织变革
大家都说，DevOps是文化+工具，而且一直强调文化，可是，文化很难落地。当让企业成员做出行为改变的时候，总会有人说“我们只做能完成KPI的事情”。仔细品味这句话，它告诉你的是：“别管我，我不想改变”。因为，假如你能知道做哪些事情可以完成KPI，那么这件事已经没有挑战了。没有挑战的事情，制定KPI也没有意义。
组织变革是一个比较大的主题，依据公司产品类型、团队组成、人员结构、公司文化等方面进行，以下是文化变革的四个步骤是：
1) 定义想要做的事情：比如我们要改变测试人员的定位，改变测试人员的能力模型，让开发人员承担更多质量保证的工作，写更多的自动化测试，而不是手工的自动化测试。
2) 定义期望的做事方式：他们就是要加强代码质量，强制的做code review，要强制的做单元测试。
3) 提供相应的培训：2014年前Google的开发人员写单元测试也是比较低的，公司提供了很多如何写好单元测试，如何写好代码，如何保证代码健康的培训。
4) 做些必要的事情来强化那些行为：强化你鼓励的行为，强化制止不鼓励的行为。任何事情必须有反馈才能形成回路，才能形成正向的积极的作用。而且针对反馈，还有非常重要的一点是，识别哪些反馈是真实的。
持续交付的七巧板，当你做组织的变革，这七个因素是不得不考虑的方式和方法。但是到底采取什么样的路径，和企业息息相关，没有任何一家企业是一样的，所以管他叫七巧板。你可以用他拼出各种各样的形状。你想拼成什么样，是真正关键的问题。也就是说，你的目标在哪里。很多团队都不能清楚的定义他们的目标，他们只能定义一个愿景，比如，我希望提升工程生产力。
企业如何让“持续交付2.0”成为一种组织能力，成为组织的DNA，持续发挥作用，从而领先竞争对手，成为自己的一种竞争优势呢？持续交付双环模型的实施与改进将涉及企业内的多个部门与不同的角色，无法由某个部门独立实施，必须在整个组织范围内贯彻执行“持续交付2.0”的思想、理念与原则。企业需要在组织管理机制、基础设施以及软件系统架构3个方面。
条条大路通罗马，而且，罗马也不是一天建成的。每个企业的实施路径可能各不相同，所需要的周期也各有长短，对各方面的能力需求也不完全一致。正如中国传统玩具七巧板一样，每个企业都应根据自己的意愿和诉求，拼出属于自己的持续交付实践地图。
3. 持续交付的七个问题探讨 |
1. 持续交付本质上是什么？它是如何提升开发效率的？
持续交付的概念已经交代了其本质，即高质量的快速交付。高质量和快速交付就是其本质。基于高质量和快速交付两个出发点，持续交付的最佳实践实际上是因团队而变的，并不是所有的最佳实践都适合于所有团队，因团队而异。然而其包含的几个基本持续交付管道则是必须的，这几个交付管道包括：代码提交，测试，部署和发布等基本管道。
几乎所有的最佳实践都能从一定程度上提高开发效率。举例说明，代码提交管道里有很多关于版本控制(Git)的使用最佳实践，比如提交前需要做pre-commit测试，提交后需要有静态代码检测，结合CI系统使用，保证了代码的质量。同样的XP(包括TDD开发等)原则以及自动化测试管道的存在同样保证了代码的质量。
表面上看，似乎开发人员花在开发，尤其是测试上的时间增加了，效率是否提升存疑，然而事实并非如此。事实上，通过实践这些操作，开发人员之间可以更好的保证项目在CI（持续集成）系统上面的健康状态。尤其是在需要大量合作的项目中，往往一段时间以后，项目build就处于不稳定的状态甚至 fail 状态，在这种状态下开发，很可能导致各种冲突的产生甚至代码的回滚，对后面的集成阶段产生极差的体验。而从长远来看，这些管道，尤其是测试管道的实现，极大保障了项目始终如一的品质，最终来看，实现开发效率的极大提升。
2. 持续交付在技术实现上有哪些关键点？
其实持续交付和DevOps一样，技术实现上是多样化的。而真正的落地关键点却不在技术上。对于DevOps来讲，关键点是DevOps团队文化的普及，其中就包括通过实践持续交付来推动DevOps文化。但最关键的点还是在于组织上从上而下的普及，即技术leader(CTO或者首席架构师)在技术团队来普及DevOps文化，包括团队内如何合作，跨部门如何合作，使用怎样的工具来实现持续交付以及怎样将DevOps文化推广到整个公司。具体到持续交付，那么最关键的还是搭建持续交付管道。持续交付管道搭建完毕以后，针对每一个管道或者步骤，再寻求适合于自身团队和每个管道的工具和技术。
3. 从2010年国外就有持续交付的书出炉，持续交付现在使用的普及率怎么样？
首先，目前来讲，大部分好的技术基本都是国外先有然后国内才开始流行的，国内互联网行业更偏重于业务或者商业模式，这在全球都可以说是领先的。然而技术上还是处于相对的落后状态。包括近几年非常火热或者逐渐火起来的持续交付，DevOps，Docker，区块链等等，都处于这种状态。
其次，国内大公司由于技术传统的问题，普及率并不高，但很多中小公司在实现持续交付上已经付出了很多努力。国外的很多大公司已经号称可以做到每天多次产品交付了，包括但不限于亚马逊，谷歌，facebook等等。国内随着容器技术和DevOps文化的普及，相信也会像国外一样，越来越多的公司开始实现持续交付。
4. 持续交付适用于什么样的公司和团队？创业团队？大公司？做什么业务类型的公司？
持续交付适合于任何团队，之所以敢这样说，是因为持续交付有一个非常非常重要的原则。即要求，代码的上线和业务的上线分离。
简单讲，就是运维可以随时上线master(release)代码。即主干代码永远处于releasable的状态，而不关心业务代码是否已经开发完毕。目前可以实现这一点的技术叫做release train和feature toggle。而且他们带来的好处不单单是这一点，通过release train和feature toggle的实现，可以使产品经理拥有在线上做A/B testing的能力，可以实现灰度发布等等。所以说，在技术上完全可以做到持续交付而不管你是怎样的业务。
5. 团队规模不同，大团队和小团队，在持续交付的应用上痛点在哪里？
持续交付能不能做好，实际上跟团队大小无关。但一般情况来讲，一个团队如果维持在5-8人之间，效率更高。不分项目大小，在实际落地过程中持续交付的痛点很可能在于测试管道的实现。因为测试管道要求既要复杂到可以cover掉大部分的代码和业务场景，又要简单到可以支持分钟级甚至秒级的交付。那么自动化测试的实现方式和执行时间就是一个很关键的问题了。
6. 老团队在转型持续交付的时候会遇到哪些阻力？
阻力分为内因和外因。内因即技术团队本身的原因，包括团队技术能力，技术团队之间的合作和团队leader态度等等。比如开发的目标是改变，运维的目标是稳定，测试的目标是控制风险，大家相对来讲拥有不同kpi，这些是技术团队本身需要解决的问题。但一个拥有DevOps技术文化的公司，肯定不会在实现持续交付的时候遇到技术阻力。
阻力其实多半来自外因。比如技术资源都是有限的，这时候各部门对于技术资源的争夺很大程度上成为了持续交付普及的阻力。若一个大的团队拥有一个大的待转型的项目，这项工作往往要持续很久甚至数年才可以完全转型完毕。而在这个过程中，产品部门需要技术资源来改进提升产品体验，甚至研发新的产品，运营部门需要技术资源来搞各种活动来实现利润。架构部门与此同时还要推动持续交付的实现。
所以外因往往是转型中的痛点。这时候，其实也有解决方案，即Martin Fowler曾经提到过的Strangler方法。有兴趣的读者可以自行搜索研究一下。一个最简单的例子，新起的项目要尽量做到使用持续交付，不要再往老路上走。如果你已经意识到自己在坑里了，就不要再继续往下挖了，新团队一上来就用持续交付也是可行的。
7. 持续交付的应用是不是在团队中常见？从个人角度来说，学习持续交付的意义是什么？会不会自己学习了，团队不用，学了也没啥用？
这个肯定不会，持续交付比DevOps更偏重实践一些，DevOps更偏文化一些。所以在学习持续交付的过程中，除了一些概念上的东西，会学到非常多最佳实践。其中包括各种各样的工具，环境配置管理，代码版本控制，各种测试工具和技术，代码build工具，持续集成工具等等。而且通过学习持续交付，可以更加了解自己目前的工作方式是不是真的适合所在的团队，继而才有可能帮助团队做出有效的改变。尤其当你是团队leader的时候，这几乎可以改变一个团队的命运。
4. 总结 |
“持续交付2.0”建立在“持续交付1.0”的“可持续地快速发布软件服务”及精益创业的“最小化可行产品”两种理念基础之上，强调要以业务为导向，从一开始就将业务问题进行分解，并通过不断的科学探索与快速验证，减少浪费的同时，快速找到正确的业务前进方向，简称为“双环模型”。因此，其涉及组织中的多个团队，需要各个团队之间紧密合作，才能缩短环的周期。
“持续交付2.0”的4个核心工作原则是坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。只有这样，才能不断缩短持续交付环的运行周期，提升用户反馈速度，从而提高业务的敏捷性。这要求管理者跳出原有软件交付管理思维模式，摆脱“害怕失败”的恐惧感，拥抱“科学探索—快速验证”思维方法，快速试错，提升持续交付能力，进而发展现有业务，并快速开创新业务。
程序员加班是常态，总有人会说“只要提高效率，就不用加班这么严重了“。但是，有时候你加班并不是个人效率低，而是涉及到组员间的协作，甚至跨部门协作时的整体效率低下，一个高效的个人面对一个低效的团队，浑身是劲也使不出来。
著名投资人（成功投资谷歌，也是OKR方法的布道者）约翰∙道尔说：“每一个业务问题，都有很多种解决方案，而且其中可能有多个方案都能够成功”！事实上，真正的关键点在于：你如何快速的找到合适的方案，你要做的是就是从中确定其中的一个或少数几个方案，快速验证。
本文参考资料文献：《DevOps时代》、《DevOps社区Meetup》、《持续交付》、《知乎》等！
往期内容回顾
《研发洞察》第4期 前世今生，DevOps未来发展的九大趋势