敏捷在程序员团队中的实践与发展现状(1)

无论是在软件或者治理 行业敏捷开发已成为众多高效开发团队的制胜之道。敏捷开发可以说是在开发中面临迅速变化需求中的一种快速开发能力。当然，敏捷不仅是简单的快速，而是在开发过程中短周期的不断改进、提高和调整；当然也不仅仅是一个版本只做几个功能，而主要的是突出重点。

在国外软件企业中，几乎将近半企业是已采纳敏捷方法进行开发，随着近年来受软件外包和外企的带动，敏捷开发在中国也出现了日渐普及的态势，如腾讯，IBM等等内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然，因此，51CTO记者采访了AdMaster（精硕科技）首席布道师程显峰，讲解了敏捷开发在团队中的实践以及进展现状。

以下是相关的采访实录：

敏捷在项目中的实践

记者：有些人认为敏捷开发并不适用于水平一般的程序员或团队，您是怎么认为的？

程显峰：至于敏捷开发是不是用这种程序团队，特别适合训练有素的团队，反过来说，如果不是一个训练有素的团队，实施传统软件工程也会失败，所以我觉得基本的要求是跟原来的一些要求基本一致的，包括沟通能力、协调能力，对于项目变动的操纵 能力都是一样的，包括传统软件开发当中讲的项目可控，整个项目可复制，同样的资源配比还可以复制这个项目，如果原来的项目这些做得比较好的话实施敏捷项目就会容易一些。

记者：很多人为了编写易变更的代码，在采纳敏捷时，抛弃许多习惯用法，由你的经验出发，如何去看待这个问题？

程显峰：从我在实施的过程中第一点需要强调的就是大部分跟传统的软件工程还是一样的，现在异化的部分过于被强调了，搞得大家以为是完全新的、不一样的东西，传统软件包括需求治理 、进入操纵 、质量治理 、测试体系，这些东西在敏捷里也都要体现、都要实施，而且要求可能还会更高，并不是把一些传统的东西抛弃掉了，既没有进入治理 又没有版本操纵 ，几个人一商量就定了敏捷，这是完全的一种误解，而且还是要好的工程基础才能实施。

记者：所以传统的方法对于程序员的要求还是比较高的吧？敏捷这样的功能经过修改之后就可以推出一个小的版本？

程显峰：并不是说推出小版本就要降低难度，这是没有因果关系的，小的版本即使推送上去，如何保证这个小的版本是对的？你也需要大版本的方法，比如软件测试、进入操纵 、需求治理 ，这些东西都得有，你采纳操纵 好它，虽然你推得比较快，看上去可能是一个一个的，如果你要是推的没有章法的话一样也是乱套的，不是你想要的东西，也会造成大量的浪费，我是这么觉得的。对于一个失败的项目就要说出失败的原因，这才是解决失败项目的办法，敏捷的方法不是，这个逻辑就是有问题的，我觉得这个没什么好说的。

记者：对于一个失败的软件项目来说，您认为敏捷方法是它的救星吗？

程显峰：其实我觉得敏捷的方法不是任何失败项目的救星，这是肯定的。至于失败这个事情，看上去可能是分工的原因，深层次可能是不交流、不沟通的原因。敏捷比较注重强调沟通互动这些方面，它是有强调这些东西，如果你的问题恰巧是由于不沟通导致的，采纳了敏捷的方法可能会有极大的改善，但也非常取决于实施的人和分析的效果。好多人说敏捷就是一个筐，什么东西都可以往里面扔，实际上也确实有点这个样子。

我觉得敏捷的方法更多的是注重发现问题的框架，就是能让你更快地发现问题、暴露问题。至于怎么解决问题，原来能解决的就能解决，要是原来解决不掉，谁也帮不了你。如果原来你有沟通问题，但是很长时间才能暴露出来，这个东西能让你在短时间内暴露出来，那么就有助于解决这个问题。很多人为了编写易变更代码采纳敏捷。

记者：想要做到敏捷开发，每个团队都要经历这样一个转型期，那么在转型期还需要每个团队根据自身的不同，找出合理有效的解决方法。你们团队的是如何来解决的？

程显峰：每个团队都要经历一个转型期，我是倾向于比较和气 地对团队进行改进，实施的东西尽量不要让团队有一个明显的转型期，比如版本操纵 ，原来的版本操纵 提交的力度、上线的流程就是这样，我会给大家介绍一个新的系统，但是并不会太影响大家的工作，适应起来又很快，这样的改进效果是比较立竿见影的，而且影响又是很小的，我特别喜欢的改进是这样的，这种改进不是间或一次才会用到的，我特别喜欢这种改进，就是你天天都会用到的，我特别喜欢那种天天都是这么调，但是每天都能省一分钟的。

大家可能都觉得敏捷特别奇妙 ，每天能省百分之二十的时间，现在我还没发现这种现象，我不喜欢这种东西，如果不是特别想省百分之二十的时间的话就不会让大家经历一个转型期，比如你告诉大家一个技巧，每天能省两分钟，这种东西大家天天用的话实际积存 下来的效果才是比较明显的，你要是教给大家一个方法，比如能省二十分钟，实际上这种方法看上去是非常美丽，但它不是什么场景都能用得到，所以我就不太喜欢这样的方法。现在有一部分也不用敏捷，我也不太情愿 教那个部分，就是每天早上例会的时候站在那里说一通。我也跟他们讲过，他们有的话可以，没有也OK，有些东西我的要求就比较死，比如上线的流程、可控性，我在这个方面的要求就比较死，开不开会对于我的项目没有什么影响，但是上线的流程就不一样，我要往回退的话就要花成本。

对于小的团队来讲真的是可有可无的，因为团队的人都坐在一起工作，未必需要一个站到板子上的形式。现在有人把形式看得很重，本来例会是很简单的，五分钟就开完了，但是吵起来了，开不完，因为一般都是开早会，吵完以后心情就不好，所以效率就下来了，这也是很正常的，但是你不要想着美丽的东西，我对美丽的东西感觉都不有用 。

记者：会不会因为不吵这个架把错误带到真正开发的过程中？

程显峰：会，所以我们要让在实际的工作当中发挥，其实例会也不是吵架的会，还有很多的会可以发现这个问题，比如通过Review，可以有各种各样的方法去发现，不用拘泥于这种形式上的东西。其实最难改变的往往是那些小的习惯，比如他就情愿 用这个手指头去敲键盘，但是这可能会影响他的效率，他不情愿 改。这种习惯的话改的阻力反而比较小，你让他去开个例会他觉得耽误时间，但是要让他改这个的话他可能会改。你想他要敲多少？天天可能都要去敲，这种感觉可能是持续的。

记者：这种其实是属于比较个性化的调整，每个人的使用习惯不一样，有些人可能喜欢用这个手按着，有些人喜欢用那个手按着，你要主动发现各个人在工作当中需要调整的地方？

程显峰：我一致认为团队就是一个消灭 个性的过程，而且这一点我是非常讲究的，包括编辑器的使用习惯和配色都有强烈要求，不像别的看上去那么自由，坐在哪里无所谓，但是你用电脑的方式必须是我规定好的。没有一个共同基础的团队根本就不叫有团队，总有一些东西是有共同基础的，而且一些高效的团队很可能所有的东西都是共同基础，就像特种兵出去打仗，一个手势就得去杀人，你还能问这个是什么意思？就像我们用别人的电脑，或者在团队当中用其他人的电脑，那些配色习惯都是一样的，我们沟通交流起来就会非常容易。

现在新人如果不配色，直接就卡掉，新人培训就不合格，所以必须要有配色，包括快捷键的使用，不能人家给你一套代码你还慢吞吞的，这会非常影响别人的心情。因为有些忽悠师天天都去忽悠各种敏捷方法，但又不注重工程实践，不注重观察细节，所以就做不到。他们不会注重这种实践，比如咱俩是木匠，我天天使完的刀子随手一扔，天天你给我收拾，你也不情愿 ，虽然我是大牌，但是你也不情愿 ，这种工作才是能省很多时间的，你说好我也说好，大家都用一个工具箱，这样才能省下很多时间。我就觉得能省时间的话，就是在任何层面上都是节约和幸免浪费的表现，我是这么觉得。