CMMI的利与弊

公司正在进行CMMI的评估,评估之初我们老总就确立了一个原则:简单实用,切合实际开发流程｡

我也担当了其中一个评估项目的项目经理,但是在实际使用过程中还是深深感受到了CMMI的繁琐｡那么我们到底要不要CMMI,在多大程度上使用CMMI呢?

CMMI的好处想必很多人都知道,主要就是规范开发过程,持续改进软件开发流程,可以有效地控制项目进度,减少项目缺陷｡

好处我就不多说了,google一下会出现很多结果 -_-

下面我就谈谈在使用过程中感受比较深的一些地方(不敢说是问题,可能是我CMMI还没用好)

首先,芝麻大的一点事情都要体现在计划当中｡有计划当然好,但是有时候对于一些突然出现的问题,比如用户要求在首页上加一个博客园的链接,很小的一个要求,如果应用CMMI的话就要改计划､改需求､改设计......,如果光改代码的话可能10分钟,改文档要半天｡

其次,每次会议都要有会议记录｡重要的会议当然要记,但是有时候临时性的,10分钟半小时的会议似乎没有这个必要

总之我感觉CMMI太死板了,太教条主义了,文档太多了｡大型项目应用CMMI可能会好一点,但是对于中小型项目来说有点得不偿失了,8人月的一个项目如果应用CMMI的话,文档这一块可能就会多出一个人月的工作量｡

最近我也正在看《人件》,正在看第二遍｡它和CMMI侧重于两个不同的方面,CMMI侧重于制度､管理,而人件则侧重于人,认为人是软件开发的核心,研究如何改进环境､改进文化等来充分发挥人的激情,来形成胶冻型团队｡

两相比较我觉得人件更适合于一般的软件企业｡吸取CMMI中的管理理念,废除其中繁琐的､无用的文档(必要的文档当然是需要的),然后再应用人件中提到的一些方式打造几个胶冻型团队,这样应该比较好｡