XP的反省-Pair Programming

好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, 有可能错误的东西做完才发现。 最后还是就不了了之了。

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

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

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

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

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

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

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

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

另类情况？？

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

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