困惑的结对编程？

每个人的阅读速度和理解能力也有偏差啊，我觉得这样子peer的效果肯定不好

嗯，这个的确是个问题,peer的效果估计不是很好，这个没有经历过啊

两个平庸的人结对也不一定等于一个高手，感觉结对编程不是适用于所有团队。如果两个很有经验的开发人员结对，岂不是浪费时间。另外，开发的时候，理思路，思考算法都需要相对安静的空间。从文化上讲，东方人相对保守，也不太适应这种编程方式，希望有些真正实践过的说些优缺点，我们不能一味的觉得人家国外大师说的就是对的， 要有独立思考能力，关于敏捷宣言，我不太赞同他对文档的观点。

如果一定要上升到这个高度的话，在我看来（一部分）中国人最需要的是少点主意，少点推理，多点实践，多点学习。结对编程是不是有利，在什么情况下有利，不需要去推理去猜测，找一个称职的导师带着你做一段时间自有体会。ThoughtWorkers都算相当有经验的开发人员吧？我们仍然每天结对编程。
至于“浪费时间”一说，我在很前面的一个回帖就说了：仅仅是尽早发现defect带来的成本节约，就足以值回票价。
补充一句：两个平庸的人不管用任何方式也达不到一个高手的水准。尤其在软件开发这件事上面，高手和低手的效率差可以是十倍、百倍。你能做到的最好的事情，就是尽快发现谁是高手谁是低手，而不是让平庸的人每天缩在格子间里混日子。

depends
我仍然重复前面的话：如果你对于pair programming的concern是耗费时间，请考虑defects流入项目后期所带来的成本。

PP确实需要有团队文化和人员素质作为前提条件。特别是现在国内依然浮躁的氛围。但是PP如果正确使用，确实可以带来品质的提升。
所以一味的说PP好或者不好都是不正确的。我们需要考虑该方法是不适合当前组织的状态。而且，PP的作业方式是在需要使用的时候用，而不是强制性一定要用。亦即不能为了PP而PP，否则便是本末倒置了。

otherwise how can they?
pair programming is not silver bullet. no silver bullet.

非常有道理，让我想起了ejb开始时候的情况，就是滥用，不考虑实际环境的滥用导致了失败，我想pp也是一样，至少在中国更要谨慎，不开个贴讨论一下pp在什么情况下使用会比较成功。

   我们最近的工作方式是半天自由活动，半天4个人在可以无线上网的小会议室，4个本本1个投影仪搞4P，比PP更爽更YL的说。

   在实践过的2P中，Peer Design 和Peer Debug 这两种PD地球人都知道是可行的，还有一种设计师偷懒，动口不动手，一边看一边带Coder的Peer Program效果也不错。可惜水平完全相同的两个程序员2P这种真正的PP在公司还没条件试验。

我曾经在团队中尝试过peer。

我觉得，绝对首先要建立在大家互相信任的基础上才能进行。另外：我认为有几个地方比较适合peer：

1，老员工 + 新员工 ：这里的老和新并不一定是指各自的工作经验，而是相对我们团队来说，后来的就是新进员工。可能你进来前1，2个星期，我会让一个老员工和你一起工作，不仅仅是编程，还包括讨论，分析等等活动。好处很明显：
    a，可以让新员工很快熟悉我门的开发框架，开发流程以及项目中的大部分规范和要求，这个要比新原来去啃稳当扎实的多。
    b，更可以增进员工之间的默契，这样以后大家一起工作就会沟通的更加顺畅。
    c，以前我们是家创业型公司，主要做web2.0方面的东西。这样也更有利于思想的碰撞。

2，引入新技术（有一定技术风险的）：
   有时候，由于项目需要，可能会引入其他的技术，而这种技术是团队内部都不是太熟悉的。那么我会安排两个比较合适的成员一起来共同研究这个新的东西。这样不仅可以防止某一个人陷入思维的死角，也更有利于新技术的推广。

其实，这些东西，需要自己亲自体验过后，才能知道具体有没有效果，并不是拿一堆假设的数字来推测，计算就能得结果的。突然想到这么多，就写到这里吧。