前　　言

从“软件工程”这一名词诞生以来，“质量”和“效率”就是它的目标。IT组织大多在这条路上探寻，从最初的瀑布模型，到CMMI，很多组织曾经尊其为软件开发过程的“圣经”。而当“敏捷运动”兴起时，他们想要“做”敏捷；当听说“持续交付”时，他们想要“做”持续交付。现在，DevOps也来了！在各种各样的交流大会里，不断传来DevOps胜利的凯歌，各种媒体也在报道它的好处。很多公司又想要“DevOps”了……

我们的确听到过一些美妙的“故事”，但它们可能都不属于我们自己。在自己身边，就连“如何让大家对这些理念或实践达成共识”都成了一大困难，这令你感到无比困扰。就像走在一团迷雾之中，耳边一直听到美妙的音乐响起，也隐约看到远处的点点亮光，然而脚下的“路”却忽明忽暗。

多年工作经历让我对这一领域有了新的认识，并进行总结与反思。“持续交付”是一个非常有吸引力的名字，总会让人浮想联翩，业务人员似乎看到了一丝希望，“所有的需求，上午提出来，下午就能拿到手”。然而，太多的企业低估了自己所面临的困难。这些困难一部分是显性的，如没有自动化测试，也做不到自动化部署，主干开发更是不可想象；还有一部分困难是隐性的，例如，职能部门之间的“墙”存在已久。业务人员嫌开发团队的软件交付速度慢，开发团队嫌业务人员提出的需求不靠谱。这很可能归因于每个人的价值思考方式。

本书的目标是希望企业中所有角色转换价值思考的角度，改进软件服务端到端的商业价值交付方式，提升相关人员之间的协作效率，最终以安全可靠的方式快速验证想法，缩短实现真正商业价值的时间。也就是说，本书不仅关注“从需求列表到可运行的软件”这一过程，还提出“价值探索-快速验证”双环，如图0-1所示，这也是本书的书名“持续交付2.0”的由来。

事实证明，没有放之四海皆准的企业管理解决方案能够完美解决每个企业遇到的问题。但是，管理者只有从整体视角出发，抵住局部优化的诱惑，才能在资源有限的情况下，引领企业创造更大的价值。本书提供了一个整体框架，给出了这个框架中各节点所涉及的原则与相关的实践方法，同时介绍了它们的优势与约束。

图0-1　持续交付双环模型

如果你将“持续交付2.0双环模型”应用到整个企业范围，就是一种企业级的组织管理变革指引；如果你将它引入某一个团队，对这个团队来说，就是团队工作模式的改进套路。既然“持续交付2.0”是一个管理框架，企业势必要根据自己的实际情况来进行定制。因此，书中列举了很多实际案例，告诉你其他企业或团队如何应用这些实践方法，达到它们的目标。这些案例也说明，解决方案与实施路径很难在企业之间进行复制，企业必须应用书中的原则，结合自身的实际情况（产品形态及所处的商业竞争阶段、团队的规模与人员技能水平、软件系统架构，以及组织管理机制与文化等），逐步探索出自己的道路。