敏捷开发一千零一问系列之七：怎样对待有见解的徒弟？

这是敏捷开发一千零一问系列的第七篇。（之一，之二，之三，问题总目录）

问题

松结对编程中，师傅对徒弟安排任务时，对于有想法的徒弟提出的意见怎样解决？

方案

步骤0：

正心，诚意。

人们究竟是在管理一我的（控制，监督，指令）仍是领导一我的（帮助，引导，培养），被管理者和被领导者其实内心是一清二楚的。

所以在师徒关系中，不能为了师徒而师徒，而是要找到师+徒这个体系的目的，把心态放在把事情作好而非维护师徒结构上，从这个角度看问题才能作好下面的事情。

步骤1：

师傅平常要多在收尾的时候检查徒弟的代码，指出其中的问题，以让徒弟正确认识本身的水平。

软件开发有一个好处是比较理性：好的就是好的，没有什么可争辩的；但也有一个坏处：好坏多半在作出来后才能看得出来，十个手指头赛过两张嘴皮子。

因此师傅应该多在最终结果上指导徒弟，徒弟就会意识到若是从头就听取师傅的意见，中间会节省不少无用功。

步骤2：

有个笑话挺逗的，有人问某人你家谁说了算？回答“一半一半。若是咱们两个意见相同，我说了算；若是不一样，我媳妇说了算。”

随着一块儿工做的时间变长，师傅也不用强调每次都有更优答案，反而能够鼓励在大方向一致的状况下，让徒弟本身进行一些“微创新”，这样徒弟不会有一种巨大的阴影感。

步骤3：

在有些时候，师徒都拿不许，这时候应该引入更强的技术力量，就是“师祖”级别的程序员加入讨论。

师傅不要由于本身都要接受指导而感到没面子，其实若是徒弟发现师傅这么厉害都还能尊重师祖的见解，本身天然更加会尊重师傅。

步骤4：

对于接近出师的徒弟，应该将其看成本身思惟的延续，而非始终仅仅看成左膀右臂。

其实不少人都将经历一个放下编程，拿起业务/管理/产品/市场乃至决策的过程，若是始终放不下，就永远拿不起来。

从这一点上说，师傅不永远是师傅，徒弟不永远是徒弟。从这个终极目的出发，反而应该在早期就培养有见解的徒弟，而不是简单地把本身的见解交给他。

培养的要点，在于心和法的培养，即养成正确的思惟方式、价值观、看问题的角度，往后遇到师傅本身也没有遇到过的问题，天然就能轻易解决。

案例

无。

分析

做为一个师傅，要理解实际上并不存在“个人想法”，而是应该存在一个“正确的想法”，所以不该该每次都突出于徒弟的不一样，而是在团队内部造成正确的价值观，鼓励人们“正确地思考”（正确是副词），从而得出“正确的想法”（正确是形容词）。这一点和敏捷开发差很少。

因此师徒团队的目标不是找到一堆能执行师傅想法的徒弟，而是一堆与师傅想法相同的徒弟，进而找到与师傅思惟方式相同的徒弟，甚至超过师傅思惟方式的徒弟。

当徒弟超过师傅的时候，师傅不能想“有人坐了个人位置”，而是应该想“有人替我办全部事了，我终于能够去办更大的事情了”。这是一种“人无我”的想法，就是不能执拗地认为本身就是师傅，而不是更高职位的人。

另外一个很无奈的事实是人会变老，思惟也会僵化（好比多数科学家都是在很年轻的时候作出贡献的，老了之后基本上就是作科普工做了；多数新公司也是年轻人创造的，老了之后公司也会逐渐衰落）。所以每一个人不管职位高低，都应该培养接班人，按照正确的思惟方式，探索新答案。（这个称为“法无我”，就是“法”也没有我，也在变化中，就是以前提到的“无住”）。