[项目管理]交换编程的最初文档

交换编程

1. 交换编程

在软件工程的开发方法中，有很多很著名也很有效果的开发方法，诸如原型、迭代、敏捷、RUP等。在谈到交换编程的概念之前，我们应该首先提一下敏捷开发方法中的结对编程的概念。

 

1.1      结对编程

 “结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计。同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处．只是这些好处必须经过缜密的思考和计划才能真正体现出来。”

——以上内容引自《结对编程技术》，原名为《Pair Programming Illuminated》，作者：（美）Laurie Williams, Robert Kessler。

 

下面我们分析一下结对编程的特点。

结对编程在很多项目中得到应用，也作为XP一个非常著名的观点和做法被很多人大为推崇。

结对编程是两个人同时做同一件事情的一种方法。表现上，会给人一种浪费一个开发人员的感觉，实质上，这的确是可以提升效率的。

同样的这个做法，我在2002年在上海进行的一个类ERP项目中用过一次，当时在我做完权限系统的全部功能后，和一个弟兄合作了一个模块，我们两个人只用了三四天时间，就完成了这个新的模块的全部功能，这相对于我们此前做的功能模块来说，时间不到那些模块开发时间的十分之一。

 

1.2      交换编程

交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅在软件项目中可以应用，同样的事情也可以在其他研究开发型项目中得到应用。

 

这是一种更容易被人们接受的方法，在后面本文会做更详细的分析，这里只是提出它与结对编程的不同之处在于：它仍然采用传统的一人一机的开发方式。

因此，它不会给人一种浪费开发人员的感觉，这种方式在2002年底到2003年间的项目中我进行了实际的操作。当时也只是基于团队稳定和一种对于结对编程不被理解而不可实施的冲动才这样做的一种试验。

1.2.1 引入原因

在传统的开发过程中，往往是一个人从一个模块的需求开始，然后作分析、设计、编码、单元测试，然后才会交给第二个人（专职测试人员进行其他测试项目），这样的开发过程会因为开发人员的变动而产生较大的影响。

而同时，结对编程的方式，对于开发人员人手严重不足的项目中，领导是不认可这种组织方式的，他们认为这会浪费很多的人力，一加一未必大于二。

而在当时引入这个方法的项目状况如下：

这是电信MSS系统的核心业务系统部分，包括了规划、设计、施工、验收、财务、合同等多个重要环节和多个部门的业务。

开发人员数量较少，人员技能较为均衡，没有水平超出其他人过多的技术人员。这个项目在最初评估的开发周期就是第一个版本在五个月内完成，而整个项目是至少要做上一年以上的，而最后的实际情况是，这个项目随着不断的升级和调整一直开发了三年多。

最初的开发团队是十一个人，后来扩展到二十三个人，主要开发人员总数为十六个人，其中有四个人技术水平相对较高，另外的七个人技术水平相对较低但是也都有三年多的实际项目开发经验，其中有三个是我2001年带的三个应届毕业生。

1.2.2 引入实施

由于开发团队中没有技术水平超出其他人很多的人员存在，因此技术方案的论证过程都是在大家的共同讨论中制定下来的，只是在团队整体控制上，当时我有相对较强的发言权，因此，在权衡了整个项目的实际情况后，我在需求工作完成后，告诉弟兄们一件事情，第二阶段设计模型的开发大家交换来做。

刚开始很多弟兄不理解，因为相对而言我的开发经验比其他人多了几年，所以，当时我说的一些话，兄弟们还可以接受，于是，我就直接要求大家按照我的计划进行执行。

在设计模型开发完成后，我再次要求大家进行了一次交换。

两次交换完成后，我保证了每一个模块都有至少两个人对这个模块十分熟悉，一方面不会因为人员的变动造成团队的不稳定（这一点考虑相对较少，因为当时的团队合作时间是比较长的，大家十分熟悉和互相都很了解），另一方面保证每一个模块的开发人员都能找到人进行讨论，这增加了团队内的沟通，方便了协调工作的进行。

因此在那个团队的开发过程中，我们经常是大呼小叫，十分热闹，我们这个团队无论走到哪里，都是十分热闹的场景。所以，这也方便了一些新的开发方法的引入，和过程的实施考虑。

1.2.3 实施效果

由于项目没有进行实际数据的度量对比，本文也无法从量化的数据上来说明问题，只能通过一些具体的事实来进行说明和验证。

当时这个项目的模块从7个扩展到了11个，人员数量从11人扩展到了23人，我们在七个月内满足了南方11家省级电信公司和集团公司的基本业务需求，从2003年4月到2003年12月期间，基本上完成了这些省公司版本的二次定制开发任务。

 

1.3      操作建议

交换编程中的操作会与其他过程有较大的差异，根据小子的经验，建议在软件工程实施的各个阶段按照如下的方式进行：

需求工程，需求调研和需求分析进行轮流交换，轮流交换至少是三个以上的人进行互换，不是两两互换。

概要设计（分析模型）开发中，需求分析到概要设计也进行轮流交换。

详细设计（设计模型）开发中，概要设计到详细设计再进行一次轮流交换。

编码实施启动后，详细设计到编码的交换采用两两交换，注意这个时候不再采用轮流交换了。

 

1.4      操作建议分析

在编码以前全部采用轮流交换的目的就是为了让更多的人了解项目进展的全部内容，有利于增加团队内的交流，使更多的人对项目所开发的内容熟悉，并能让他们提出自己的观点。也有利于使更多的人从更多的角度来研究某个系统模块所需要实现的功能和用户需要解决的实际问题，不会因为某个人的定式思维而出现理解偏差造成对需求的理解不到位。

详细设计到编码的交换采用两两交换，这是因为前期需求已经基本上都稳定下来了，这时候不需要对用户需求进行更多方面的理解，只需要进行实施，并进行纯粹的编码工作。这时候作轮流交换就不存在任何意义了，相反只能影响开发进度。

 

2. 优劣分析

这里所提到的优势都是和具体的开发方法相关联的，大部分是相对于XP方法中的结对编程，同时也会分析它与传统开发方式间的优劣。

 

2.1      开发时间“浪费”不明显

1)     表现

这个开发时间“浪费”不明显是相对于结对编程与传统开发模式而言的。至少让老板没有感觉到人员分配方式带来了人员的浪费。

结对编程，大家都知道，需要两个人共用一台计算机，一套键盘，做同一个故事。这样的开发方式往往会给人感觉浪费了一个人，虽然事实上未必如此，但是如果哪个项目经理第一次甚至说前几次这样做，估计大多数老板都会表示反对的，因为他会感觉自己的技术人员只有一个人在做事情。

同样，在2006年的敏捷中国开发者大会上，ThoughtWorks的总经理也提到了这个问题，他的解释是这样的：当两个人合作三个月以上，则效率会超过两个人单独编程的效率！

注意：这里有一个时间前提——三个月以上。

三个月这个时间未必是真实确凿的时间分界线，它只是一个模糊的大概的时间范畴，如果两个人配合的好，也许只需要两个多月，如果配合不好，也许需要四五个月的时间，或者更长的时间……

我相信这样的说法连Martin也不会反对的。

从这个时间界限上，大家可以看看国内公司的项目状况，然后再继续我们的讨论。

2)     分析

①    项目情况

国内很少有时间限度较长的项目，大多数项目都是在三个月到半年时间内结束的。有些甚至只有一个月。

这样的时间特性，将使得这个三个月的期限变成了一句空谈，也就是说，当两个人磨合好了的时候，项目已经结束了。

这时候，有人会说，下一个项目还可以继续合作呀，好，那我们来看看国内项目团队的人员变动情况，然后再继续。

②    人员情况

国内大多数的公司都处于一种为了谋生而存在的状态下，有很多技术人员都有三五个月就跳槽的经历。

不仅仅是技术人员，往往公司也是这种状态，很多公司就是为了某一个项目而建立的，老板在招聘技术人员的时候，都是往最低限压低技术人员的工资，当一个技术人员对项目了解到一定程度的时候，这个时间往往是在三个月到半年时间之间。

半年，或者一年，是一个人最容易发生跳槽行为的时候，因为这个人了解了公司的实质情况，如果老板当时骗了人，那么这个人必然要离开公司；如果老板当时过分的压低了他的工资收入，那么这时候这个技术人员就希望能够获得加薪……除此之外，还有很多很多其他的因素，都会给人带来未知的行为。

也可以说，国内很少有团队成员能够合作时间达到一年以上。

这样的话，第一个项目磨合好了，第二个项目就是在考虑跳槽，第二个项目未结束，人就走了，这是我们平时很常见的现象。

这个时候做结对编程，效果就不会那么明显，因为在人员相对成熟的时候，人的心理发生了较大的变化，工作的积极性和配合程度也远远不及刚刚进入公司的时候。

那么结对编程在这样的环境下还能进行下去么？大家不用分析就可以知道了。

有人说，如果配合不好，那就换人结对，不一定非要这两个人结对。这就要从项目组人数说起了。

 

③    项目组人数

在我所开发过的项目中，大概有不到一半的项目有十个人以上的开发团队。最大的团队开发人员是不到三十人，这二十多人还要分成几个组，每个组也就五六个人而已。

在这种情况下，结对的问题就出现了，在组内的你只能和这么三五个人结对，是不是都很容易配合起来呢？这个事情很难说。

配合不好怎么办？换人？换项目？还是换公司？当然，如果配合了三个月还配合不好，站在公司的立场上，是肯定要考虑开除掉某人了，至少也要将他降薪或者调离这个项目组，因为公司承担不起这么大的风险，项目经理更是在担着风险，因为结对编程的事情老板本来就不太乐意看到，本来老板就有意见，而项目组如果发生了这样的配合力度很差的情况，项目经理的处境可能就非常危险了。

 

综合上面这三个方面的情况，我们可以得到如下的结论：

结对编程在中国这些短小项目过多的情况下是不太适合的！结对编程其实更适合一些相对人员较为稳定的开发环境，否则，三个月的低效率配合时间会让老板将项目经理的脑袋当球踢的。

但是，结对编程还是有其好处的，比如，提高项目组的稳定性，当一个人离开后，另外一个人可以很快地将新人带到位，项目组不会因为人员变动而发生较大的风险问题。

同时，结对编程提高了程序员之间的交流，团结了项目组内成员，同时容易形成人月神话中提到的胶冻团队的效果。

另外，在三个月后还是有效率提高的情况发生，的确能够带来很好的效益的。

这时候，交换编程就带来了很好的效果，一则，没有老板担心的两个人做一件事情的风险，同时，增加了项目组内成员的沟通交流，也提高了团队的稳定性。

那这个问题如何解决？这里，我们不妨来看看交换编程是如何提高项目组稳定性的。

 

2.2      项目组稳定性提高

1)     表现

在我前面的例子中可以看到，一个模块至少有三个人对他很熟悉，因此在后面的开发过程中，无论哪个人发生变动，都不会影响这个团队的稳定性，所有的任务都能够很好的延续下来。

每一个系统的模块都会至少按照阶段数量（不同的项目会有不同的开发周期，同时也就有不同数量的人会对这个模块十分熟悉）分给不同的人来进行开发。

如果和结对编程配合起来使用，则将会使得对同一个模块了解的人数达到一般交换编程的两倍人数。

 

2)     分析

有了这样的对每一个模块都很熟悉的人员数量的存在，团队的稳定性就会表现出来，任何一个人的变动，或者少数人员的变动都不会对团队和开发进度产生较大的影响。

因为随时都可以有其他人来接替这个发生变动的人的全部工作，也很容易培养新人进入到团队内来进行工作。

 

2.3      团队内没有绝对高手时交换编程更适合

1)     表现

当团队内没有绝对高手存在时，也就是说，系统的架构设计将是更多的人一同讨论出来的，并在开发过程中不断的修改和调整。

 

2)     分析

没有绝对高手存在，系统架构设计就不能够在系统进行分析设计前完成，而同时架构的不稳定，就无法更好的安排任务计划和制定故事，这些都会影响到整个系统的开发进度和过程，同时，敏捷编程所倡导的很多做法就无法在这个大前提下来进行实施。

国外能够很好的采用敏捷的做法来实施项目的一个原因是，他们有很多工作在一二十年经验的开发人员，这些人员的经验积累是非常重要的，他们可以更好的在项目开始的前期对项目进行整体的控制和把握，同时做好项目计划，制定好任务故事，而这一点，在国内，尤其是中国的软件公司中还不具备这个条件，因此，很多项目我们都处于的状态类似于我前面所举的电信项目的团队情况，甚至情况比那个团队还要差得很多。

 

2.4      团队内交流增加

1)     表现

前面已经提到：“因此在那个团队的开发过程中，我们经常是大呼小叫，十分热闹，我们这个团队无论走到哪里，都是十分热闹的场景。”

这种频繁的交流，无形中使得团队的凝聚力提高，相互之间的关系和合作也都更为密切。

 

2)     分析

如果是一个人从头到尾开发一个模块，他就几乎不需要和团队内非管理人员进行交流，甚至在某些情况下他只需要和客户做好沟通就足够了。而这时候，及时进行了同行评审，这个技术人员也可能会认为：那么两三天的时间，这些人不可能了解这个系统模块的内容。这种评审也就容易流于形式而无法得到真正的重视。其他人也会认为评审是浪费自己的开发时间，于是评审到了一定程度就会成为可有可无的状态。

如果有较多的人参与了这个模块的前后期分析和开发，每一个阶段，都可以找到别人来进行讨论，同时，在评审时，对这些人提出的意见也就更容易接受——因为他至少会认为这几个人比他更早的介入这个模块的分析，在某些程度上会比自己了解的更为深入。

 

3. 深入讨论

交换编程的应用方式是有其适用环境的，另外，在小子的实践和研究中，小子还要建议如果团队合适，可以考虑与结对编程配合使用。

 

1)     适用环境

这种开发方法的适应性较强，这里分为团队状况和项目情况两个部分进行一些说明。

 

①    团队状况

交换编程适用于人数超过两个人的开发团队，因为交换一次至少也需要两个开发人员。

大的团队也可以应用交换编程的方式，来进行项目开发。

要求团队内的成员有一两个具有两三年以上开发经验的，就可以采用这种方法进行团队开发——而对于一般的项目，哪怕没有什么技术难度，这也是最最近本的人员技能要求了。

 

②    项目情况

项目规模不限，开发周期的适应性也较强，对于任何类型的项目都可以适用。

 

2)     与结对编程配合使用

如果领导比较认可结对编程的开发方式，这个时候，您引入交换编程也会带来同样的好处：

①    团队稳定性：

至少有一点，团队的稳定性从对系统业务模块熟悉的人数上来看，增加了一倍。

②    团队凝聚力：

团队成员之间的交流会更为频繁，这样就会更多的降低因为少数人的思想和考虑偏差造成对用户需求理解不足等问题。

 

有了上述的情况表现，也使得团队的规范化操作能力更强，也可以使得很多问题能够在有效的沟通中的到解决。

 

4. 综述

由此可见，交换编程的存在是有其道理的，没有用过的朋友，不妨尝试一下，至少对您的团队没有什么伤害和大的变动，可以逐渐推进。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/257598/viewspace-165677/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/257598/viewspace-165677/