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也能过日子 。

评论

66 楼 gurudk 2008-12-03  

问题转化为，你能够识别90%不合适的pair，或者避免其中的一部分。

65 楼 daquan198163 2008-08-17  

敏捷质疑: 结对编程, 代码集体所有权

64 楼 Rossalee 2008-08-17  

我没有PP过，但我却一直认为，如果真让我在一个两人共一台计算机的公司工作，而且在工作时间一直有人要盯着我的公司工作。
那我的反应就是“给多少钱请我，我也不去”

63 楼 icewubin 2008-07-18  

emarket 写道

to icewubin  好像引用的多 javaeye特慢：
1. 如果新人的悟性比较高，而又好学，恰当的应用pair应该是一种不错的方案，不过任何的学习过程都需要时间消化。我的经验，整天用pair去完整一个story的过程无意于填鸭，而如果能够在pair的时候画龙点睛一下,剩下的自己摸索。
2. agree
3. 如果某个新人需要经常需要救火，说明他的performance不行，很容易早早地让他走人，但是pair的时候如果东西没有做好，比较难辨是非，我们公司曾经有一个家伙，一年以后我才在几次pair的过程中觉得他思路不清，不过已经过了试用期很难让他走了。（头三个月此人跟我pair了几次，不过当时觉得有可能是新环境所以没太注意，因为和别人pair, 反正task几乎都按时完成了,所以也没有怎么露馅。个人觉得pair的环境下很容易混水摸鱼） 有人会说peer review干什么去了，注意，office的环境下说别人的好话很容易，坏话一定要有根据，例如 "xxx, 跟我pair, 结果东西没做完.."---难道你不用负责吗？。"xxx的code skill 比较差，你看这段，简直。。。" ---是不是和你pair的呀？俄

4. 所以我说pair不够人性化，我从4年前开始做XP, 发现知识的增长速度明显慢于以前的公司，虽然那时整天msn 不过我个人也都是比较自觉地，除了每天早上看sohu新闻20分钟，其他时间在公司所谈所看的都是和技术相关的，而现在只要一不pair,就上mitbbs, wenxuecity 堕落呀：） 究其原因，1.以前会好学些，2,时间可以自己支配，3,如果自己愿意，完全可以看一天和工作无关的技术，只要deadline前交工就可以了 （当然免不了有时候要加班赶工）。 一个宽松的工作环境是双赢的。
如果非要拿solo的话msn qq会聊八卦， 其实pair的时候更方便，俩人跟进了，直接聊天唠嗑得我也不是没见过。 如果在遇到一个ppmm (不过我生平还没遇到过) , WSN可能连口水都留下来了。每天standard up可能都要争了... 说远了，不过我们是不是可以讨论一下ppmm对pp的影响以后——：）

1.先前说了，当然不用整天pair，大部分时间是在工作而不是培训，只是利用完成任务的过程达到另一种高效培训的效果，主次不能颠倒。

3.呵呵，我说的救火不是那个意思，在很多小公司，救火专指其他项目因为缺人或者赶时间，紧急抽调人头离开项目前去“救火”，不是你理解的那个意思，主要是指人员被抽调的风险。

你说的评价体系问题和pair本身没有关系，是公司评价体系或者说考核评估体系决定的，合理的考核体系能够适当避开你说的那些问题。

4.一方面，不是所有人都和你一样自觉，很多人上了MSN和QQ，自己在不知不觉中就大大降低了自己的有效工作时间效率。一个电话或者MSN、QQ对话直接或间接浪费被“骚扰”人15分钟。

另一方面，我觉得，我每次对新人说一遍对我来说很陈旧的“知识”的时候，对我自己而言，也是有提高的，既提高了自身知识体系结构的清晰程度，有提高了自身的表达能力。

批发一下别人的话：“知识三境界，你掌握知识->你能很清晰地说出你掌握的部分->你能很快的让别人理解你掌握的知识”，表达和沟通能力、和形形色色的人的沟通能力都是很重要的。

所以要有share的精神，不要认为和一废才pair就是浪费时间，带废才也是对自己能力的一种提高，另一方面来讲，你要往领导岗位走（技术总监类的位子一样是领导岗位），必须要学会如何处理各种能力的关系，充分调动手下各种水平的人的能力，这些能力也能在和废才pair的时候得到一定的锻炼。

开个玩笑，如果新人个个悟性极高，将来还不爬到你头上？

大部分人不是在google工作，公司里的总会有很多普通程序员，那些新人不管能力高低都有可能将来是你的下属，从大局上来讲，用人是要讲性价比的，如果一个新人悟性不高，要求工资比较偏低，RP还不错，是应该适当的用一些高效的办法培养和培训，而且这样的人也相对的留得住。

62 楼 javavsnet 2008-07-18  

emarket 写道

to icewubin  好像引用的多 javaeye特慢：
1. 如果新人的悟性比较高，而又好学，恰当的应用pair应该是一种不错的方案，不过任何的学习过程都需要时间消化。我的经验，整天用pair去完整一个story的过程无意于填鸭，而如果能够在pair的时候画龙点睛一下,剩下的自己摸索。
2. agree
3. 如果某个新人需要经常需要救火，说明他的performance不行，很容易早早地让他走人，但是pair的时候如果东西没有做好，比较难辨是非，我们公司曾经有一个家伙，一年以后我才在几次pair的过程中觉得他思路不清，不过已经过了试用期很难让他走了。（头三个月此人跟我pair了几次，不过当时觉得有可能是新环境所以没太注意，因为和别人pair, 反正task几乎都按时完成了,所以也没有怎么露馅。个人觉得pair的环境下很容易混水摸鱼） 有人会说peer review干什么去了，注意，office的环境下说别人的好话很容易，坏话一定要有根据，例如 "xxx, 跟我pair, 结果东西没做完.."---难道你不用负责吗？。"xxx的code skill 比较差，你看这段，简直。。。" ---是不是和你pair的呀？俄

4. 所以我说pair不够人性化，我从4年前开始做XP, 发现知识的增长速度明显慢于以前的公司，虽然那时整天msn 不过我个人也都是比较自觉地，除了每天早上看sohu新闻20分钟，其他时间在公司所谈所看的都是和技术相关的，而现在只要一不pair,就上mitbbs, wenxuecity 堕落呀：） 究其原因，1.以前会好学些，2,时间可以自己支配，3,如果自己愿意，完全可以看一天和工作无关的技术，只要deadline前交工就可以了 （当然免不了有时候要加班赶工）。 一个宽松的工作环境是双赢的。
如果非要拿solo的话msn qq会聊八卦， 其实pair的时候更方便，俩人跟进了，直接聊天唠嗑得我也不是没见过。 如果在遇到一个ppmm (不过我生平还没遇到过) , WSN可能连口水都留下来了。每天standard up可能都要争了... 说远了，不过我们是不是可以讨论一下ppmm对pp的影响以后——：）

pair时候难免会有浑水摸鱼的，这和公司文化有关，xp本身解决不了吧。
比如高低搭配，如果是那个高的其实是水货，但是在公司年头长了，低的不太可能去揭露那个高的是水货，他不敢说。如果低的是水货，那高的可以跟别人说低的水平差，别人会相信。
如果是同水平的搭配，其中一个很水，另外一个也不一定能够揭露他。因为东西是两个人做，你说他差，别人觉得你的team精神不够。

61 楼 emarket 2008-07-17  

60 楼 emarket 2008-07-17  

to icewubin  好像引用的多 javaeye特慢：
1. 如果新人的悟性比较高，而又好学，恰当的应用pair应该是一种不错的方案，不过任何的学习过程都需要时间消化。我的经验，整天用pair去完整一个story的过程无意于填鸭，而如果能够在pair的时候画龙点睛一下,剩下的自己摸索。
2. agree
3. 如果某个新人需要经常需要救火，说明他的performance不行，很容易早早地让他走人，但是pair的时候如果东西没有做好，比较难辨是非，我们公司曾经有一个家伙，一年以后我才在几次pair的过程中觉得他思路不清，不过已经过了试用期很难让他走了。（头三个月此人跟我pair了几次，不过当时觉得有可能是新环境所以没太注意，因为和别人pair, 反正task几乎都按时完成了,所以也没有怎么露馅。个人觉得pair的环境下很容易混水摸鱼） 有人会说peer review干什么去了，注意，office的环境下说别人的好话很容易，坏话一定要有根据，例如 "xxx, 跟我pair, 结果东西没做完.."---难道你不用负责吗？。"xxx的code skill 比较差，你看这段，简直。。。" ---是不是和你pair的呀？俄

4. 所以我说pair不够人性化，我从4年前开始做XP, 发现知识的增长速度明显慢于以前的公司，虽然那时整天msn 不过我个人也都是比较自觉地，除了每天早上看sohu新闻20分钟，其他时间在公司所谈所看的都是和技术相关的，而现在只要一不pair,就上mitbbs, wenxuecity 堕落呀：） 究其原因，1.以前会好学些，2,时间可以自己支配，3,如果自己愿意，完全可以看一天和工作无关的技术，只要deadline前交工就可以了 （当然免不了有时候要加班赶工）。 一个宽松的工作环境是双赢的。
如果非要拿solo的话msn qq会聊八卦， 其实pair的时候更方便，俩人跟进了，直接聊天唠嗑得我也不是没见过。 如果在遇到一个ppmm (不过我生平还没遇到过) , WSN可能连口水都留下来了。每天standard up可能都要争了... 说远了，不过我们是不是可以讨论一下ppmm对pp的影响以后——：）

59 楼 icewubin 2008-07-14  

emarket 写道

icewubin 写道

emarket 写道

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

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

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

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

引用

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

自学的东西当然有，这些东西一般情况下，只能是个人下班回家自己学去，除非是没有项目或者是公司专门的培训。

一般讨论的当然是这些学习不能解决的问题，否则要工作经验干吗？这类的学习必须是工作中才能掌握的。

既然是工作中才能掌握的，pair的方式就是效率极高的一种带新人的方式。

“工作中才能掌握的“ 不能推出 “pair的方式就是效率极高的一种带新人的方式“
1. pair是一对一 效率显然低于一对多
2. pair的时候高手的思路 （解决问题） 明显别于 培训的时候的老师的 思路 （传道授业）。
3. 代新人的成本不能bill给customer.

1.应该说是不特别占用时间的情况下，结合实际项目的一种带新人的方式，同时能完成工作任务，不需要以后太多的交接和沟通成本。这个效率极高，是这样的出来的。

2.刚才说过了，和特别的一对多的培训是不能比的，不是那种不完成生产任务的培训时间。
3.没有说要把带新人的成本bill给customer。现实是很多项目一般都是1老带1-3新，或者2老带2-5新，以此类推。很有可能的一种状态是，为了“快速”完成项目，分配好任务以后，各管各。结果，代码风格多达3种以上，新人不断的问老员工问题（也顺带打断老员工的思路，一打断就直接加间接浪费老员工15分钟，这是有科学依据的），某个新人或者老人因为“救火”或者离职导致巨大的交接成本，还因为代码风格不一致，之后接手的人如同落至地狱（还会蹦出“与其让我改这垃圾代码，不如让我重写”的让项目经理发毛的语录），等等，鲜活的例子太多了，请问这些不用customer付账么？国内的情况来说一般customer才不管呢，多半就是项目延期而已，付账的是公司自己啊。

4.说的直白点，在软件过程管理非常不规范的国内公司；在大部分人非常不喜欢写文档，写了也懒的积极更新的国内程序员；在国内程序员大部分会不自觉的上QQ、MSN聊八卦等等情况下，结对还是效益不错的。当然啦，没必要8小时结对嘛，开个玩笑，如果真的8小时结对，还能省一台电脑的成本和电费。

58 楼 emarket 2008-07-14  

icewubin 写道

emarket 写道

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

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

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

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

引用

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

自学的东西当然有，这些东西一般情况下，只能是个人下班回家自己学去，除非是没有项目或者是公司专门的培训。

一般讨论的当然是这些学习不能解决的问题，否则要工作经验干吗？这类的学习必须是工作中才能掌握的。

既然是工作中才能掌握的，pair的方式就是效率极高的一种带新人的方式。

“工作中才能掌握的“ 不能推出 “pair的方式就是效率极高的一种带新人的方式“
1. pair是一对一 效率显然低于一对多
2. pair的时候高手的思路 （解决问题） 明显别于 培训的时候的老师的 思路 （传道授业）。
3. 代新人的成本不能bill给customer.

57 楼 emarket 2008-07-14  

icewubin 写道

emarket 写道

另外有时候两个绝顶高手pair也会有问题,首先从benefit来讲，不大，TDD, refactoring, DI, Pattern已经能够如火纯清，用不着另外一个人看着，多性能处理器似的大脑，已经能够递归到第N层。反而意见的分歧往往会抹杀创造的火花，而提出折中的方案。

这只能说明其中一个真正的懂沟通的人也没有，高手也是要学习沟通技巧的。

首先在结对模式下，主要负责编的高手可以不需要反复对自己的构想进行复查，因为有另一个人帮你看着，没有后顾之忧，效率是极高的，不知道搂主有没有体会。

同时帮你看着的那个高手，不能因为意见的分歧而打断你，要么事先和你讨论好，要么暂时妥协先跟着你的思路走，然后等你告一段落后再重构。

方法是死的，人是活的。

效率极高有，但是很少 ，跟所作的东西和pair的人有关，所以觉得PP不值。 一个有着这么强的适用局限的方法，注定是不会普及的。

56 楼 xo_tobacoo 2008-07-09  

pp是咋回事？两个共用用一台电脑？
如果不是，pair就不能相互勾结，获得娱乐时间？
pp更多是强调讨论的价值，思维互补，轮休，代码监督吧？

思路决定出路！

55 楼 runwit 2008-07-07  

不讲什么？

54 楼 昏暗学子 2008-07-07  

一天全pair也太离谱了一点,我们以前公司一般一天就是pair 2-4个小时

53 楼 hax 2008-07-05  

其实我很想尝试PP，可惜没有机会。。。

52 楼 wiisola 2008-07-03  

比较赞同= =虽然以前没这么想过～

51 楼 cats_tiger 2008-07-03  

PP这个东西，我一开始就觉得不行，最起码没有自由了。
PS，要是领导一定要求我PP，那么必须是MM，否则GG我就走人

50 楼 icewubin 2008-07-02  

emarket 写道

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

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

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

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

引用

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

自学的东西当然有，这些东西一般情况下，只能是个人下班回家自己学去，除非是没有项目或者是公司专门的培训。

一般讨论的当然是这些学习不能解决的问题，否则要工作经验干吗？这类的学习必须是工作中才能掌握的。

既然是工作中才能掌握的，pair的方式就是效率极高的一种带新人的方式。

49 楼 icewubin 2008-07-02  

emarket 写道

另外有时候两个绝顶高手pair也会有问题,首先从benefit来讲，不大，TDD, refactoring, DI, Pattern已经能够如火纯清，用不着另外一个人看着，多性能处理器似的大脑，已经能够递归到第N层。反而意见的分歧往往会抹杀创造的火花，而提出折中的方案。

这只能说明其中一个真正的懂沟通的人也没有，高手也是要学习沟通技巧的。

首先在结对模式下，主要负责编的高手可以不需要反复对自己的构想进行复查，因为有另一个人帮你看着，没有后顾之忧，效率是极高的，不知道搂主有没有体会。

同时帮你看着的那个高手，不能因为意见的分歧而打断你，要么事先和你讨论好，要么暂时妥协先跟着你的思路走，然后等你告一段落后再重构。

方法是死的，人是活的。

48 楼 icewubin 2008-07-02  

emarket 写道

用两个小时做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可以直接提高编程效率。）
中午休息之后也是一样地。一个小时可以喜欢做什么就做什么

效率提高不仅仅是你眼前开发上的，代码质量（因为结对某种意义上来说就是即时的review），新人培训成本，未来的维护和交接成本也是要一起考虑的。

47 楼 yh_private 2008-07-02  

protti 写道

yh_private 写道

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

另类情况？？

你指的另类情况是？我说的新手是指这个家伙也在软件也干了一段时间了，最近一直混在当前项目里。老手刚从别的项目调来。
顺便回复下emarket，你说的很有道理，写代码的确不会在时间上提升75%，我们也严格控制速度。保持1+1=1.5左右，但你在结对时有没有发现。两个人在一起的时候精神很集中。我们都关QQ GT MSN，不看网页可以说是满效的两小时，和一个人松散的4小时比起来慢不了多少。而且代码的质量会提高很多，我们也很少因为开发时找个莫名其妙的错误耽误10几分钟的时间。
最后关于你说早上先pair，我想这个事情可以灵活的去做，并不一定要早上，并不一定要什么什么时间来放松，我们要的是花点时间把两个人的状态都调整好，这样开始才会高效，如果一个人在不停的干活，边上那个鬼却似乎要睡着了，那就没有必要pair了不是？