敏捷开发“松结对编程”实践之四：平常工做篇

本文是“松结对编程”系列的第四篇。

团队中常见的一种状况计划、估算、设计的时候你们还在一块儿，但编程的时候就会分开。分开看似是安全的，可是却充满隐患。

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分钟”。这样既不会让徒弟被卡住，也不会让师傅由于常常被打断而致使没法工做。但师傅能够随时发起交流，由于他们是去帮助徒弟的，聊的也是徒弟的事情，不存在打扰的说法。

在多数状况下不管徒弟学得多好，小组的主要产出仍然可能一大半来自师傅。所以不能把师徒团队变成一个简单的学习团队，而要经过保证师傅的时间，来保证其首先是一个工做团队。

这个工做习惯一直保持到后来我管理一个市场/销售/支持团队的时候：我选择坐在开放空间的最中央的一张大桌上（各部门经理也都在中央桌上而非独立办公室里），若是有人有事来找，都会问：“有空么？”答案是有空，或者某个时间以后。尤为是天天有10个以上不一样的人会找你的时候，时间管理方法是很关键的。

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

-------------------------------------------------------

前检查点的基本做用是保证后续工做有大体的方向，并且徒弟能从师傅的设计过程当中受益。

后检查点的基本做用是保证完成的工做符合要求，并且徒弟能从师傅作出的改进中受益。

在平常工做中，师傅要常常过问徒弟的工做，但以保证本身的产出为前提。不能由于已经进行了共同设计和估算，或开了例会就放弃平常跟踪，问题每每出在小处。

下一篇，将就代码审查作一些探讨，也就是师傅怎么帮助徒弟改进本身代码的过程。