自　　序

2002年，我偶然得到一本书，名为《解析极限编程》。书中介绍的软件开发方法与现实中使用的工作方法截然不同。书中的很多实践看上去都不现实，如测试驱动开发、持续集成、结对编程、用户故事等，这让我感到很新奇，怎么会有团队这么做呢？但这些方法看上去的确很诱人，于是我带着“怀疑”的态度，在实际工作中引入了其中一些方法，但执行上还是打了一些折扣。例如：我没有做测试驱动开发，而只是增加一些单元测试；我没有做结对编程，而是要求代码评审（code review）；我没有做持续集成，而是每日构建。一段时间后，虽然能感受到一些收益，但并没有那么显著。

直到2005年，我的一个朋友向我展示了他们如何使用这种开发方式交付真实的软件项目，以及真实的编写代码的过程。每一次修改代码，都编写并执行一系列的自动化测试用例；每一次提交，都会进行持续集成。这是一种从未有过的编码体验，开发工程师很少需要启动程序，通过单步调试来找出代码中的问题。这使我真正相信，的确存在按照这种敏捷方式工作的团队，而且离我并不遥远。

2007年，我加入ThoughtWorks，希望能体验敏捷软件开发方式。作为一名需求分析师和交付经理，我加入了持续交付平台GoCD的产品研发，我的搭档就是Jez Humble（该产品的产品经理），他也是《持续交付》的作者之一，书中很多实践都来自我们团队自己的软件产品研发过程。从想法的诞生到产品上架，我经历了一个完整的产品研发过程，也真正认识了敏捷开发方法，掌握了持续交付实践。

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组织效能相关的问题时，能够以适当的思考方式和背景知识来应对，在今后的工作中少走一些弯路，至少遇到相似问题时，可以有所参考。