经典图书《持续交付》已出版8年，一直受到软件行业从业者的关注。书中的软件开发原则和实践也随着商业环境VUCA特性的明显增强而逐渐受到软件技术人员的认可。这本书得以迅速、优质地在中国出版与译者乔梁密不可分，圈内人都亲切的称乔梁为“乔帮主”。
乔梁是《持续交付》译者，持续交付领域专家，持续交付和DevOps理念在国内的首批实践者和布道者，被业界称为“国内持续交付第一人”。国内最早致力于通过敏捷开发与精益理论改善软件价值交付效率的实践者之一，精研各种软件工程方法论。
8年后乔梁带着他的全新著作《持续交付2.0：业务引领的DevOps精要》面向大众。这本书将《持续交付》一书的思想融会贯通，经过8年的管理实践，精心总结与提炼，提出“持续交付2.0双环模型”;作者独创性地将持续交付理论与当前的技术热点DevOps理念完美结合。
同时《持续交付》一书作者Jez Humble为本书作序。腾讯副总裁曾宇、百度地图事业部总经理李莹、ThoughtWorks中国区总经理 张松滴滴高级技术总监路宁、百度工程效率部负责人李涛、阿里巴巴研发协同平台负责人叶渡等众多企业高管和技术专家联袂推荐。
《持续交付2.0：业务引领的DevOps精要》
作者：乔梁
2002年，我偶然得到一本书，名为《解析极限编程》。书中介绍的软件开发方法与现实中使用的工作方法截然不同。书中的很多实践看上去都不现实，如测试驱动开发、持续集成、结对编程、用户故事等，这让我感到很新奇，怎么会有团队这么做呢？但看上去这些方法的确很诱人，于是我带着“怀疑”的态度，在实际工作中引入了其中一些方法，但执行上还是打了一些折扣。例如，我没有做测试驱动开发，而只是增加一些单元测试；没有做结对编程，而是要求代码评审（code review）；没有做持续集成，而是每日构建。一段时间后，虽然能感受到一些收益，但并没有那么显著。
直到2005年，我的一个朋友向我展示了他们如何使用这种开发方式交付真实的软件项目，和真实的编写代码的过程。每一次修改代码，都编写并执行一系列的自动化测试用例；每次提交都会进行持续集成。这是一种从未有过的编码体验，开发工程师很少需要启动程序，通过单步调试来找出代码中的问题。这使我真正相信，的确存在按照这种敏捷方式工作的团队，而且离我并不遥远。
2007年，我加入ThoughtWorks，希望能体验敏捷软件开发方式。作为一名需求分析师和交付经理，我加入了持续交付平台GoCD的产品研发，我的搭档就是Jez Humber（该产品的产品经理），他也是《持续交付：发布可靠软件的系统方法》的作者之一，书中很多实践都来自我们团队自己的软件产品研发过程。从想法的诞生到产品上架，我经历了一个完整的产品研发过程，也真正认识了敏捷开发方法，掌握了持续交付实践。
2009年以后，我作为外部顾问或内部教练，开始为国内外很多企业提供相关的组织敏捷与精益转型咨询服务，客户既有PC互联网时代的巨头，也有传统IT企业；既有国内知名大企业，也有高速成长的移动互联网创业公司。在与客户合作的过程中，我对“持续交付”有了更深刻的理解，也对如何帮助组织实现“持续交付价值”有了全新的认识。
2007年，我认为包括极限编程在内的众多敏捷开发实践是快速高质量软件交付的法宝；2010年之后，我发现实践本身虽然非常重要，但更重要的是支撑实践的组织管理方法、工作思路与理念。于是，我的口头禅成了“别提敏捷，只解决问题！”。2012年后，更多的软件开发方法与敏捷流派在国内开始盛行，但其背后的核心理念与主要工作原则并没有根本性的变化。无论什么样的方法，都应该以“解决问题”为出发点，而“解决问题”的一个重要前提是“能够正确定义问题，并达成共识”。
我当然不是思想无用论的支持者。相反，我认为思想对每个人对事物的认知和理解至关重要。但咨询经历告诉我，对事物的正确理解，并不能确保正确的思想和理念在现实中落地，也不能确保对企业有大的和直接的帮助。对方法应用者而言，其目标是通过对思想理念的认知，能够尽早解决自己（或者客户）所面临的棘手问题。
正如企业经营管理一样，软件工程发展的历程也是各种方法论不断出现与发展的过程。从20世纪60年代“软件工程”这一术语的诞生，到20世纪70年代提出瀑布软件开发模型，以及1985年提出的迭代增量开发和1986年Barry Boehm在“A Spiral Model of Software Development and Enhancement”一文中提出的喷泉模型，20世纪90年代的软件能力成熟度模型集成（Capability Maturity Model Integration，CMMI）的产生和多种轻量级软件开发方法，21世纪初敏捷宣言的正式发表，再到精益软件开发方法、看板方法，以及持续交付和DevOps运动。所有这一切变化，既反映出该领域的快速变化，也反映出没有哪一种理论或方法能够完全解决这个领域面临的所有问题。
本书希望能够让读者在了解“持续交付”全貌的基础上，当遇到与IT组织效能相关的问题时，能够以适当的思考方式和背景知识来应对，让你在今后的工作中少走一些弯路，至少遇到相似问题时，可以有所参考。
从“软件工程”这一名词诞生以来，“质量”和“效率”就是它的目标。IT组织大都在这条路上探寻，从最初的瀑布模型，到CMMI，很多组织曾经尊其为软件开发过程的“圣经”。而当“敏捷运动”兴起时，他们想要“做”敏捷；当听说“持续交付”，他们想要“做”持续交付。现在，DevOps也来了！在各种各样的交流大会里，不断传来DevOps胜利的凯歌，各种媒体也在报道它的好处。很多公司又想要“DevOps”了……
我们的确听到过一些美妙的“故事”，但它们可能都不属于我们自己。在自己身边，就连“如何让大家对这些理念或实践达成共识”都成了一大困难，这令你感到无比困扰。就像走在一团迷雾之中，耳边一直听到美妙的音乐响起，也隐约看到远处的点点亮光，然而脚下的“路”却忽明忽暗。
多年工作经历让我对这一领域有了新的认识，并进行总结与反思。“持续交付”是一个非常有吸引力的名字，总会让人浮想联翩，业务人员似乎看到了一丝希望“所有的需求，上午提出来，下午就能拿到手”。然而，太多的企业低估了自己所面临的困难。这些困难一部分是显性的，如没有自动化测试，也做不到自动化部署，主干开发更是不可想象；还有一部分困难是隐性的，例如，职能部门之间的“墙”存在已久。业务人员嫌开发团队的软件交付速度慢，开发团队嫌业务人员提出的需求不靠谱。这很可能归因于每个人的价值思考方式。
本书的目标是希望企业中所有角色转换价值思考的角度，改进软件服务端到端的商业价值交付方式，提升相关人员之间的协作效率，最终达到以安全可靠的方式快速验证想法，缩短实现真正商业价值的时间。也就是说，《持续交付2.0：业务引领的DevOps精要》不仅关注“从需求列表到可运行的软件”这一过程，还提出“价值探索—快速验证”双闭环，如图0-1所示，这也是本书的书名“持续交付2.0”的由来。
事实证明，没有放之四海皆准的企业管理解决方案，能够完美解决每个企业遇到的问题。但是，管理者只有从整体视角出发，抵住局部优化的诱惑，才能在资源有限的情况下，引领企业创造更大的价值。本书提供了一个整体框架，给出了这个框架中各节点所涉及的原则与相关的实践方法，同时介绍了它们的优势与约束。
图1 持续交付双闭环模型
如果你将“持续交付2.0双环模型”应用到整个企业范围，就是一种企业级的组织管理变革指引；如果你将它引入某一个团队，对这个团队来说，就是团队工作模式的改进套路。既然“持续交付2.0”是一个管理框架，企业势必要根据自己的实际情况来进行定制。因此，书中列举了很多实际案例，告诉你，其他企业或团队如何应用这些实践方法，达到它们的目标。这些案例也说明，解决方案与实施路径很难在企业之间进行复制，企业必须应用书中的原则，结合自身的实际情况（产品形态及所处的商业竞争阶段、团队的规模与人员技能水平、软件系统架构，以及组织管理机制与文化等），逐步探索出自己的道路。
先谈谈本书的结构和内容。全书共包括3部分内容。第一部分介绍了“持续交付2.0”的双环模型；第二部分主要讨论使用“持续交付2.0”框架中可能遇到的问题，以及改进过程中需要遵循的原则。第三部分主要是案例分享，目的是让读者体会在持续改善过程中，不同企业和团队的实施重点与解决方案的不同。书中具体内容如下所示。
第一部分主要讲述“持续交付2.0”双环模型（即持续交付“8”字环）和“持续交付2.0”的4个工作原则，还会介绍两个闭环“价值探索”与“快速验证”的执行步骤与相关原则。
- 第1章讨论持续交付的发展必然性，并介绍“持续交付2.0双环模型”及其4个基本原则。
- 第2章讨论“价值探索环”（简称“探索环”）的4个核心环节，以及每个环节的指导原则与实践方法。只有业务方能够以“精益”方式思考，持续交付才能更显威力，否则很可能退缩成为持续交付1.0的单环模式，即只有“快速验证环”。
- 第3章简单阐述“快速验证环”（简称“验证环”）中各环节的主要活动，并给出各环节的工作方法。
第二部分主要阐述“持续交付2.0”的实施七巧板中，三大主要板块的工作原则与实践方法。这三大板块包括组织机制、软件架构与基础设施。其中组织机制是一个复杂课题，本书仅讨论持续交付所需的文化，以及建立文化的四步法。组织架构、人才结构、激励机制等内容将在本书的续篇中专题讨论。基础设施部分是产品研发过程中最基础的工作。这部分首先讨论持续交付部署流水线及其工具设计原则，然后分别介绍部署流水线的建立与优化必须关注的五大领域，也就是说，业务需求协作流程、分支与配置管理、构建与环境管理、自动化测试管理，以及部署发布与监控管理。
- 第4章讨论持续交付能力的提升需要企业具有信任、安全和持续改善的组织文化，并介绍丰田公司和谷歌公司用过的改善组织文化四步法。
- 第5章讨论软件架构对实现持续交付快速验证能力的重要性、有利于持续交付的软件架构特征，以及软件架构改造的3种方式，即“拆迁”“绞杀”和“修缮”。
- 第6章讨论如何利用约束理论和精益思想，发现流程中的瓶颈，使各角色之间的业务需求协作更加顺畅，提升需求流动速度。
- 第7章讨论快速验证环所依赖的部署流水线的设计原则与工具链建设草案。
- 第8章讨论代码仓库的分支方式对持续交付的重大影响，以及不同分支方式下部署流水线的建设方案。最后介绍代码分支的数量对发布策略的影响。
- 第9章回顾持续集成的历史，并讲解如何判断团队是否在实践“持续集成”，还给出企业实施持续集成的五大步骤。
- 第10章讨论软件发布以前制订自动化测试策略需要考虑的因素，还介绍持续集成对自动化测试用例的编写与运行要求。最后，为了提高自动化测试的投资回报率，团队如何为遗留系统编写和增加自动化测试用例。
- 第11章讨论软件配置管理,它是持续交付快速验证环的基础。对代码、配置、环境、数据做好配置管理，最终实现一键部署和一键测试，让各角色在协作过程中能够全部实现自动化服务，并且互不影响，解放人的大脑和双手，做更有价值的事情，而让机器做它擅长的事——不断地重复
- 第12章讨论降低生产部署与发布风险的技术与方法。
- 第13章讨论软件在运行时，数据收集与分析的重要性，以及衡量数据监测环节的衡量指标，包括正确性、完整性和及时性，此外，还介绍测试扁平化趋势，以及生产环境上的质量巡检与演习。
第三部分主要是实战案例的分析。它们分别代表不同类型的公司、不同大小的团队以及不同的软件产品特点。我将带你深入案例现场，了解当时状况，分析问题，并提出解决思路。
- 第14章介绍一个百人工程师的互联网产品团队历经一年时间，如何打造快速运转的“持续交付2.0双环模型”，并且做到可持续运转。
- 第15章介绍在无法“测试右移”的情况下，一个大项目中的小团队如何改变团队协作模式，从“死亡行军”转变为“无缺陷交付”。
- 第16章介绍一个微服务化开发团队如何在项目运行的过程中，通过逐步对基础设施板块中各模块进行改造，提升交付质量与频率，并推动运维人员也做出改变，真正成为一个“DevOps团队”。
持续交付1.0关注于“从提交代码到产品发布”的过程，如图2所示，并且提供了一系列工作原则和优秀的实践方法，可以提升软件开发活动的效率。
图2 持续交付1.0的关注点
但是，我在实际咨询过程中发现，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。可是，这些功能的确花费了团队的很多精力才设计实现。这是一种巨大的浪费。这种“无用”的功能生产得越多，浪费就越大。我们是否可以找到一些方法，让我们付出的努力对业务改善更加有效，或者只用很少的成本就可以验证对业务无效呢？
精益思想
2011年出版的《精益创业》一书给了我一些启示。其核心思想是，开发新产品时，先做出一个简单的原型——最小化可行产品（Minimum Viable Product，MVP），这个原型的目标并不是马上生产出一个完美的产品，而是为了验证自己心中的商业假设。得到用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。
Eric Rise在书中强调，精益创业就是一个“开发—测量—认知”的验证学习过程，如图3所示。也就是说，把创意快速转化为产品，衡量顾客的反馈，然后再决定是改弦更张，还是坚守不移。
图3 “开发—测量—认知”环
该书主要关注于创业初始阶段，将精益思想贯穿于产品“从0到1”的过程。事实上，它也可以用于产品“从1到n”的过程中。
1996年，Womack、Jones和Roos在《精益思想》一书中指出，精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。
在精益管理理论中，“浪费”是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。并指出，业务生产中所有活动都可以归结为以下两种活动，也就是增加价值的活动和不增加价值的活动，而不增加价值的活动就是浪费。在被归类为“浪费”的活动中，又可以分为必要的非增值活动和纯粹的浪费。必要的非增值活动是指从客户的角度看虽没有价值，却可以避免（潜在的）更大的浪费或降低系统性风险的活动，如图4所示。
图4 软件产品开发中的活动浪费
例如，生产流水线上的装配工作是增值活动，质量检查是必要的非增值活动，而因材料供应不足产生的生产等待以及因质量缺陷导致的返工都被认为是不必要的浪费。在软件产品服务的全生命周期中，也同样包含多种“浪费”，例如，无效果的功能特性、各生产环节中的等待（如图5所示）、没人看的文档、软件缺陷、机械性的重复工作等。
图5 用户视角的增值活动与浪费
尽管“消除所有浪费”几乎是不可能的，但是，我们仍旧要全面贯彻“识别和消除一切浪费”的理念，持续不断地优化流程与工作方式，达到高质量、低成本、无风险地快速交付客户价值的目的。
双环模型
自2009年Flickr（一个聚合全球知名热门图片分享网站）声称其网站每天部署10次之时起，“主干开发+持续集成+持续发布”已成为硅谷知名互联网公司应对VUCA环境的一种主流软件研发管理模式。这种变化的原动力并不是来自技术团队本身，而是来自业务与产品方的诉求。为了在VUCA环境中更快地了解海量用户，快速验证大量业务假设和解决方案，他们改变了业务探索的模式，并催生了软件研发管理模式的改变，两种模式相互促进，从而形成了互联网软件产品研发管理的双环模式，即“持续交付2.0”，如图6所示。
图6 持续交付2.0的双环模型
“持续交付2.0”是一种产品研发管理思维框架。它将精益创业与持续交付1.0相结合，强调业务与IT间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实践，帮助企业以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。
对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有限的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，简称为持续交付“8”字环。
它由两个相连的环组成：第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动，如图7所示。
探索环包含4个可持续循环步骤，分别是提问、锚定、共创和精炼。
- （1）提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。
- （2）锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。
- （3）共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。
- （4）精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。
验证环也包含4个可持续循环的步骤，分别是构建、运行、监测和决策。
- （1）构建：是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。
- （2）运行：是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
- （3）监测：是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
- （4）决策：是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。
探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。它们之间相互促进，探索环产生的可行性方案规模越小，越能够提高验证环的运转速度；如果价值验证环能够提高运转速度，则有利于探索环尽早得到真实反馈，有利于快速决策，及时对前进方向进行验证或调整。
本文摘自《持续交付2.0：业务引领的DevOps精要》
作者：乔梁
持续交付2.0不只是关于软件的交付模型，而是从业务问题出发，关注业务假设验证速度的双环业务模型。只有从业务目标出发的持续交付实践才有强大的创造力和生命力！
书中指出，持续交付2.0双环模型高速运转的三个支柱分别是组织机制、软件架构和软件交付基础设施，同时给出了提升价值探索环以及快速验证环运转速度的多种可行方法。
本书还为我们呈现了在企业内部改善持续交付2.0能力所需遵循的基本原则，包括组织文化建设、软件系统架构、业务协作、配置管理、构建集成、自动化测试、发布与监控七大板块，并指出各领域实践关键点，以及多种可实操性方法。同时，通过3个完整的实践案例过程分析，说明每个企业或团队都必须从自己的业务目标出发，根据自己的实际情况，制定自己的改善路线。
