XP的反省-Pair Programming

常常看到论坛上有人讨论PP（Pair Programming）,但是大多是纸上谈兵，书上云的过多。真正谈感受的少。 我在一家做XP的公司做了4年了，从做service到做product, 总的来说pair programming给我带来的的忧大于喜，缺点大于有点。

 

总的来说PP有它的优点，很多researcher也发表了论文，记得比较清楚的一片就是一个大学里面对一个班的学生分组实验，结果用PP的那组效率比较高。 但这毕竟是research, 给我们的启示是PP在某种特定的情况下的结果:

 

1. Pair的人必须对等 （同班同学）

2. Pair的人必须全力以赴 (同学们，老师在做实验哦，不要走神！)

3. Pair的人必须对要解决的问题有相同（或相近）的认知

 

而上面的3点在现实公司里却大部分情况下不能成立。1就不用说了，2，举个例子，如果有一个人生病，或是惦记的其他的事则会screw up整天的进度。3，和1相关，人的水平不同，不可能像大学那样对一个东西的认知近似。

 

我个人的经验是10%的pair时间是高效的pair，其余的则是浪费时间 。

 

另外从人性的角度来讲，pair on everything则是对人性的xx ，强调沟通没有错误，但是工作毕竟是工作，如果天到晚说比写花的时间更多，则有点本末倒置了。我们公司是100% pair, 任何的task，不管有没有必要，都要pair （条件允许的话）, 老板的原则是绝不让任何一个知识点停留在一个人的脑瓜里：）,一个人躺下了，另一个就能补上。 但是从现实的角度来讲，我们的产品的确出现过超过一个developer走了，结果他们经常working的那个module就会没有人能够维护了，结果需要重写。 所以从knowlege spread的角度来说，公司的benifit和情感留人+document, 比pair来的更实惠。

 

另外pair的确剥夺了developer的个人空间 。 以前的公司， 上网灌水，给朋友 MSN, 的小动作全都不行了：（， 也许有人会说这些的东西在公司应该禁止！ 但是现实一点，我来java eye灌水 ， 跟几个圈内的朋友msn讨论心得，是对工作有正面影响的。 而且msn的圈内朋友对于疑难问题的帮助会很大的。

 

而且还有一点最大的就是pair剥夺了自学的时间 ， 没有pair的时候当有东西不会的时候， 对一个问题的研究会刨根结底，但是pair的时候，如果你的partner会，他大概只会给你概括一下，如果你的partner不会，那就会是一个非常有趣的pairing session, 什么google, yahoo, 大部分情况，结果是 this is a fking task that we should never touch as we dont have corrosponding knowlege... 但是如果一个人能够静下心来把问题的来龙去脉搞清楚，把相应的prerequiste的knowlege搞清楚， 问题在得到解决的同时，自己也会得到提高。说白了当两个新手在pair的时候的确很低效，而且不利于“成长”

 

说了这么多， 一句话

少Pair可以怡神，多pair的确伤身， 不pair也能过日子 。

评论

46 楼 protti 2008-07-01  

yh_private 写道

来简单说下我的pair，现在可以说是一个老手一个新手在结对，新手完全可以自己干好所有的事情，他知道需求，老手对需求知道的要少些。
我们每天早上可以拿出时间两个人去读新闻，然后看资料，做点自己喜欢的事情，大概一个小时左右之后我们开始pair，我们并不担心看新闻聊天所浪费的时间，因为我们可以用两个小时的时间去做4个小时所做的事情。
（这并不是说pair可以直接提高编程效率。）
中午休息之后也是一样地。一个小时可以喜欢做什么就做什么

另类情况？？

45 楼 careprad 2008-06-30  

任何企图去除个人效应的目的都是适得其反
微软大概也是这个毛病

44 楼 simenliu2003 2008-06-30  

早就看Xp中提出的结对编程不顺眼了，不过一个写程序，一个写测试还是值得借鉴。

43 楼 Garriot 2008-06-28  

我还是比较赞同PP的，但PP并不是对任何人都合适。
我们公司的一个过程管理的Leader曾经说，XP，包括PP，最适合高度成熟和高度自律的程序员。这句话我非常赞同。
不要让Senior和Junior PP，那是虐待。

一个tutor和我一起解决问题，体验PP的时候，我连走神的想法都没有。。。

42 楼 fangshun 2008-06-28  

什么东西就是思想再好，要是乱用，死用，别有用心的用，那也是垃圾的，结对编程更多引导的是整个团队的高度交流，更透彻的需求分析，程序设计，并非只有两个人才是这个过程的起点和终点！

41 楼 SpitFire 2008-06-27  

引用

1. 如果是solo, 我一天最多工作2-3个小时，其它时间用于update自己的knowlege和research。用于交流（大部分是争论和说服）的时间完全可以节约下来。 而且最大的好处是可以working from home.没有必要一定要去office

2. solo的艺术在于个人时间和工作实践的统一，所以老板不会觉得你在surf internet. 但是pair之外的个人时间，大部分老板还是想不开的(我要去pay那人在天涯上灌水？)。当然你可以argu我是在看技术网站，但是你不能保证其他人就不看风月网站。

1.如果你的工作就是这么安排，有较多的research，那没有问题，你可以每天只pair 2-3个小时，这是你工作性质不同引起的，大多数的开发人员是不可能被boss安排成这样的

2.对于第二点，也是很关键的，敏捷不只是程序员甚至不只是项目经理的事，也是公司管理层面的事情，需要将敏捷的思想传播到公司的每一层并得到他们的理解，也就是要让boss明白让员工每天去天涯灌水1小时(只是个例子)可以提高工作质量。所以敏捷导师的作用就非常巨大， 他需要跟不同的人，进行不同层面的沟通，这也是一个长期的过程。

40 楼 taowen 2008-06-27  

自学和training有帮助,但是和pairing不是替代关系.
对于有的时候不必要pair的问题,同意你的观点.我在工作中,做spike的时候就是solo的.但是做完了spike,做story的时候就一定要pair,因为spike的东西往往是有难度不好弄的东西,不和别人的pair,别人就可能看不懂这块代码.如果你roll off了,这块代码可能就没人敢碰了.于是请假回个家可能都会被同事的电话打扰.

39 楼 emarket 2008-06-27  

好pair容易进行的前提，面试
1。 如果只是pair一两个小时 很难看出来， 而且有些人面试的时候和实际工作中大不相同

2。 我做了4年的XP， 从崇拜，质疑 倒 反对 某些practice.

3。 如果有个人没用过TDD, 我们更应该看他的潜力。

pair进行中的一些实践
1. 如果是solo, 我一天最多工作2-3个小时，其它时间用于update自己的knowlege和research。  用于交流（大部分是争论和说服）的时间完全可以节约下来。 而且最大的好处是可以working from home.没有必要一定要去office

2. solo的艺术在于个人时间和工作实践的统一，所以老板不会觉得你在surf internet. 但是pair之外的个人时间，大部分老板还是想不开的(我要去pay那人在天涯上灌水？)。当然你可以argu我是在看技术网站，但是你不能保证其他人就不看风月网站。

3. 同意

4. 同意, 但是也有一个问题 就是自己给自己找压力，本来一个人学一个东西就可以了，这么一换 就成n个了。 会造成广而不精的后果。 而且还有一个大问题就是如果交换了pair如果有人对某个设计有一个严重分歧的很有可能会推翻重来， 例如 Senior A 和junior B pair on task 1, task 1完工后 Senior A 换取去solo database stuff， Senior C 换来和 junior B 继续pair on task 1的后续task2 这时Senior C觉得task 1简直太stupid乐，这是junior B 因为是个新手，只能一头雾水的follow Senior C 的高论， 我们公司就发生过多起此类事件，结果大家agree on不改变原先设计人的思路 ，这显然更stupid, 有可能错误的东西做完才发现。 最后还是就不了了之了。

引用

好pair容易进行的前提，面试

1.面试如有可能，要pair
2.员工的综合素质要高，个人能力，沟通，合作等，面试时要测量出来，试用期很重要
3.面试时要看重TDD的能力

pair进行中的一些实践
1.提倡合理的休息，一对pair一天4-5小时的有效工作时间是非常高效的
2.每天或每周要有一定的个人时间
3.spike适合pair分头研究，再pair一起解决
4.多进行pair的交换

38 楼 emarket 2008-06-27  

非常同意您的观点，新手和高手的相对性。

但是pair programming 是在干活， 不是在培训（当然有些人也可以把它当作副产品）。  学东西完全可以业余时间学，如果公司要培训 送去上个培训班也行。

自学花一个月的东西 pair能够一周搞定 确实有点夸张。 很多东西如果不能系统的学习 而只是听别人说，很难做到举一反三的。

当然我也不否认和高手pair有画龙点睛的效果，不过自己还得花大力气去画龙才行。

引用

taowen 2 小时前
新手和老手不是一个工作年限上的问题.新手可能是一个有十多年java经验的开发者,但是已开始到一个RoR项目上,他就是一个新手.所以从这个角度再来看,一个项目有非常多的理由不能配备足够的所谓的"高级程序员".想让一个项目从一开始到结束都全部配备水平均等的程序员,是不现实的.从整个产业的角度来讲,每年都有那么多新毕业的学生,他们肯定是需要成长的.pair从我看来无论在项目内还是在整个公司角度,都是最有效的"知识迁移"和"人才培养"的手段.而且,也不光是一个新带老的问题.pair在促进交流,提高团队成员对所有代码的责任感等很多方面都有作用.
任何有过管理实际项目经验的客户,对于这种情况的存在都是知道的.没有谁会天真的要求软件开发公司把他们所有的SA,SE都放在他的项目上.他是付不起那么钱的.因为这样算上软件公司要付出的很多机会成本(一个SA,可能就能带一个新的项目).
表面上来说,成本是增加的.但是这种成本是固有存在的.如果团队或者公司有一个人需要去了解一方面的知识,公司就需要投入成本让他成长.这种成本可以体现为一个人,低效地去自学去提高一两个月.也可以体现为两个人,效率稍低地工作一两个星期.

37 楼 taowen 2008-06-27  

新手和老手不是一个工作年限上的问题.新手可能是一个有十多年java经验的开发者,但是已开始到一个RoR项目上,他就是一个新手.所以从这个角度再来看,一个项目有非常多的理由不能配备足够的所谓的"高级程序员".想让一个项目从一开始到结束都全部配备水平均等的程序员,是不现实的.从整个产业的角度来讲,每年都有那么多新毕业的学生,他们肯定是需要成长的.pair从我看来无论在项目内还是在整个公司角度,都是最有效的"知识迁移"和"人才培养"的手段.而且,也不光是一个新带老的问题.pair在促进交流,提高团队成员对所有代码的责任感等很多方面都有作用.
任何有过管理实际项目经验的客户,对于这种情况的存在都是知道的.没有谁会天真的要求软件开发公司把他们所有的SA,SE都放在他的项目上.他是付不起那么钱的.因为这样算上软件公司要付出的很多机会成本(一个SA,可能就能带一个新的项目).
表面上来说,成本是增加的.但是这种成本是固有存在的.如果团队或者公司有一个人需要去了解一方面的知识,公司就需要投入成本让他成长.这种成本可以体现为一个人,低效地去自学去提高一两个月.也可以体现为两个人,效率稍低地工作一两个星期.

36 楼 szhnet 2008-06-27  

没Pair Programming过 不过很想尝试一下

35 楼 balaschen 2008-06-27  

taowen 写道

pair有很多种形式的.不光是简简单单地分配两个人干同一件事情.比如可以一个人写测试一个人写实现.或者一个人写一个测试,然后接着另外一个人来实现,然后再轮换.不同的方式达到的效果是不同的.实际工作中,比较多的情况是高低搭配.一个老手带一个新手.这种时候比较适合老手写测试,新手写实现.然后等新手实现好了之后,老手再指出设计中可以改进的地方,这个时候来演示如何去用重构来改进设计.
这个过程是不是一个很高效的实现功能的过程?当然不是.如果不带pair,那个老手可以以两倍甚至三倍的效率来工作.但是这样的team就没法发展.老手永远没有机会roll off.公司的员工也没有成长.
有的时候,客户指定只买一个人,不买一个pair.后期就发现,那一块东西别人都不知道,出了什么问题都得打电话问以前做的那个人.

那么从短期看，pair增加了公司的成本？

34 楼 SpitFire 2008-06-27  

好pair容易进行的前提，面试

1.面试如有可能，要pair
2.员工的综合素质要高，个人能力，沟通，合作等，面试时要测量出来，试用期很重要
3.面试时要看重TDD的能力

pair进行中的一些实践
1.提倡合理的休息，一对pair一天4-5小时的有效工作时间是非常高效的
2.每天或每周要有一定的个人时间
3.spike适合pair分头研究，再pair一起解决
4.多进行pair的交换

33 楼 andyhu1007 2008-06-26  

likeblood 写道

鼓掌，xp让人精神紧张，这样的情况不利于喜欢宽松环境的程序员，至少我是如此
轻松的环境才能高效，我现在一周的工作往往2－3天就完成，剩下的时间可以来这里灌水

轻松的环境还是可以偷懒的环境？

32 楼 javavsnet 2008-06-26  

taowen 写道

pair有很多种形式的.不光是简简单单地分配两个人干同一件事情.比如可以一个人写测试一个人写实现.或者一个人写一个测试,然后接着另外一个人来实现,然后再轮换.不同的方式达到的效果是不同的.实际工作中,比较多的情况是高低搭配.一个老手带一个新手.这种时候比较适合老手写测试,新手写实现.然后等新手实现好了之后,老手再指出设计中可以改进的地方,这个时候来演示如何去用重构来改进设计.
这个过程是不是一个很高效的实现功能的过程?当然不是.如果不带pair,那个老手可以以两倍甚至三倍的效率来工作.但是这样的team就没法发展.老手永远没有机会roll off.公司的员工也没有成长.
有的时候,客户指定只买一个人,不买一个pair.后期就发现,那一块东西别人都不知道,出了什么问题都得打电话问以前做的那个人.

客户只给一个高级工程师的钱，哪位的公司可以加一个初级的去高低搭配？初级的预算哪个部门出？
这种高低搭配对于软件公司本身有利，拿客户的钱培训自己的低手，对于客户并不合适。
后期的事情当然还是由软件公司负责，你工程师换项目、调动岗位都必须对当前的客户负责，不是你说换就换的，换的过程中，交接的成本肯定由软件公司出，没听说过由客户出的，后期出了问题当然还是要软件公司负责。没听说过没有买pair，然后人员调动了，让客户出额外的成本。如果客户出了，那就是公司的销售太强了。

31 楼 emarket 2008-06-26  

daquan198163 写道

emarket 写道

，但如果把pair programming作为公司的一种制度，不分场合的应用例如
1. 高手与低手
2. 两个低手
3. branding work
4. 需要研究的例如 spike
5. 两个人有严重分歧的
6. 有个人生病的，
7. 有严重走神的

1、可以让低手更快成为高手
2、两个低手也互有长短，共同提高，好过一个人闷头做事没进展
3、4没看出有啥特别的，研究型的工作反而更需要有个人多讨论
5、如果不是在结对，其中一个人的错误就不会暴露
6、换个结对的伙伴，其实即便没人生病也应该经常换的
7、PP只会减少这种状况

1. 代价太高， 让低手回家自学（剥削一下 ：） ） 早上来了点拨一下会比较好，如果遇到个迂腐的，怎么pair都没用
2. 闷头做事不提倡，不过更反对两个人闷头做事
3. 两个人写html， 着色， css... 好在我们公司对于这种工作已经不pair了
4. 研究工作有了眉目才适合讨论， 否则只能纸上谈兵， 瞎扯
5. 分歧不一定就是错误，也可能两个人都对呢。
6. 生病的容易传染，令我我特受不了不洗澡，口臭，身上有怪味的 pair
7. 要命的是pair的时候navigator走神， 有人就是这样， drive的时候很精神， navigate的时候打瞌睡。 我遇到过一两个，不过不是很普遍。

30 楼 emarket 2008-06-26  

新手的悟性很重要，有些人怎么pair都提高不要， 有些人只要稍微点拨就能精通 （有点宿命论了，不过大概意思就是这个）。 如果照你所说如果新手会很快成长为老手，那有为什么 ‘实际工作中,比较多的情况是高低搭配’

'那一块东西别人都不知道,出了什么问题都得打电话问以前做的那个人.' 这恰恰说明了必要的文档的重要性，不过XP的简单设计原则 应该很少会造成这种情况的发生

引用

pair有很多种形式的.不光是简简单单地分配两个人干同一件事情.比如可以一个人写测试一个人写实现.或者一个人写一个测试,然后接着另外一个人来实现,然后再轮换.不同的方式达到的效果是不同的.实际工作中,比较多的情况是高低搭配.一个老手带一个新手.这种时候比较适合老手写测试,新手写实现.然后等新手实现好了之后,老手再指出设计中可以改进的地方,这个时候来演示如何去用重构来改进设计.
这个过程是不是一个很高效的实现功能的过程?当然不是.如果不带pair,那个老手可以以两倍甚至三倍的效率来工作.但是这样的team就没法发展.老手永远没有机会roll off.公司的员工也没有成长.
有的时候,客户指定只买一个人,不买一个pair.后期就发现,那一块东西别人都不知道,出了什么问题都得打电话问以前做的那个人.
atusoft 16 小时前

29 楼 emarket 2008-06-26  

用两个小时做4个小时的事，说法有点夸张 （我只你把它归结到pair programming），刚才还有个朋友说如果老手不合和新手pair会以2-3倍的速度完成task。 一般的用XP的公司都没有说8个小时pair的， 6-7个小时属于普遍。不过我很难赞成你们用用两个小时的时间去做4个小时所做的事情是pair programming的结果。

假设 A和B, 分别完成task1, task2, 需要 4小时， 也就是 8 man hour. 但是你们如果pair了2小时完工， 需要4 man  hour. task1从原来的4 小时 （4 man hour）缩减到 1 pair小时 （2 man hour）. 也就是说pair可以从某种角度提高工作效率by 75%  我个人觉得不大可能，人的因素肯定占很大比例。

我们公司还有个有趣的现象就是有一个iteration我们发现我们的velocity突然提高，最后究其原因 那周我们没怎么pair...



其实我想在我公司提倡的恰恰和你相反，早上大家来了先pair一个小时，然后该干么干什么去， 如果意犹未尽，可以继续，但是下午最好不要再pair了。

引用

来简单说下我的pair，现在可以说是一个老手一个新手在结对，新手完全可以自己干好所有的事情，他知道需求，老手对需求知道的要少些。
我们每天早上可以拿出时间两个人去读新闻，然后看资料，做点自己喜欢的事情，大概一个小时左右之后我们开始pair，我们并不担心看新闻聊天所浪费的时间，因为我们可以用两个小时的时间去做4个小时所做的事情。
（这并不是说pair可以直接提高编程效率。）
中午休息之后也是一样地。一个小时可以喜欢做什么就做什么

28 楼 yh_private 2008-06-26  

来简单说下我的pair，现在可以说是一个老手一个新手在结对，新手完全可以自己干好所有的事情，他知道需求，老手对需求知道的要少些。
我们每天早上可以拿出时间两个人去读新闻，然后看资料，做点自己喜欢的事情，大概一个小时左右之后我们开始pair，我们并不担心看新闻聊天所浪费的时间，因为我们可以用两个小时的时间去做4个小时所做的事情。
（这并不是说pair可以直接提高编程效率。）
中午休息之后也是一样地。一个小时可以喜欢做什么就做什么

27 楼 likeblood 2008-06-26  

鼓掌，xp让人精神紧张，这样的情况不利于喜欢宽松环境的程序员，至少我是如此
轻松的环境才能高效，我现在一周的工作往往2－3天就完成，剩下的时间可以来这里灌水