[敏捷开发][结对编程(Pair Programming) ]

如果案楼上说的
那就不要推广XP了
因为可以结对的人太少了。。。
至少要聪明才行


我认为不必要水平相近
我的第一份工作
我的第一个组长说过
如果你写的程序
别人看不懂
那么一定是你写错了。。

我每每写程序都以他的话为座佑名
每个人写的代码必须要
有一定基础的人看的懂才算是好程序
（很多功能的程序反而不是好程序）

第二不要让人猜你的想法
每个人的想法会随时间变化而变化
变化很小时连自己也不能查绝
但是两个人一起工作时会让另外一个人很苦恼
因为你十分钟之前作的东西
与你现在作的东西跟本没有一点关联
所以一定要说出来
我现在要做什么。。。。
而这一点很难作到真的很难。。。
我试了N次失败的次数正在减少但还达到50%
而其它的人一上来不熟悉
想要沟通不一定会比我与我搭挡更好（一起工作一年有余平时还一起吃饭聊天）


第三两个人一起工作很累的
比想像的还累
很容易就放弃了
每次都是很累
想明天不结对自己写程序多好

结对时间很短
还没有很好的效果产生。。。
生产率没提高多少

不，我列出来的四种类型都是可以很好进行结对的。而且，很多软件公司第四种developer偏多，是结对的主力人群。第五种，没有办法，只能放弃。

3和4我也没有好办法，这和个人的天性有关。

对这句话理解有误

关于天性，我想说的是：道理，几乎每个人都懂。要多锻炼身体，多睡觉，少熬夜，少抽烟少喝酒，但是知道并不是每个人都会去做。很多人也知道敏捷，知道他是非常优秀的软件开发，知道他可以打造更高质量的软件，知道他可以更好的释放软件价值。但是，由国内传统的软件开发向敏捷过渡，是需要一个改变的过程，市场竞争将是改变的直接动力。在这个过程，必须由“心知达到身知”。不同的软件公司，公司的不同阶段，不同的团队，不同的项目，开发方法都是不尽相同，但也不尽完全不同。

其实，结对并不适用在全部的编程场景下，很多时候一个人有思路时就写得行云流水，并不希望还要与旁边一个人作交流。但是在攻克一些难题或时间较紧又要快速解决问题时结对的功效绝对是大大的好，因为这时更需要发散性思维，两个人的思维面更广，更容易找到解决问题的方法。

从个人的角度来说，是这样。有的developer技术很棒，思维很敏捷，不需要同伴就可以写出质量非常高的代码。而且，在刚开始实施结对编程的时候，要照顾自己的同伴，也许个人的工作效率还有所下降。
但是，从公司和团队的角度来说，这是非常不利的。这样，公司的技术和业务只会掌握在一小部分这样技术明星手中，如果一旦有人员流动，公司就会受到严重损失。
结对编程是一种编程模式，他可以大大的提供代码质量，但不是一个人的代码质量，而是整个项目整个团队的代码质量。我们希望通过这种编程模式，把软件开发的技术、方法、业务在整个团队中传递开。让大家一起互相促进、互相学习，互相影响。达到由心知到身到的过程。

不知道对
大多数的重覆工作
结对的好处在哪里？
如果是有必要思考的问题
很多人会有结对倾向
如果是由习惯可以完成的工作（如写Action时）
结对时习惯不一样
会产生很大的阻力。。。。
以前完成过但是现在要重完成的工作
会让士气下降的很快。。。。
PS：
对于结对来说，
是不是要减少重覆工作呢？
但是大量的学习新技术
与发明通用类的产生浪费
又很严重
不如重覆开发的生产力高

你怎么知道？
你怎么知道这次的重复是合理的，那次的重复是应该被重构的？
这就是需要pair的理由之一：两个脑袋总好过一个。

依次类推,三个好过两个,四个好过三个.......岂不是越多越好了?(钻牛角尖了,SORRY!)

三个人时可以达成共识的可能性比四个人高一个数量级以此类推
五个人达成共识后产叛徒可能性比四个人高一个数量级以此类推