对于结对编程我有疑问

不一定要有XP思想和相近水平，只要愿意交流，通过结对总可以工作得更好。不愿意交流或者无法交流的人，我觉得，他最好的位置就是缩在角落啥都不要干，不造成副作用就很好了。



没错。4小时紧凑的工作足以让人累得不行。所以XPer是没办法加班的。

我们现在同时在作JDO的开发和一个电信的项目, 7个人，１个是需求扮演on-site customer，３ pairs，我杂事比较多，只要一有空，我就pair。其他人轮换。

７个人中４个是第一次作xp。奇迹般所有人都很open，这里只有经验多寡之分，没有高手低手之分。

项目时间极紧张，２０天。好了，不敲了，要做集成测试了。

     楼上的说法很不错，我个人也觉得，如果将结对编程理解并实践成这样，实施的可行性是相当高，所起的作用也会不错。
   只是，我想更多的了解在作者愿意的情境下成功的例子。

我就是想知道这种条件以及现实的环境是否具备这样的条件。
首先，我们考量一下这样的每段时间，换句话说，也就是一个人在每天或者每一段时间会做着截然不同的内容，我不清楚那应该是一个怎么样的系统，但是我知道，一个真正的企业系统，关理解同一个模块的内容都是需要相当长的时间几个月甚至半年，而且这还是有比较充分的分析和设计的情况下。今天把你丢去做工作流，明天把你丢去做权限，后天把你丢去做财务分析。我不清楚，人的分配人员的调整谁来负责，谁来做？我今天刚刚想到一个解决问题，但是上司要调我去另一块（因为也许其他人都完成等这掉换），是不是就丢弃。感觉很像一个喜欢到处去拣水果的熊。

首先说明这样的工作环境要求并不高，并且很多公司也没有40小时/周，一天都是7和7.5小时。但是任何一个做软件的人，如果认为人每天都保证7.5小时100%工作是不可能的，也没有任何一个人会是这样长期的工作。在这样一种不可能（是人不可能而不是环境）的要求进行实践，是不是盲目？有些照搬书的味道。

至于绩效考核以及人的评估体系，那是人力资源部所做的事情，但是我上面列出历来都是有比较严格企业规程软件公司的标准之一。XP适合于小团队，我是赞成。但我部清楚怎么叫每个成员把握项目的进度？怎么理解把握这个词？因为我相信，在绝大多数中国的软件项目中，成员的能力经验水平以及性向（是性格取向）都是不同，或者说是可以阶梯化的。要最基层的成员怎么个理解项目的进度并且把握？绝大部分程序员能把握的只是自身任务的进度，而不是项目整体的进度以及迭代模式，否则，不个个都可以是项目经理了么？

从全程来看，我相信结对编程是缩短了项目的整体时间，但是，问题是客户、企业关注的是软件是否完成的时间，而不是最终实施的时间，难道楼上没有这样的经验么？企业领导，客户是问你做完没有，问你是否能够提交，而不是说提交后要多久才可以真正实施。如果纯粹通过double开发的资源（人力或者时间）从而降低整体的质量和时间，那么是否又违反了XP的另一个实践呢？

根据楼上这一点，我就可以确切知道楼上是通过纸笔绘出思路，然后用编程，再通过不断的重构（形容类似于曲线的模拟逼进吧）来达到设计思想的表现，但我想说明的是，第一你画的图和你编写的代码是两码事，设计辅助工具的双向转换的目的就是在于此。第二中国的绝大多数程序员对于UML的理解或者说表达没有那么好的功底。第三，如果有很多人可以关从代码或者从编程人员若有若无的敲键瞬间就可以很快看懂一个程序或者模块的设计思路和想法
，呵呵，那大家都是神童了。首先声明，我不具备这样的能力。
从任何一本书上我都知道这是非常好的实践，我也相信作者的目的和实践的来源的准确性。，但是问题是，在应用上，在中国软件企业的应用上，在中国软件项目的应用上，又有多少个项目团队，多少个人真正成功应用了这些实践，如果是，那么我问的问题自然也就不是问题，不是么？

其实从很多网友的帖子我已经看出，实施这个XP实践的往往都不是照搬，而是根据实际情况进行调整，比如说，局部的结对编程（包括人员范围、时间范围、模块范围），然后将经验推广。大家更多地将结对编程理解为一种share，一种技术，经验，知识的share，通过共同商讨、解决问题，来提高communication，来降低误解和疏远。
   对那些能从中获益的朋友，我非常恭喜，也渴望向之学习。
   其实讨论这个问题的最终目的，我只是想说明，很多东西并不能照搬，仅此而已。

嘿嘿，以上的看法纯属个人看法。懒得敲字了，一会还得开会呢。这个问题实在是比较复杂，一时半会也难以说清。

不过，严重同意凤舞凰扬的看法，就是不要照搬，要根据自己所处的环境来理解，来实践。

还有，我们并不是用纸笔来画图，然后重构。这个只是我自己的实践而已。我们团队都是用CASE工具的，但是实际过程中由于人员素质的问题，导致往往错误百出，这也是我比较郁闷的地方。

不过有一点要说明的是pair programming确实很累，累的要死。以至于每天5到6个小时就累的不行了。

体力要求实在太高了。。每次做完两个小时，好累。但看着成果，我跟我同事说，今天早上也就差不多了。

我觉得结对编程在人数多，交换结对频繁的情况下能够促进沟通(xp4原则之一)，确实有到处捡水果的意思。
但我个人认为xp对团队要求很高，团队人员是上来就能做的人，和项目相关的技术都已经大致掌握或很容易上手，那种边做边学还不能跟上的人不适合xp团队，但谁都不可能是任何领域的专家，那么在你不强的地方就对和你结对的人有着高要求了，他得能带带你，并且能知道什么时候你成手了。
这样的话我想到处捡水果也无所谓了。:)

我想楼上的人真的实施过pair programming 吗,我们一直想试一下呀

两个人坐在一起只是个形式而已。经常互换作Code Review同样可以保证代码的质量，不一定非要坐在一起。我更喜欢短会＋头脑风暴的方式。把主要代码的结构和流程，类之间的关系大家讨论一下就ＯＫ了。再说也不一定所有人都喜欢边写旁边还有个人边看边说的。：）