无论是在软件或者管理行业敏捷开发已成为众多高效开发团队的制胜之道。敏捷开发可以说是在开发中面临迅速变化需求中的一种快速开发能力。当然，敏捷不仅是简单的快速，而是在开发过程中短周期的不断改进、提高和调整；当然也不仅仅是一个版本只做几个功能，而主要的是突出重点。
在国外软件企业中，几乎将近半的企业是已采用敏捷方法进行开发，随着近年来受软件外包和外企的带动，敏捷开发在中国也出现了日渐普及的趋势，如腾讯，IBM等等内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然，因此，51CTO记者采访了AdMaster（精硕科技）***布道师程显峰，讲解了敏捷开发在团队中的实践以及发展现状。
简介：程显峰，毕业于悉尼大学，《MongoDB权威指南》译者，MongoDB中文社区创始人。Emacs使用者，Ruby写手，Scheme爱好者。AdMaster***布道师，负责团队建设，人员培训，新技术普及，还有一些公司技术PR的工作。
以下是相关的采访实录：
敏捷在项目中的实践
记者：有些人认为敏捷开发并不适用于水平一般的程序员或团队，您是怎么认为的？
程显峰：至于敏捷开发是不是用这种程序团队，我认为特别适合训练有素的团队。反过来说，如果不是一个训练有素的团队，实施传统软件开发也会失败，所以我觉得基本的要求是跟原来的一些要求基本一致的，沟通能力、协调能力，对于项目变动的控制能力都是一样的。包括传统软件开发当中讲的项目可控，整个项目可复制，同样的资源配比后还可以复制这个项目，如果原来的这些做得比较好的话实施敏捷项目就相对容易一些。
记者：很多人为了编写易变更的代码，在采用敏捷时，抛弃许多习惯用法，由你的经验出发，如何去看待这个问题？
程显峰：从我在实施的过程中***点需要强调的就是大部分跟传统的软件工程还是一样的，现在异化的部分过于被强调了，搞得大家以为是完全新的、不一样的东西，传统软件包括需求管理、进入控制、质量管理、测试体系，这些东西在敏捷里也都要体现、都要实施，而且要求可能还会更高，并不是把一些传统的东西抛弃掉了，既没有进入管理又没有版本控制，几个人一商量就定了敏捷，这是完全的一种误解，而且还是要好的工程基础才能实施。
记者：所以传统的方法对于程序员的要求还是比较高的吧？敏捷这样的功能经过修改之后就可以推出一个小的版本？
程显峰：并不是说推出小版本就降低难度，这是没有因果关系的。比如说这小的版本即使推送上去，如何保证这个小的版本是对的？你也需要大版本的方法，比如软件测试、进度控制、需求管理，这些东西都得有，你才能控制好。虽然你推得比较快，看上去可能是一个一个的，如果你要是推的没有章法的话一样也是乱套。不是你想要的东西，也会造成大量的浪费，我是这么觉得的。
记者：对于一个失败的软件项目来说，您认为敏捷方法是它的救星吗？
程显峰：对于一个失败的项目就要说出失败的原因，这才是解决失败项目的办法，敏捷的方法不是，这个逻辑就是有问题的，我觉得这个没什么好说的。
其实我觉得敏捷的方法不是任何失败项目的救星，这是肯定的。至于失败这个事情，看上去可能是分工的原因，有可能深层次的来讲是不交流、不沟通的原因。敏捷比较注重强调沟通互动这些方面，它是有强调这些东西，如果你的问题恰巧是由于不沟通导致的，可能采用了敏捷的方法可能会有极大的改善，但也非常取决于实施的人和分析的效果。好多人说敏捷就是一个框，什么东西都可以往里面扔，实际上也确实有点这个样子。
我觉得敏捷的方法更多的是注重发现问题的框架，就是能让你更快地发现问题、暴露问题。至于怎么解决问题，原来能解决的就能解决，要是原来解决不掉，敏捷也帮不了你。但是它能帮助你发现问题，比如说原来你有沟通问题，但是很长时间才能暴露出来，这个东西能让你在短时间内暴露出来，那么就有助于解决这个问题。
记者：想要做到敏捷开发，每个团队都要经历这样一个转型期，那么在转型期还需要每个团队根据自身的不同，找出合理有效的解决方法。你们团队的是如何来解决的？
程显峰：我是倾向于比较温和地对团队进行改进，实施的东西尽量不要让团队有一个明显的转型期，比如版本控制，原来做的版本控制、提交力度、上线流程这些，我会给大家介绍一个新的系统，但是并不会太影响大家的工作，适应起来又很快，这样的改进效果是比较立竿见影的，而且影响又非常小。这种改进不是偶尔一次才会用到，而是天天都能用到，比如说调试方法，每天能省一分钟就行，我特别喜欢这样的改进。
大家可能都觉得敏捷特别神奇，每天能省百分之二十的时间，现在我还没发现这种现象，我特别不相信这种东西，就是不想省百分之二十的时间就不会让大家经历一个很长的转型期。比如你告诉大家一个技巧，每天能省两分钟，这种东西大家天天用实际积累下来的效果才是比较明显。你要是教给大家一个方法，比如能省二十分钟，实际上这种方法看上去是非常漂亮，但它不是什么场景都能用得到，所以我就不太喜欢这样的方法。现在大家吹嘘的敏捷方法可能有一部分也不敏捷，我在这个团队里也不太愿意教那部分，比如说每天早上例会的时候站在那里说一通。我也跟他们讲过，他们有的话可以，没有也OK，有些东西我的要求就比较死，比如上线的流程、可控性，我在这个方面的要求就比较死，开不开会对于我的项目没有什么影响，但是上线的流程就不一样，我要往回退的话就要花成本。
对于小的团队来讲真的是可有可无的，因为团队的人都坐在一起工作，未必需要一个站到板子上的形式。现在有人把形式看得很重，本来例会是很简单的，五分钟就开完了，但是吵起来了，开不完，因为一般都是开早会，吵完以后心情就不好，所以效率就下来了，这也是很正常，但是你不要想着漂亮的东西，我对漂亮的东西感觉都不实用。
记者：会不会因为不吵这个架把错误带到真正开发的过程中造成成本的耗费？
程显峰：会，所以我们要在实际的工作当中发挥，其实例会也不是吵架的会，还有很多的会可以发现这个问题，比如通过Review，可以有各种各样的方法去发现，不用拘泥于这种形式上的东西。其实最难改变的往往是那些小的习惯，比如他就愿意用这个手指头去敲键盘，但是这可能会影响他的效率，他不愿意改。这种习惯的话改的阻力反而比较小，你让他去开个例会他觉得耽误时间，但是要让他改这个的话他可能会改。你想他要敲多少？天天可能都要去敲，这种感觉可能是持续的。
记者：这种其实是属于比较个性化的调整，每个人的使用习惯不一样，有些人可能喜欢用这个手按着，有些人喜欢用那个手按着，你要主动发现各个人在工作当中需要调整的地方？
程显峰：我一直认为团队就是一个泯灭个性的过程，而且这一点我是非常讲究的，包括编辑器的使用习惯和配色都有强烈要求，不像别的看上去那么自由，坐在哪里无所谓，但是你用电脑的方式必须是我规定好的。没有一个共同基础的团队根本就不叫团队，总有一些东西是有共同基础的，而且一些高效的团队很可能所有的东西都是共同基础，就像特种兵出去打仗，一个手势就得去杀人，你还能再问这个是什么意思？就像我们用别人的电脑，或者在团队当中用其他人的电脑，那些配色习惯都是一样的，我们沟通交流起来就会非常容易。
现在新人如果不配色，直接就卡掉，新人培训就不合格，所以必须要有配色，包括快捷键的使用，不能人家给你一套代码你还慢吞吞的，这会非常影响别人的心情。因为有些忽悠师天天都去忽悠各种敏捷方法，但又不注重工程实践，不注重观察细节，所以就做不到。他们不会注重这种实践，比如咱俩是木匠，我天天使完的刀子随手一扔，天天你给我收拾，虽然我是大牌，但是你也不愿意。你和我都收拾的很好，大家都用一个工具箱，这样才能省下很多时间。我就觉得能省时间的话，就是在任何层面上都是节约和避免浪费的表现。
记者：如能得到准确的数据支持，敏捷实施能够更好地开展下去，那么敏捷实践下的程序员工作指标将如何衡量?
我是觉得这个数据比较难以衡量的，因为衡量有意义的必须是在某种固定的场景下。比如对于我这里来讲，我可能会要求程序员开发一个标准模块的实践，但是对于别人来讲，这个他可能不太注意。从实施的角度来讲，我对怎么度量这个事情想的不是很多，我是比较相信主观看法的，因为我在实施的过程中是跟他们在一起工作，不需要用那些数据来告诉我他们已经进步了，他们做外部咨询的就比较注意这个事情，因为他们需要给那些老板写报告，我不太需要这个东西，我对其它的产品负责就可以了。
#p#
敏捷开发的解决方案
记者：刚才提到你特别关注的除了工作规范和开发规范上的细节，还有就是发布流程。
程显峰：是这样的，发布流程实际上就像互联网团队的一个核心，就是有一个标志，如果我拿到一个需求，***到发布有多长时间，这是看整个团队效率的标志性衡量，现在很多人都讲敏捷，其实软件度量是一门学问，究竟度量什么大家非常有争议，但是我感觉没有太多争议。所有的度量尺度都用时间，因为时间是比较公正的，没有差别的。比如你用代码行数，大家都说代码行数不是一个标准尺度，你用C写的五百行和用Java写的五百行到底能不能衡量？但是你用时间的话，我这里一秒和在美国那里一秒是不是都一样的？所以所有的东西都应该用时间来衡量，很多东西都可以转化成时间。比如上线效率就可以转化成时间，拿到一个需求到***推上线就是一个标准的时间，你能在多短的时间之内完成这个事情，这是你团队效率的一个提升。
还有一个非常重要的提升，就是当你发现线上的东西有问题，多长时间能回退到上一个版本？我们可以在秒级之内回去，就是一分钟之内退回去。这是整个团队开发效率的一个显著的管理，如果你做不到这一点的话，比如你已经发现Bug了，第二天才能把这个更正，其中的时间全部都浪费了，而且对于一个线上系统就是损失。我是讲比较实在的东西，对于开发流畅要把控的特别严，怎么才能把控上线的这些东西呢？就是要把上线的过程和开发的过程、测试的过程全都紧密地联系在一起，这是一个整体，而不是把它们割裂。包括很多传统企业这个方面做得也非常好，并不是敏捷独有的。所有的东西我坚信都不是敏捷独有的，对于优秀的工程实践来讲都是通用的，整个过程都是非常好、非常快。
记者：在敏捷方法流程中具体 实践的有极限编程（XP）和Scrum等等，Scrum目前团队用的是比较多的，对于极限编程不知道您有没有了解，据我了解很多团队用过Scrum的都不喜欢极限编程的实践方式，能说说您的观点吗？
程显峰：Scum只是一个简单的沟通框架，所以大家的接受程度会比较高，只是规定了你该在什么时候沟通，该在什么时候反思，早上起来应该怎么跟大家交流，抽张扑克牌估算一下这个东西，Scum只是一个实施框架。极限编程是大量工程实践的集合，比如极限编程里讲TDD，它是具体让你操作的，比如咱俩就在一块，它是一种具体的工程实践，就是这么做。但具体工程实践大家反感就比较大了，因为跟他以前的做法不一样，而且问题的关键在于实施这种东西最重要的是有一个人带一个人去实施，两个人都不会你就在那儿极限编程，这个太扯了，根本一点用都没有，这种东西就是师傅带徒弟。
比如结对编程，两个人都没结对过，你如何在那儿结对？比如本来是一个大锯，你在这边我在那边，大家都没使过这个锯，咱俩就商量这个锯到底怎么拿，所以时间长了以后没有效果，大家马上就对这个不看好，然后就失败了，他们不能带来效果。一般在成熟的公司里面，他们是极限编程。就像结对这种最简单了，总共有两种，一种是师傅带徒弟，就是一个mentor，一个是徒弟在这里学，mentor一开始会给你演示所有的编程，你就在后面看，mentor可能会给你提问，等过了一阵你来，mentor在后面观察你、指导你，然后让你干这些。这是带新手非常有用的招，很快就能把新手培养出来。
另外一种就是两个人的水平差不多，就是互相干活，一个人负责设计，另一个人负责实现，这是真正的工程模式。那个是教学模式，你就要求两个人合作很长时间，比如我说的设计他不懂，这就玩完了，没法在一起。关于你说的极限编程，两个人没在一起合作过，或者两个人都没搭档过，你还在电脑上干自己的，后面的人就特别没意思，没有互动没有交流，好多工程实践都是这样的，虽然跟你平时的编程方法不一样导致的。Scrum跟大家多数的东西都不冲突，只是原来要开会，现在也要开会，现在规定好了什么时间开什么会，只是轻度地改变了你的东西，所以实施起来非常容易，大家的认可度也非常高，而且某种程度上见效又比较快。主要是因为它能发现一些具体的非技术上的问题，比如沟通的障碍、理解需求有问题，或者节拍上有问题，有的部门太快了有的部门太慢了，他们能发现这些问题。
记者：当一个敏捷团队工作时，有时透明化的流程会暴露出机构中的问题，而这些问题又被称为敏捷开发流程的过失。在整个行业中，您们开始遇到这种情况了吗？敏捷开发会使行业的缺点逐步暴露，从而在各方面招致一些与敏捷开发对抗的反对意见吗？
程显峰：是这样的，按照我的理解，我觉得暴露问题是个好事，暴露问题就说明这不是一套有效的方法。为什么丰田要做单件流的系统呢？因为任何一个环节出了问题，马上就要停掉工作，他是可以以最快的速度发现问题、解决问题。为什么是一键而不是两键呢？因为一键可以发现的更及时，要求生产线上的所有环节都要严格匹配，如果有稍微不匹配的地方马上就会跳出来。如果它是一种发现问题的话，我觉得这种很好，不发现才是问题，发现问题不好吗？我觉得非常好。当然，你肯定会遭到反对意见，这个我觉得是实施的人应该想清楚的事情，实施什么会遭到反对意见，或者不实施什么会遭到反对意见。
记者：在实施当中有没有过这样的情况？
程显峰：肯定会有，这个可以来自于各个方面，但是你要实施的话就要想清楚，比如老板什么时候会反对？不出效益的时候会反对。所以刚开始实施的时候不会去做那些影响步骤的问题，你要先见效，有很多方法可以先见效，但是很多人都不知道，你要实施那些先见效的，这对树立信心、树立威望都是非常有帮助的。你不能一开始就挽起袖子说要怎么干，没有获得之前这些事情是做不了的。我们团队刚开始还好，有些团队你要实施敏捷，或者实施某些具体工程实践的话会有挑刺，这就跟你实施人员的素质有关了，比如你能说服他就说服，要是说服不了他的话你也没法实施。
有的人去实施版本控制，他就说要用分步式的传统模式，有些人就说为什么要用分步的？那么你做一个版本宏观动作，我用这个做一个，我们比一下。因为技术这个东西很好衡量，大家一看就都明白，它不比了，就实施吧。你要有手段和信心去实施这个东西，而且你要知道对手是什么，如果你控制不住这个局面的话，以后实施的时候会有各种各样的东西。比如实施测试，测试的好处你有没有给团队看到？你自己都不会测试，也带来不了什么好处，你就说服不了团队去做这种事情。
比如这里是有框架层面的东西，我特别愿意实施工程实践，因为我对工程实践的把控力特别强，你要是反对我，我有很多理由去说服你，而且非常容易见效，你要很快地赢得工程技术人员的信任。反而在实施这个项目时大家会很嘀咕，觉得这个家伙到底写没写过代码？是不是只会这些？因为它不涉及到任何技术细节。工程实践就不一样了，你说代码这么写不合适，那你就得说出不合适的道理，你要那么设计的话就是一种技术的对抗。其实遭到反对意见不光是敏捷遇到，干什么事情没有反对意见？没有反对意见的事大家早就做了，也不需要其他人。
记者：其实我想了解你们开发的反对意见。
程显峰：在我看来大部分的意见其实是一种固有思维的反应，就是他们固有模式的一种反应，以及固有的工作习惯不愿意改变的反应。问题是他没有见到你要实施这种东西好处的前提下会跳出来反对，你要做的事情是要证明这种东西会给他带来利益。比如刚才说的那种，你用你的版本控制，我用我的版本控制，你自己本身有非常丰富的经验，你看到别人那么做就能很清楚地知道这样做肯定是简单或者容易的时候就不会比了。要是知道自己一定会赢的话肯定会比，肯定是他实施的新东西对他来讲是有好处的，但是他又不愿意付出改变的成本，又不愿意让大家明确地见到这种好处，因为团队的人要是都知道这种好处你就没法演下去了。所以很多事情要把它透明化，就是不存在那种边边角角的东西。
当然，阻力是各种各样的，***的方式就是把这些东西都透明化，这些程序员相对来说还是非常讲道理的，因为跟机器打交道多了，有一说一，思维方式还是比较客观公正的，不会说这些东西明明是效率高的却跟你说不行，一般不会有这种情形。
记者：目前国内出现了很多敏捷教练的角色，敏捷的教练需要具备什么样的素质？
程显峰：我个人觉得不管你具备什么样的素质，你要能和开发团队打成一片，要能赢得开发团队的尊重才能做得下去，否则你天天讲，人家不信你，其实你什么事都做不了，你可以不懂技术，但是开发团队都很信你，这也OK，但是开发团队一般都有一种倾向，就是技术沙文主义，不懂技术的人是不能打交道的，你要是想真正在这个团队里混下去的话就得跟他们打交道。不同的团队当然不一样了，比如华为有敏捷实施的红头文件。
记者：这种规范开发人员的工作习惯，优化他们的习惯，教他们一些工程方法，这跟CTO的职能有什么区别？技术部门的Leader职能跟它有什么区别？
程显峰：比如丹峰就负责技术架构设计运营，我就负责培训，发现团队的问题并整合这些看上去非常琐碎的事情，还有一些其它培训方面的事情，他们是思变，是想着怎么去打这个仗，我是像个教官一样想着怎么提高他们的战斗力。他们只想怎么用这些人，然后打哪儿，这是他们要管的事情，我是教他们怎么使用武器，让他们训练有素，学会配合这些常规性的事情。
#p#
敏捷与管理的发展现状
记者：对于未来几年敏捷开发的发展，您希望看到哪些新方向?有何建议?
程显峰：发展方面的问题我还真不知道，还是觉得有点落后，这个还需要积累吧。很长时间才会有一些改进，国内技术上落后的已经比较少了，反而是管理上落后的非常非常多。比如Facebook的崛起，大家都看到它用的是什么技术，很少有人看到Facebook在壮大的时候立马就从e-Bay挖了一个人给他们做工程方面所有的事情，他们从很早期的时候就从e-Bay挖了一个高管去做所有工程化的东西，很早就做了，非常有远见，这些事情很少有人知道。Facebook每年开了什么会，开发了什么框架他都知道，到了一定程度你就会发现它不是几个毛头小子一个Idea就可以发展起来的。e-Bay大概已经有二十多年，其实是经验非常丰富的人去做这个事情，并不是一个Idea就能行，现在好像不太注重这个方面。
其实在美国都是由非常资深的人去做工程化，而且这个市场还是比较稳定，真正去做这些东西的人还有一个相对比较稳定的流动环境，不会是从哪里突然冒出一个人就能做这些事情，或者是凭一个Idea就可以做。
记者：微软就有自己的工程研究院和微软研究院，也是不一样的。
程显峰：其实从开发的各种东西来说，类似微软、苹果、谷歌这些大公司，他们在工程管理上都有很多非常有经验的人，但是这些人在国内往往不讲这些。比如原来谷歌测试的负责人段念就是讲测试方面的稍微多一些，那个属于工程化的一部分，你就可以看到一些，多半也是做类似的工作，实际上他是一个非常有经验的做工程化的人。
记者：主要还是国内管理上的问题。
程显峰：对，软件研发的管理落后的不是一点半点，国内那种落后的方式跟美国六七十年代有一拼。其实现实就是这样，尤其是互联网公司还在觉得自己是什么高科技，其实工程管理的水平差得一塌糊涂，但是不是垄断高额利润，如果是从一个软件公司的角度去衡量的话，那个研究体系简直是一塌糊涂。
记者：其实从工程化的角度也会影响本身推出产品的效率或质量。
程显峰：其实工程化是一种内功，为什么IBM谁打他都不太怕？内功非常深厚体现在几个方面。
记者：IBM也比较开源。
程显峰：它的内功深厚也是有各种方面，首先就是知识产权方面保护得特别好，专利大户向来都是***，第二就是在基础研究各个方面，工程化的思想，好多软件工程的思想，软件工程的方法，他们也很注重敏捷的一些东西。这就衍生了一个问题，为什么抄IBM的人都很惨、都死掉了呢？因为内功不够。IBM的管理方法非常重型，轻型的公司想抄都死掉了，为什么？因为你根本无法调动那么多的资源驾驭那么重型的方法，你的内功不行，就是这样。IBM原来那个case版本控制系统使用起来多负责啊，***用的大部分都是电信系统，就是跟它有相同内功级别的人。他的客户都是金融、能源方面的，要是小公司用IBM做咨询，即便是你付得起钱也实施不下来。
记者：实施下来也达不到那种业务规模。
程显峰：我是觉得软件业的发展还是应该从基础做起，实实在在地把软件做好，不要过分地强调那些概念，好多人都是想解决别人的问题，每年实施的过程当中尤其要注意，作为一个团队的leader，你最清楚的是团队自身的问题，你也最容易解决团队自身的问题，要是每天都解决自身的问题的话一定是个特别好的教练，根本不需要去搭理别人，但可以借鉴别人的方法，看别人是怎么借鉴类似的问题。一定要着眼解决自身的问题，因为他们解决的都是别人的问题，比如看到别人的沟通方法就觉得自己的团队沟通有问题，实际上你就是三个人，你有什么沟通问题？根本就不存在。
记者：听你这样说，敏捷并不是一个特别有别于传统开发流程、软件开发工程的方法，只是在里面加入了一些管理的理念，能够把工程化和管理结合起来，可能就是一种敏捷。
程显峰：软件行业的管理方法主要来自于两个途径，六七十年代的时候大体上是借鉴建筑行业的系统化管理方法，主要是需求管理、建筑管理方面的内容，另一次改进就是在九十年代后期，由于丰田在制造业上的改进，就是精益方法，主要的改造就是发现问题及时生产及时交付，所有迭代周期这方面的东西。软件行业主要的来源就是制造业，实际上他们也不能太超越这两种。我就觉得现在老是想标榜自己跟别人不同，反而是把自己给害了，那些方法实际上会在那些产业里实施得更好。
你看《精益软件开发艺术》那本书，写得特别好，那是波音的一个家伙写的，因为波音在制造业生产的时候用了这种方法，他在波音的软件部门，借鉴了波音的生产，然后再去用精益的思想改造，实际上都是借鉴其它传统行业的。传统软件的方法主要是建筑业的，建筑业和制造业都是比较成熟的，他们也会互相借鉴，借鉴***的结果其实是发现方法和方法之间的差别没有想像的那么大，可能只是流派之分而已。比如大家都注重的版本控制、质量管理，整个周期管理这些东西，哪个没有呢？而且具体的操作方法大家都可以借鉴，你敏捷比较推荐的版本控制，实施到传统软件当中可不可以？也可以的。实际上并没有那么不同。我觉得这是一种商业策略，给划分了非黑即白，不是那样子的。其实大家真正在玩的时候就会觉得他们是可以有很多互通的，大家也可以互相借鉴，而且两种方法都在成长，这就跟武侠小说里的江湖差不多，大家都是为了各自的势力划分出来，他们就是邪教，我们就是明门正派。
其实那两个人讨论的就是一个风花雪月的问题，完全没有必要分什么派别，大家讨论的就是一个质量控制的问题，敏捷也可以用，传统也可以用，根本没有必要说这个方法就是属于谁的，但是这种实践的东西多起来之后就会发现越来越多的共同之处。
记者：***就会发现自己在实践的过程中总结一套结合了传统和敏捷的方法。
程显峰：肯定的，我觉得比较负责、比较讲究实际的人都会结合自己这块东西去实施的，敏捷方面有个非常重要的东西，要是按照书本上实施的话肯定不是敏捷，最重要的就是裁减，你要按照自己的东西去裁减，包括传统的软件研发人员那一套也有裁减，只是很多人都不知道。传统的软件研发虽然很重，但是会按照自己的需求去裁减，要是完全按照那种东西就会死得很惨，所以你要实施一套流程的时候***件事情就是裁减，要把它裁成合适自己那块，包括电信企业里面实施的东西都是经过裁减的。
原来我的一个同事他们在项目实施的时候首先就是要看标准的研发流程，弄下来一份之后再裁减，就说这个我们不要了，那个我们不要了，要是按照标准化他们也受不了，肯定不行，包括传统的实施。比如你就在一个猪圈，非得按照摩天大楼的质空标准去做，肯定不行，虽然都是建筑，但是不符合实际，所以最重要的就是符合实际产生效果，拿给老板也好说好看。
记者：那种大型的软件，比较像传统的，他们之间也有软件开发的部分吗？
程显峰：肯定会的，工程实践现在已经借鉴了很多，包括版本控制一般都是集中式的，现在大家对分布式的都会比较倾向，甚至是说发布流程。这些东西无所谓谁都可以用，比如传统上的需求管理软件、Bug跟踪系统，敏捷也在用。敏捷也有这些东西，你也需要跟踪Bug，你也需要有针对性地上线打包。
记者：所以只要技术能力强，跟敏捷没有多大关系，都是在创业团队里用敏捷的比较多。
程显峰：是这样的，大家为什么要用敏捷？很多都是创业小团队偷懒的行为，因为他实施不了那种重型的，也没有实施的经验。其实在国内实施规范化的还是相对较少，他们觉得这个东西能够玩转才这么做的。而不是真正考察过，做了一个比较公正的技术选型，比如传统上我们会得93分，用了敏捷会得94分，根本没有数据，就是自己想，那种我们能不能玩？玩不了，这种我们能不能玩？差不多，实际上差得挺多的。因为敏捷强调的是不同，不同的东西又很少，所以大家就会觉得很容易。其实国内真正好的测试团队简直凤毛麟角，能玩得起测试的凤毛麟角，能把发布上线流程做好的也很少，这两个都做好了，我觉得你是敏捷还是传统都已经不重要了，这些对你才是实实在在的东西，对于质量、对于产品都是非常有益处的东西，至于长什么样子已经不重要了，关键是对你是否有好处。
大家现在都是有点炒概念，不讲实惠，我是比较讲实惠的，这些东西好不好我很快就能知道，所以我要的是实惠。我向老板汇报的时候也是这样，老板不看这些概念，他也不懂，创业的人好多是Idea出身，炒个概念会很好看，也会很好卖，但是大家现在都知道了，也不见得好卖。
记者：你们现在关注团队的开发，是从哪个方面去看这个问题？
程显峰：我个人比较关注的就是发现问题的方法，比如传统的东西，包括制造业的那些管理方法我也都会看一些，比如《约束法》、《关键目标》的那套东西，主要是强调管理的，各种各样的管理思想都能启发你，实际上并不需要看特别针对软件行业的东西，要看软件行业里的东西我一般比较愿意看失败的案例，就是类似《***软件》那种常见的错误，比如程序员不善于沟通，然后说不是自己错误。人家在七十年代的时候已经把这些总结得特别好了，你会发现过了四十年还是那些问题，你就看那些老的书就会发现这些问题已经存在相当长的时间了，完全没有什么新鲜感。里面刻画的东西都是一样的，具体的问题还是很一样的，可能百分之九十的问题都是书上写过的，不会有太大的差异，只是人不一样、环境也不一样，问题还是差不多的。比如注重质量、需求发散，这些问题都是非常常见的。
记者：看来还是比较大块的问题，而且也不是软件行业专有的，各个行业其实都有这样的问题。
程显峰：但是你看软件行业的大师以前写过这些话就会觉得挺有意思的，当然，你还可以借鉴一些制造业的，我觉得都会帮助很大。
记者：还有管理方面的，只要是这个行业的都适用。
程显峰：其实这个点应该也差不多，我看腾讯的荣昊也做软件管理，他也是什么管理方面的书都看了。如果光看这个方面的话，因为都是需要互相借鉴的，要是想做得比较好的话还是需要看很多东西。确实有些东西大家都太强调了，软件行业的人都特别喜欢强调个性，其实管理的方法通用性还是比较高的。你看德鲁克写的那些书，每一条都是挺实在的，尤其是项目场景非常好。
