图灵访谈之二:专访乔梁

10月29日,图灵社区就“持续交付”这一主题,采访了知名技术讲师、百度高级架构师乔梁先生,以下为访谈内容。

人物简介:乔梁

拥有十多年软件开发及项目管理经验,专注于提高企业的高质量软件交付能力,推广最佳实践。曾为多个大型电信企业、互联网企业提供专业的软件交付咨询服务。

现任百度项目管理部高级架构师,负责百度过程改进与持续交付推广实施。曾任Thoughtworks资深咨询师,敏捷交付管理工具Go的项目经理,对敏捷项目管理及持续集成有深入的理解与丰富的实战经验。

InfoQ特约编辑,主持《持续集成专栏》。

2011年Jolt 优胜奖图书《持续交付》的译者,并参与《ThoughtWorks 软件开发沉思录》的翻译。

一、持续交付是面向整个价值流的概念与技术

图灵社区:《持续交付》这本书得以迅速、优质地在中国出版,您功不可没。我们注意到,原作者也在序言中对您致谢,这是很少见的。是否可以谈谈您跟作者、跟这本书的渊源,以及承担翻译的过程?

乔梁:我和Jez是在ThoughtWorks的同事,一直关注这个领域。从2007年开始一起在北京做一款产品,叫“Cruise”,也就是现在的“Go”,敏捷交付管理工具。他是产品经理,我是交付经理,一直合作得很好。后来,公司策略调整,产品移到美国继续开发。

我很早就知道他在写这本书,前前后后花了大概有三年时间吧。2010年的5月,英文版还没有出版的时候,我就看了一遍书稿,觉得非常好,就希望能翻译成中文。他说:“版权在出版社,我可以跟出版社沟通,如果中国要引进,就推荐你来翻译。”英文版出版以后,国外出版社就介绍我跟图灵的杨海玲接触。实际上,即便没有人来找我,我也会把这本书翻译成中文。当与图灵讨论这本书的翻译时,我正在翻译第二章了。

图灵社区:那么说,其实你们当时在公司内部的项目里面就已经应用持续交付,是吗?或者可以说,这本书是ThoughtWorks公司内部方法的总结?

乔梁:对,的确是的。我们开发的产品Go,最初叫做持续集成与发布管理工具。在开发过程中,我们有很多种的自动化测试,而且每周都要将最新构建部署到自己的服务器上,供我们自己做持续集成,每两周会发布到公司内部的服务器上供其他团队使用。所以,我们本身就需要有一种能够对开发过程进行建模的发布管理工具。而这个产品中的“部署流水线”,就是我们在做这个项目的时候演进出来的,也成了《持续交付》一书中的核心模式。

这本书里面介绍的很多实践方法,都在Go这个产品中应用过,所以,我非常熟悉。比如书中讲到的云端测试,我们的项目就用到了。在做测试的时候,我们会利用命令行方式启动EC2中的数十台机器,将产品部署到上面,执行一系列的测试后,再将结果传回来,然后自动关掉那边的虚拟机。这就解决了我们硬件不足的问题,并且还可以用来测试一下并发问题。

图灵社区:我们已经进入了“持续交付”的主题,您能不能用最通俗的方式来讲解一下“持续交付”这个概念?

乔梁:这本书的标题已经把这个概念阐述得非常清楚,就是通过一种可靠的、自动化的、可重复的交付方式快速地将软件发布给用户。这就是持续交付最本质的核心内容。这本书讨论的主要是支撑实现持续交付的一些原则和最佳实践。

我们可以从两个层次上理解持续交付。一是概念层次上,怎么算持续交付?就是能够不断地将功能特性交付到用户手里,而且是快速、高质量且可靠地交付。二是技术层面上,持续交付的实现细节是什么?它是软件系统的构建、部署、测试、审核、发布过程的一种自动化实现。其中的核心模式就是部署流水线。本质上,这几个环节就是通过部署流水线串联起来的。而其中的关键是全面自动化和全面版本控制。当然,像探索性测试、易用性测试,以及管理人员的审批流程等还是需要一定的手工操作。

图灵社区:这本书出版后,读者的反馈中提到持续交付跟持续集成的关系。按照您刚才的描述,我觉得持续交付这个模式是面向客户的,用户在过程中不断得到更新的产品,而持续集成是在公司内部开发流程,到某个阶段,才会交付到用户。是这样理解吗?

乔梁:对,其实大家也都在讨论,这不就是持续集成的扩展吗?的确,持续交付的一个前提是持续集成。但它进一步强调了它的作用范围,即持续交付的受众是所有参与到软件交付过程的人,而不仅仅是开发人员和测试人员。持续集成的定义很窄,就是把代码集成起来,并运行测试保证质量,而持续交付要求的是不断地构建、验证,并尽快交付到用户手中。业务人员可能并不关心做不做持续集成。而要做到持续交付时,需要所有人的关注和参与,它强调的是从拿到一个需求开始,到交付给用户这个过程需要花多长时间。所以,两者的视角范围不一样,持续集成相对窄一些,只面向开发和测试团队,而持续交付面向的受众是参与到整个端到端的价值流的人员。

图灵社区:这样看,持续交付是很大的进步啊。

乔梁:我认为这是大家对软件关注点的转移,不再是一批功能,而是它所提供的用户价值。最初的软件开发,通常是客户提供一个功能列表,软件团队进行开发,然后一并交给客户,那就行了。而现在,市场变化很快,所以业务调整也很快。客户当然希望能够持续交付。举个简单的例子,在互联网行业,快速地交付一个功能,得到一定的反馈,再做相应的调整,这是一件理所当然的事情。那么,关键的问题就是,我们的软件交付团队如何才能具备这种“持续交付”的能力。

二、持续交付是可实施的

图灵社区:对持续交付这一主题,这本书是从哪些角度来讨论呢?

乔梁:首先,这本书提出了对软件交付更高的要求——能够持续交付。并且,不单提出了这种要求,还提供一整套的原则、方法和实践。如果只是持续交付理念的话,我不会喜欢这本书,更不会翻译它。持续交付的理念,一说大家就都明白了,关键是如何做到。这本书里面有很多的原则和实践,而这些原则和实践是可以落地实施的,都具有可操作性,是被验证过的。只要遵循这些原则和实践,就可以达到持续交付的目标。这是非常关键的。今天很多同学的提问,其实都可以在这本书上找到答案,这是我认为这本书非常好的原因之一。

图灵社区:那就是说,只要是开发流程中涉及到的具体工作的人,其实都可以从这本书获益。不仅能明白公司层面、交付层面的目标,也会掌握自己的事情可以怎样做得更好?

乔梁:对。在译者序里,我提到产品经理、项目经理、开发人员、测试人员、运维人员都可以从这本书里得到他想要的内容、想实现的方法,这是我认为特别好的地方。大家甚至可以把它当作手册,当遇到一个问题的时候,直接翻到相关章节读一下,就会有启发和收获。即使不想了解持续交付,但对软件开发过程的任何一个环节有问题,都可以翻一下这本书,它可以让你的工作变得更轻松。

图灵社区:我们了解到,您已经在百度内部应用持续交付来进行开发流程的管理。能否具体讲一下,实施的过程会遇到什么问题?

乔梁:百度目前在一些团队中做了这样的试点。遇到的问题更多是由角色职能之间原有的隔阂造成的。比如说要缩短发布周期,原本三个月才测试一次,现在三周就测试一次,对测试人员的交付压力该有多大?原来三个月部署一次,现在三周就部署一次,运维工程师压力该有多大?我不认为跟团队说“我们做持续交付吧”,就马上能做。首先取决于业务方面有没有这种“持续交付”的诉求,有诉求后再通过实际的操作让这种诉求变成可能。

现在很多软件产品,一个版本的开发要三四个月,而业务人员只能说:“好吧,三个月就三个月吧”。此时,交付团队成了业务瓶颈。不过,这是不是事实呢?其实不是事实,只不过传统的软件开发方法给大家造成了这样的印象,完全可以通过各种各样的手段变得更快、更好。当然,这种新的方式也对整个交付团队有了更高的要求,比如在技术实现、团队协作、开发习惯等方面。

另外,还有一些具体的技术问题要解决。比如,如何将大的功能分解成可交付的小功能。如何能够做到快速的验证。解决这些问题可能需要对原有的系统架构进行调整,可能还需要对原有的测试框架和测试方法进行改进。

只要业务方面有这样的诉求,我们的交付团队就应该做出反应,别再让软件交付能力成为业务扩展的瓶颈。

图灵社区:对于您所遇到的角色职能之间的隔阂的问题,是怎样解决的呢?

乔梁:这些隔阂都是有背后原因的,我们需要帮助他们解决那些具体问题。比如,测试频繁,测试人员不够;部署很难很累人,部署170台机器就要两周的时间,如果三周部署一次的话,部署人员岂不是要累死?的确需要解决这些现实问题。提供一些具体的方法手段,使相关人员也能够接受。

在这个团队中,把发布周期从三个月降到三周,我们花了半年的时间。不是动动嘴皮子,而是需要额外付出很多努力。在前三个月里,要还很多技术债,要做很多自动化的准备。而且,从开发的角度衡量,那段时间的生产率还会有一定的下降,下降多少视团队和产品而定。但最终能达成目标,很关键的一点是,要跟团队阐述清楚:做了这些事情以后,能够让你的工作得到什么样的改善。

而且,我认为,持续交付最终很可能带来组织结构的调整,从原来面向职能划分的组织结构转变成面向产品或服务来划分的组织结构。

图灵社区:您推广持续交付模式的时机,是在原有产品的下一个周期吗?

乔梁:对,基本上都是已有产品,是遗留系统。能做全新产品的情况最好,但那种机会很少。绝大部分情况都是在一个遗留系统上工作。这个时候,肯定要慢慢改进。这就是为什么在今天百度这个团队的案例中,我们花了半年的时间。

从组织推广的角度看,很多人会认为半年时间太长了,希望可以通过什么方法快速达成持续交付。但持续交付跟持续集成一样,都是最难的一个环节,需要一定的技术提升,而不仅仅是靠流程。我是敏捷开发的拥护者,SCRUM的门槛低,大家都能采纳,这就迎合了一些需求,能够在开始的时候让过程变得有规律可循,并达到一些效果。所以,SCRUM只是个起点,如果真的想做好,技术环节是逃不掉的。先做好持续集成,要做到持续交付就不会太坎坷。如果持续集成做不好,持续交付就是个泡影。

三、持续交付将变成必备能力

图灵社区:在博客上,您翻译了持续交付成熟度模型,这个模型已经在您的团队或产品中应用了吗?

乔梁:我们先追溯一下相关的历史。最开始的时候,记得是2009年,社区中有人总结了一个持续集成成熟度模型。然后,在这本书中提出了一个持续交付成熟度模型,被认为是1.0版。Jez根据近一年的实际应用,对其进行了一些修订,于是又有了1.2版。这个模型本身是普适的,并没有说特定的某个领域适用,所有的软件团队都可以拿过来做解读,用这把尺子量一量现在在哪儿,下一个目标在哪儿。也就是说,它是用于团队自我改进,而非用于团队间的横向评比。

但是,有人把它与CMMI做类比,用来衡量团队达到了几级。这其实是一种不当的用法,因为,这个模型是贡献给社区的一个参照,并未想过要成为一个用来衡量团队绩效的标准。我们在百度也只是用来衡量团队持续集成实践的成熟度,以便发现团队的下一个改进目标。

而且,它是对持续交付实践过程的一种度量,不是对业务结果的度量。所谓对过程的度量,就是指各维度的实践做得怎么样。但是这样的实践之后,对业务有什么样的贡献,是周期缩短了还是bug减少了,最终还是服务于这些业务目标。假如在每一个维度上的级别都很高,但业务的贡献度却没有那么高,我觉得那一定是有问题的。

图灵社区:在中国,您是“持续交付”的积极推动者,可以谈谈您在这方面的具体工作吗?

乔梁:本职工作之外,我做过一些演讲,参加了很多技术会议和沙龙,写了几年的博客,在InfoQ、CSDN等发表一些相关的文章。正如翻译这本书的初衷,我认为持续交付是正确的事情,希望更多的人从中受益。

2005年,我就开始研究和使用持续集成实践。当时,我根据所在团队情况来定制持续集成,认为每天构建一次也是持续集成。2007年加入ThoughtWorks后,我有很大感触:之前其实可以做得更好,只是原来没有看得那么远。比如,在做Cruise这个产品的两年多里,一共发了7个版本,从1.0到1.3.2,从来没有哪个人担心发布的时候会失败。在持续交付实践下,该产品的新功能发布完全由业务决定,因为新功能已经开发完,放在那里了。市场人员需要的时候,就拿去发布好了。

在2008年,我做了一些持续集成主题的演讲,受众不太多。2009年也不太多。但是,今年的受众就比原来多很多。这是一个信号。企业应该具备软件的持续交付能力,具体要怎么做,这本书就讲得很清楚了。

图灵社区:对《持续交付》这本书,各方面评价都很高。Martin Fowler认为这是“2010年最重要的技术书”,Dr. Dobb's也认为这是多年难得一见的巅峰之作。是否可以结合您自己的理解,谈谈这本书的内容可能对行业带来的改变?

乔梁:我认为持续交付是必然趋势,因为相比上个世纪九十年代,用户已经更成熟了,对计算机越来越了解熟悉,对软件的要求也越来越高。

九十年代初,计算机的应用并不普及,而现在,三岁顽童也能玩一玩。业务人员对软件行业的交付能力要求必然越来越高。市场需求是这样,如果没有这种持续交付能力,这个软件企业可能就会死掉。

这种快速应对变化的需求对于互联网企业是毫无疑问的。那么,对于传统企业,是不是也要求具有这样的交付能力?其实这方面的要求也是有的。我举个例子,比如传统行业,它的竞争对手很可能是互联网公司,因为很多业务都拓展到了互联网上,而传统企业在软件交付这方面的积累,还远不如互联网企业,那它该怎么办?

很多人问为什么要持续交付,业务上没有这个需求,其实很可能是业务人员受原来工作方式的影响,不知道能够做到持续交付。业务人员不了解什么持续交付,但他很可能会说:“我不知道我什么时候要,但我要的时间你能随时给我就行了。”所以,持续交付跟持续集成的动因不同,它是由业务驱动的。只是目前不是所有人都明白可以这么做,当竞争到白热化的时候,持续交付就成了必要的能力。

图灵社区:这样看来,其实很多行业都面临持续交付产品的转型。翻译本书的过程中,您对出版流程也有所了解了,您觉得我们需要什么形式的持续交付吗?

乔梁:我翻译这本书的时候,还是批量生产的,尽管每两个月就会交一定量的译稿。如果我们的频率更高一些,比如我翻译好一章,甚至一节之后马就会由编辑审校,并能尽早对外发布样章,那么会收到更多的反馈,改进翻译质量。另外,我认为,对于阅读,纸质图书在未来可能都只是珍藏版,大部分内容会发布到网络。出版业的更多的工作内容是与读者的交互和内容的挖掘。在这一过程中,只要发现新的内容,就可以交付新的出版物。

图灵社区:关于持续交付这一主题,你是否还可以推荐给读者更多参考资源,比如经常关注的网站、博客等等?

乔梁:国外在这方面发展得比较快,我经常看一些像Dev2OpsDevOps on agileweboperations、build doctor这类的网站。另外,也关注一些论坛,比如devops-toolchain的google group等。还有持续集成工具的发展,这些工具大大小小也有30种。比如在国内比较少见到的AntHill Pro,在Go发布之后,也推出了它的“部署流水线”解决方案。其他开源工具,如Jenkins也有些相关插件,通过不同的组件组织在一起来完成“部署流水线”的定制过程。

图灵社区:感谢乔梁先生今天抽出时间来接受图灵社区的采访。


更多精彩,加入图灵访谈微信!