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

......
当我重操旧业时，对眼前的一切感到不知所措。面对项目管理学会（PMI）和能力成熟模型（CMM）认证计划，大家对最佳实践的理解似乎主要停留在过于强调过程定义和详细的前端计划上。更为糟糕的是，这些方法将我所熟知的精益制造潮流作为其存在的正当理由。
......
详细的前端计划给我的印象是，它和精益制造原则完全背道而驰。在我看来，由员工组做出的过程定义是与授权截然相悖，而授权是成功地进行精益制造的核心所在。我觉得，制造业的比喻似乎被滥用于软件开发领域。在我看来，CMM 在急于对过程进行标准化时忽略了发现和创新精神，而这种精神是成功地进行整体质量管理的关键因素。大家知道，ISO9000 以及 Malcolm Baldrige 奖与质量计划的成功并无多大联系，或者毫无关系。它们对记录成功有用，但通常会妨碍创造成功。
......
这并不是说 CMM 和 PMI 不好，只是对所有经历过精益革命的人来说，它们倾向于以错误的方式对待软件开发项目。我们希望本书能改变软件开发范式：将强调过程改为强调人员，将分散改为聚集，将推测改为基于数据的决策，将计划改为学习，将跟踪能力改为测试能力，将成本和进度控制改为商业价值的交付。

......
也许，有些人所以不愿意采用产品开发方法，是因为过去采用了一些不适当的比喻（metaphor，我们说的隐喻）。软件开发业试图模仿制造业和土木工程的实践，结果必定会产生混乱。在一定程度上，这是因为他们对这些学科的真实性质缺乏充分的了解，而且他们并未认识到这种比喻的限制。
......
敏捷软件开发实践已被证实可以在某些组织内发挥作用，Jim Highsmith 在 Adaptive Software Development 一书中详述了这些实践之所以起作用的理论基础。本书通过将众所周知，并得到认可的精益原则应用于软件开发，进一步扩充了敏捷软件开发的理论基础。不过，本书还进行了更为深入的论述，它提供了一些思考工具，以便协助读者将精益原则转换为适合于特定领域的敏捷实践。我们希望本书能够促成对敏捷开发方法更为广泛的认可。

它们对记录成功有用，但通常会妨碍创造成功。