敏捷在团队中的实践与发展现状(2)

敏捷开发的解决方案

记者：刚才提到你特别关注的除了工作规范和开发规范上的细节，还有就是公布流程？

程显峰：是这样的，公布流程实际上就像互联网团队的一个核心，就是有一个标志，如果我拿到一个需求，最后到公布有多长时间，这是看整个团队效率的标志性衡量，而且现在很多人都讲敏捷，其实软件度量是一门学问，究竟度量什么大家非常有争议，我感觉我这边没有太多争议，所有的度量尺度都用时间，因为时间是比较公正的，没有差别的，比如你用代码行数，大家就会说了，代码行数不是一个标准尺度啊，你用C写的五百行和用Java写的五百行到底能不能衡量？你说我用时间，我这里的一秒和美国的一秒是一样的，没有差别，所以所有的东西都应该用时间来衡量，很多东西都可以转化成时间，比如上线效率就可以转化成时间，拿到一个需求到最后推上线就是一个标准的时间，你能在多短的时间之内完成这个事情？这是你团队效率的一个提升。

还有一个非常重要的提升，就是当你发现线上的东西有问题，多长时间能回退到上一个版本？我们可以在秒级之内回去，就是一分钟之内退回去，这是整个团队开发效率的一个显著治理 ，如果你做不到这一点的话，比如你已经发现Bug了，第二天才能把这个更正，其中的时间全部都浪费了，而且对于一个线上系统就是损失。我是讲比较实在的东西，对于开发系统的把控必须要特别严，怎么才能把控上线的这些东西呢？就是要把上线的过程和开发的过程、测试的过程全都紧密地联系在一起，是一个整体，而不是把它们割裂。包括很多传统企业这个方面做得也非常好，并不是敏捷独有的，所有的东西我坚信都不是敏捷独有的，对于优秀的工程实践来讲都是通用的，整个过程都是非常好、非常快的。

记者：在敏捷方法流程中具体 实践的有极限编程（XP）和Scrum等等，Scrum目前团队用的是比较多的，对于极限编程不知道您有没有了解，据我了解很多团队用过Scrum的都不喜欢极限编程的实践方式，能说说您的观点吗？

程显峰：Scum只是一个简单的沟通框架，所以大家的接受程度会比较高，只是规定了你该在什么时候沟通，该在什么时候反思，早上起来应该怎么跟大家交流，抽张扑克牌估算一下这个东西，Scum只是一个实施框架。极限编程是大量工程实践的集合，比如极限编程里讲TCB，它是具体让你操作的，比如咱俩就在一块，它是一种具体的工程实践，就是这么做的，具体工程实践大家反感就比较大了，因为跟他以前的做法不一样，而且问题的关键在于实施这种东西最重要的是有一个人带一个人去实施，两个人都不会你就在那儿极限编程，这个太扯了，根本一点用都没有，这种东西就是师傅带徒弟。

比如结对编程，两个人都没结对过，你在那儿结对。比如本来是一个大锯，你在这边我在那边，大家都没使过这个锯，咱俩就商量这个锯到底怎么拿，所以时间长了以后没有效果，大家马上就对这个不看好，然后就失败了，他们不能带来效果，一般这种东西在成熟的公司里面，他们是极限编程。就像结对这种最简单了，总共有两种，一种是师傅带徒弟，就是一个Mentor，一个是徒弟在这里学，Mentor一开始会给你演示所有的编程，你就在后面看，Mentor可能会给你提问，等过了一阵你来，Mentor在后面观察你、指导你，然后让你干这些。这是带新手非常有用的招，很快就能把新手培养出来。

另外一种就是两个人的水平差不多，就是互相干活，一个人负责设计，另一个人负责实现，这是真正的Pair工程模式，那个是教学模式，你就要求两个人合作很长时间，比如我说的设计他不懂，这就玩完了，没法在一起了。关于你说的极限编程，两个人没在一起合作过，或者两个人都没搭档过，你还在电脑上干自己的，后面的人就特别没意思，没有互动没有交流，这就完了，好多工程实践都是这样的，是跟你平时的编程方法不一样导致的。这跟大家多数的东西都不冲突，只是原来要开会，现在也要开会，现在规定好了什么时间开什么会，只是轻度地改变了你的东西，所以实施起来非常容易，大家的认可度也非常高，某种程度上见效又比较快，因为它能发现一些具体流程上的问题，比如沟通的障碍、理解需求有问题，或者节拍上有问题，有的部门太快了有的部门太慢了，他们能发现这些问题。

我是觉得这个数据比较难以衡量，因为衡量有意义的必须是在某种固定的场景下，比如对于我这里来讲，我可能会要求程序员开发一个标准模块，或者是条形化的实践，我会这样去衡量，但是对于别人来讲，这个他可能不太Care，就是从实施的角度来讲，你可以看一下王晓明给华为和腾讯做的，你可以看看他的，我对怎么度量这个事情想的不是很多，我是比较相信主观看法的，因为我在实施的过程中是跟他们在一起工作的，不需要用那些数据来告诉我他们已经进步了，他们做外部咨询的就比较Care这个事情，因为他们需要给那些老板写报告，我不太需要这个东西，我对其它的产品负责就可以了。

记者：当一个敏捷团队工作时，有时透明化的流程会暴露出机构中的问题，而这些问题又被称为敏捷开发流程的过失。在整个行业中，您们开始遇到这种情况了吗？敏捷开发会使行业的缺点逐步暴露，从而在各方面招致一些与敏捷开发对抗的反对意见吗？

程显峰：是这样的，按照我的理解，我觉得暴露问题是个好事，暴露问题就说明这不是一套有效的方法。为什么丰田要做单件流的系统呢？因为任何一个环节出了问题，马上就要停掉工作，他是可以以最快的速度发现问题、解决问题，为什么是一键而不是两键呢？因为一键可以发现的更及时，要求生产线上的所有环节都能严格匹配，有略微 不匹配的地方马上就会跳出来，如果它是一种发现问题的话，我觉得这种很好，不发现才是问题，发现问题不好吗？我觉得非常好。当然，你肯定会遭到反对意见，这个我觉得是实施的人应该想清楚的事情，实施什么会遭到反对意见，或者不实施什么会遭到反对意见。

记者：在实施当中有没有过这样的情况？

程显峰：肯定会有，这个可以来自于各个方面，但是你要实施的话就要清楚，比如老板什么时候会反对？不出效益的时候会反对，所以刚开始实施的时候不会去做那些影响步骤的问题，你要先见效，有很多方法可以先见效，但是很多人都不知道，你要实施那些先见效的，这对树立信心、树立威望都是非常有帮助的，你不能一开始就挽起袖子说要怎么干，没有获得之前这些事情是做不了的，我们团队刚开始还好，有些团队你要实施敏捷，或者实施某些具体工程实践的话会有挑刺的，这就跟你实施人员的素养有关了，比如你能说服他就说服，要是说服不了他的话你也没法实施。

比如讲故事，有的人去实施版本操纵 ，他就说要用分步式的传统模式，有些人就说为什么要用分步的？那么你做一个版本宏观动作，我用这个做一个，我们比一下。因为技术这个东西很好衡量，大家一看就都明白，它不比了，就实施吧。你要有手段和信心去实施这个东西，而且你要知道对手是什么，如果你操纵 不住这个局面的话，以后实施的时候会有各种各样的东西，比如实施测试，测试的好处你有没有给团队看到？你自己都不会测试，也带来不了什么好处，你就说服不了团队去做这种事情。

比如这里是有框架层面的东西，我特别情愿 实施工程实践，因为我对工程实践的把控力特别强，你要是反对我这些东西，我有很多理由去说服你，而且非常容易见效，你要很快地赢得工程技术人员的信任，反而是你实施这个项目大家会很嘀咕，大家会觉得这个家伙到底写没写过代码？是不是只会这些？因为它不涉及到任何技术细节，工程实践就不一样了，你说代码这么写不合适，那你就得说出不合适的道理，你要那么设计的话就是一种技术的对抗。其实遭到反对意见不光是敏捷遇到，干什么事情没有反对意见？没有反对意见的事大家早就做了，也不需要其他人。

记者：其实我想了解你们开发的反对意见。

程显峰：在我看来大部分的意见其实是一种固有思维的反应，就是他们固有模式的一种反应，以及固有的工作习惯不情愿 改变的反应。问题是这样的，他是没有见到你要实施这种东西的好处的前提下会跳出来反对，你要做的事情是要证明这种东西会给他带来利益，比如刚才说的那种，你用你的版本操纵 ，我用我的版本操纵 ，你自己本身有非常丰富的经验，你看到别人那么做就能很清楚地知道这样做肯定是简单或者容易，他才不比了，要是知道自己一定会赢的话肯定会比，肯定是他实施的新东西对他来讲是有好处的，但是他又不情愿 付出改变的成本，又不情愿 让大家明确地见到这种好处。因为团队的人要是都知道这种好处你就没法演下去了，所以很多事情要把它透明化，就是不存在那种边边角角的东西。

当然，阻力是各种各样的，最好的方式就是把这些东西都透明化，这些程序员相对来说还是非常讲道理的，因为跟机器打交道多了，有一说一有二说二，思维方式还是比较客观公正的，不会说这些东西明明是效率高的却跟你说不行，一般不会有这种情形。

记者：目前国内出现了很多敏捷教练的角色，敏捷的教练需要具备什么样的素养？

程显峰：我个人觉得不管你具备什么样的素养，你要能和开发团队打成一片，要能赢得开发团队的尊重才能做得下去，否则你天天讲，人家不信你，其实你什么事都做不了，你可以不懂技术，但是开发团队都很信你，这也OK，但是开发团队一般都有一种倾向，就是技术沙文主义，不懂技术的人是不能打交道的，你要是想真正在这个团队里混下去的话就得跟他们打交道。不同的团队当然不一样了，比如华为有敏捷实施的红头文件。

记者：这种规范开发人员的工作习惯，优化他们的习惯，教他们一些工程方法，这跟CTO的职能有什么区别？技术部门的Leader职能跟它有什么区别？

程显峰：比如丹峰就负责技术架构设计运营，我就负责培训，发现团队的问题并整合这些看上去非常琐碎的事情，还有一些其它培训方面的事情，他们是思变，是想着怎么去打这个仗，我是像个教官一样想着怎么提高他们的战斗力，他们只想怎么用这些人，然后是打哪儿，这是他们要管的事情，我是教他们怎么使用武器，让他们训练有素，学会配合这些常规性的事情。