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

用百分比吧。质量部门是全公司人员数量的大约1/300到1/400。

我不知道你为什么一定要完全否定我们自己同胞的一些实践经验。认为大部分实施 CMM 失败的公司所有的责任都在他们自身，而这个标准或者过程就是完美无瑕的。
正如 o6z 所说，好的软件工程研究者需要广泛涉猎，而不仅仅是局限于 SEI 的书籍和资料。软件工程涉及的范围非常广泛，包括技术、管理、心理学等等。管理是不可以移植的，而且管理方法确实存在着人种学的差异，针对日本人有效的管理方法对于美国人未必完全有效，而针对印度人有效的管理方法对于中国人也未必完全有效。为什么你认为我们中国的开发者和管理者就完全没有能力发展出来一套适合自己的软件工程理论和开发方法？

另外，你所说的这些再次证实了 CMM 基本上只适合于外包类软件企业这个我们以前得出的结论。

QUALITY IS FREE！
我不知道我们还需要对这个问题进行什么讨论？显然在更高质量级别的情况下，你的成本至少应该是不变，而不是提高，更不会大幅度的提高。这样的问题在我看来是常识。
审计的作用在什么地方呢？你无法回答这个问题，因为这个问是CMM不可能告诉你的。当然这个问题其实根本就不是一个软件工程的问题，而是一个管理学和财务学的问题。
同时我再次要对同一个问题发问：“如果你的制度已经可以确实保证你每一天都必须提交代码，那么你的每月一次的审计究竟意义何在？”
可以从开始我就知道你们根本就不会得到什么满足，寻找同道可能性在我们这个工程化的论坛中本身就不存在。而实际上包括你已经其他这里大多数的人对我都有深深的误解，以为敏捷是我的理论基础。其实恰恰相反，我一直的追求就是寻找敏捷的缺陷，从而提出自己的方法论体系。这个工作已经进入尾声，但愿我能完成它。
其实敏捷也好cmm也好rup也好，都是传统软件工程的组成部分，他们各自都有其实现的基础，也有其有效的范围，我们没有必要去证明其中任何一种是万能的。我们的工作应该是以社会现实出发，寻找最低成本投入，最高效果输出的方法，来改造我们的企业，进一步去改造我们的环境。至少你承认cmm不能解决明目前的根本问题，那么你为什么不能承认我们应该去关注究竟什么可以解决目前的问题呢？这样的讨论才会既有学术价值，也有社会价值。
当然最后我必须承认虽然我调查和深入过几个CMM企业，我对于其理解一直只是概念的阶段，而从来没有进入一个心领神会的境界。当然这样的原因并不是我们对于CMM研究的少了，或者对于CMM有什么先天的抵触，而是因为CMM的基本概念在我这里本身就没有成为可以可以自圆其说的系统，从而造成我对其系统的领会永远只能停留在表面。而我一种在寻找一个可以说服我的思想系统，可以解释CMM那不成系统的模型，可惜从来没有人能够说服我。他们往往只是拿着一条一条的CMM宣传手册上的言语，来说明CMM如何科学。既便他们能够脱离那宣传的陈词滥调，也只是拿着一些被阉割的理论来正确CMM确实是基于经典软件工程和管理的产物。可惜我这个人从来都是用自己大脑思维，对于他们的观点我根本就不可能认同。
现在的关键是经典的软件工程已经不能适应社会对于软件的需要，因为银弹早就被证明是不存在的。我想这个上面我们应该是有共识。但是社会并不会因为我们不能制造出银弹就放松对于软件的要求。因此说过程研究对于目前的状况以及将来的状况都不能提供给我们需要的东西。认识到这一点，就会让我们对于CMM和rup以及xp之列有一个清醒的认识，从而避免方法论大战的再次发生。
至于CMM的种种细节在我看来研究的价值不大，因为其从根本上来说是一种标准，而不是方法。标准的一个必然属性就是其必须建立在一个非最佳的基础上，也就是说CMM只能满足于最基本的要求，而不可能成为最佳实践的整合。这一点是CMM从来都不愿意承认的。但是由于一些被证明的最佳实践在CMM中根本就无法得到充分的贯彻，因此其标准地位一直不能得到充分的实现。你们可以继续讨论如何在CMM下实现TDD和迭代开发，看看你们究竟能够提出一个什么样的措施。而作为软件开发成为一个工程的基础措施的SCM最佳实现——持续集成，你们在CMM系统下又能如何实现呢？设计领域的重构你们又如何实现呢？最佳的评审实践PP你们又如何实现呢？最佳的需求实践，用户进度可视化又如何实现呢？最佳的变更管理实践和交流实现又如何实现呢？这些问题需要你们CMM人去解答。
但是既便你们能够解决上面所有的问题，还是无法证明其解决了CMM想要解决的问题，也不能证明其可以解决我们现在所要面对的问题。

最后我要纠正一个大家普遍存在的错误用词，敏捷过程。
过程是一种自成系统，并且自包含的流程，其完备性充分，可再造性相对较低。敏捷方法体系的任何一个方法，都不能满足完备性的要求，其可再造性也相对较强。或者说敏捷还是处在一个快速发展的轨道上，还没有资格被成为过程。这一点上RUP就要完善的多。但是如果作为RUP的内核UP，其规模相对较小，也不能成为一种过程。

很多做ISO-9000认证的公司在ISO-9000被搞烂了没人信了之后立马转行做了CMM，这确实就可以说明一些问题了，起码可以说明为什么有你说的这个现象。

同时我想再次强调软件开发是一个开发过程，而不是一个可定义产品的再生产过程，在这个领域使用传统行业的种种说法应该尽量的小心谨慎。

青海渔风
=====

虽然不排除在国内有这样的倾向，但是，其内在的驱动力不是这样的。其实，就算有些企业是因为这个而来，也至少证明了，CMM本身存在是有其道理的。

批判了CMM这么久，我有必要批判一下agile。你没有看错，我现在就要说说agile的问题。
我们知道软件开发的根本矛盾在MM中已经被证明了，并且得到软件工程领域普遍的认同。但是这本书上也说这个矛盾是无法解决的，也就是不存在银弹。
agile不是银弹，这一点不需要讨论。这不是agile的缺陷，但是agile没有围绕软件开发的根本矛盾展开工作这不能不说是其本质上的不足。而作为软件方法方面的研究如果不以解决本质矛盾为最初出发点，其价值就必然大大折扣。
这个问题由于和主题讨论不是关系很大，我就不作展开了。
当然我会在最近就这个问题提出我的看法。其实我对于CMM的种种评价并非来自我的原创，而是来自我多年贯彻国外对于CMM各种整理的总结。基本上我说的问题，SEI也表示认同，并且正在进行针对性的修改。可惜的是这样的修改需要时间，也需要考虑其与前面系统的兼容性，所以我们只能耐心等待。

万事万物存在都是有道理的。CMM的标准卖价20万，通过CMM的企业国家补贴80万，这就是它存在的道理。

真是长见识

找工作要混文凭 搞外包要混CMM

俺们国家的包装业可真火