千家信息网最后更新 2026年11月03日解读敏捷3 - 解读敏捷实践之结对Review
程序员A碰到了程序员B。"Scrum糟透了"程序员A说。"为什么啊？听说Scrum很好啊，我们公司也在准备实施Scrum。"程序员B回答。"千万别，你们会后悔的。""你们实施的是真正的Scrum吗？""当然，Scrum里面的3个角色、4个会议和3个产物我们都有啊。"
敏捷非常简单，却又极其困难。敏捷方法学由一系列敏捷实践组成，而当人们实施敏捷的时候，却急于一次性实施整个方法学。他们看重敏捷实践简单的形式，却不了解或者不想花费心思了解任何一个敏捷实践背后的内涵，从而导致没有一个敏捷实践能够做到位，不能享受到对应的好处。最后却发现投入那么大，期望那么高，收获却那么少。敏捷实施带来的只是无穷无尽的伤痛，不得已只好告别敏捷。 "
谁说我看不见，我只是把视力集中到一点，以改变我以往对事物的看法"--周星驰《大话西游》。让我们把视力聚焦于单个敏捷实践，看看能否改变以往对世界的看法。
敏捷实践之结对Review 1. 是这样做的 结对Review是由两个开发人员一起进行代码Review的方式。它发生在其中一个开发人员完成了一段代码功能后。两位开发人员的分工是写代码者和Review者。Review者通过与写代码者面对面的交流来完成结对Review。Review者依次向写代码者提出6个问题："这段代码完成什么功能？""为什么要完成这个功能？""设计思路是什么？""符合架构思路吗？""符合代码规范吗？""我们一起来看看代码和你回答的前五个问题能够对应吗？"（不限于，还可以有安全性能等方面的问题。） 一次结对Review的时间最好不超过30分钟，Review的代码最好是最近1-2天的代码。 可以简单描述为2个人，1段代码，6个问题，30分钟。
2. 可用于
2.1 代码Review 结对Review能够有效地解决传统代码Review所存在的问题。传统代码Review存在如下问题：1）投入产出比低，检出的问题大多是低级问题；2）效果不稳定，严重依赖于Review人员；3）制度化推行，可持续性差。现实中，没有几个软件企业能够做好代码Review，因此我以前说过，这是检验软件企业软件开发能力的一个基本指标。这里的传统代码Review是指由代码能力更强的人Review写代码人的代码这一传统方式。
2.1.1 投入产出比 代码Review有3个级别，1）代码是规范的：代码可运行、符合编码规范、无低级错误；2）代码是正确的：正确理解需求、符合架构、设计正确；3）代码是可维护的：业务和应用架构清晰、设计简单、代码可读性好。 传统代码Review侧重于第一个级别，兼顾二三级别，而结对Review则主要作用于第二三个级别，兼顾第一级别。传统代码Review在Review频度上没有明确的规定，要读懂并发现二三级问题要求很高，付出的代价很大。剔除偶然因素，传统代码Review追求的最高目标就是所有的代码都符合代码规范，对促进代码进化的帮助不大。而结对Review的目标则要高得多，能够激发思维，促进代码演进。 结对Review的6个问题考察了代码实现、业务理解、设计思路、架构理解等各维度的关联性，除了代码规范问题外，能够更有效的发现以前很难找出的业务理解问题和设计缺陷。并且采用双人相互监督方式，在结对Review过程中两个人的对话和思维碰撞，能够活跃思维，从而更好的帮助发现关联性问题。 结对Review能够超越正确性，关注可读性和简单性，从而提升整个系统和产品的可维护性、可扩展性。在结对Review过程中，要求在短时间内把业务、设计和代码实现说清楚。这就要求不仅仅做到代码正确，还要做到思路清晰、代码简单，并且能够有效的避免偶然性编程。
2.1.2 人员依赖 每个软件企业都希望代码更好。为了保证Review的效果，使用传统代码Review的方式严重依赖于代码能力更强的人员来Review代码能力更弱人员的代码。这种方式有极大的副作用。1）代码能力强的人的时间被大量占用，以至于他们没有时间去完成他们的工作；2）这甚至会引起权力争夺，谁有资格谁没有资格是代码能力是否得到公司认可的评判标准。如果人们热衷于去钻营代码Review资格，就会大大增加公司的内耗和影响到整个公司开发人员技术能力的提升。 结对Review则不是这样，它对人员没有多少业务技术上的依赖。事实上在结对Review过程中，代码问题往往是写代码的人自己找出来的，参见《从小工到专家》中的"橡皮鸭"。第一次看到这一点的时候不会相信，这有点违反直觉。实际上，大多数高级别问题都是关联性问题，而人的注意力是有限的，在写代码时常出现关联性遗漏。结对Review的6个问题考察的重点就在关联上，往往是Review的人还没有反应过来，写代码的人都发现了。 当然，结对Review对人员有性格和其他方面的依赖。如果总是批评，或者写代码的人不愿意向他人展露自己的理解和设计思路，这时候就会故意找茬，引起争吵。
2.1.3 可持续性 传统代码Review依据的是传统的管理理念，正确的事情就应该做，应该做的事情就变成制度逼着做，制度带来的就是抵触和阳奉阴违。这就是中国最爱的运动式管理。领导重视了，就好一些，领导不重视了，就基本无效了。时间都在运动中过去了，企业却还是一年又一年的原地踏步。 结对Review一开始就考虑了可持续性。结对Review的成本随着熟练度会持续降低，到了后期，每天15分钟足矣。而它带来的收获却是可以持续的，基本每次都可以发现一些问题，而且还有其他的收获，参见下面的个人学习、团队建设。相比枯燥的代码，与人进行交流有趣多了，还可以开开玩笑什么的。有趣又有收获的事情，又不累人，可以经常做，甚至可以成为习惯。
2.2 个人学习 学习是软件开发人员必备的能力，然而学习却是个问题，参见《为未来学习》系列。新人面对的问题人称"种蘑菇"，很多老人都面临增长极限的问题。
2.2.1 新人 有一种新人培养方式叫"种蘑菇"。参见蘑菇管理定律："蘑菇管理"是许多组织对待初出茅庐者的一种管理心态，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。--互动百科 还有种新人培养方式是"导师制"。新人入职后指定一位导师，负责指导新人。而导师无法面面俱到的满足新人的要求，企业也缺乏足够多的优秀导师。 还有种脱产式新人培训，3-6个月给新人集中培训。这种培训模式成本超高，大多数小企业均无法承担。 结对Review是一种工作中培训的有效方式，可以和上述3种方式形成有效的补充。 那些表现优秀的新人天生就会结对。他们知道自己的代码有很大的提升空间，他们会主动向团队中的其他人请教，你会经常看到他们参与讨论，积极请教，他们成长的很快。然而中国人比较被动，也有很多新人还不会结对，他们的成长可能不如预期。所以新人为了自己的成长，企业为了新人的成长，有必要推广结对Review。 结对Review为新人提供了更好的环境，让新人可以得到更多的指导。新人可以通过参加结对Review了解到更多的业务、架构、设计、代码等方面的知识，并且因为是实战代码，比培训的效果强很多。新人写的代码可以被结对Review，在Review的过程中发现各种各样的问题，接受各种各样的指导，从而既可以提升代码质量，也可以学到更多。
2.2.2 老人 软件企业中的老人面对的问题是增长极限。经过3-5年的工作，很多人都到了极限，无法从日常的工作中得到更多的收获。而公司内高端的岗位就那么多，也无法让每一个人随意的做实验，虽然提拔实验的方式在软件行业很普遍。 结对Review可以给老人锻炼的机会，让他们能够从日常的工作中得到更多的收获。 当老人Review新人的代码时，他们要学会如何提问，如何从信息中挖掘更深层次的内容，同时还不能让新人觉得难受。结对Review让老人学会如何鼓励他人，如何与他人沟通。 当老人的代码被新人Review的时候，他们要学会如何简明扼要的说明重点，如何用简单的方式说明复杂的问题，这将有效的帮助老人们沉淀总结自己的知识技能。 当老人间相互Review的时候，他们要学会如何PK，如何把话题控制在一定范围内，如何妥协和达成一致，如何更有效的说服别人。 上述的沟通能力、影响力、冲突解决能力和问题解决能力是每一位高端人才必备的能力，但很多人没有在工作中刻意的培养这些对自己未来发展至关重要的技能。
2.2.3 学习 每个人都想成为终身学习者。能够在任何环境下都比别人优秀，都能脱颖而出，想想都让人激动。然而大多数人都放弃了，因为工作的目的是结果，所以他们不得不一天又一天的重复使用自己以前学到的经验和技能。 结对Review让工作和学习有效的结合在一起，一方面在同样时间投入的情况下可以拿到更好的结果，另一方面可以满足终身学习的期望。 通过结对Review，可以学习知识。无论是新人还是老人，你都可以通过更多人的眼睛看世界，了解到很多业务和技术知识，新人可以快速成长，老人可以避免自己的知识结构变得陈旧过时。 通过结对Review，可以掌握技能。例如设计模式，关键不在于设计模式是什么，这种知识可以通过书本学习。在结对Review过程中可以了解到别人关于设计模式的很多思考，了解设计模式在什么情况下适合使用，在什么情况下不适合使用，发现和应用设计模式解决现实中的问题。这种实战锻炼是掌握技能的最好方式。 通过结对Review可以锻炼能力。沟通能力、影响力、冲突解决和应变能力等等都可以通过结对Review进行提升，而很多人都在抱怨平时没有机会进行这些能力的锻炼。 通过结对Review可以学习如何学习，养成学习习惯。很难找到能与结对Review比美的学习方式，它简单、安全、有效、可持续。它简单，因为只需要找到一个愿意和你谈30分钟的人就可以开始。它安全，你们在找出代码哪些地方可以提升，不会让你在大庭广众下丢脸，不会影响你的考评。它有效，能够快速的得到有效的反馈。它可持续，这是一个可以使用一辈子的技能，可以在任何公司使用。
2.3 团队建设 我们都知道，团队和一群人是不同的。每个人都期望为一个团队工作，在这个团队中人们不仅仅为了完成任务而走在一起，他们是为创造出超越期望的产品，工作有趣而且充满挑战，每个人都能感受到尊重和信任，团队充满友善的氛围，每个人都有成长。然而遗憾的是，这样的团队可遇不可求。敏捷就试图向大家描述这样一种情景，很多人都信了，然而在试验后他们发现自己做不到。最后的结论是，敏捷对人要求太高了，只有足够优秀的人才能玩转敏捷。 其实真正的原因是我们不知道怎么去建设这样一支团队，我们不知道如何达成我们的梦想。结对Review可以帮助我们吗？ 软件开发团队的关键在于协作，而不在于分工。结对Review是两个人使用的最基础的协作方式。
2.3.1 暴露团队问题 在大多数软件项目中，人与人之间不交流，甚至有点矛盾也只是小问题而已，只要他们能够完成分配给他们的工作，毕竟软件开发人员是内向、不善交流并且很难管理的，同时传统的管理方式更强调分工而不是协作。然而那些我们忽略的最后会伤害我们，从软件开发中的Bug类型就可以得出结论，70%以上的问题来自于需求误解、遗漏等问题，而这些问题是可能通过沟通协作解决的。 结对Review强制两人坐在一起交流，如果他们不能很好的沟通协作，立刻就会暴露出来。提前解决协作问题既可以锻炼团队的冲突解决能力，还为未来的工作消除了一个隐患。
2.3.2 团队氛围 一个良好的团队自然有良好的团队氛围，但这种氛围是如何形成的呢？ 有一种方式叫"破冰"。破冰是一种让团队成员快速相互熟悉的有效手段，不过控制不好就会"又黄又暴力"，会超出有些人的承受底线，反而破坏了团队的形成。并且因为破冰的内容大多与工作无关，所以人们在工作中能否像工作外一样很好的合作，还是个未知数。 结对Review是一种融入到工作中的、温柔的团队氛围建设方式。从两个人开始，在结对Review的过程中，被Review的人需要打开心扉，坦诚自己的思考，Review的人需要努力思索，通过提问激发更多的灵感，双方共同发现问题，解决问题，并共享Review带来的小小成就。相互间感恩、尊重、开放透明的团队氛围随着工作中的小细节逐渐开始形成，而这种团队氛围通过长期结对Review小心的呵护和培养逐渐成型。 当然，破坏永远比建设容易。即使结对Review有用，好不容易建起的团队氛围也可以被其他措施在几天内破坏殆尽。
2.3.3 补位备份 主动补位是一种强大的团队能力，让团队能够从容的面对病事假等多种人员减员意外。但要做到被动补位都很难，可能是由于人们相互间不熟悉对方的工作，也可能是人员积极性不够，还可能是人员的能力不够。通过结对Review，上述的3个问题都不是问题，补位的基本难题解决了。 很多公司都有强制的备份措施，其含义就是有人离职了公司不会受到损失。这种措施往往会受到有意无意的抵制，通常是形同虚设。而通过结对Review形成的网状备份关系则是一种更加先进的备份关系，其建设并不需要额外的强调和努力。
2.3.4 团队行为规范 每一个优秀的团队都有自己的默契和行为规范，这些行为规范不是写在纸上的制度，而是被团队成员骄傲的宣称，这就是我们的做事方式。这种行为规范需要长时间紧密的配合才能形成。结对Review就是紧密配合的一种典型形式，它能够促进团队统一认识，相对快速的形成团队行为规范。 "你这种代码看起来怪怪的，和我们以前的风格不一样啊。你看，应该这么写。""这个业务不是这么理解的。""这种方法太棒了。"上述的话语通过结对Review在团队中快速传播，从而形成执行中的代码规范。
2.4 组织转型 很多企业对现状并不满意，期望改变。然而企业往往发现，他们自身被自己长期以来形成的组织文化所绑架，所谓的转型困难重重，能做到的无非是换一换领导，改一改流程，并不能影响到企业内大多数人的行为。 前一段时间做了一个小统计，开发人员的时间都用到哪里去了？发现一个开发人员只用了1/3-1/5的时间写代码，其工作有一半以上的时间在申请权限、了解需求的细节、各种各样的会议、等待测试结果、等待上线、翻查日志等工作中。他们的工作可以优化、效率可以提升吗？从他们自己那里得到的答案是肯定的，然而企业的领导可能却无法看见这一切。 结对Review不一定有这么大的效果，它每次只能改变一个人的工作成效和两个人的合作关系，但我坚信，微观的优化最后一定会反映到宏观上。如果任意一个人的工作有做得更好，任意两个人之间的关系都有改善，整个企业一定会被影响改变。
2.4.1 企业文化/价值观/复杂系统 具备一定自组织特征的个体以简单的方式组成的关系网络往往都是复杂系统，企业就是这样一种典型的复杂系统。而改变复杂系统有一种简单的方式，改变这些个体之间的互动关系。常见的组织转型方式包括组织重构、流程制度转变，这些方式的根本都在于改变了人与人的互动关系。 结对Review改变了软件开发人员间的互动关系，当推广到整个组织，其带来的涌现效应能够改变整个组织。 企业文化/价值观就是这种涌现的样例。企业文化是一个企业表现出来的，内部员工的做事方式和行为规范，是企业内部所有人共同遵循的价值观。 最近听到比较多的"开放、透明、分享、责任"，这些价值观相信在很多企业的企业文化中都或多或少有提到。如果一个企业本身的管理方式就是建立在信息不对称、从上至下的基础上，这种控制式管理方式本身就与上述企业文化违背，最终企业文化要么挂在墙上，要么四不像。 结对Review能够从微观上为企业文化打下基础。被Review的人在结对Review的过程中必须向Review的人开放和透明，讲述他自己在这段代码开发过程中的思考和理解。他们分享他们对业务和技术的理解和认识，共同承担软件开发的结果。当结对Review成为习惯，开发人员相互间的信任建立，人们做到更加"开放、透明、分享、责任"，这一切为企业文化打下了很好的基础，帮助了企业文化落地。
2.4.2 知识管理/学习型组织/社交网络 企业中的知识管理是指企业针对个人及社群所拥有的显性知识和隐性知识的确认、创造、掌握、使用、分享及传播进行积极及有效的管理。彼得圣吉的《第五项修炼》让学习型组织广为人知，学习型组织是指企业通过组织学习实现员工知识更新和保持企业创新能力。 不过大多数企业都是心有余而力不足。企业中的知识管理就是形成了一个有一个文档库，成立培训机构和组织了大量的培训。然而落到微观层次，员工的成长是否符合预期？是否涌现了足够多的人才？ 知识管理的一个关键是知识的流动。当前我们处于知识极大丰富的时代，迷失在知识的海洋是一件很正常的事情。在这种时候，知识的受控有序流动，知识的应用才是知识管理的关键。 结对Review在理论上可以成为企业中任意两个人之间显性知识和隐性知识流动的途径。如果我们把企业看做两两间关系构成的社交网络，那么通过定义两个人之间知识流动的方式，与工作密切相关的知识在企业中流动起来。君不见，通过两两间互粉的关系，信息在微博上的流动速度。 还有一种战术，称为"信息轰炸战术"。就是利用频繁的结对Review，形成以工作为中心的信息弥漫的氛围，利用员工的潜意识思考时间，说不定有什么好主意从此诞生。
3. 与……相关 3.1 变形 结对Review虽然在描述上是两人，人员可以增加。例如增加到2-3个人Review一个人的代码，其中一个人作为主要提问者，另外1-2个人作为附属提问者。 在形式基本保持不变的情况下，结对Review有多种变形方式。
3.1.1 时间上变形 结对编程：结对Review可以看做编程的后续，向前移动就变成了结对编程。结对Review与XP中的结对编程很像，那是不是应该称为结对编程呢？不然，在极限编程的维基百科中，结对编程都已经被改称为结对程序设计了。结对编程那苛刻的实现条件让人望而生畏，并且不能得到管理层有效的支持。结对Review能够得到开发人员的认可和管理层的支持，可以为结对编程打下基础，未来可以在关键代码编写时部分采用结对编程。 结对设计（敏捷建模）：将结对Review移动到程序编写之前，就成为了结对设计，甚至是敏捷建模。可以用于关键代码设计，用户故事设计思路Review。
3.1.2 角色上变形 结对Review可以用于测试与测试之间的测试用例Review，开发与测试之间的用户故事设计思路、代码或者测试用例Review，开发测试PO之间的用户故事Review等等。
3.1.3 内容上变形 结对邮件Review：通常见于外企，多数开发同学缺乏与外国人沟通的英语能力和沟通技巧，结对邮件Review能够让你发出有效的邮件并能快速掌握写好邮件的能力。在第一个外企工作时，我的一个经理每次都和我一起Review发给外国人的邮件，让我快速掌握了英语邮件的基本能力，非常感谢她。 还有结对方案Review，结对计划Review，结对总结Review，结对PPTReview等等无数多种变形。
3.2 有助于何种敏捷实践 在结对Review得以推行后，会对下述的敏捷实践执行有帮助。 简单设计（XP）：结对Review有助于简单设计实践的推行。什么样的设计能够称得上简单设计？能够在短时间内陈述清楚，并达成一致的设计方案很难变得很复杂。并且结对Review可以让代码变得更简单，具有更好的可读性和可维护性。 代码标准（XP）：几乎所有的软件企业都有代码规范，放在文档里的。然而代码规范只能在一定程度上防止代码变得更烂。符合代码规范的并不一定是好代码，代码规范只是表明，我们企业受过伤了，我们的代码不能比代码规范里面的更烂。结对Review有助于形成执行中的代码标准，并能够保证持续的对代码进行优化，从而可能不断提升代码标准。 敏捷建模：在结对Review养成的开放的讨论分享习惯非常有助于推行敏捷建模。
3.3 受益于何种敏捷实践 如果已经执行了下述的敏捷实践，可以帮助实施结对Review。 每日立会：在每日立会上关注结对Review，是一种有效的推行结对Review的方法。 回顾会议：回顾会议能够让团队更容易达成对结对Review的一致认识，从而有助于推行结对Review。 完整团队：团队中的成员不能像资源一样随意变动，这会阻碍结对Review的前期推广效果，完整团队实践能够提供一些帮助。
3.4 采用了何种敏捷方法 从上面的变形就可以看出，结对编程、结对设计、结对Review，结对才是关键。从这里我们总结出了一种基本的敏捷方法，结对。看来所谓的敏捷实践，也许就是几种敏捷方法应用于软件开发实践的结果。而这些敏捷方法也可以应用于非软件开发领域。 到底存在哪些敏捷方法？如何应用这些敏捷方法？理解敏捷方法是不是更能了解敏捷的本质呢？期待后面有机会来分享一下这方面的认识。
3.5 与敏捷价值观的关系 参见《敏捷价值观》和Scrum与XP中的价值观，在此就不复述了。 这篇文章实在是太长了，请参见上面结对Review与企业文化/价值观之间的关系。
3.6 应用了何种敏捷理论 复杂系统：敏捷中的自组织、涌现等很多概念和提法都来自于复杂系统理论。现代的学习型组织/知识管理和企业管理理论很多也与复杂系统理论相关。供希望更深入钻研的同学参考。
4. 实施方法和案例 请参见以前写的《结对Review》系列文章，考虑在后面推出更完整的敏捷实施方法论和案例。
5. 后记 完全没有想到这篇文章会写的这么长，这么累。其实我的本意是想给今年一直在做的结对Review实践进行一次总结，完整收尾。不多说了，后面还想对相关的敏捷实践都进行类似的剖析，并以之为依据展开对敏捷的理解和认识，讨论敏捷实施方法论和描述一些案例。现在看起来，上述目标完全就是一本书，就把写这本书作为2012的目标之一吧。祝所有的读者新年快乐！ PS：在未做特殊说明的情况下，本文的大多数名词解释均来自维基百科。
