软件开发和团队”最小模式”初探1
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人模型”，对开发团队的建设做一个“最小模式”的探索。
