推荐实践：结对Review
每一味药都是有副作用的，每一个实践也是。通常的想法是尽量减少和避免其副作用，然而这绝非最佳做法。有些药就是因为其副作用而广为人知，例如伟哥。软件开发中各种各样的实践也都有副作用。如何降低有害的副作用，放大有益的副作用？
结对Review不是一个全新的实践，而是旧有实践的包装，主要原因恰恰是因为其副作用。结对是最小的团队，在这个最小的团队中如何进行团队合作，如何促进团队学习，结对Review开了个好头。
1. 实践介绍
1.1 实践简介
在开发人员完成一份任务后，由开发人员和团队的另一名成员坐在一起进行结对Review。Review的方式是由该开发人员来讲解他对于这个任务的理解、他的设计思路和他的实现。而与他结对的同学则不停的与他对话。常见对话包括：为什么会有这个任务？这个任务的价值是什么？为什么说这个设计能达成任务目标？这个设计有没有考虑这些情况？这段代码太复杂了。
1.2 最低要求
基本无要求。如果已经应用了结对编程，可以不使用该实践或将该实践作为不能结对编程时的补充。
1.3 使用时机
1）完成一个任务的开发后立刻进行；2）在提交代码前进行。
推荐每天进行，最多两天至少进行一次。当积累的代码太多时，Review的效率和效益都会降低。
1.4 思路来源
1）橡皮鸭
来自于《程序员修炼之道》，其原意是超过一半的问题都可以通过与橡皮鸭进行交流而解决。在请教别人之前，先把问题向橡皮鸭解释一遍。当然，把橡皮鸭换成人的效果会更好。
而大部分开发人员却没有意识到更不要说养成了这种很好的习惯，结对Review将帮助开发人员养成这种习惯。
2）结对编程
结对编程是非常著名的敏捷实践，也是比较出名的难度高。1）取得管理层的支持比较难；2）结对编程需要极大地改变了开发人员的习惯；3）结对编程带来很大的工作负荷和压力；4）结对编程本身的限制很多。
结对Review相对来讲简单很多，只需要稍微改变一点工作习惯。虽然可能不能完全得到结对编程的好处，但是是一种低成本高效益的办法。对期望推行结对编程的团队来说，还可以作为准备工作。
3）代码Review
代码Review是指开发人员完成代码编写后，将代码以某种方式提交给Review人员，Review人员Review代码，指出问题的工作方式。代码Review的问题是1）枯燥：对Review的人来说，看代码很枯燥，而且基本上全是付出；2）效益低：Review出的问题以代码规范方面的问题居多；3）不持久：长期使用容易导致团队成员的排斥心理。还没看见过这种Review方式在一个公司取得很好的效果。
结对Review则是一种有趣的多的Review方式。在与人的互动中可以根据任务的大小、难度、整体情况灵活的调整关注点。
1.5 效益点评
从成本的角度，结对Review在开始的时候投入稍高于代码Review，但它带来的效益远超于这些投入。
1）质量保障
结对Review是一种代码Review的方式，对代码质量能有比较好的保障。相对于普通的代码Review，结对Review在发现业务理解和设计思路的问题方面有比较大的优势。
2）知识传播
通过Review的过程，这一对人在交换他们对业务、设计和实现方面的理解。而通过在团队中不断的交换结对，业务、设计和实现方面的知识能够有效的在团队中传播。而这种传播对团队能力、个人能力提升、新人培训都可以起到很好的效果。
3）心态的改变
结对Review通过改变工作的方式，将逐渐改变团队成员的心态。团队成员在结对Review过程中将开始分享和沟通。在分享和沟通的过程中感受到其他团队成员给自己带来的帮助，从而更愿意接受他人的帮助，更愿意合作。在分享的过程中给其他成员带来帮助，更好的感受到自身的价值，更愿意付出。分享、沟通、付出、合作、相互学习，好团队的氛围从这里开始。
1.6 注意事项
1）哪些人结对？
因为结对Review的要求较低，所以使用方式上可以比较灵活。1开发+1开发；1开发+1开发+1测试；1开发+1测试。在此外，还可以增加一个新人，也试过1开发+1新人、1新人+1新人的方式。甚至可以考虑更多的人。
2）Review哪些内容？
业务、设计、实现和规范是基本的Review内容。但是在与不同的人Review时的侧重点可以稍有不同。例如和架构师一起Review不讨论点设计思路，好像有点说不过去。
3）时间控制
根据个人经验，一次Review的代码最好不要过多，1-2天的代码工作，结对Review的时间大概在20-40分钟。
4）有用原则
只有一直找到结对Review对自己的意义，结对Review才可能坚持下去，否则的话，最终都会流于形式。这就要求大家经常问自己，结对Review对我有什么用？怎样让它更有用？在问自己的过程中，也调整了心态。
5）慢与快
对每一个实践，大家都会有很多期望。然而过于着急收获结果，就可能失去最重要的结果——习惯的改变和养成。
2. 实施建议
在如下情况下，可以考虑实施结对Review。虽然我个人把这个实践看做一个比较万金油的实践，并且经常用这个实践来作为敏捷实施的第一个实践。
2.1 案例1
A团队已经实施了一段时间的Scrum。代码集体所有制的问题一直让A团队的Leader头疼。A团队中的成员仅对系统的某个部分熟悉，导致成员只能承担相应的工作。A团队进行过几次尝试，效果很不好。1）让成员去做不熟悉的部分，结果是费时费力，产出很低，质量很差；2）组织培训，培训的投入产出比也很低。
点评：在工作中进行知识传播才是更有效、更全面的知识传播方式。在推荐后团队开始使用，在实施后的第一个回顾会议中，2位主要开发人员提到自己亲身体会到了“橡皮鸭”的好处。在Review过程中，他们自己发现了自己的问题。
2.2 案例2
B团队是个基础组件团队，由技术比较强的几位同学组成，负责为其他几个团队提供公用的基础组件。B团队的困扰是做出的基础组件在有些团队不容易被接受。
点评：跨小团队的沟通在很多公司都是问题。1）团队对外来的帮助存在疑虑；2）不是我们做的怎么体现我们的价值；3）不了解别的团队的工作，想帮的帮不上忙，想被帮的找不着人帮。B团队准备自己先用结对Review，未来计划进行跨团队的结对Review解决上面的3个问题。
2.3 案例3
C团队最近出了好几次线上故障，因此组织了一个活动，让团队成员花费很多时间进行代码Review。然而他们对Review的结果进行了如此的评价，找出来的大多数问题都是代码规范问题，效益不够。
点评：结对Review是效益更高的Review方式。故障不仅要应对，更重要的是要有长线的信息沟通和传播机制去解决。
2.4 案例4
D团队最近来了些新人。D团队为新人准备了比较宏大的培训计划。培训讲师们花费了较多的时间准备，当然新人们也花了很多时间学习理解。然而落到实际工作中，不少新人反映：1）提高不够，师傅没有时间指导；2）成就感不够，总是练习，没有实际的工作。
点评：大规模的培训看起来很美，实际的投入产出比不高，并且对团队当前的工作影响也比较大。在以前的工作中，尝试过对新人的工作中培养方式：1）结对Review：主要作为听和提问题的那一位，熟悉业务、技术、设计；2）领取小Bug，由师傅进行指导，完成后结对Review；3）领取小任务，结对Review。因为团队中存在结对Review的机制保障，所以不需要额外为新人做太多特别的工作，也敢于分配小任务给新人，新人的成就感比较高，上手较快。
"