Agile，Pair Programming 1+1>n

Pair Programming.jpg

Pair Programming - 结对编程，敏捷中非常重要的一项实践。

之前参与的几个项目，都有结对编程的实践。而我现在所参与的一个项目，是从项目开始到现在的一两个月时间里，严格按照结对编程的方式来进行开发的，并且每天会轮换（Pair Rotation，可以用这个工具 - Parrit）。这一两个月的时间里面，让我对结对编程有了更深刻的理解和认识。抛开结对编程理论里面说的好处，我想记录分享一下最近这段时间在我们团队里面真实发生的一些关于结对编程的故事和体会到的好处。

• 1+1 = 0.8
  一谈到Pair Programming，很多人都会提出疑问，为什么一个人可以干的工作要两个人一起做？两个人一起结对工作的效率是多少呢（1+1会不会等于2）？会不会是浪费Resource？
  这个项目中developer有四个人，团队成员对这个项目的MVP(Minimum Viable Product) 过了一边之后，想要做一个简单的预估。有同事就提到，我们采用结对的方式开发，预计开发资源的效率为1 + 1 = 0.8，也就是说，两个人结对编程，最后的结果是0.8个人。这个预估可能是凭以前项目的经验得出来的。

• 1 + 1 > 2
  我们是从几个不同的团队抽出来的resource组成现在这个开发团队的，团队合作默契或者其他一些因素，而且团队成员一半是没有实践过结对编程的，所以刚开始开发的效率一般。但不久后的一段时间，有几天我觉得我们的效率是明显的1 + 1 > 2的。也就是两个人结对编程，最后的产出比两个人单独进行更多。

• 1 + 1 > n
  最近，我已经不想跟2进行比较了，1 + 1 > n，n是3呢，还是4呢，还是更大的数字？我觉得我没办法给出具体的数字，因为从开发效率上讲，绝对是大于2的，如果再长远考虑对团队和公司的益处，这个数字可能会很大。

结对编程的好处

从预估的1 + 1 = 0.8，到1 + 1 > 2，再到1 + 1 > n的这个过程，我体会到了很多结对编程的好处。

• 快速学习新知识
  我之前做的项目都是用Java写的，对Node.js并不熟悉，跟同事一起结对，很快就基本掌握了Node.js以及其他一些不熟悉的技能。团队中的同事也很快学习到了写单元测试、TDD、重构、IDE快捷键的使用等等。
• 工作更加专注、效率高
  一个人工作的时候，很容易被IM、微信、电话、邮件等信息打扰。每次中断，再开始，都需要时间重新进入状态，对工作效率影响很大。我们用固定的两台机器来进行Pair，我电脑基本处于锁屏状态，手机基本上都不知道丢哪个角落了，有同事错过了好几个快递电话。（所以这段时间如果各种消息没有及时回复还请见谅）。Pair的时候，我们比以前更加专注，自然效率就高很多。
  我还发现一个很有趣的现象，就在前几天，当我跟一个同事pair开发一个新feature的时候，我脑海里思考着这个功能应该怎么去做，思绪越想越复杂，我当时靠着椅子上抱着自己的脑袋，而另外一个同事没有想那么多，直接就开始写了，后面我才发现，自己当时想得过于复杂，我们很快的把那个feature完成了。如果，我们不是pair的形式开发，当我陷入这种思考的时候，可能会有一段比较长的时间都是在思考。这种情况也发生在其他同事身上。其实每个人的技能、知识、想法都不一样，有时候自己觉得难的，没有头绪的，可能是自己想的过于复杂了，其他同事可能觉得简单， 反过来也是一样。当我们结对编程的时候，就好像一起爬山，你拉我一把，我拉你一把，很快就爬上了山顶，而不是在某块石头前面一直徘徊。
• 被打断之后，很快速的能接上
  工作过程中，难免有同事被其他事情打断，当他处理完再回来的时候，可以简单的和自己的partner沟通一下，就能很快进入状态。
• 信息共享
  通过每天的Pair Rotation，我们每个人对项目所有事情都有一定的了解。任何一对Pair都可以去做任何一个Story。
• 代码质量更高
  一个人开发feature的时候，基于进度的压力或者自己的惰性，有时候虽然知道自己写的代码存在隐患或者不够clean，但很容易心里会出现这样的想法：算了吧，先这样吧，问题不大，单元测试以后再加等等。这样的代码上到production之后出问题或者以后的同事来做修改的时候，都需要花费多很多的时间。
  两个人一起Pair的时候，第一，当跟其他同事一起pair的时候，惰性没那么大，也不想留下一些隐患；第二，假如自己真的不想去改，自己的partner可能会主导来改， 当partner改的时候，自己又很容易加入一起改了，最终实现让代码存在的隐患消失并且代码更加整洁等等很多方面的好处。
  对以后的影响，也是我考虑1 + 1 > n n可能会很大的一个因素。

怎么结对编程

在结对编程的过程中，我们经常会有不愉快的情况出现，特别是在项目开始的前一段时间，现在已经有了很大的改善，我们的效率也噌噌噌的上涨。在这个转变的过程中，我对怎么结对编程有了更深的理解。

• 说话技巧
  程序员，公认的情商比较低。所以在一些沟通交流技巧方面，大家都不太擅长。在我们Pair的过程中，经常会出现下面的对话情景：
  A: 你这里写错了，你这里不能这样，你这里不熟的话，我来写。
  这段话有什么问题呢？可能现在看起来没什么问题，但在pair的时候，自己的partner听到这样的话会影响情绪。Pair的时候要站在团队的层次，一对Pair不要分你我，写出来的代码都是一起的。不能归咎于个人。我们可以这样说：
  A: （我们）这里写错了，（我们）这里不能这样，我们可以这样试一下吧，（我们）这样写会不会更好。
  可以不说我们，但最好不要一直说你你你的。
  还有一种情况：
  A: 我告诉你这样不行，我说了这样不行，你还不信...balabala。（语气比较强硬）
  在pair的过程中， 经常有一方认为自己是对的，声音会很大声，感觉要证明自己是对的，对方是错的，并且要压倒对方。
  每个人都有很强的自尊心，沟通的时候，一定不要情绪很大，这样会让对方不舒服。尽量用委婉一点，让对方更容易接受的语言来沟通。

• “自我牺牲”
  每个人都有不同的想法，Pair的时候，经常会意见不同。举个很简单的例子，对一个方法命名或者一段代码的实现方式，如果自己的想法和Partner的差不多，或者对方的虽然会差一点点但没啥影响，这个时候，可以简单表达出自己的想法，然后倾向于采用partner的方式。而不是努力去证明自己的更好，对方的不好。当然，假如对方的想法是错的，或者影响很大的时候，还是要提出来。当双方都保持这种“自我牺牲”的心态的时候，也许对方听取了你的建议之后，也会建议采用你的方法。

• 学习的心态
  每个人的技能、知识会不一样，有些方面自己比Partner强，有些方面自己比Partner弱，要时刻保持可以从对方身上学习到Partner强处的心态。千万不要想着要证明自己更强，而不好意思承认自己某些方面不如其他人。

• 切换Driver 和 Navigator
  Pair的时候会更加专注，会更加累。经常性的切换Driver和Navigator会让Pair的整体效率更高。就好像开长途汽车，经常轮换着开，会让车子一直保持高速前进，并且更加安全。

• 信任
  跟团队比赛一样，一定要相信自己的队友。就算他某些地方不强，当你很信任他的时候，并在必要的时候给一些好的建议，会让团队Pair的效率提高很多。

• 听取partner的意见
  出现不同意见的时候，不要抢着键盘一意孤行的按照自己的想法去实现。多尊重一下自己的Partner，或许他的方法会更好。假如他的方法差不多，可以用前面提到的“自我牺牲”采用对方的方式。

• 给自己的partner鼓掌
  当一起克服了困难，或者效率很高的时候，（最近有几个story，一眨眼的功夫就完成了，比我预期的快很多）。给自己的Partner鼓掌，虽然可能是一起完成的，甚至是自己的贡献更大，都没关系，一对Pair，不分你我。给予对方肯定和赞美，非常利于团队合作，对提升Pair效率帮助很大。而且大家一起工作会很开心。

• 严格采用结对的方式
  很多时候，大家会提出问题：结对编程又很多好处，但是不需要一直结对编程吧。有些简单的东西，一个人来做就好了。
  在团队开始采用结对编程的开始阶段，也就是结对编程经验不够丰富或者体会还不深刻的时候，我建议团队还是严格按照结对的方式，不管团队中要做的时候是简单的还是复杂的，都严格结对来做。如果一件事情很简单，那就一起结对很快速的完成，或者说那天的工作就轻松一点。而且经常我们对简单困难的把控其实是不够的，开始认为简单的事情，不一定真的简单。
  其实，少一点时间浪费在思考某件事情要不要结对编程，直接严格采用结对编程的方式，会简单暴力点。长期来说，对团队及个人都是有很大的帮助的。
  所以，我的建议是，最好严格一点，直接采用结对的方式，不需要考虑做的事情是什么。

总结

以上是这段时间的一些体会。如果你所在的团队还没有采用结对编程，建议可以尝试一下，可以先小范围，但严格结对的方式来开始。如果你所在的团队结对编程的效率不高，可以参考一下我上面所说的一些细节。
我们Pair效率提升的过程中，我也体会到Retrospective和Feedback的重要性，后期我会整理一篇关于这两方面的文章分享出来。

欢迎大家一起交流：[email protected]