软件开发和团队管理


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都觉得遥不可及的团队,不要轻易尝试敏捷开发,先打好自己的内功根基.

 

我的银弹

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

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

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

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

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

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

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

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

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

 

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万还想开车的吊丝们,唯一的办法就是自己到二手车市场去淘.

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

首先我必须说明我个人的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人模型的总则:

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

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

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

6人?他们需要会什么并做什么?

1.       管理者

2.       构架者

3.       需求者

4.       设计者

5.       编码者

6.       测试者

管理者

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

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

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

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

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

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

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

构架者

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

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

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

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

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

需求者

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

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

需求挖掘-客户交流

需求开发-系统分析

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

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

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

设计者

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

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

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

编码者:

软件的最终实现者。

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

测试者

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

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

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

软件团队的标准和缺陷

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

有没有管理

有没有特定的构架

有没有专业的需求人员

有没有中层设计师

有没有开发(这个不会没有)

有没有测试的最终防线,

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

 

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

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

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

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

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

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

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

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页