图灵访谈之三十七:专访Jez Humble谈我们为什么要“持续交付”

Jez Humble,中文名韩捷,是ThoughtWorks的首席咨询师,也是《持续交付》一书的作者之一。从2004年开始,他进入ThoughtWorks,并在北京、班加罗尔、伦敦和旧金山的ThoughtWorks Studio工作。他拥有牛津大学的物理和哲学学士学位,以及伦敦大学亚非学院的民族音乐学音乐硕士学位。现在他和妻子、女儿居住在旧金山。

图灵社区:那我们就开始吧。你能简要地介绍一下你自己,以及此次来中国的目的吗?

Jez:当然,我是Jez Humble,我写了一本叫做《持续交付》的书,是ThoughtWorks的首席顾问,我来中国的原因是我要在这里做几个Workshop以及一些演讲。ThoughtWorks在中国有公司,我们在这里也有客户,而且我的书也由图灵在中国出版了,所以我也很乐意来中国宣传一下这本书。而且ThoughtWorks也希望可以扩大“持续交付”在中国的影响面。

图灵社区:我希望这会对这本书的销量带来增长。

Jez:我也这么想(笑)。

图灵社区:我曾经看过你的学业背景,看起来很复杂,你学过物理、哲学,甚至还学过一门叫做人种音乐学的专业,这看起来和你现在所从事的工作有些无关,你觉得这些知识和经历对你现在的工作有什么帮助和启示?

Jez:我在大学之所以学习这些专业是因为我对这些东西很感兴趣,但很不幸的是这些东西赚不来钱,所以我转向了计算机(笑)。因为在还是个少年的时候,我经常宅在家里写程序,后来我竟然惊奇地发现,这也是一种生财之道。我认为物理和哲学对于计算机还是很有用的。物理中我学到了电子学,这帮助我理解了计算机根本的工作原理。而学习哲学的时候就要学习逻辑,这对我如何清楚地思考很有帮助。而音乐学似乎不是那么有用,但是人种音乐学研究的是音乐和文化之间的联系,尤其是文化那部分很有意思。人种音乐学可以分成人类学和音乐,人类学对于产品设计来说是很有用的学科,因为在设计产品的时候需要观察人是如何和产品交互的。所以当用户体验的工作人员在做产品的时候这些知识都能派上用场。所以从根本上来说,我认为所有事情都是有联系的,根本就不存在没有用的知识。而且大部分在开发产品时遇到的问题都是出在“人”身上,其中包括如何与人交互。所以我所学到的所有知识都可以有其用武之地。

图灵社区:接下来这个问题我们曾经问过Martin Fowler,现在可以问问你了。图灵公司是勇于尝试“敏捷开发”和“持续交付”的。我们计划在今年引进的新书中,采用每翻译完一章就发布一章的出版方式。您对出版业如何应用敏捷,有什么建议吗?

Jez:这其实是个很好的想法。但是令人惭愧的是,《持续交付》这本书花了我和Dave四年的时间才完成,所以我不能说我们在这方面的工作达到了持续交付的级别(笑)。在出版界有一家美国的初创公司叫做leanpub,在那个网站上你可以完成自出版。如果出版商打算这么做的话,如果图灵打算这么做的话,我认为这对你们来说是很好的,对于作者来说也不错,大家都可以收到很快的反馈,这绝对是个好点子。

图灵社区:你的书曾得过Jolt大奖,有人曾评价说“持续交付”将会影响接下来的十年,你是怎么看的呢?

Jez:我非常高兴有人能这么说。可以这么说,其实我们所写的东西并不是真正的原创,我们在书中讨论的很多概念其实都已经被很多人谈论了很多年了。比如说,我们在书中提到的一个主要概念就是“质量内置”(build quality in),这个观点其实有人在上个世纪50年代就已经提出了。我很高兴可以影响软件行业二三十年,但遗憾的是,IT软件行业对于历史的理解并不充分。所以我觉得如果我们可以让人们更好地认识历史,同时也可以让人们在工作中做得更好,我就已经很高兴了。但是我个人认为持续交付这个概念可能要十年之后,人们才能完全接受。因为要做到持续交付其实还是挺难的。

图灵社区:今年的Jolt奖得主是《实例化需求》,你读过这本书吗?

Jez:我知道这本书,Gojko Adzic 是这本书的作者。我没有读完,但是读了一部分。就我读的这部分而言,我很同意他的说法,我甚至在我的演讲中也经常提到这本书。我认为他在书中提到的方法是很管用的,而且这本书中的概念和《持续交付》的内容也是相辅相承的。

图灵社区:我听说你在写一本叫做DevOps Cookbook的书,这本书进展得怎么样了?你负责哪部分的写作呢?

Jez:有七个人在写这本书。其实并没有明确每个人应该负责的部分,我们打算把好的实践经历和工作模式都放到这本书中来。我不知道这本书出版的具体时间,但是写作的过程很愉快,这也会是一本很有价值的书。这本书的重点在于系统思考和精益思想的应用,以及文化问题和技术问题,我们希望可以鼓励开发和运维团队更有效地合作,书里也涉及帮助运维团队应用敏捷和精益原则在工作中这样的技术问题。 这本书的大背景是这样的,我们会设定一个基调就是如果要达到从开发,到运维,再到用户这样无障碍的状态就要采用一些好办法。如何让企业的各个部分更有效地合作,如何建立管道,就像我们在《持续交付》这本书中说过的一样。什么是应该做的事,完成这样的事需要什么步骤,这就是我们在书中想表达的。

图灵社区:刚刚你才说过“持续交付”的难以实现性,那你有没有打算就此再写一本书呢?比如叫做《CD实战》之类的?

Jez:我和另外两位来自ThoughtWorks的同事其实正在写这样的一本书。但是我还没有写多少,所以可能大家还都不知道。我可不想逢人就说:嘿,我正在写书呢。结果书两年后才出来。

图灵社区:Dave Farley曾说过任何在3-6个月内需要再次改动的软件都适用于持续交付。这看起来是个很大的市场,但是中国有一些技术领袖,他们对持续交付持怀疑态度,他们对待这种新的工作模式态度是防御性的,你认为怎样才能鼓励他们尝试持续交付呢?

Jez:其实我不太理解为什么有人会对持续交付持怀疑态度。事实是,我和Dave在书中写到的东西都是来自于我们的真实经历,书中的概念都是来自ThoughtWorks的众多项目。其实这本书的创作人并不只是我和Dave,而是很多ThoughtWorks的同事以及我们的共同经历,书中提到的所有概念我都曾经在实践中应用过,有些在大企业中,有些在分布式的机构中,而且也涉及不同领域。 我们如果对一个概念有任何怀疑的话,那这本书也不会收录这个概念。我们没有编造任何东西。事实上也有其他人有类似的概念,比如leanstartup,以及DevOps社区的很多思想。我们说的其实都一样,而这些都是建立在50年的管理经验上的。
如果仔细看看很多大公司比如google, facebook, MSN, 甚至是苹果,他们都需要接受每天发布两次这样的挑战,google每天都会做上千万次的自动化测试,这些都在实践中应用过。 所以需要记住的是,持续交付并不是试验性的东西,也不是充满风险的,恰恰相反,我们所作的一切都是要降低风险。我们的目的是把团队的效率最大化,当你说你的项目完成了80%的时候,这个项目真的是完成了80%。我们之所以写这本书是因为我们厌倦了超时工作,厌倦了周末加班,厌倦了危险的发布,我们要更安全的发布,我们要每周认真工作40个小时,然后周末回家的时候可以很自信地说:我们的工作都是有效的。所以我希望至少持怀疑态度的人可以尝试一下,如果你有好的经历可以分享出来,如果遇到问题也要分享出来,这样大家才可以在社区里互相帮助。

图灵社区:当我们说到敏捷的时候,很大成分我们说的是人。在采访Bob大叔的时候他曾经说过,任何工具或者流程如果让人们在自己的工作环境中感到举步维艰,那它就不能被称为敏捷。持续交付中的概念中哪个最能代表这个思想?

Jez:我认为Robert Martin这句话很有道理。持续交付中最重要的思想就是作为一个开发者,我希望能尽快地看到我写下代码所产生的反馈。缩短周期时间后,生产时间减少,发布之后你就可以马上看到人们使用时的反映,所以就可以知道,人们到底喜不喜欢你刚刚所做的东西。所以持续交付的一大好处就是让开发者和用户产生直接的联系,一旦开发者和用户挨得更近了,所产生地反馈循环也就越发得强大。我觉得这就是Bob大叔所说的。这也是以前的发布方法的问题之一,作为开发者,你写完代码后,可能要等上半年才会看见产品发布,这感觉真是糟透了。因为那时候你可能已经进入到其他别的项目中了,而你写的代码还没有在实践中应用呢。所以如果开发人员每天上班写代码,而他自己也不知道这些代码是不是有价值、是不是有效,这种感觉肯定不好。而更重要的是,在这样的情况下,你就无法学习,如果无法看到代码变成产品,无法看到人们如何使用,你就无法学到如何创造出更有价值的东西。我觉得这个的重要性不仅在于要让你感觉到你创造的价值,也要让你学习到如何能做得更好,而没有反馈这一切都无法实现。

图灵社区:在这本书中,有很多实践是和人们惯常开发软件的习惯相悖的。比如说,如果单分支开发可以是主流的话,那么Git为什么这么受欢迎?Git或者分布式VCS在分支上的表现怎么样?

Jez:Git 是一个强有力的工具,我很喜欢使用Git,我也很喜欢使用Mercurial,事实上我已经用了5年多了。我对分支完全没有意见,但是我对归并有一些看法(笑)。Git就像C++一样,同样都是很棒的工具,可以用在好的方面,也可以用在坏的方面。我觉得Git并不是要人们在长功能分支上工作,它的目的是让人可以更好地合作、更好地交流。Git有分支并不意味着人们就应该用功能分支来开发软件,这是完全不同的概念。我其实在这方面已经写了一篇文章在continuousdelivery.com,乔梁好像已经把它翻译成中文了,我用长篇大论阐述了我的观点。我认为Git没有问题, 分布式VCS也没有问题,如果你在Github上发现了克隆代码,而这些代码也作了很大的改动,它们是绝对不会再归并回原始代码的。必须要确定分支出去的代码不会变动得太多,否则它们就会变得无法归并。在开源项目中可以见到这样的现象,在Github上也可以见到,你可以把项目分支出去,但是这并不意味着你就应该做一个长长的分支,Git可从没告诉你要这样做。

图灵社区:必须要在实施持续交付前实施持续集成吗?你觉得它们的区别在哪?

Jez:我认为是这样的,确实应该在实施持续交付之前实施持续集成。持续集成在实践中就是每个人都要提交到主干,而且要确证做到当测试失败后,团队就会马上停下来,修复它,以保证代码每时每刻都处在工作状态。而持续交付是要保证这样的代码处于可以部署的状态,要优先保证你的系统处在可发布状态,而不是功能开发状态。还有另外一种实践叫做持续部署,持续部署意味着你把所有通过持续集成的版本发布到生产。持续交付是说如果你希望的话,可以去做持续部署,但是不做也是可以的。所以这是比持续集成更进一步的状态,如果你觉得发布所有能够通过持续集成的版本都没有问题的话,那就是持续交付了,这就是它们的区别。但是大多数人的系统都更加复杂,很多通过持续集成的版本都不足以发布出来。有一条持续集成的规律就是,是否通过持续集成,在几分钟内就可以确定,而这在大规模的系统中并不足以给你足够的信心来作为发布条件。所以才有了持续交付。

图灵社区:你的书中很少提到工具,你曾说过在这本书的网站上会有关于工具的资料,但事实上上面关于工具的内容并不多,你是怎么做出这种抉择的?

Jez:我个人认为工具这方面是很无聊。当然,这并不是说我认为工具很无聊,我们公司自己也在做很多工具,比如Mingle, Go, Twist, 等等。工具是很重要,但是工具有一个问题,就是它们发展变化得太快了,我也没在每天的工作中引入太多的工具,所以我也没法就此发表太多观点。有很多人在自己的博客中,或者写文章提到了工具的使用,有一个很棒的邮件列表叫做devops-toolchain groups,可以在那上面讨论关于工具的内容。而且还有很多其他资源,所以我就不研究这方面的内容了。我更乐意研究我比较在行的部分,比如从大公司的项目或者thoughtworks的项目中借鉴经验,讨论其中的实践、模式,以及原则,这才是我感兴趣的方面。

图灵社区:当谈到持续交付时,你总是会提到很多“每个人”,你认为有没有可能这才是实施持续交付的难点?

Jez:在大多数机构中有两种情况让持续交付的实施变得很困难,退一步说也让软件开发变得很困难。第一种就是功能分区,开发人员、测试人员、运维人员都各自为政,这让持续交付变得很困难。精益软件讨论的就是跨功能团队,在这样的小团队中每个人都参与到产品或者服务的发布中来,大家都在“一个房间”内,这是最好的开发软件的方法。不要一直都陷在过程优化中,在上个世纪80年代,大家认为功能分区是个好主意,这个想法在现在看来并不十分受用,也不太有效,甚至有点可怕。有位软件质量方面的专家Elisabeth Hendrickson在2001年发表了一篇论文,他指出单独成立一个测试部门,让软件开发的质量变得更糟。功能分区不是开发高质量软件的方法。而另一个问题存在于架构中,人们在设计软件的时候并没有把可扩展性和可测试性作为主要考虑因素,这样的系统实施持续交付很苦难,事实上,这样的系统做任何改变都很困难,而很多人都有这样的问题,而这个问题可不是好解决的。

图灵社区:非常感谢你接受我们的采访!

Jez:非常感谢你们的采访邀请!


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