本文是“松结对编程”系列的第六篇。（，，，，，，，）

松结对编程是小型团队的实践，大约运行在1个师傅+1～3个徒弟的尺度上，当面临更大尺度的时候，就需要大型团队模型。这里推荐139团队模型，因为它不但可以让松结对编程运转顺利，还解决了大团队沟通、绩效考核、师傅的出路等问题。

139团队的整体情况相当复杂，将另有系列博文描述，这里只描述与“松结对编程”相关的内容，以保证本系列博文的完整性。

基本概念

139团队就是1个项目经理，3个师傅，9个徒弟的简称，当然实际上未必正好凑够13个人，也未必正好每个师傅都有3个徒弟。

在第一篇里边已经提到过三个层级的工作关系，下面是一些深入的剖析。

绩效考核

绩效考核历来是软件业最头痛的问题，按代码行考核吧新程序员写的垃圾代码比高手多，按任务数考核吧任务大小不一，按功能点考核吧多数人不会数，按工作按时完成率考核吧师傅还帮不帮徒弟了？……139团队大致有个答案：按1-3-9的层次安排大致薪金和奖金比例（在139团队系列中有详细分析）。

139团队认为绩效考核首先是团队的整体绩效；在分解到个体时，不是看具体每个人干活多少，而是看在团队中所起的作用。

所以，想加薪？带徒弟吧。不过有一点，带一队没用的徒弟是没用的，首先要有团队绩效，才会有个人绩效。

人员招聘

人员招聘一般在较高层进行，最低也是项目经理，但是最终带新人的却是师傅。所以招聘的时候应该请未来的师傅也在场，部门经理/项目经理可以问师傅“这个人给你当助手，你觉得够吗？”这个问题我最近正好问过，师傅的话语权很重，因为如果他不喜欢，下面的配合会很难。如果是招聘师傅，项目经理心里要对此人和现有师傅水平的高下比较有个概念，尤其是沟通和教学能力。

师徒的差异既不能太大，也不能太小。太大学不明白，白耽误师傅的功夫；太小没什么可学，还可能引发冲突（经常半斤大战八两，如果其中一个是二两就打不起来了）。如果理解了松结对编程的上述实践，在遇到实际人员的时候实际情况实际分析一下就可以了。

职业生涯规划

徒弟学好了可以做什么？可以独立工作，比如新出现一个模块或业务，可以单独交给此人开发（要配代码审查人）；做得更好了可以做师傅，带徒弟。

师傅学好了可以做什么？可以做项目经理。比如如果有个师傅带了多达3～5个徒弟，而且还想增加人，那么他的那个模块多半要分拆为一个子项目了，而分拆后，师傅是新项目经理的最佳人员。

之前呆过的一家高成长性公司，去的时候只有18人，一年半以后就达到120人了，而业务骨干多半都是当年的徒弟，而不是新招来的高手。究其原因，一则业务壁垒不是刚招来的高手能突破的，二则师徒制度使人成长很快。最初大家并没有正式的师徒制度，但是项目经理无私地指导大家，为团队成长和后来建立师徒制度建立了条件。本人刚去的时候工作五年了，还不知道申请的内存要删除（C++），现在的编程功底基本上都是在这家公司学成的。

主程序员团队

如果遇上一个顶十个的师傅，也有团队模型就是主程序员团队。师傅干活，徒弟打杂+学习。本人用过两次半，都很成功。主程序员团队的工作方式更“松”，但也有其工作模式和师徒制度，本博客中已有一篇博文与之相关。

主程序员团队不如松结对编程团队健康和有潜力，个人感觉只适合某些情况。

本文未涉及的139团队内容

自组织团队的激励机制，大型团队的计划会，大型团队的每日立会，大型需求团队与开发团队的配合，强分工团队的工作方式，139团队详细的绩效考核/非物质激励等内容，将在139团队系列中展开讨论。

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

139团队是应用松结对编程的大型敏捷团队，在其3-9级别上适合松结对编程过程，而在整个层面上适合Scrum过程。

139团队解决了绩效考核、人员招聘、职业生涯规划等一些大团队问题，从而为小团队（师徒团队）应用松结对编程和日后健康成长铺平道路。

 

本文是“敏捷开发松结对编程实践”的最后一篇，本系列所属实践仅适用于几个开发人员的微观环境，其外围大型团队的实践请参考“大型敏捷开发团队：139团队模型”系列。

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

后记

任何开发方法都有局限性，也都有可取之处，松结对编程也不例外。

笔者在多年开发及咨询过程中，逐渐发现所有研发方法都会遇到困难，而所有研发方法经过变形都可以某种方式应用下来。关键问题在于，在遇到困难的时候不要因为困难而否定方法，而要积极为解决困难寻找答案。格言说得好：不是缺少发现问题的眼睛，而是缺少解决问题的手。

松结对编程本身就是在实际环境中应用敏捷开发和结对编程的时候遇到困难后的变形，所以在应用松结对编程的时候如果遇到困难时，办法只有一个：继续变形。

敏捷开发传入中国已经10年了，但是如果问哪家企业非常成功地应用敏捷开发，谁能出来好好地讲讲案例，几乎无一能者。究其原因无外乎两个：

1. 过于迷信方法，因此尝试原封不动地使用方法，结果水土不服遭到失败。

2. 过于不迷信方法，尝试失败后就轻易放弃。

整个过程中最容易被忽略的，是实践者自身的创造力。其实早在创建Scrum的时候，Ken就指出Scrum只是一个起点，他建议人们从原装的Scrum入手以保持稳定的过程框架，并进而自行发挥。但多数人在应用时，都过于喜欢查书，百度，google，找培训课程，看博客——包括这里，只要还找不到的，也不再尝试不再创新，这就背离了创始人的初衷。

个人感觉凡是不违背敏捷之神的研发管理方法，均为敏捷。所有敏捷的实践者，都应该在敏捷的大框架下，跟着自己直觉和本能的引导，去创造适合自己的敏捷实践方法。

 

点击下载免费的敏捷开发教材：《》