敏捷开发“松结对编程”实践之一：人员结构篇（大型研发团队，学习型团队，139团队，师徒制度）

本文是“松结对编程”系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八）

传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。

传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。

一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况。

二是来自基层的，两人若有高低，高手肯定觉得还不如我一个人干的快；两人若旗鼓相当，难免产生争执。

其实在我们身边一直有一种方法很像结对编程：“师徒制度”，就是每个新人来到公司，都指派一个师傅带着，在技术与业务方面提供指导。他们既不用一台电脑，也不是老死不相往来，这其实就是一种“松散”的结对编程。只不过多数企业虽然有这种制度或实践，但却很少有很清晰的定义，难免限制了这种实践的效果。本系列的目标，就是从人员结构、计划实践、日常工作实践、绩效考核等各个角度，来完整地思考和建立这种制度。

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

挑选小组长（师傅）基本原则

乐于助人，有责任心，善于沟通，擅长管理，技术精湛，业务精通……很可惜，好词汇越多，越难找到符合的人。不过，一些基本原则还是要考虑的：

1. 尽量找对业务有兴趣的人

整体上偏业务的人未来有更好的发展（这是我2001年的上司的原话，事实证明很对），由于有行业壁垒也较少跳槽。由于小组长角色未来将被提拔为更高的项目经理、产品经理，对业务的了解也会为此做好铺垫。

2. 尽量找善于沟通的人

善于沟通的程序员成长更快（还是那位上司的原话），也更能帮助别人成长。

挑选组员（徒弟）基本原则

1. 徒弟能力一定要低于师傅（应该说：师傅一定要高于徒弟）

很常见的一种做法是把几个水平相当的人放在一起工作，认为这样他们可以互相学习，其实不然。

之前我们在的项目组经常发生技术“争论”，发生的次数多了，我们发现一个规律：每次争执不下的，都是两个技术相当的人，而每次争执的解决，都是一个水平更高的人给出一个截断众流的方案，然后大家散去。

2. 徒弟年龄不要太大

如果有两个水平相当、月薪要求都是6000的程序员，当然找年轻的了，有发展潜力，后劲足。

挑选组长（大项目经理）基本原则

1. 项目经理必须喜欢业务胜过技术

项目经理是掌舵的而不是干活的，因此必须对业务有深刻理解。

2. 项目经理最好精通技术

这里不讨论是否存在“不懂技术却精通管理”的项目经理，但是如果目标是项目成功而非证明奇迹的确存在，项目经理应该首选那些从小组长成长起来的既懂业务技术又精湛的人选。

这里的“精通技术”不是从技术实现层面考虑的，而是从“技术想象力”层面考虑的，就是说他必须能想象到有某种技术存在。比如以前我们遇到一个程序员写了一大堆重复代码，原因就在于他的想象力受到了局限，明明有虚函数、模板等各种方法来简化代码，却没有想到。“没有学到”是无法避免的现实情况，但“没有想到”是可以避免的。

团队结构和运行理念

既然待在某个“位置”上，每个人必有不同的职责。这里就不一一列出了，因为猜都猜得出来（比如师傅要带徒弟之类）。下面只列出松结对编程与一般小组的核心差异。

1. 对每个小组（师傅+1～3个徒弟）整体考核

也就是师傅要负责到底，不能出现“他刚来所以把事情办砸了”的情况。这里的负责到底，包括计划、估算、跟进、进度、质量、徒弟成长……等一干事情，本系列的其他文章中都将展开描述。

2. 在工作中学习

尽管“松”，但还是“结对编程”，学习和指导过程实在生产过程中集成的，因此师徒关系的成败不只是人员成长，还包括任务和项目的成败。这首先是一个生产团队，其次才是学习团队。

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

人员挑选好了，接下来就是要进行计划、跟踪等日常工作，请参考本系列的其他文章。

由于这是本系列的第一篇文章，请关注本博客blog.csdn.net/cheny_com。

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》