云鹏杂谈 之 随机结对

    一则小品：开发进行中，有个技术很菜的家伙A总是有这样那样的问题搞不定，来找作为技术主力的你解决。为了帮助他，你不得不放下手中的活。等你回到座位时，看看自己的程序，发现思路已经断掉了，于是只好从头再来。等刚有了思路，另一个同样总是有问不完的问题的家伙B又来了，于是你又不得不为B的程序殚精竭虑。就这样过了不知多久，你发现这些恼人的家伙终于不来了，可一看时间，原来是快下班了。被折磨了一天的你虽然还没完成自己的任务，但终于可以解脱了，于是也不禁长吁一口气。就在这时，项目经理宣布：今晚加班！尽管你还想说点什么，可是盒饭已经端了进来，不仅由项目经理亲手放到你面前，并热情而亲切地说道：“辛苦了！”没办法，你不得不大声说一句“为人民服务！”，接着在饭后继续干别人的活。好容易熬到晚上十点，项目经理终于宣布解放了，别人都因获得自由而雀跃起来，可你却只能低着头默默地拿程序回家去做。就这样，你连周六、周日也不得不干到晚上九点，可一个月之后项目快结束的时候仍然发现，进度最慢的一个就是自己，居然还差三分之一没完成。
    这则小品可能有点夸张，不过问题却很现实，相信很多人都有过类似经历。对此，建议运用结对编程。虽然结对编程有利于提高代码质量，不过却是以消耗人工为代价的，而且经常是1+1<2，所以这里考虑对结对编程做些变通，以便在不增加开发人员，至少是少量增加开发人员的情况下实现结对。想法很简单，就是把核心人员抽出来，只做支持，将其任务派给别人，别人有问题时就协助解决，没问题时则可以与组内任一成员结对。但这样做不会导致项目延期吗？的确，我还无缘进行此项试验，无法提供有说服力的数据，但项目不延期是可以保证的。理由很简单，非核心人员会承担多少任务？如果非核心人员承担的任务是饱和、甚至超饱和的，这意味着项目在开始时就已经注定要延期了。而通常情况下，即使是核心人员也不会被分配以过满的任务，目的是预防可能出现的问题，何况在得到核心人员的协助后非核心人员的开发效率还会提高呢？此外还有两个变数：一是开发人员在任务加重后心态的变化；一是核心人员处于机动状态，随时可以分配以任务。
    不过，随机结对也并非针对所有情况，例如开发人员少于5人，或者开发团队整体素质过低，均不适用。至于如何设立随机人员比较恰当，我认为：当开发人员在5-9人时，应设立1个随机人员；而当开发人员多于10人（含10人）时，则应每5-7人设立一个随机人员。当然，在设立随机人员时，也应将开发团队的整体素质及组织情况考虑进来，以便做出更合理的安排。