软件开发和团队管理.docx

《软件开发和团队管理.docx》由会员分享，可在线阅读，更多相关《软件开发和团队管理.docx（17页珍藏版）》请在第一文库网上搜索。

1、软件开发和团队管理2大伤痛软件开发了这么多年，也带了很多的团队，真的没什么心得，只能说有点感慨。软件开发到底难不难，这真的是一个问题，刚刚毕业的时候，觉得做软件乐趣很大，困难很很小，结果呢，到现在还没有一个项目令自己满意。既然不难做，但为什么就是做不好，这真的是一个揪心的问题。软件团队到底需要多少人，这已经不能称为一个问题，而是一处伤痛，初出茅庐的时候也曾经认为一人一机就是软件，但遥望印度千人团队，真心不知道他们在干嘛，为什么要那么多人，难道他们都很苯？如果说有什么心得，还不如说我心中的2大伤痛，以搏一笑：1软件只需要开发就可以完成，团队只需要开发就可以组成。2.软件出了问题是可以改的，而且不

2、难改软件就是开发也许大家会笑，当事实上大部分人都会被这2个问题伤到，而且伤了好多年。软件只需要开发，这个看上去是一个很浅显的道理，就像古龙式的大侠那样，杀人就是用刀划过敌人的身体，就这么简单；是的，软件开发就是把代码编写出来，编译运行，交给客户，的确就这么简单。细细品位这第一个伤痛，我发现这个问题其实是看似偶然中的必然；软件的最小组成就是代码，有了代码就有了软件的实体，有了实体就可以认为完成了软件，这个是非常实际的想法。加上老板最关注的是项目的成本和时间，那么为开发团队增加开发人员看似是最“有效经济”的方法，一人开发一周，那么2个人最不济开发3天应该够了把一一大家都会如此思考。当然，软件开发还

3、真的是神奇的所在，它的一个神奇之处就在于,无论如何，软件的生产过程还是可以完成的，无论如何，在一定的时间和努力之后，软件还是诞生了，他的诞生时候似乎是必然的，不可阻挡的,那么我们还在担心什么呢。软件没有失败有人说,软件完成仅仅是万里长征第一步,还差的远呢,客户的要求还远远没有结束.真正的修改还在后面.是的，软件开发的第二个神奇之处就是,软件可以通过不断的修改来弥补以前的错误，不管你提交的软件是IOO分还是20分,它都可以通过不断的修改而继续存活下去，可以这样说，只要还能修改，软件就没有失败,那我们还担心什么呢.2大神奇法则这里,我们引出了软件开发的2大神奇法则：1 .软件只需要开发就能进行,并

4、且基本都能完成.2 .软件只要修改就可以存活,而且很少最终失败.首先,我们必须感谢这2个神奇的法则，它大大降低了软件开发的入行门槛，使得很多团队和个人，即使懵懂幼稚，即使身无长处，亦能昂首踏入这个行业，以各种各样的姿态开始自己的职业生涯.其次,这2个法则也深深的伤害了很多团队和个人,在进入这个行业若干年以后,很多人发现,这2个法则所营造的就是一个迷魂阵,一个无底洞；软件总能完成却从未结束;软件不会失败却从未成功；困惑与当下的实践,迷茫于未来的发展.我在担心什么我在担心什么，其实我也说不太清楚；首先,那些必然完成的软件没有给我和我的团队任何美妙的感觉,做的好不好,是否可以算成功,这个问题几乎没有

5、人可以回答,那么自然也就没有答案了.其次,永无止境的修改,最终的结果只能是伤痛，日积月累的疲惫感,不断受挫的成就感,加上毫无希望的未来.几乎没有人会喜欢这种永不言败”的感觉，团队的崩溃和软件的摆烂,几乎是必然的结果.最后，梦想和发展，几乎已成奢望,遥望欧美令人羡慕的先进开发方式,展望自己30岁以后的发展空间，总是觉得那么遥不可及,对职业生涯的希望已经到了破碎的边缘.寻找突破如何突破,无非是自身寻求突破和效仿先进模式；自身寻求突破太过理想化,如果自己有这个能力，要突破早突破了，何必等到现在.效仿他人先进模式是必然的，当也绝不能盲从：别人的先进模式是大学毕业水平，而我们刚刚走出幼儿园，怎么学，学什

6、么，并没有想象那么简单.这里就谈2个大家都耳熟能详的模式：CMM1和敏捷开发.CMMI是一个非常不错的体系，当我希望大家知道的是,CMMI就是大学毕业水平,给我们这些幼儿园和小学的小朋友来用的确是有点一知半解.CI2就基本要求到20人团队（一个项目），试问一般中小公司有多少单个开发团队可以到20人？更不要说团队内部的人员素质是否达标这个问题.也有人谈到裁剪,这个是没错的，但问题是谁来裁剪？让我们这些小朋友来裁剪大哥哥的论文？靠谱吗？难上加难.我也曾寄希望与国内的CMMI培训团队来帮我们裁剪,最终也是发现这也是勉为其难.CMMI能用,但全用是邯郸学步,裁剪是困难重重.敏捷开发,这个更是一个冷笑话

7、,敏捷开发是什么，是高中水平吗，完全错了，敏捷开发是研究生水平，是参透了大学水平的更高层次的升华,软件开发没有“银弹，没有捷径,如果小学还没有毕业,就先用研究生的手法来解题，其结果只能是彻底的失败.我的看法是，如果CMMI2都觉得遥不可及的团队，不要轻易尝试敏捷开发，先打好自己的“内功“根基.我的“银弹”1学习：学习了解先进模式和理念1自省:认真分析自身团队和成员的能力1定制：寻找最小模式，从零开始，重新组建合理团队，搭建合理流程.1发展:走上不断积累提高之路这里我认为有以下几点心得：不去了解先进模式是闭门造车,必然失败.不根据本身团队情况是盲目改革,必然失败.软件开发有其规律,最小模式绝对不

8、是两把菜刀闹革命”，没有办法获得最低资源要求,就不要改革.如果你的改革不能形成有效的积累模式,就不要改，改革为的是将来不断壮大而不是现在解决一时疑难，没有发展通道的改革还不如不改.CMM12,1还是1.5?首先说个老实话,软件开发是没有什么所谓最小模式的；如果可以我并不希望去尝试所谓的最小模式；现在开开一2万的二手小车是没办法,并不代表我愿意一辈子开这种车.CMMI3认证要求最少有20人参加,其实是给出了一个硬性的指标,要保证CMMI3所能达到了质量要求,大部分流程域是不能裁剪的,那么就要保证有足够的资源去做正确的事情.也许是我没有赶上好时节,我所经历的项目和团队,还真的没有单个20人的规模,

9、不过团队是小但也是要活下去的,不管如何,生活还必须继续，软件还是要完成.也许小团队一定要上CMMI3还是好高鹫远了，那么我们来看看CMMI2,但CMMI2也不是省油的灯，里面竟然已经包括了QA管理,配置管理，需求管理和度量管理，这些东西已经不是5个人以下的团队能够运作的了，这4项工作我认为至少增加3-5人的辅助管理量,加上与之配套的开发团队成员，整个规模保守估计应该在10T5人以上,说老实话，对于一般的软件公司，这个规模也有点勉为其难.怎么办,再减？CMMI初级是完全“懵懂”模式,几乎所有团队都可以达到,这里我就不加说明了，那么CMMI2似乎已经就是最底限度，小于10人的团队真的与CMMI无缘

10、吗?那些过程域真的是一个都不能再剪吗？这个CMMI专家们是没有答案的，唯一的途径，只能靠自己去摸索一就像怀揣了12万还想开车的吊丝们,唯一的办法就是自己到二手车市场去淘.于是乎,对这个介于CMMI2和CMMI初级之间的”最小模式”的探索开始了.首先我必须说明我个人的3点看法：1“最小模式”是我个人容忍的最底限度,如果这个都达不到,我个人认为你不是在做软件,而是在玩软件；也许有其他的高手也认为我的”最小模式”是在玩软件，同理.2 .“最小模式”的软件质量必然低于CMMI2标准,软件开发没有侥幸,减价不减量的好事情从来都是没有的，当然我个人认为”最小模式”的质量还是可以接受的，否则我就是误人子弟了

11、.当然有可能只是我接受，大家还需要自行判断.3 .“最小模式”是给现行的,迷茫的，一些小团队们一个建议,一个起点,我还是希望大家能从这里起飞而不是终止,正如我开头说的那样，没有人愿意一辈子做所谓的“最小模式”，人总是要有理想的，2万的车刚工作开开是可以理解的，一辈子开是要被人鄙视的.2条主线.4个步骤如果说真的存在一个最为简单的模型，我认为软件的开发过程必须存在2条主线和4个步骤。2条主线就是管理和技术。4个步骤就是需求,设计,开发和测试。2个主线是双轨，4个步骤是车厢。无轨车子无法行驶，无车一一这就不谈了，这个就没意义了。这里需要说明的是，4个步骤仅仅是软件执行过程的内容，其关注点是软件开发

12、的生命周期而不是项目，项目的运作还需要更多的考虑，就像火车的行驶，需要出站和进站的过程，行驶过程还需要监控，这样才能保证安全。项目的运作我们暂且不提，我们就说软件开发，看看我们最少需要点什么内容。管理管理是什么，如雷贯耳到不需要解释了；项目管理,开发管理，团队管理,这些名词都是耳熟能详.我认为3个人以上的团队就需要管理，不说别的,就是让3个各自为战的程序员能够在规定的时间，规定的技术做出规定质量的软件,这个就很像一个神话故事了.一句话,管理者不可或缺，目前软件的规模越来越大,孤胆英雄或者喋血双雄式的开发团队已经非常少见了，那么绝大部分团队都必须存在“管理者”这个穿针引线的角色.但很多场合下，大

13、家对管理者都有偏见,大家都认为这是一个闲职，工作量估计比我们的公务员还低，不就是发个通知，买个晚饭的人吗.所以大部分管理都是以兼职的身份而存在,最为常见的是,技术高手顺便管理一下即可.我想说的是,管理的工作其实非常的繁重,也非常的关键,管理对软件的质量,时间，团队,能力和最终成功与否,起到了至关重要的作用，管理不但要有,而且要专职,没有专职管理的团队就是没有司机的车,我真的建议你不要上去.技术技术,这个太简单了，没技术能做软件吗，团队有大有小,但里面的开发人员谁没有2把刷子.所以,技术是最不是问题的问题.真的是这样吗.这里,我需要提出另外一个概念一构架,构架是什么，软件开发者都有自己的看法，大

14、家也知道构架师是一个了不起的岗位，也成为了很多软件人的梦想.构架是什么，我的理解就2个字:驾驭.能驾驭的技术就是构架,不能驾驭的技术仅仅是理论.构架代表的不仅仅是技术本身,而是对技术的理解,领悟,经验和积累，就像开客车的司机,他不但要有特殊的驾照,还需要有多少年，多少路的客车经验,如果什么都没有仅仅是会开车,这里面的风险就足够毁灭一次长途旅行.构架和驾驭有3方面的问题需要考虑：首先是深度和广度：构架必须涵盖项目开发所有的问题,请注意是所有,任何开发中的问题最好都已经有一个成熟的方案来应对.这也许是一个很高的要求,但我们必须要明确这是我们构架发展的方向.比如说,这个项目某个问题没有好的解决方案,

15、那么下一个项目就有了，若干项目以后,构架的深度和广度就能有很大的提高.其实不管是什么等级的问题，就必须有成熟的方案而不是留给开发人员自我发挥，比如Web项目，不仅仅是性能,安全,报表这些高级问题需要解决方案,就一些基础问题如转页，Session,上传等等都必须有成熟的思路；这就是广度和深度和含义；很多人热衷与遇到问题找谷歌百度,而且谷歌百度的确也找的到临时方案,这里暂不提临时寻找方案对项目进度造成的冲击,我就说一点,很多梦寐以求的构架师,难度就是谷歌百度一分钟就能取代的吗,其中奥秘大家一想便知.其次是统一：这个是很明显的问题，构架必须统一，开发团队里面的每个人,其技术路线都是不同的,对构架的理

16、解也不同,但一个项目的构架必须统一，统一才能驾驭和控制，统一才能保证项目质量的水平一致.构架的广度对统一有很大的影响,广度越大,每个人自我发挥的余地就小，统一的部分就多，构架就越容易驾驭.这里多说一句，很多新手程序员对既定的构架压缩自己的发挥空间非常的反感,我这里要诚心的告诉这些新人,构架定义良好的团队是你的福音，一个让新人随意发挥的团队才是真正的坑爹,切记.最后是积累和培训：构架绝对不是只存在于当下项目，当下团队的产物,没有一个构架师可以在他的第一个项目就形成一个惊天地泣鬼神”的构架,构架需要在大量的项目中不断的积累和提高；另外构架绝对不是一人或者一群人的专属，离开了特殊的人或者群体，构架应该依然有强大的生命力，这就是培训I,构架应该便于向各种各样的后人传授,传授的越快越便捷,构架的成熟度越高.需求需求就是要明确