CMM到底给我们带来了什么？

哈哈，这个帖子还真是火热。
   看了大家的帖子，基本上分为两部分。我想我应该属于中间者吧。
   其实大家在讨论CMM的时候，应该分开来看，将CMM模型、CMM模型与软件过程、CMM认证、中国企业的CMM认证实施情况四个部分。
1.单纯看CMM模型，我实在找不出它的KPA有什么问题，配置管理、QA、测试、项目管理，它着重描述的软件开发中的关键点至少在目标上来说是恰如其分的。当然，它的一个方面，也是大家所诟病的就是每个KPA的评估是根据文档的，以及文档的数量。
2.CMM模型与软件过程，几乎95％以上的人都将CMM与RUP等同起来，或者说将CMM与敏捷过程完全剥离开来，其实这是不恰当的。CMM的模型是考量软件过程中关键点来评估软件过程的成熟度，而与这些点是怎么样的串联以及关系是没有任何要求和强制的。
3.CMM认证，和大多数人一样，我虽然承认模型中的可取性，但我并不认同CMM的认证。如果我承认软考或者其他认证的可取性一样，但并不认同参与认证一样，尤其要通过一个这样的认证需花费巨大的成本，没有几百万的直接投入是不可能通过的。
4.CMM之所以这么臭，也就是和最后一点相关系了。我不清楚gigix是否说的属实（不过我清楚中国信息产业部也有自己的认证，相反和CMM还不同，并不承认CMM，为此还争论过很久），但是，真是绝大多数软件企业不是内修本事，而是尽做些表面文章,而媒体、行业又在大肆吹捧（我实在觉得中国的软件行业好浮躁，喜欢抄概念），所以作为从业者的我们，多少对其都会有些抵触。
    CMM对于软件过程的真正部分，也就是开发这一块评估是相当弱的，也是由于这是最难评估的。另外实施CMM的都是用UP的，也就是有固定规则的过程，所以在这种情况下开发部分的持续集成是比较难以实施的。其实啊，对于大团队多独立模块的持续集成（也就是日集成）我一直都是保留疑问的（也正是因为我在这个方面缺乏经验。）

关键还是要有一些有能力的人来做一些关键的事情。
往往是一些没有能力，没有开发经验的人在上面作指导，他们也不清楚那些文档的作用，只是为了文档而写文档，因而没有什么指导意义。

不过话又说回来了，如果有一些有能力的人在上层作指导，不需要什么CMM，那怕是自己想出来的方法，也照样能做好软件。

别人既然可以在那个位置上总是有他的理由的。
其实项目管理是不需要懂技术的，只不过这个规则在中国行不通而已。
不懂就不听你的。
观念问题。

说一套做一套
也不知道我上次的CMM考了几分