实践Pair Programming

前段时间在Team内小试了一下Pair Programming,小记一下感受。

         当我周会上决定近段时间的新功能两人结对开发时，大家一片欢呼，热烈欢迎，可现实状况——我们4个人都没有PP过的

经验，也都道听途说而已。为了先试试效果，决定先由我和另一个技术稍强，性格外向的组队。

        和他一起Programming的过程还是比较愉快。与其说是Pair Programming，不如说是Pair Talking。我们两个人讨论的时

间要比Coding 所花的时间多。比如需求理解不一致经常会争论；对设计经常会脑子灵光一现，产生好的Idea，然后就停下来讨

论可行性；程序不同的写法的差异和后果也会讨论一番；一些不好的编码习惯也会随时有人纠正；我也会把自己的很多开发的

经验告诉他。我发现平时我都没太多话的，这段时间都快成话唠了：）

       和他Pair的过程，我估计工期比一个人单独做略短一点，所以总工时 < 一个人做的工作 * 2，大约1.6倍左右。为什么会小

于2？因为两个人每小时都是有效工作时间，没人偷懒：）。但代码质量绝对有信心，最后User验收该功能也没有Bug。

        之后我安排他和一个比较内向的女生Pair，女生技术和经验上都差一点。发现效果比我们Pair时大打折扣。开始我发现女生

基本什么上都听他的，几乎没有提出自己的任何建议。后来我要求男生把Pair时的主控权大多时候交给女生，大多时间由女生

来掌控电脑，他负责Review她的工作，发现问题及时指正。这样让女生在做的过程中体现她的思路，了解她的思路后两人才能

更好的交流。最终产品质量也还不错，User验收只发现很少Bug。这个女生自己也说从他身上学了不少东西

       Pair Programming一段时间之后，还是可以看到很明显的效果。Team内大家的交流比以前多了，以前很少有人主动讨论

新技术。我一直想在Team内做单元测试也基本实现了，大家对Junit的思想和基本用法也都通过“一传十，十传百”比较熟悉

了。

      最终感觉， Pair Programming实施和个人性格关系很大，和外向的人Pair是件愉快的事情，和外向的人Pair确是比较沉闷。

最后一句有笔误吧。。。

我觉得许多程序员都内向，但是讨论到编程的时候就都来劲了。如果连编程的时候都沉闷，是否说明他其实不喜欢编程？？

哈哈，手误

应该是：
和内向的人Pair确是比较沉闷

也有很多人喜欢自己捣腾，而且沟通上有障碍，除非和比较熟悉的人

非常支持，我们 pair 的时候感觉也是这样，要努力的发挥出积极性才可以。

可以弄点小零食，大家一个吃，另一个干活。^_^

要是让BOSS看到......

是写一段时间然后交换代码review一下的那种结对，还是两个人坐在一起从早到晚？

想问问楼主：
1.项目时间紧吗？
2.结对的对象除了性格上的考虑，是不是在技术上也要考虑，如果差的太多，是不是就相当于1个人在教另一个人怎么开发，成本会不会太高？

Pair Programming是敏捷的最佳实践之一
其目的是提高团队内部的沟通交流，促进知识传递和提高代码质量。只要能达到目的，具体的形式就并不重要了。

敏捷实践的实施，很类似于我们面向对象中的设计模式的应用。设计模式专家们一再强调是：在一定的上下文环境（Context）下，你出现了这样的问题（Problem），于是你才可以使用这样的解决方案（Solution）


当然不是。我们在下面两种情况下很重视Pair:

1.新加入项目团队的成员。每个人都有义务和新成员Pair一周左右，让他快速了解项目的开发方法、业务、技术等。

2.业务逻辑很复杂的功能模块和新技术。

其它就根据项目和团队的情况来了。

总而言之，这些实践是来帮助我们的团队提高工作效率，而不应该是团队的形式或负担。

坐在一起，我觉得你说的不是结对，而是代码走查
我觉得Pair最重要的是两个人会不停的说话交流

1.们是属于公司的IT部门，不是很紧，但也会有时间压力
2.不知道你说的“差的太多”怎么衡量，我比另外一个要经验丰富一些，不过感觉还是能从他那学不少东西