敏捷开发“松结对编程”系列之七：问题集之一
人员与结构
在团队中使用层级结构，是否阻碍了个体与外界的沟通？
极少有底层程序员或新手能和产品经理做深入的沟通的，所以中间放上师傅这一层，让其代为问问题，徒弟旁听，不但不会阻碍，反而会促进。
这样徒弟可以更快地学会问答技巧或熟悉业务，真正学成了，师傅才懒得在中间“阻碍”呢，呵呵。
师傅又要懂业务，又要懂技术，又要带徒弟，是否要求太高了？
的确不低，但是如果不要求这三个师傅如此，就要要求全组如此，更难；当然可以要求让程序员们可以不懂业务，但这样的程序员怎么放心让他干活呢。
但实际上，这点要求算不上什么，和“多才多艺”二字沾不上边。所以这种人其实很多，只是他们没被赋予这种职能而已。
师与徒
高手不愿意带徒弟怎么办？
所谓求什么得什么，如果企业给个人能力高的人发高薪，而不给能带团队的人发高薪，屋子里边坐着的一定是一堆不愿意带徒弟的高手；反之则反。
另外一个角度，139团队不只是一个学习团队，而首先是一个生产团队。师傅带徒弟，一定程度上有上级带下级的感觉。还没有一个上级不希望自己有更多手下的，也没有上级希望自己手下都是饭桶的。
所以制度合适，人自然改变。
招聘了徒弟，没有师傅愿意带怎么办？
以往人是招聘来塞给某人“你负责他的成长的”，现在应该是有师傅说“忙不过来了，给我招聘个徒弟吧”。师傅要参与徒弟的招聘和试用。
徒弟不听师傅的怎么办？
试用期就走人。
时间与效率
师傅一个顶仨，照顾别人是否降低效率？
要做好时间管理，就是师傅找徒弟随时，徒弟找师傅预约（“我有问题……”“好，等15分钟……（继续干活至一段落为止）”）。
一个人看那么多人的代码，会不会很花时间？
高手看新手的代码，10分钟就能看到一大堆错误。
师傅看徒弟的代码，5分钟就行；每天早上做了设计，中间还有前后关键点，没什么可看的。
今天看到的问题，明天不可再见，早晚一天无问题可见。师傅是培养徒弟干活的，不是给徒弟擦屁股的（在试用期就要考核这个，不怕起点低，但一个人连培养价值都没有，还能干啥）。
专家与杂家
大家需要了解的东西太多，生产率是否降低？
我见过的最高的几个高手，都是以更广泛地了解业务和技术为特点的。
我见过一个13个人的团队，9年来人换了好几批了，从来都是每人只负责的功能，都是“专家”。产品最后有25万行，被一个高手花一年半改为1.3万行。问为什么原来的代码那么多，答：“原来的专家走了，没人能看懂其代码，所以只能大面积拷贝粘贴。”这样的专家，要他何用。
有些人希望只专注于自己的工作，怎么办？
目光这么窄的人，能做好自己的工作才怪；所知这么窄的人，能委之重任才怪；一直自己干活的人，能管理部门才怪。很多人苦苦钻研技术，希望能力提高然后被提拔，实在是缘木求鱼。道理一讲就通。
如果还讲不通，迟早会发现不想当将军的士兵，连厨子都做不好的，呵呵。
绩效与成长
师傅学不到东西怎么办？
师傅之上还有师傅；师傅人数少，可以送去培训……师徒制度里边没有关于师傅怎么学习的内容，但如果理解“有问题处无答案”，这类问题很好解决。
教会徒弟，会不会饿死师傅？
如果我是老板，我会喜欢下金蛋的鹅，胜过金蛋，因此给鹅更多钱。
如果我是师傅，我会喜欢卖金鹅蛋，胜过卖烤鹅腿，因此能值更多钱。
如果我是徒弟，我会羡慕下金蛋，胜过我就是个蛋（好惨啊）。
徒弟的能力超过师傅怎么办？
我的编程能力超过我师傅的时候，他做部门经理去了，因为我们部门的所有师傅，都是他的徒弟，不选他选谁。
能力的不总是等于编程能力，而是一种在不同年龄不同层次有不同定义的东西，只有这种东西才能叫做能力。
上面这句话套用金刚经语法，就是“如来所说能力，则非能力，是名能力”，刚开始很难理解，但理解了就发现是一种很通用很有效的思维方式。
比如把“创新”带进去，就会得到乔布斯的创新观：我们苹果所说的创新（价值观创新），是不能被模仿的创新，所以才叫做创新（换言之能被那么容易模仿的，还谈不上什么创新）；你们模仿iPod，我就做iPhone，你们模仿iPhone，我就做iPad；你们模仿iPad，我就得胰腺癌……
因为何为“能力”，怎样根据“能力”确定师傅和徒弟，根据什么“能力”来考核师徒，是139团队和松结对编程的核心，所以多说两句。
点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
