软件开发和团队管理

2大伤痛

软件开发了这么多年，也带了很多的团队，真的没什么心得，只能说有点感慨。

软件开发到底难不难，这真的是一个问题，刚刚毕业的时候，觉得做软件乐趣很大，困难很很小，结果呢，到现在还没有一个项目令自己满意。既然不难做，但为什么就是做不好，这真的是一个揪心的问题。

软件团队到底需要多少人，这已经不能称为一个问题，而是一处伤痛，初出茅庐的时候也曾经认为一人一机就是软件，但遥望印度千人团队，真心不知道他们在干嘛，为什么要那么多人，难道他们都很苯？

如果说有什么心得，还不如说我心中的2大伤痛，以搏一笑：

1.       软件只需要开发就可以完成，团队只需要开发就可以组成。

2.       软件出了问题是可以改的，而且不难改

 

软件就是开发

也许大家会笑，当事实上大部分人都会被这2个问题伤到，而且伤了好多年。

软件只需要开发，这个看上去是一个很浅显的道理，就像古龙式的大侠那样，杀人就是用刀划过敌人的身体，就这么简单；是的，软件开发就是把代码编写出来，编译运行，交给客户，的确就这么简单。

细细品位这第一个伤痛，我发现这个问题其实是看似偶然中的必然；软件的最小组成就是代码，有了代码就有了软件的实体，有了实体就可以认为完成了软件，这个是非常实际的想法。加上老板最关注的是项目的成本和时间，那么为开发团队增加开发人员看似是最“有效经济”的方法，一人开发一周，那么2个人最不济开发3天应该够了把――大家都会如此思考。

当然，软件开发还真的是神奇的所在，它的一个神奇之处就在于，无论如何，软件的生产过程还是可以完成的，无论如何，在一定的时间和努力之后，软件还是诞生了，他的诞生时候似乎是必然的，不可阻挡的,那么我们还在担心什么呢。

 

软件没有失败

有人说,软件完成仅仅是万里长征第一步,还差的远呢,客户的要求还远远没有结束. 真正的修改还在后面.是的,软件开发的第二个神奇之处就是,软件可以通过不断的修改来弥补以前的错误,不管你提交的软件是100分还是20分,它都可以通过不断的修改而继续存活下去,可以这样说,只要还能修改,软件就没有失败,那我们还担心什么呢.

2大神奇法则

这里,我们引出了软件开发的2大神奇法则:

1.       软件只需要开发就能进行,并且基本都能完成.

2.       软件只要修改就可以存活,而且很少最终失败.

首先,我们必须感谢这2个神奇的法则,它大大降低了软件开发的入行门槛,使得很多团队和个人,即使懵懂幼稚,即使身无长处,亦能昂首踏入这个行业,以各种各样的姿态开始自己的职业生涯.

其次,这2个法则也深深的伤害了很多团队和个人,在进入这个行业若干年以后,很多人发现,这2个法则所营造的就是一个迷魂阵,一个无底洞; 软件总能完成却从未结束;软件不会失败却从未成功; 困惑与当下的实践,迷茫于未来的发展.

 

我在担心什么

我在担心什么,其实我也说不太清楚;

首先,那些必然完成的软件没有给我和我的团队任何美妙的感觉,做的好不好,是否可以算成功,这个问题几乎没有人可以回答,那么自然也就没有答案了.

其次,永无止境的修改,最终的结果只能是伤痛,日积月累的疲惫感,不断受挫的成就感,加上毫无希望的未来. 几乎没有人会喜欢这种”永不言败”的感觉,团队的崩溃和软件的摆烂,几乎是必然的结果.

最后, 梦想和发展,几乎已成奢望,遥望欧美令人羡慕的先进开发方式,展望自己30岁以后的发展空间,总是觉得那么遥不可及,对职业生涯的希望已经到了破碎的边缘.

 

寻找突破

如何突破,无非是自身寻求突破和效仿先进模式;自身寻求突破太过理想化,如果自己有这个能力,要突破早突破了,何必等到现在.

效仿他人先进模式是必然的,当也绝不能盲从: 别人的先进模式是大学毕业水平,而我们刚刚走出幼儿园,怎么学,学什么,并没有想象那么简单.

这里就谈2个大家都耳熟能详的模式: CMMI和敏捷开发.

CMMI是一个非常不错的体系,当我希望大家知道的是,CMMI就是大学毕业水平,给我们这些幼儿园和小学的小朋友来用的确是有点一知半解. CMMI2 就基本要求到20人团队(一个项目),试问一般中小公司有多少单个开发团队可以到20人? 更不要说团队内部的人员素质是否达标这个问题.也有人谈到裁剪,这个是没错的,但问题是谁来裁剪? 让我们这些小朋友来裁剪大哥哥的论文? 靠谱吗? 难上加难. 我也曾寄希望与国内的CMMI培训团队来帮我们裁剪,最终也是发现这也是勉为其难. CMMI能用,但全用是邯郸学步,裁剪是困难重重.

敏捷开发,这个更是一个冷笑话,敏捷开发是什么,是高中水平吗,完全错了,敏捷开发是研究生水平,是参透了大学水平的更高层次的升华,软件开发没有”银弹”,没有捷径,如果小学还没有毕业,就先用研究生的手法来解题,其结果只能是彻底的失败. 我的看法是,如果CMMI2都觉得遥不可及的团队,不要轻易尝试敏捷开发,先打好自己的”内功”根基.

 

我的”银弹”

l 学习:学习了解先进模式和理念

l 自省:认真分析自身团队和成员的能力

l 定制:寻找最小模式,从零开始,重新组建合理团队,搭建合理流程.

l 发展:走上不断积累提高之路

这里我认为有以下几点心得:

不去了解先进模式是闭门造车,必然失败.

不根据本身团队情况是盲目改革,必然失败.

软件开发有其规律,最小模式绝对不是”两把菜刀闹革命”,没有办法获得最低资源要求,就不要改革.

如果你的改革不能形成有效的积累模式,就不要改,改革为的是将来不断壮大而不是现在解决一时疑难,没有发展通道的改革还不如不改.

 

CMMI 2 , 1 还是1.5 ?

首先说个老实话,软件开发是没有什么所谓最小模式的; 如果可以我并不希望去尝试所谓的最小模式; 现在开开1-2万的二手小车是没办法,并不代表我愿意一辈子开这种车.

CMMI3 认证要求最少有20人参加,其实是给出了一个硬性的指标,要保证CMMI3所能达到了质量要求,大部分流程域是不能裁剪的,那么就要保证有足够的资源去做正确的事情.

也许是我没有赶上好时节,我所经历的项目和团队,还真的没有单个20人的规模,不过团队是小但也是要活下去的,不管如何,生活还必须继续,软件还是要完成.

也许小团队一定要上CMMI3 还是好高骛远了,那么我们来看看CMMI2, 但CMMI2也不是省油的灯, 里面竟然已经包括了QA管理,配置管理,需求管理和度量管理, 这些东西已经不是5个人以下的团队能够运作的了,这4项工作我认为至少增加3-5人的辅助管理量,加上与之配套的开发团队成员,整个规模保守估计应该在10-15人以上,说老实话, 对于一般的软件公司,这个规模也有点勉为其难.

怎么办,再减? CMMI初级是完全”懵懂”模式,几乎所有团队都可以达到,这里我就不加说明了,那么CMMI2 似乎已经就是最底限度,小于10人的团队真的与CMMI无缘吗?那些过程域真的是一个都不能再剪吗? 这个CMMI专家们是没有答案的,唯一的途径,只能靠自己去摸索—就像怀揣了1-2万还想开车的吊丝们,唯一的办法就是自己到二手车市场去淘.

于是乎,对这个介于CMMI2和CMMI初级之间的”最小模式”的探索开始了.

首先我必须说明我个人的3点看法:

1.       “最小模式”是我个人容忍的最底限度,如果这个都达不到,我个人认为你不是在做软件,而是在玩软件;也许有其他的高手也认为我的”最小模式”是在玩软件,同理.

2.       “最小模式”的软件质量必然低于CMMI2 标准,软件开发没有侥幸,减价不减量的好事情从来都是没有的,当然我个人认为”最小模式”的质量还是可以接受的,否则我就是误人子弟了. 当然有可能只是我接受,大家还需要自行判断.

3.       “最小模式”是给现行的,迷茫的,一些小团队们一个建议,一个起点,我还是希望大家能从这里起飞而不是终止,正如我开头说的那样,没有人愿意一辈子做所谓的”最小模式”,人总是要有理想的,1-2万的车刚工作开开是可以理解的,一辈子开是要被人鄙视的.

2条主线. 4个步骤

如果说真的存在一个最为简单的模型，我认为软件的开发过程必须存在2条主线和4个步骤。

 

2条主线就是管理和技术。

4个步骤就是需求,设计,开发和测试。

 

2个主线是双轨，4个步骤是车厢。无轨车子无法行驶，无车――这就不谈了，这个就没意义了。

这里需要说明的是，4个步骤仅仅是软件执行过程的内容，其关注点是软件开发的生命周期而不是项目，项目的运作还需要更多的考虑，就像火车的行驶，需要出站和进站的过程，行驶过程还需要监控，这样才能保证安全。项目的运作我们暂且不提，我们就说软件开发，看看我们最少需要点什么内容。

管理

管理是什么,如雷贯耳到不需要解释了;项目管理,开发管理,团队管理,这些名词都是耳熟能详. 我认为3个人以上的团队就需要管理,不说别的,就是让3个各自为战的程序员能够在规定的时间,规定的技术做出规定质量的软件,这个就很像一个神话故事了. 一句话,管理者不可或缺,目前软件的规模越来越大,孤胆英雄或者喋血双雄式的开发团队已经非常少见了,那么绝大部分团队都必须存在”管理者”这个穿针引线的角色.但很多场合下,大家对管理者都有偏见,大家都认为这是一个闲职,工作量估计比我们的公务员还低,不就是发个通知,买个晚饭的人吗.所以大部分管理都是以兼职的身份而存在,最为常见的是,技术高手顺便管理一下即可. 我想说的是,管理的工作其实非常的繁重,也非常的关键,管理对软件的质量,时间,团队,能力和最终成功与否,起到了至关重要的作用,

管理不但要有,而且要专职,没有专职管理的团队就是没有司机的车,我真的建议你不要上去.

技术

技术,这个太简单了,没技术能做软件吗,团队有大有小,但里面的开发人员谁没有2把刷子.所以,技术是最不是问题的问题.真的是这样吗.

这里,我需要提出另外一个概念—构架,构架是什么,软件开发者都有自己的看法,大家也知道构架师是一个了不起的岗位,也成为了很多软件人的梦想.构架是什么,我的理解就2个字:驾驭. 能驾驭的技术就是构架,不能驾驭的技术仅仅是理论. 构架代表的不仅仅是技术本身,而是对技术的理解,领悟,经验和积累,就像开客车的司机,他不但要有特殊的驾照,还需要有多少年,多少路的客车经验,如果什么都没有仅仅是会开车,这里面的风险就足够毁灭一次长途旅行.

构架和驾驭有3方面的问题需要考虑:

首先是深度和广度: 构架必须涵盖项目开发所有的问题,请注意是所有,任何开发中的问题最好都已经有一个成熟的方案来应对.这也许是一个很高的要求,但我们必须要明确这是我们构架发展的方向.比如说,这个项目某个问题没有好的解决方案,那么下一个项目就有了,若干项目以后,构架的深度和广度就能有很大的提高. 其实不管是什么等级的问题,就必须有成熟的方案而不是留给开发人员自我发挥,比如Web项目,不仅仅是性能,安全,报表这些高级问题需要解决方案,就一些基础问题如转页,Session,上传等等都必须有成熟的思路;这就是广度和深度和含义; 很多人热衷与遇到问题找谷歌百度,而且谷歌百度的确也找的到临时方案,这里暂不提临时寻找方案对项目进度造成的冲击,我就说一点,很多梦寐以求的构架师,难度就是谷歌百度一分钟就能取代的吗,其中奥秘大家一想便知.

其次是统一: 这个是很明显的问题,构架必须统一,开发团队里面的每个人,其技术路线都是不同的,对构架的理解也不同,但一个项目的构架必须统一,统一才能驾驭和控制,统一才能保证项目质量的水平一致.构架的广度对统一有很大的影响,广度越大,每个人自我发挥的余地就小,统一的部分就多,构架就越容易驾驭.这里多说一句,很多新手程序员对既定的构架压缩自己的发挥空间非常的反感,我这里要诚心的告诉这些新人,构架定义良好的团队是你的福音, 一个让新人随意发挥的团队才是真正的坑爹,切记.

最后是积累和培训: 构架绝对不是只存在于当下项目,当下团队的产物,没有一个构架师可以在他的第一个项目就形成一个”惊天地泣鬼神”的构架,构架需要在大量的项目中不断的积累和提高;另外构架绝对不是一人或者一群人的专属,离开了特殊的人或者群体,构架应该依然有强大的生命力,这就是培训,构架应该便于向各种各样的后人传授,传授的越快越便捷,构架的成熟度越高.

 

需求   

需求就是要明确做什么，明确了做什么才能作对；但软件是一个很神奇的东西，不知道要做什么就开始做了这个几乎是经常发生的事情。不知道要做什么也能做完这个也不是什么稀奇的事情。

需求不仅仅是一个业务的东西，更是一个共识和契约；需求不可能穷尽，客户想要的一定比我们能做的更多，而开发团队则要求一个稳定而合理的范围。

面上的需求虽然也是需要点技巧的，但大部分人还是能够理解并交流的，这些需求大多流于客户需求范畴，就是搞清楚客户想要什么样的软件。而需求的问题常常发生在2个方面： 可实现性和稳定性。 说白了，需求最终还是要技术拍板能不能做，另外还需要客户和开发团队达成共识，做到什么范围为止； 不知道大家有没有发现，可实现性和构架有很大的关系，而稳定性则需要博弈，这里就需要管理者的协调，当然这里还有商务问题，这个就不在本文的范围以内了。

 

设计

设计就是我们应该怎么做，我们的软件是什么风格的，什么套路的。开发者经常忽视设计而相对重视需求，原因很简单，开发者不能决定需求，但可以决定设计，因为设计是技术范畴的东西，但这就恰恰是设计的问题所在。

         第一个问题是设计的合理性，这是大家常常忽略的问题，因为合理性不仅仅是技术问题还是需求问题，大多数项目中，客户的需求常常延伸到设计，尤其是界面和用户体验。所以原型确认被越来越多的提上议事日程，在需求阶段就加以解决，甚至作为需求的身份出现。这是一个问题.

         另外一个问题是设计的统一，因为设计是技术范畴，那么开发者几乎人人可以设计，比如增删改页面，毕业生都会做，但大家的风格必然各不相同，但一个软件必须有统一的设计，而且要统一所有的细节，这个问题就必须在设计阶段给予解决。很多时候会出现形似神不似的问题，细节设计问题防不胜防，造成软件大问题不多，小问题遍地的尴尬局面，面对严格的客户，这样的软件难称专业。想到这里就不难去理解，小日本为什么要写那么罗嗦的设计文档了。

开发

         开发是大多数软件人的看家本领了，但事实上大部分人并不是太会编程，或者在学会编程以前就去做其他事情了。

         开发注意2个问题：自律和自检。

         首先看你有没有规范，就是你写的代码有没有套路，最明显的标记就是注释。这里面的问题大部分人都有自己的心得，我就点到为止。

        第二个问题是开发的自检，流行的方法是Code Review和单元测试，Code Review需要第三方的介入，比如双人编程，而单元测试需要编程以外的能力，这些都需要人力和时间的投入，所以也常常被人忽略。开发的自检不仅仅是为了公司和项目，也是为了自己，大家可以反思下，从自己开始编程以来，编程能力提高了多少，都是如何提高的，就能体会我这句话的深意。

测试

         测试是验证软件的正确性，当然主要是需求的一致性，不过很多测试都会忙于侦测代码的漏洞，这个其实是在为整个开发团队买单，包括构架人员。

也许，对于一个真正的开发人员来说，真的不需要测试了，他的代码基本是完美的；但我还是想说，还是给我一个测试吧，古诗云“不识庐山真面目，只缘身在此山中”；再神奇的开发都不能完全发现自己代码的问题，更何况，软件是需要用另外一个视角去审核的。

         测试的东西说老实话我也没有太多深入的研究，我只是想告诉大家一个好的测试人员是开发者的守护者和老师。据说微软用资深开发做测试，这个估计就是极致的模式了吧。

 

6人模型

上一篇文章说到了“2条主线和4个步骤”；那么顺理成章的，我的软件开发和团队“最小模型”就是6人模型。在展开6人模型以前，我必须阐明以下几个观点作为6人模型的总则：

l 首先，我之所以要用6人而不是6角色，就是想暗示我认为6人各自独立的必要性，而反对合并和兼职（虽然我对兼职也有一定的理解――请查看以后的章节：金刚合体和巨人肩膀），我认为6人可以不必全程参与，但不要合二为一。

l 6人是最小模型，6人缺一不可，缺一则伤及软件质量的根本，或者说，软件质量会减低到我能容忍的极限以下，但是否达到我的质量标准不等于软件成功的标准，这个大家要有清楚的认知。

l 6人具有各自的专业领域，各自有独特的方向和技能。也许我们的团队暂时找不到6个绝对合适的人，但我们必须承认这是我们的方向。

哪6人？他们需要会什么并做什么？

1.       管理者

2.       构架者

3.       需求者

4.       设计者

5.       编码者

6.       测试者

管理者

遵循管理主线的团队领导,引领航行的舵手和船长.

管理者需要软件项目管理的技能。

管理者是“闲职”吗，答案肯定是否定的，我们不扯PMP  9大领域，5个环节，我们也不扯CMMI关于各种管理的长篇大论，我就指出我认为管理者不得不做的4件事情，大家来看看我们需不需要这个管理者。

1.       时间管理：计划告诉大家要做什么，监督了解大家正在做什么，做了多少；审核保证大家的工作已经完成。告诉我，如果没有管理者，谁知道，大家需要做什么，现在做了多少，未来什么时候做完。

2.       沟通管理：软件开发不是独立存在，有随时要求更多的客户，有期望永远大于实际的高层，每天都有不同的人希望了解，交流和变更软件开发的内容和进程，这些交流工作交给只愿意带着耳机闷头开发的人合适吗。

3.       团队管理：3人成党，4人成帮，人的问题总是比代码复杂的多，无论组织个小型的饭局，还是解决每个人的烦恼，这里总需要一个协调人的存在。

4.       风险管理：软件开发有风险吗，有，而且大到任何人无法相信，从来没有按时完成的软件计划，从来没有符合需求的软件产品；那么谁来带领大家未雨绸缪，在风险到来前做好一切准备，把风险的影响降到最低，只能是管理者。

构架者

遵循技术主线的团队领导,软件开发最终还是技术活,技术高低决定软件的层次高低。

构架者需要精通项目相关技术，并具有相当的应用经验，能够选择和驾驭相关技术给出项目的合理解决方案。并且该解决方案可追踪，可执行，可培训。

首先构架者需要了解一定规模的该领域的相关技术，以便于根据不同项目要求进行选择，构架者需要有足够的技术储备。

技术选择了还不够，构架者需要对其的可执行性具有相当的把握，自己都不会，奢求其他人无师自通？最典型的构架笑话是，大家就按某某构架自己做把，自由发挥，如果大家利用一个构架都没有你来的透彻，那么你为什么不能先行消化，让大家少走弯路，减少质量损耗；反之，如果有人对构架的理解比你还高一筹，那么为什么让你来当构架者。

最后构架不能仅仅考虑能否实现，还需要考虑延伸属性，比如性能，稳定，并发等等问题。这个就需要积累，非一日之功。

需求者

需求是软件存在的理由,满足需要是软件成功的主要标准,需求者是原始需求的发掘者，并加以整理和抽象，成为软件的需求.

         在整个6人模式中，管理者应该是完全的非技术人员（虽然很多管理者是技术出生，但在我的模型里面他的技术职能几乎没有）；而需求者是对半开，为什么怎么说，需求者分2个阶段。

l 需求挖掘－客户交流

l 需求开发－系统分析

需求挖掘需要的是交流能力，逻辑能力。

而系统分析，需要的是逻辑能力和软件设计，分析和一定的技术功底。

需求人员需要从客户那边挖掘（请注意不仅仅是记录，因为很多客户不了解自己的实际需求），然后抽象，分析并设计出一个软件的雏形，给设计者提供前置范围。同时，需求者需要在构架者的帮助下，基于自身一定的技术功底，保证所设计的软件系统架设在可执行的技术构架之上。

设计者

承上启下，软件最终形态的创造者,同时也是需求的监督者和编码的指导员.

具有软件具体表现的设计能力，他是系统分析的后续和细化，但为什么不让需求者进一步细化设计，这个理由我后面会说：如果没有设计者，设计也不会消失，而是向需求或开发两端转移，一般是向开发转移，设计和需求或开发合并会出现什么问题，这个我后面会详细阐述。

很多公司的美工会成隐性的软件设计者，这个是有道理的，因为界面和人机互动的确是软件设计最关键的一环。但我认为设计者最好还是具有一定的技术背景，无任何技术背景的设计者会给开发者带来不小的困扰，所以我比较建议美工仅仅作为设计者的一个外部资源来调用。

编码者:

软件的最终实现者。

编码者的能力和事务我这里不加累述了。大家都是对于开发都不陌生。

测试者

软件质量的守护神,需求,设计和编码的监督者.

可以这么说即使需求－设计－开发环节是无懈可击的，测试者的作用依然是存在的，不同角度的需求验证对软件的质量起到定海神针的作用，况且，无懈可击的开发流程，更象是一个神话，不是吗？

测试人员，需要具备测试的相关的工具和方法，他的主要责任是验证需求的一致性，但很多时候他们会参与到技术纠正里面去，如果出现了这种情况，他们就更显得不可或缺，因为如果没有他们，软件的质量将会如何？

软件团队的标准和缺陷

由上，我们可以得出一个软件团队的标准：

有没有管理

有没有特定的构架

有没有专业的需求人员

有没有中层设计师

有没有开发（这个不会没有）

有没有测试的最终防线，

以此6点，来了解一个软件团队有没有最基本的配备。

 

这些条件都极大的影响到了软件的质量和项目的成败。那么如果达不到这些标准，是否软件就没办法开展了呢，事实也不完全是这样的，除了开发以外，软件可以在缺少其他5人的状态下完成，因为软件开发是一项神奇的活动――请参考我的《引论-谈下我的软件和团队之路》，但缺少任何一人，对软件会造成什么缺陷呢，请让我慢慢分解：

无管理：整个开发是无序状态的，开发团队不受控制难于了解，难以了解项目的计划和进度，无任何信息输出，大部分风险都无法回避和减轻，各种团队矛盾难以化解。

无构架：项目的技术风险无法欲知，很容易进入技术雷区，即使勉强度过也很容易留下隐患；每个开发的技术无法统一，造成项目技术选择混乱，即使侥幸完成项目，该会在项目的维护过程中吃尽苦头。最后一点，团队的水平永远无法提高。

无需求：软件会迷失于开发者的自我想象，而大部分客户都没有确认需求的习惯，大家都希望做完了再看，看完了再改；而最后的结果是，导致开发成果与客户预期偏差太大，大量修改返工，成本时间增加，程序员无穷压力，导致团队陷入泥潭，最终崩溃。

无设计：设计常常有实际开发者独自完成，其质量，内容完全决定于个人，质量水平，设计标准无法统一，使得项目出现风格迥异，瑕疵不断的尴尬局面，虽然可能不伤及根本，但难以称专业。另外开发和设计具有互斥性，设计繁复必然导致开发困难，大多数开发人员，在个人技术弱点和技术难点上，常常趋利避害，简化设计以减轻自身压力，造成设计需求服从于开发需求，本末倒置。

无开发：这个大家都很清楚是不可能的，不加累述。

无测试：智者千虑，必有一失；说的是即使开发者具有极强的自律和自检能力，也需要一个审核者的辅助，何况一个连测试都不具备的团队，其开发的自律和自检能力不容乐观，没有测试大部分结局只能是错误百出。