◆人员情况:国内大多数的公司都处于一种为了谋生而存在的状态下,有很多技术人员都有三五个月就跳槽的经历。不仅仅是技术人员,往往公司也是这种状态,很多公司就是为了某一个项目而建立的,老板在招聘技术人员的时候,都是往最低限压低技术人员的工资,当一个技术人员对项目了解到一定程度的时候,这个时间往往是在三个月到半年时间之间。半年,或者一年,是一个人最容易发生跳槽行为的时候,因为这个人了解了公司的实质情况,如果老板当时骗了人,那么这个人必然要离开公司;如果老板当时过分地压低了他的收入,那么这时候这个技术人员就希望能够获得加薪等等,除此之外,还有很多很多其他的因素,都会给人带来未知的行为。也可以说,国内很少有 团队成员能够合作达到一年以上的时间。这样的话,第一个项目磨合好了,第二个项目就是在考虑跳槽,第二个项目未结束人就走了,这是我们平时很常见的现象。
这个时候做结对编程,效果就不会那么明显,因为在人员相对成熟的时候,人的心理发生了较大的变化,工作的积极性和配合程度也远远不及刚刚进入公司的时候。那么结对编程在这样的环境下还能进行下去吗?估计不用分析就可以知道了。这时有人会说,如果配合不好,那就换人结对,不一定非要这两个人结对。那这就要从项目组人数说起了。
◆项目组人数:在我所开发过的项目中,大概有不到一半的项目有十个人以上的开发团队。最大的团队开发人员是不到三十人,这二十多人还要分成几个组,每个组也就五六个人而已。在这种情况下,结对的问题就出现了,在组内的你只能和这么三五个人结对,是不是都很容易配合起来呢?这个事情很难说。配合不好怎么办?换人?换项目?还是换公司?当然,如果配合了三个月还配合不好,站在公司的立场上,是肯定要考虑开除掉某人了,至少也要将他降薪或者调离这个项目组,因为公司承担不起这么大的 风险。 项目经理更是在担着风险,因为结对编程的事情老板本来就不太乐意看到,本来老板就有意见,而项目组如果发生了这样配合力度很差的情况,项目经理的处境可能就非常危险了。
综合上面这三个方面的情况,我们可以得到如下的结论:
结对编程在中国这些短小项目过多的情况下是不太适合的!结对编程其实更适合一些相对人员较为稳定的开发环境,否则,三个月的低效率配合时间会让老板将项目经理的脑袋当球踢的。但是,结对编程还是有其好处的,比如,提高项目组的稳定性,当一个人离开后,另外一个人可以很快地将新人带到位,项目组不会因为人员变动而发生较大的风险问题。同时,结对编程提高了 程序员之间的交流,团结了项目组内成员,同时容易形成人月神话中提到的胶冻团队的效果。另外,在三个月后还是有效率提高的情况发生,的确能够带来很好的效益的。
项目组稳定性提高
◆ 表现
在我前面的例子中可以看到,一个模块至少有三个人对他它很熟悉,因此在后面的开发过程中,无论哪个人发生变动,都不会影响这个团队的稳定性,所有的任务都能够很好的延续下来。每一个系统的模块都会至少按照阶段数量(不同的项目会有不同的开发周期,同时也就有不同数量的人会对这个模块十分熟悉)分给不同的人来进行开发。如果和结对编程配合起来使用,则将会使得对同一个模块了解的人数达到一般交换编程的两倍人数。
◆ 分析
有了这样的对每一个模块都很熟悉的人员数量的存在,团队的稳定性就会表现出来,任何一个人的变动或者少数人员的变动都不会对团队和开发进度产生较大的影响。因为随时都可以有其他人来接替这个发生变动的人的全部工作,也很容易培养新人进入到团队内来进行工作。
更适合没有绝对高手的团队
◆ 表现
当团队内没有绝对高手存在时,也就是说,系统的架构设计将是更多的人一同讨论出来的,并在开发过程中不断的修改和调整。