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

这不是agile的缺陷，但是agile没有围绕软件开发的根本矛盾展开工作这不能不说是其本质上的不足。而作为软件方法方面的研究如果不以解决本质矛盾为最初出发点，其价值就必然大大折扣。

是的，经过我这两年的思考以及和大家的讨论，差不多也能得到这样一个结论。
对于我们的项目开发或者产品开发，最重要的问题还是对于行业业务的深入理解。如何迅速理解和把握一个行业的业务，目前还只能完全依靠经验，而没有想出什么更好的方法。我认为建立针对某个行业的领域模型才是最为重要的问题。而软件的可用性（良好的交互设计和界面）是另外一个相对次要，不过对于赢得市场也非常重要的问题。后面还有良好的面向对象设计等等问题。而 XP 的 TDD 和重构对于第三个问题（得到良好的设计）是非常有帮助的。尽管如此，关键的问题还是在于对于行业业务的理解和把握。

我曾经以为 MDA 是迈向这个方向的一个重要尝试。不过现在还很难说，只有等等看了。

是的，经过我这两年的思考以及和大家的讨论，差不多也能得到这样一个结论。
对于我们的项目开发或者产品开发，最重要的问题还是对于行业业务的深入理解。如何迅速理解和把握一个行业的业务，目前还只能完全依靠经验，而没有想出什么更好的方法。我认为建立针对某个行业的领域模型才是最为重要的问题。而软件的可用性（良好的交互设计和界面）是另外一个相对次要，不过对于赢得市场也非常重要的问题。后面还有良好的面向对象设计等等问题。而 XP 的 TDD 和重构对于第三个问题（得到良好的设计）是非常有帮助的。尽管如此，关键的问题还是在于对于行业业务的理解和把握。

我曾经以为 MDA 是迈向这个方向的一个重要尝试。不过现在还很难说，只有等等看了。

你说的这种东西目前有一些已经存在。比如HL7、NGOSS等。

我的观点是，MDA就目前的情况，实现它的目的只能是个神话。

HL7和NGOSS也并不是灵丹妙药啊
我们一直在说行业标准行业经验，殊不知真正有创造性的企业是不会被行业经验束缚的。

如果一个行业可以用一两套“标准”的IT系统一统天下，那么这个行业的创造性何在？这些企业的竞争力何在？

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想要解决的问题，也不能证明其可以解决我们现在所要面对的问题。

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想要解决的问题，也不能证明其可以解决我们现在所要面对的问题。

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

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

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