作者：永春 来源：博客园 酷勤网收集 2008-04-15
CMMI(Capability Maturity Model Integration)即能力成熟度集成模型，主要包括过程管理、项目管理、软件工程、过程支持等几个大的过程。
公司正在进行CMMI的评估，评估之初我们老总就确立了一个原则：简单实用，切合实际开发流程。
我也担当了其中一个评估项目的项目经理，但是在实际使用过程中还是深深感受到了CMMI的繁琐。那么我们到底要不要CMMI，在多大程度上使用CMMI呢？
CMMI的好处想必很多人都知道，主要就是规范开发过程，持续改进软件开发流程，可以有效地控制项目进度，减少项目缺陷。
好处我就不多说了，google一下会出现很多结果 -_-
下面我就谈谈在使用过程中感受比较深的一些地方(不敢说是问题，可能是我CMMI还没用好)
首先，芝麻大的一点事情都要体现在计划当中。有计划当然好，但是有时候对于一些突然出现的问题，比如用户要求在首页上加一个博客园的链接，很小的一个要求，如果应用CMMI的话就要改计划、改需求、改设计......，如果光改代码的话可能10分钟，改文档要半天
其次，每次会议都要有会议记录。重要的会议当然要记，但是有时候临时性的，10分钟半小时的会议似乎没有这个必要
总之我感觉CMMI太死板了，太教条主义了，文档太多了。大型项目应用CMMI可能会好一点，但是对于中小型项目来说有点得不偿失了，8人月的一个项目如果应用CMMI的话，文档这一块可能就会多出一个人月的工作量。
最近我也正在看《人件》，正在看第二遍。它和CMMI侧重于两个不同的方面，CMMI侧重于制度、管理，而人件则侧重于人，认为人是软件开发的核心，研究如何改进环境、改进文化等来充分发挥人的激情，来形成胶冻型团队。
两相比较我觉得人件更适合于一般的软件企业。吸取CMMI中的管理理念，废除其中繁琐的、无用的文档(必要的文档当然是需要的)，然后再应用人件中提到的一些方式打造几个胶冻型团队，这样应该比较好。
以上只是一家之言，只代表我个人观点，相信园子里也有不少项目管理的行家吧，欢迎讨论。
敏捷软件开发第二版 那位用例大师写的 里面的例子都很有趣呢
详细论述了 结对编程呢。我觉得我们的项目里需要有活力，而且有创造性的原意实现敏捷，愿意按照书上说的去试验 。
飞过作为EPG成员,最大的感觉就是到了中国的cmmi都是走了味的商业产物.
不是为了改进过程而CMMI,而是为了CMMI而CMMI
CMMI说明了软件开发中都包括了那些活动，这些活动完全可以根据自己组织的实际情况来进行裁剪。
也就是说CMMI说明了要做哪些事，但是并没有规定怎么做，所以，你也可以用敏捷等其他开发过程来实施CMMI中所定义的一些活动。
上面只是引用啊，到底对不对，还要通过亲身的实践才能有体会。
ps.刚刚还在为需求管理的过程定义成：确认，跟踪和需求变更控制这样的三个过程文件，还是为需求管理定义一个过程的问题争论后有感。
ps2.越来越感觉做cmmi过程改进和开发软件差不多，所以觉得cmmi过程改进还是不错的。