软件开发和团队”最小模式”初探2－6人模型（下）

金刚合体和巨人肩膀

6人模式是必须的,而且请注意我这里尽量用了”人”这个名词而不是”角色”,为什么?很多人认为既然是角色,就可以兼职,比如管理兼构架,构架兼需求,设计兼开发,开发兼测试. 这样一个团队就变成2-3人了,也能形成合理的6”角色”模式.

真的如此吗? 但我要提醒大家的是,这6个最基本的人(或者角色),她们面临的内容角度是不同的,她们自己互为影响和监督,轻易把任何角色集于一身是要付出一定的代价的.

更少人的团队模式不是不能成功,软件成功是一个复杂的概念,不一而足,但不完整的团队绝对不能苛求更多甚至于完美; 比如: 无管理就不能苛求时间质量可控,无构架就不能苛求技术统一合理;无需求就不能苛求无返工无争议;无设计就不能苛求软件界面优美t统一,功能精妙易用;无编码(这个…,基本不可能);无测试就不能苛求极高的质量和无暇的品质.

但我也深知很多团队都处于一个“巧妇难为无米之炊”的窘境，没有6个人，或者没有6个合适的人，该如何去做，是否可以以更少人去开发一个软件，关于这个问题，我原则上是不赞成的，但我会给出我的看法。

如果需要更少的人，我们一般有2个办法。

一个人担任2个或以上角色，这个就是“金刚合体”。

我认为，金刚合体有2个主要的原则：

1：不同性质的工作不能合体，这里的不同性质主要是指，交流为主的工作不能和技术为主的工作混合，原因大家都应该可以理解，交流工作偏开放，需要交流和主动；而技术偏封闭，需要一个相对安静的环境来独立思考，这2种工作不易轻易混合。

2：利益相悖的工作不能合体，管理和其他角色，因为有相互监督的关系，不易合并，否则就是自己管理自己？ 构架和开发不易合并，构架可以参与底层的或者范例的开发，这个是没有问题的，但如果还是项目的主力开发，承担了大量的工作，那么构架人员就难免为了减轻工作压力而降低构架的水准。

管理和其他角色不利于轻易混合，管理以交流协调为第一要务,而技术工作需要时间和空间,管理和其他角色必然相互影响,导致事倍功半. 所以我建议管理必须独立存在.

构架是纯技术角色,它需带有交流属性的需求和设计会相互影响,而开发呢,构架进行部分开发还是可行的,但要注意,首先构架人员其能力和主攻方向必然是不断提高项目的构架水平,除非项目的构架已经十分的稳固,牺牲构架的大量时间去开发是得不偿失的,况且在有可替代资源的前提下,让构架这样的高级资源去做普通资源的工作,无论对高级资源的心理感受和普通资源的培养这些角度来说,都是相当的不利.我的建议是,构架可以作为一个主程的身份参与部分编程,比如通用类或者底层代码,但必须严格控制工作量,严禁涉及大量的具体开发任务.而需求设计和构架不宜合并.

需求由于也具有交流特性，如果和构架，开发结合必然会影响其工作效果. 但需求的交流又和管理不同,需求是交流业务逻辑,而管理是信息疏通,人际关系为主,另外需求还是有一半技术分析的部分,这个和管理又是相互影响的.另外需求和设计开发具有互斥性,如果需求来做设计和开发,一则会使需求人员过早陷入细节,而降低他对整体业务的把握;二则设计和开发的困难会反作用与需求,迫使需求让步与设计和开发中的困难. 我的建议是需求要尽可能的独立存在.他可以服务于多个项目,但不要在一个项目里面身兼他职.

设计本身也具备交流的需要，前面说了,设计工作不利于和需求合并,所以很多时候这个接力棒就会交给开发,但很多开发不愿意交流而宁可靠自己的想象去设计，这就是技术工作影响交流工作的一个范例. 而如果迫使开发人员出设计文档又变成自编自导,加上时间压力,开发人员的设计常常是仓促了事,但一点必须明确,设计即使被合并了也并没有消亡,只是这个设计被开发人员隐藏了起来,变的不可控制,不可积累.这个不但造成了当前项目的隐患,对团队日后的不断提高也设置了障碍.我的建议是在人力资源允许的情况下,分开开发和设计,让略强的开发去做设计而不要实际动手,然后让他们去评审开发的工作是否合理.

测试,一般的合并方式就是有开发代劳了,这个我是不太认同的.完美的代码也需要测试，因为测试的角度是需求审核者,他的责任是确认在经过了设计和开发以后，需求有没有丢失；那么需求以后的设计和开发就不适宜带着自己的理解来审核自己的工作，所以他们不适宜做测试;但需求者是可以测试的,但很遗憾的是,一般需求者不会愿意干这个脏活累活,另外技能也需要重新学习.我的建议是,要么需求者来测试,要么就独立存在.

 

除了金刚合体,另外一个可以减少角色或者其压力的方法是”巨人肩膀”.

巨人肩膀来自于2个方面:

l  公司积累

l  业界标准

由于软件项目的独特性,管理,需求,开发和测试由于和实际项目的独特需求有关,即使存在可供使用的标准,也只能作为工作的指南,而不能成为工作结果本身.比如已经达到CMMI3水平的团队也不可能去除管理,因为每个项目的管理内容不同,遇到的情况也不同;

我认为,能够利用巨人肩膀的是构架和设计.在一个特定的软件领域,如果公司已经形成的相当的积累,或者说业界已经有了相当成熟的标准,那么构架和设计大可不必亲力亲为,而可以稳稳的站到巨人的肩膀之上.如一个成熟的游戏公司,其开发一个新游戏的构架基本可以沿用以前的构架,另外一个网站的设计后台的构架,完全可以沿用业界已经成熟的方案.

那么,如果有了巨人的肩膀,是否就可以省略构架人员和设计人员了吗,我的答案还是否定的.

首先,公司的积累绝对不是无中生有,它就来自于公司每个项目中的构架和设计人员的点滴汗水,公司的积累和构架设计人员的存在本身就是一个悖论,因为有了他们的存在,公司才得以积累下一些财富,而财富的不断增加才使得他们的压力得以解放,反而言之,一个从开始就不重视构架和开发人员的团队,根本无从积累,所谓的”公司积累”这个巨人只是镜花水月.

那么”业界标准”呢,拿来主义能不能代替自己的构架设计人员,我认为也是欠妥的.牛顿的”巨人肩膀”之说其实只是一个谦词,牛顿本身就是巨人,在登上巨人肩膀以前,你自身必须能够爬上巨人的手臂.业界的标准模式,构架体系只是熟菜而已,它们比生菜是有所进步,但还是需要消化以后才能进入团队,成为团队适用的财富,而这个消化人就是我们的构架和设计人员.

总之,我认可”巨人肩膀”的存在,如果运用恰当,的确可以大大减少构架和设计人员的压力,但我认为,巨人肩膀的存在不是对构架设计人员的否定,相反,优秀的构架和设计人员才是巨人肩膀的前提, 当一个团队得以踏上巨人肩膀的时候,恰恰是构架设计人员辛勤耕耘得以回报的时候.

简易团队构建指南

第一步:寻找领航者.

在团队中寻找一个管理者，并赋予他一定的权力，我对这个管理者的建议是：

1. 具有一定的交流能力，不能是“纯技术人员”（大家懂的）
2. 如果没有管理技能要进行一定的项目管理培训，磨刀不误砍柴工。
3. 开发技能不能空白（这个与我的理论稍微矛盾，但我认为小团队的领导开发技能不能完全空白，而且一般的团队里面选拔出来的管理者也不可能空白）
4. 有一定的资历和威信。
5. 最重要的一点：尽可能的分离他的非管理工作，让他去管理！

 

第二步:确定技术制高点

我们搞技术的，大家心里都有一杆秤，谁更厉害点，一目了然。所以寻找团队技术高点不是问题。问题是要把这个技术高点搞成构架人员才有困难。我对构架人员的建议是：

1. 必须是团队技术最高者（除非有严重性格问题）
2. 大家可以对构架集思广益，但构架者才是决策人，他是技术的领导。
3. 尽量减少其具体开发，让他可以思考，总结和写文档。如果有更多的人手，让他去教别人，审核别人，不要让他做。（在次级人员水平差距太大的情况下，他可以写通用和后台代码）
4. 鼓励他尽可能总结，思考，写文档，培训，审核，而不是具体开发。

 

第三步:需求分析师

         选拔对客户交流有特长，同时也是团队里面的技术骨干的人来做需求，最好有5年以上的经验，不要拿新人去做需求。

1. 愿意并且也有和客户交流的特长。
2. 技术能力不弱，能理解构架者的技术选择。
3. 擅长需求开发方法和工具（比如UML）。
4. 尽量不参与具体的设计和开发，保持其需求全局感。

 

第四步:高级开发来设计

         设计一般来自比较高级的开发，但比较纠结的是开发往往不够，但这不应该是理由，因为即使没有设计，所有的开发也必须自行设计，所以抽出1－2个开发做设计是磨刀不误砍柴工。完整明确的设计可以省下开发一半的思考时间。

我的建议是：

1：开发中的高手，对系统设计有合理的认识。

2：能在美工的协助下做原型

3：一个设计可以对2个开发，设计规范成熟的团队可以对3－4个。

4：设计可以审核开发的代码，并引导他们理解自己的设计。

 

第五步:培养我们的开发

前面的文章我已经说了一个大概的思路。

1. 通过一定的编码规则磨练其自律性。尤其是注释。
2. 不断自检：Code Review 和单元测试。

 

第六步:加入最后的防线

尽可能的加入测试人员，来协助开发人员。我的建议是：

1. 测试开发比例，1：1达不到，就1：2或者1：3，再少就压力太大了。
2. 培训基础的测试技能。

 

 

6人模式还仅仅是起步

        CMMI3的最底限度团队是20人,6人团队仅仅是吊丝们没钱又想过上好日子的一点自我挣扎;别人是针对千万級项目的,而我们仅仅是拿来做10万级项目.

         那么我们就說CMMI2吧,CMMI2已经要求完成配置管理,需求管理和QA的监督,6人团队谁来做,有人会说,不是有项目管理可以做配置,需求分析可以做需求管理,测试可以QA吗; 我只能苦笑. “又要马儿跑,又要马儿不吃草”,这已经是一个笑话了,现在还要马儿能飞,是不是想缔造一个神话呢? 我的看法,还不如先让马儿跑起来看看吧,至少还是在跑了. 所以说6人模式,也就一个CMMI 1.5 的水平,再上去不过是自欺欺人而已;但我觉得无需气馁; 我所知道的是: 6人模式已经可以让团队初窥门径,登堂入室,让团队中的每个人都能够慢慢的思考,细细的品位,一个真正健康的软件团队应该需要什么,如何去做,自己的职业生涯方向何在,为团队和个人的进一步发展,打开一扇天窗,做到了这一步,已经是非常了不起的进步了.

最后说一个题外话，一个团队的长期稳定的健康发展最终还是取决于2点：

l  团队的自我发展和积累

l  个人的上升通道

         我提出的6人模型也考虑了这2点，为团队的未来未雨绸缪：团队的积累来自与每个分工明确的角色对自身独特技能的不断钻研，并在实际工作过程中的不断总结，一个分工明确，空间充足的模型，为每个角色上的人提供了独立思考的机会，他们经验的汇聚，形成了团队的自我发展和积累。另外，开发－设计－需求－构架－管理，正是一个开发必经的发展之路，只有脚踏实地，步步为营，才能在自己的职业生涯中走出一个个坚实的脚印。

最后，我还有点梦想，我梦想我们的软件人能够突破环境和条件的约束，以自身的远大理想为基础，加上对软件开发的无限热情，勇敢的去开拓自己和公司应该去走的道路，绝不能浑浑噩噩，得过且过和固步自封，不管以什么样的模式，都必须去寻找软件开发的真谛。

 

注：以上不是结束语，后面的章节，我还会对我现在正在实践的流程做一些方面的展开，把6人模型推向实用化。

软件开发,项目管理,开发管理,团队管理. CMMI,PMP

http://www.cnblogs.com/zergcom/archive/2012/08/03/2622192.html