TW洞见 | 徐昊谈结对：要更快的编码，还是要更快的交付

1. 我今天有几个问题想咨询你一下，首先第一个问题就说，你在，以敏捷教练来帮助团队实施敏捷的过程中，最经常遇到的一个团队发现的问题是什么？就说因为我这边也待过一些敏捷团队。但是感觉他们就说有些为了敏捷而敏捷，为了形式而形式，就说走形式化主义，你们有没有遇到这种情况？

徐昊：我觉得这是一个比较常见的问题，这个我觉得，这也是跟我们在做软件过程中，有一个很有意思的现象。我们一直认为敏捷是团队的事情，比如最简单是说，我们听到很多工程实践，无论你是结对也好，持续集成也好，还是你交付用户故事。很多管理者认为说，那这个东西其实跟我没有什么关系，那这个是跟团队是相关的。实际上，我跟你换个角度你去想这个问题，如果这个团队使用什么样的方法，对你作为这个团队的管理者，或者你团队再上面那一层，如果对你没有任何影响，或者你自己的工作没有任何变化。实际上从这个角度上来看，那他用什么方法他都是一样的，那你就不能期望他给你带来一个真正的变化。比如我们这里面有一个很典型的情况，比如当你在做敏捷交付的时候，我们主要指的是这种迭代式的交付。这时候你最典型的情况是，我以前这个团队可能三个月过来他跟你讲，我现在是一个什么样的状态，或者我一个月过来给你讲一次。现在可能是每个迭代他都会帮你看，我做了什么，我下面的计划是什么。你可能之前我一个月，我只能计划两个的小时的时间，看看他的进度。而现在我每个迭代都要花30分钟，跟这个团队来聊聊你现在的进展，你需要我的地方。而我们在做敏捷转型的时候，绝大多数人都会忽略掉你团队的中层管理者，甚至是中高层管理者对于这个团队时间的这样一些整合。所以我们通常会发现，我团队已经开始在做迭代计划了，我已经开始在做迭代交付了。而我们上面再往上一层，无论是你最终的用户也好，你还是我中高层管理人员，他还是认为我应该三个月过来看一下，我应该两个月过来看一下。慢慢的你就会发现，这个冲突会变得越来越严重。这个时候你总会屈从于我某种形势，比如如果他们很多企业说，我的KPI订的很详细，或者说这些东西你是不能放弃的，那我们底下的这些实践就开始慢慢的会变得走样，所以这个时候这是一个非常常见的问题。而在我看来，通常是因为这个教练他没有协调好你的团队和他团队之外的这些人的沟通环节。实际上我们要知道，这种转型不是团队自己可以进行到的。他必须必定他对外的沟通方式、交互方式都在发生变化，那么与他相关的所有的相关责任人，他们的工作方式都会发生变化，而你如果不认识到这点，我们最终就会像你讲的，当然这是一个很容易出现你刚才说的这个问题的时候的一个因素。这也是我看到很多国内来做敏捷转型的，这是一个很重要的一个盲点，我只管团队，我并不去管他的这种中高层管理者。而我们在做的时候呢，通常我们会要求，比如最简单这个项目能不能成功，我们肯定会说，你主管的这个团队，比如你是项目经理，你是Program Manager，甚至你是IT部门的人。如果你让我带这个团队，你想它成功，那么你每周必须给我半小时到40分钟时间。如果你没有这样的投入，我没有办法来保证你这件事。因为那就是一个，我要告诉你很清晰一个信号是，这个变化不光发生在你的团队身上，对你的工作方式也会有影响。只有这样的时候，我两方面越多的了解，因为当那个人他越多的进入到里面，他越多的了解，他越多的理解我以前做事的方法，现在在敏捷里面我可能这么做，所以慢慢的我们才可以去实现一个真的。否则的话，当你出现这种冲突的时候，你绝大部分情况下都是，下面的人会屈从于我们上面已经成型的体系，所以你的转型会失败。 2.刚才你也讲到了，敏捷里面有一个实践叫结对，我印象比较深的，因为你们昨天演讲，实际上也是ThoughtWorks比较典型的一种pair的那种方式，ThoughtWorks是不是对这种结对的方式比较推崇？结对这种方式最大的优势和好处是什么？

徐昊：比如做一个听众，你觉得昨天我们那种结对的方式给你留下一个什么主观上的感受和印象呢？

3.首先我感觉，就是说形式上比较新颖，观点上一些碰撞和相互补充。

徐昊：实际上我们在结对演讲的时候，其实我们通常结对演讲，就是大家可能看到会有人说，我们两个人一块来做演讲的，通常是一个人是讲一段，另外一个人再过来讲。而我们通常的形式，是让一个人去把握一条主线，比如昨天那个演讲的时候，姚遥他是在把握整个的这样一条主线，我们要怎么讲，我们是从那块到什么地方来的；而另外一个人，他的方式更多的是说，他会对主线上的观点进行展开和这样的一些补充，所以这样的情况下才会保证我们不会发的非常散。同时我们在一个这个上面，同时我们又有足够的冲突，我们又没有足够的碰撞感。就说我们讲一个什么事情，我们展开，他举个例子，我再举个例子，彼此这种回应的方式。因为我们基本上结对演讲都是这样讲的，比如之前我跟Martin Flower做演讲的时候一样的，是我来做这样的一条主线，他会去做一些很自由的补充，这是一个我们非常常用的这种演讲的方式。这个时候也跟我们就在工作中也是类似的，因为我们工作中的时候他是一样。因为我们认为，你结对编程这件事情的时候，就是如果你仅以开发效率来看，就是你不用想，你如果仅以开发效率来看，他一定是慢的。他一定是慢的，这个是毫无疑问的，有很多的资料都会显示，结对编程它的效率可能会降低到你原来的65%，就是如果你考虑两个人单独去开发的话。实际上我们要注意这样一件事情，就是你软件的生命周期，包括现在在这次大会上，我们多了很多运维和这种DevOps这样的相应工作。其实我们去衡量一个软件的整个生命周期，你会发现我的一个项目，他可能运营了十年，但它的开发周期可能只有三个月，它最开始的开发周期。后面都是间歇式持续开发、持续交付的过程。所以如果你考虑我整个全生命周期的话，那么我在前面的三个月，可能在我整个软件生命周期只占非常小的一部分，这个时候你用什么样的效率去优化它，在我们来讲，就不是什么大问题，你能把这个效率提高一倍，我十年软件你用三个月开发，我十年软件你用四个月开发，其实没有什么区别，他其实没有区别。他更重要的是在你后面的维护的效率上怎么样变得更高。而在这时候我们在做结队的时候，我们看重的是他在后面长期上给我们带来的好处。因为我们知道，造成我软件不可维护的一个根本原因是我的知识壁垒，这段代码只有他熟，其他人他都不了解。所以这个时候我们在用，一定要坚持做结对化就是说，我们并不希望在前面，我从三个月降到一个半月。那我后面的时候，我每一次交付的时间会变得越来越长，这不是我们希望的。而我们希望在整个软件的交付生命周期上，去平衡所有的成本。所以这样来看，如果单比编码的速度，我可以毫不夸张的讲，这种结对开发一定是慢的方法。但是如果你考虑在整个软件生命周期中去做交付，我还没有见到一个比结对开发的方式更有效的方式，当然你是在团队开发的前提下。比如我有十几二十几人的团队，或者是有几百人的团队，在团队开发情况下的时候。可以避免我这种知识孤岛，可以让我每个知识和技能都存在这样一些备份，这个时候会在整个上面会降低你的交付的成本，并且提高交付。 4.下面一个问题是，昨天谈到了成都分公司，你们去年才成立的。说你们新人胜任模式，在成都分公司这边全部应用了。你们能够最短在多长时间内能够判定一个新入职的员工是符合你们的要求的，就说能够胜任这个岗位？

徐昊：如果讲到最短的话，我们有一两个星期就有离职的同事。就是因为他比如他过来说，这个东西不是我喜欢的工作方式，不是我喜欢的工作环境，或者说这种。因为实际上你会想象一下，他对于人员成长，我们在昨天还有一点没有讲，我们为什么要把你的东西都显示化的表达出来，因为在做Coach的时候，在做辅导的时候，最重要的一步是，你要获得你被培养人的许可。因为实际上培养件很私人的事情，比如我为什么会选择你过来教我这个技能上的成长，我为什么选择你作为我在技术上和职业上的这样的内部一个导师，这是一个很私人的事情。所以在这上面的时候，就是我们都会先问，你是否愿意接受这样的方式辅导。有人就直接讲我不愿意，我不喜欢这样的方式。那就没有办法，既然你没有办法。因为我们其实去年有很多在管理实践上、基础上的这样一些presume，我们认为一个比较大的presume，就是我们招人的时候都是基于假设的，昨天我们也大概讲过这个问题。因为你在面试过程中，你可以了解一个人，但是你所做的一切都是我有一个假设，他在面试中，我表现出来一个什么样的状态，我认为我的假设被得到支持了。但是你真的放到你公司的实际环境中的时候，你的假设可能会被推翻，你可能会做出新的假设。所以如果这个人他，我就拒绝，我就不愿意跟大家以这样的方式合作，我们其实是没有办法验证，他是否在公司内最终能否胜任，其实我们是没有把握的，所以这样，还不如既然大家在理念上有冲突，那我们就去这样。所以这个时候也其实某种程度上来讲，为我们节约很多成本。如果我这个人他心态不够开放，他不愿意学习，那么他在ThoughtWorks本身的职业发展也会受到很大限制。这时候还不如很早发现，我们就把这个事情解决掉更好。 5.那剩下来的，就是离开的人，还有剩下的人，你们是怎么保证他在工作状态中，处于那种投入的那种状态？因为我经常发现公司里面，实际上很多人是，有部分，可能有一小部分、一挫人是经常会打酱油的？

徐昊：实际上这就牵扯到我们另外一种方式，比如我们刚才讲的是结对开发，结对开发他利用人的一个什么样心理呢？就是所有人都不希望在自己的对位的人的身上表现的很差，就他是一种心理。因为我们在做结对开发的时候，他为什么就是说，在做结对开发的时候，很多人会变得更加专注。原因是因为我们不希望，假如我认为咱们俩是平等的，我跟你一起工作，我不希望我的表现明显差过你。所以在这样的时候，因为两个人在一起做的时候，你就会有相互的一个激励的作用。而且同时比如另外一个人，并不是说你坐在这，我坐在这，你写代码我在旁边看着，这就是在做那种结对开发的。结对开发有很多种不同的方式，而在这里面的时候，我们一个人写一个人看，这种方式我们要求它的时间非常短，而且我们只在某个特定时期内会使用这样的方式。而通常的方式，比如说无论是在用TDD的，我们叫乒乓的方式，一个人写测试，一个人另外写实现。还是说我在重构的时候，用的Keyboard and Mouse，一个人在动鼠标，一个是在动键盘，都是两个人合作一起去完成那一份代码，所以这个时候不太可能出现纯粹的酱油。因为这个时候如果出现了很快就会发现，因为我的一个Pair，他马上就会抱怨，你为什么不跟我合作，你为什么是这样一个态度？所以这个时候就是能够很有效的避免它。 6.昨天这个演讲上提到学习型的组织，你们的项目的产出，实际上是这种模式的一个副产品。你们如何保证这个产品，就是这个项目它能够成功，并且能够在规定的时间内，或者说之前完成？

徐昊：这个东西实际上你可以换个角度来考虑，如果你有一个团队，他的技能不足，比如说你招聘的团队里面有很多新人，有很多毕业生，你在传统方法下的时候，你怎么来保证它能够按时并且完成我的任务呢？ 7.要把东西写出来。

徐昊：这个就是一样的道理，实际上在那样的时候，我们之所以讲它是一个副产物，跟你讲的是一模一样的道理。我们去完成项目是验证你学习的标准，所以你的产出，我们为什么让他是一个by-product呢，是说你的产出是为了来验证你的学习的，而你的产出物恰好就是你做的项目。因为你把这个项目做了，我就认为你能在规定的时间内，你规定你把这个项目做了，我就认为你学会了。否则我就认为你没有学会。那么也是在上头，这个是我们在讲它是一个这种副产物的效果。就这个我们要求我们的学习是非常Focus的，你一定是跟我当前项目用到的东西相关，而且跟你自己的技能Gap是相关的，这一点。我有什么地方不会我才去学，我有什么地方不会了，而我这个Gap被填上的一个原因是，以前这个故事，或者这个需求，在这个项目中我之前做不了。通过我的学习，我现在可以做，我可以把它做完。并且得到项目组中其他人的认可，这个时候是。另外一点是，你刚才强调这个结对也是一方面，我有经验的人和没有经验的人在一起结对，这个时候通常在我有经验和没有经验的人结对的时候，有经验的人去写测试了，他不写真正的生产代码。因为他用他的测试去表达他设计的这样一项意图和功能的这样一些意图，而由这个人自己，就是我缺练的这个人，这个人可能我技能不够的这个人，他去写这个实现代码。因为这个可能跟大家想像中恰恰是相反的。因为我们要求是说，你越senior了，你通过测试来表达你代码意图，通过测试来表达设计是非常容易。因为实际上现在我在Pair-Programming的时候，我让他想写成这样的代码，我只要他写个测试，他不可能写成其他样子的。那这个时候其实我再教给他你的在这种情况下的时候，你应该怎么去写代码。那么这样的时候，他也可以通过这样的方式慢慢去锻炼他写代码的技巧，我们通过这样的方式，我们等于是通过这样一个方式去验证，因为你在实际操作的过程中，可能有人会给你实时的反馈，你这个地方做得好，那个地方做的不好，应该怎么样多做一点，只会促进让他学得更快。 8.首先可能保证他能够这个经验或者技能一定要在某个时间内预研完成，或者说成功的掌握，然后后面的话可能。

徐昊：那你的成功的掌握是怎么验证的？这个人那我看了三天之后，我看了TDD，我看了Java，我找很好的书，《Java编程思想》，《Head First Java》，《Head First Design Pattern》看完全之后你怎么知道他会了？ 9.你们成都公司成功运用这个模式的话，大概用了多长时间？

徐昊：我们是，因为这个模式很有意思，因为这个模式是我们去年，在一个客户那边，我们给他们在做咨询的时候，我们发现了。因为他们那边，我们观察到这个企业，就像你刚才讲的转型的时候有很多困难。后来我们发现呢，最终在它的企业内我们发现想解决这个问题呢，我们可以把它的组织结构和对他团队定位进行一个调整。当时我们这个方案呢，在那边得到一些还不错的反馈和效果的时候，大概是四五月份。所以我们成都办公室是从4月份开始的，所以我们在一开始的时候，我们就尝试过用这样的方式，在团队里面，从一开始其实我们就在尝试，从很早的团队我们就在尝试做这样的事。 10.从没有到差不多到能够成功运行，大概是要用到4个月？

徐昊：看你的规模了，实际上我们做得规模比较大，因为我们是在整个办公室级别，包括我们前面的招聘，我们去招人的方法和我们培养的方法也结合的比较紧密。前面有一个没有讲的，是我们之前招聘的，有一个叫这种lean improvement，这种精益招聘，它是作为我们后面学习培养，我们后面叫LOT，叫Learning Organiation Transformation，学习型组织转型，这个东西它是精益招聘的结果，是我们最初的那一块画布，实际上在招聘的过程中，我们就产生了。然后当这个人，当他On Work，当他进入公司的时候，当他加入团队的时候，我们的Recruiting Team就会把他之前，我们在面试过程中做的发布，我们对他的判断和评判交给团队，去来制订他的Coach方案和我团队里面的胜任计划。所以这个时候，他是一个更大规模的这样一个实现，所以我们在做整体上，我们花了很多时间。因为你在部门上的时候，比如以前我们的团队，它并没有采用这种精益招聘的方法，我们可能会对他们的一些工作流程和习惯发生一些变化。但是你在团队级别其实是很快的，团队级别可以用比较快的方式去做这个。我们里面还有很多具体实践，因为我们实际上没有分享的特别细，因为时间很有限。比如我们很多里面关于团队学习的，你去建立这个机制并不难。但是真正这个东西你让大家感到收益是很多跟团队学习相关的一些这样的实践，然后大家才能够坚持下来。还会觉得这个东西对我真正是有帮助的。 11.还有一个问题我为南京的那一些企业问的，假如说有南京这边企业对这个感兴趣，ThoughtWorks是不是提供全方位的咨询服务？从组织转型？

徐昊：是的，因为这个是我们去年新创造的一个这种新的Third Consultation，这个实际上我可以说，这个就是我去年在一个项目上面做出来的东西。因为我们觉得这个价值很大，对很多企业会有帮助，所以这也是我们为什么决定先在我们自己身上做更大范围应用，因为我们觉得这个对知识性企业是非常有帮助的一个事件。

原文发表于InfoQ：http://www.infoq.com/cn/interviews/pair-programming-and-software-lifecycle