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

CMM中没有这么明确的规定吧（CMM一般说periodically & Event-driven这些放之四海皆准的话），我估计是你们在为CMM添砖加瓦。
那怎样保证这些审核的内容能够怎地符合当前实践的情况，真的是在为项目的解决问题？如果说这本身就需要一个过程，我对在一个业务环境比较复杂多变的情况下，这个审核的效能有些疑问。你们有什么好办法来弥补这个鸿沟吗？或者CMM/CMMI有什么好的办法？

青海渔风
======
其实正是因为在CMM中很多文字如你说言的放之四海而皆准，才造成在实践中很多的灵活性与理解上的差异性。同时也增加了实践的难度。不过，换一句话，这也正说明CMM是对于已有的经验的总结，至少他准。在配置评审一项上，CMM的条文本身是分层次的。比如最抽象地是说要做定期审核，但是，在实践一层，企业往往有根据自己的现实选择的权力。

至于评审的流程是否符合当前实践的情况，这个问题简单，回答却是很复杂。在CMM上，或许我们不应该说：当前这个审核的流程不是最优的，但是，它是根据历史经验积累，优化而来的。它比过去我们采用过的更能够保证产品的质量。

业务环境的多变，并不会妨碍审核的效能。因为不同的项目类型，本身就可以采用不同的审核流程。（实践中也是如此，一个最基本的，新产品研发项目的流程就是与产品维护的流程是不一样的），所以，并不是说在CMM企业中，只有一套流程。如果企业的业务差异太大，那就必须为不同类型的业务制定不同的流程。一个实际情况是，在软件外包企业中，因为其面对项目的不确定性，所以，它内部都有数套流程备用。每一套，都规定了其适用于什么样的项目类型。并提供了选择的流程，去帮助项目经理做出最优选择与裁剪。

还是一句话：CMM不是用来解决业务问题的，所以，业务问题本身是不能够对于是否要使用流程构成影响。但是，不同的业务问题解决的流程要求是不一样的，所以，CMM允许企业根据不同的业务问题域制定多套流程，根据实践情况，依照一定的流程/标准进行选择。

我不同意这种对文档的态度，SEI自己对这些东西的态度也在转变。这点作为CMMI专家的你们我想很容易从CMMI中的描述感觉得到。我认同在这方面敏捷的说法，Working software over comprehensive documentation
二十年前CMM的概念提出的时候有他的意义，对于软件工程的贡献和作用今天应该重新评估评估，如果考虑到互连网，考虑到敏捷和软件本身的作用这些因素的话。

所以很多人觉得CMM或SEI比较狡猾，我想知道这个世界上除了peroidically和Event-driven还有什么其它的触发方式，如果CMM中充斥了这些东西，CMM就在某种程度上什么也没有说。如果这样，CMM的作用在哪里？我还不如直接对着《Managing Software Process>>中的内容来参考好了，至少Watts.没有这么模糊的言语。什么东西都是企业来选择，那还能把它抬高到“软件工业界事实标准”这个高度吗？怎样来保证通过评审来订出的级别的权威性呢？当然用级别来做广告是另一会事情。

青海渔风
======
对于敏捷过程，因为这个帖子是关注于CMM，我不想多言。如果将来有机会，我们可以进一步交流。

但至少有一点，我从来没有关起门来成一统，也没有说CMM一出，一统江湖。请不要妄自揣度。软件工程发展今天，早就是你中有我，我中有你。已知的行业的最佳实践就是那么多。很多所谓的体系，只不过，将一些最佳实践以不同的方式进行组合之后，融会而成。

我来这里不是为了华山论剑的。所谓谁是第一，只不过是一场虚名的游戏而言，对于自已的提高并无益处。也许正有某位高人，在此处看帖而发笑，觉得你我都是如此幼稚，就一些如此简单的问题，还在讨论来讨论去。

讨论，就要报着谦虚的态度，而不要胸有成见，固步自封。

CMM 假如真的仅仅是标准，采用什么样的过程完全由开发团队自己选择，那样就好了，我们也不需要再争论什么了。
问题是如 o6z 说的，CMM 可不仅仅只是标准（象阳光空气一样哺育万物的东西）。学习和理解 CMM 需要很长时间，加以有效的裁减需要更长的时间（总要有个一年时间吧，我猜测），这个周期和成本成为了中小型软件企业的难以承受之重。我现在明白了为什么 CMM 催生了这么多的咨询顾问，为什么 CMM 在大多数软件企业最后变成了精英治国，无法争取到广大开发人员的充分理解和赞同。其实很多时候，我们并不需要这样灵活的标准或者过程，我们需要的也仅仅就是 XP 这样明确和节省时间的东西。
学习 XP 的时候，我总有明天就把某种最佳实践付诸实施的冲动，因为很多东西对于我来说都是如此的明确和容易理解。而学习 CMM 的时候，总有一种老虎吃天无处下嘴的感觉。直到现在我仍然对于 CMM 的一些规定感到莫名其妙（当然，我承认我的智商确实没有达到 160）。
学学 XP 吧，每天早上起床念一遍 KISS。

这句话是相当主观的。

青海渔风
=====
我个人从来不认为CMM是什么软件工业界事实标准。其实这种说法的大肆宣传，本身就是国内软件业的浮躁的一种体现。

正如一个抽象的概念，无法用具体实体去定义一样，对于软件开发管理这样的东西，在目前情况下，还处于一个无法统一意见的地步。CMM也只是基于一些经验的总结，而非一套独创性的理论。在这一点上，它还算是谦虚的。

至于CMM的作用在哪里？至少从我个人的实践以及目前的工作环境来说，它的作用是非常明显的。但是，在国内的很多的企业中，的确也是看不到的。打个一类比：给你一台织布机。会用的人可以织出美丽的织锦，而像我一样不会用的人，看到它只是一堆烂铁。

所以，对待CMM，我们不能因为它在国内普遍的失败案例去否定它的价值。而应该看到：它在印度之类的大企业中的成功本身就已经说明它的价值是很大的。现在我们应该讨论的是，如何学会动用CMM这个工具来与参与国际竞争。

对国内的软件环境而言， 用CMM这个工具来参与国际竞争也许最后是参与软件外包的竞争。我对印度的大企业的管理水平不太清楚，但是如果说做简单的软件外包，或者呼叫中心这种业务外包，也许用不到CMM这么特定的体系，是不是ISO就可以了？

我想问一句，你们的流程是用什么方式来维护的？维护成本大概是多少一个级别？

呵呵，很多通过ISO的软件公司，都还要去通过CMM的。这就可以说明一些问题吧。