敏捷开发“松结对编程”实践

　　团队中常见的一种情况计划、估算、设计的时候大家还在一起，但编程的时候就会分开。分开看似是安全的，但是却充满隐患。

　　2001年，一位招聘考试前三名（一共120员工）的程序员的两个月的成果被彻底放弃重写，原因是里边包含3000多个常数，而且很难修改（码流参数），重写的人座位距离他只有4米，重写也只花费了2周；2002年，一位月薪7000（那时候北京房价才3000多）的程序员编写了一个月的4000多行代码，在一个下午被重写为50多行，座位距离他只有5米的项目经理疑惑加惊讶地问：“你真的没学过c++ template？”。

　　这就是团队的距离，即使是高薪聘请来的程序员也难免犯错。难道我们只能避免下一次问题发生，而不能避免这次问题发生？

　　前检查点

　　前检查点就是在做某功能的最初一段时间，师傅与徒弟结对编程，完成最初最重要的设计。

　　“开始做X功能的时候叫我一声，咱们敲定一下具体怎么做。”这个是师傅的前检查点标准语法。尽管在共同估算的时候大家还是略有共识，但是限于计划会的有限时间，徒弟未必真的知道怎么做。在刚开始的一两个小时里边，师傅带领徒弟一起把基本的结构理清楚，最好写上一些基本代码，让徒弟有一个直观的概念。

　　在上面提到的2周的重写工作中，重写者和被重写者一起工作了1.5天，重新设计了打包类、递归函数等最难缠的部分；被重写者在剩下的两周里边完成了工作，而且很出色。倘若这一切发生在两个月前该多好。那次事故之后，我们订立了更严格的代码审查制度，所有代码均由部门技术最好的人审查后才进代码库；之后再来的新人，均指派师傅，并由师傅保证其代码质量；将人员划分为需指导的/免于指导的/可指导的/可培训的四级（10年后我在NEC参观交流时发现了几乎完全相同的分级制度）。

　　前检查点的工作作用是打下设计的基础，保证工作顺利进行。如果一切按照前检查点的设计进行，徒弟可以继续独立工作，如果有偏离，要询问师傅。

　　前检查点的学习作用是显而易见的，师傅平时工作的精华都展示在徒弟面前。而且这种展示是动态的，在结对编程的状态下，徒弟可以完整地看到师傅是怎样入手工作，怎样

　　后检查点

　　后检查点就是某事做完后，师傅检查一下徒弟的结果，保证达到验收标准。

　　曾经分配给我一个刚毕业半年的组员，刚来没多久就经常看到他上网玩，过去一问，原来工作做完了（真的非常快），惊奇之余赶紧看看结果：功能是有了而且实现得也很好，就是总有点瑕疵：要么按钮不正，要么界面上有错字。后来就改成每次任务完成都赶紧喊我去看看，修正后继续下一个。他后来能力超群，在此公司作为“台柱子”10年，现在还在。

　　其实多数新人在大学中都形成了“能运行就行”的概念，并不懂商业软件开发的标准。本人也一样，毕业5年还不知道delete内存（C++），每次都是多预留点C盘空间，这样程序就能多运行一段时间，下班之后关机重启就可以了……这样的软件肯定无法在服务器上长期运行的。

　　后检查点的工作作用是可用来进行代码审查，以确保软件产品的质量，之后会提到。

　　后检查点的学习作用是帮助新人学习商业软件的开发标准，逐步养成好的习惯。

　　日常工作

　　除了在任务前后的时间点外，日常8小时也应该保持良好的沟通。在一次极端的环境中，我们曾经将其发挥到极致。

　　当时我们以很高的日薪临时聘用了两个不错的程序员。他们技术虽然很好，但是却对业务一无所知，也没有提前看过文档。因为总共也没有多少天，当然不能把任何一分钟花费在熟悉业务上，所以……

　　1. 每天早上（包括第一天）

　　整个软件被大致分为三类功能区，互相关联。组长（我）也自己编程，负责其中一类功能。

　　有20分钟的晨会，组长会把一个简单的设计文档的一部分拿出来讲解给两个人，同时指出今天要做的工作要给予其中的哪些内容，他们提问我回答。散会前我们会就没人的工作做一个简单的估算（当年还不会扑克牌估算，太可惜了），确保当日是可以完成的。

　　晨会会提到技术问题，而不是每日立会中说的只说进度。但技术问题一般只涉及到要求，比如“做分段计价模型的时候，不要在C++里边做For循环，看能不能在SQL里边解决，如果解决不了来找我”“好，我试试。（或）这可能吗？”凡是有问题的就会稍微深入一点；凡是“我试试”的，都放过，但如果试验的结果不通就必须找组长讨论而不能自行解决。

　　小组加组长只有3个人，所以所有人都参加这个20分钟会，包括肯定不做某任务的人，也听组长和别人的讨论。

　　2. 每天下午1：30点左右

　　就是吃饱饭犯困的时候，组长会分别和大家在计算机前碰头一下，主要是看当日的工作是否可能在下班前完成（坚持不加班）；另外就是看是否和晨会上预想的一样。

　　其实就算是短短的半天时间，事情就可能有变。有一次其中一个程序员在一上午写了大约4屏幕的代码（一般每天才写这么多），而功能却遥遥无期。原来他不知道有个函数可以快速实现这些功能，正在自己造轮子，他本应该告诉组长所遇到的困难。

　　程序员很少在这个时候求助，他们总是相信自己能最终解决问题……因此在转型为自组织团队的时候，担心程序员会偷懒的想法整体上是多余的，更需要预防的是蛮干/过于乐观/激进/需求镀金/消息闭塞/无法互相学习等问题。

　　3. 每天下午下班前

　　当时6点钟有《七龙珠》（工作场所有台电视），两位对此都很着迷，所以我们基本到点就看片，看完后散伙回家。

　　因为也不能让电视台调整播出时间，基本上下午5点就要开始打扫战场：组长分别找两位，看最终结果是否完成，并做一下修改。同时还要做代码审查（请看下一篇详述）。

　　由于估算不会太准确，我们专门把所有三不管的小功能梳理出来，谁提前做完了，谁就找其中一个把剩下的闲工夫占上，结果其中一位几乎包揽了全部。

　　4. 晚上

　　对，组长晚上还要工作。在他们走后组长会在晚上做个集成，把几个人做的功能合成在一起运行。当时也没有持续集成工具，所以只能手工。

　　在正常项目的正常团队中，这个工作应该在第二天的工作时间完成，也就是说或者找专人（或轮流），或者让组长做，或者让自动工具做最好。推荐小组内轮流负责此事，因此可以让大家理解别人的工作、整体的工作，乃至与组外人员的集成工作等内容，为组员成长为组长打下基础。

　　5. 随时

　　可以已经注意到我们没有“每日立会”，一则当年还不知道Scrum，二则感觉一个3～5人的团队还要靠开会交流实在迂腐。比如在篇首提到的两次事故中，团队都没有少开会，但都因为缺少随时的沟通而导致大错。

　　其实任何伸伸懒腰的时间都可以进行沟通。不过一般不要“太随时”，应该以师傅的时间为主，也就是如果徒弟遇到了问题，但可以绕过去先走着，就先来一句“我这有问题，有空帮忙看看”+“好，再过15分钟”。这样既不会让徒弟被卡住，也不会让师傅因为经常被打断而导致无法工作。但师傅可以随时发起交流，因为他们是去帮助徒弟的，聊的也是徒弟的事情，不存在打扰的说法。

　　注：上述部分内容仅限于特定环境中，但思路很多时候都是可取的。