困惑的结对编程？

假设的数据是一个起点。你可以把真实数据填充进去，得出你自己的结论。如果你连定性的分析都没有做，又为什么不肯接受这些假设的数据呢？

如果是研发性质的项目，结对编程就不适用了吧？

你的数据大体上我还是接受的，因为我的项目给了我这样的体验，最多就是各个阶段的倍率有所不同而已。
对于没有尝试过结对编程的我，与其给我一通我没有体验过的数据(指使用结对编程后的数据)，不如告诉我，在我的特定应用场景中，他能在哪些方面提高生产力。不同应用场景的差异很大，我想初学者都希望能有更有针对性的解答。

可以先把应用场景讲一下啊

我想这里很多人在结对编程这方面都会有很多疑惑吧

我上头的回复说了，以数据驱动为主的项目(在短期内不会改变)，有些是遗留系统并且有相对稳定、统一的框架，并且开发人员很熟悉这套框架。

自己试一下就知道了，你会喜欢上结对编程的。

我们的项目现在快交付了,有一些隐藏很深的bug,结队改bug真的效率很高.

结对编程我觉得在两个水平相当或者在意识、能力上互补的两个人身上应用时，效果会很不错！古语云“以人为镜，可以知得失”，结对编程就可以很好地形成一种互助共进的气氛和效用！

ans to:hzhui
您的数据我没有明白什么意思
“如果有一个需要一个人8小时开发的模块，将由8个人花一小时去写代码，也就是等于总共要花费16个工作人日”
这个“一个需要一个人8小时开发的模块”工作量不是8人时吗？为什么花费需要16人日？

抛开这个不谈，我理解您想要说明的意思。
但是，有一点，您举的例子是单纯的编码阶段的，如果以后软件开发不需要编码呢？这些所谓的数据还有没有意义？所以说这个是历史的产物。PP是peer review的一个具体实现，所以只能使用在特定的环境，特定的历史时间框架下。
还有一点是“协作”，如果为了PP而把两个人放在那里，表面上看起来在一起工作，结果一个人在写代码，另外一个人在睡觉。或者说两个人其实在聊天，这个都没有什么意义了。所以，PP比较理想化，可以认为是Y理论的体现，属于一种极端。

to:gigix
您给的数据是比较正确的，但是想稍微改一下：到“编码阶段”发现并修复的成本就为10
这个改为：到“实现阶段”发现并修复的成本就为1。
因为“编码阶段”是“实现阶段”的一种“实现”。
“由于频繁的peer review，设计、编码阶段的大量bug不会流转到测试、维护阶段。”
我个人认为对XP进行说明的例子都是很典型的，但是对一般的开发项目而言发生的概率并不大。比如某些算法的错误，某些字符的错误。但是对于研发型的项目可能作用更大些。
相对PP所能带来的好处，我更愿意把这些人力放在架构的设计及管理，以及迭代周期的缩短上。

顺便我们再来看一下XP里面的一个有趣的东西。XP建议团队规模不要大于12个，以及采用PP，这样Team Leader需要的管理能力在绝大多数时间其实是6。

三人行，必有我师

我们的老祖宗早就教导我们要这样做了，呵呵