三．对CMMI的思考
笔者在学习CMMI的过程中，也产生过一些疑问，进行过一些思考，具体如下：
1. 实施CMMI最好采用什么方式来驱动？
CMMI只是告诉我们需要做什么，但具体如何做，以及采用什么工具、方法和技术等去做，这些答案需要我们自己去找。
实施CMMI最好采用什么方式来驱动呢？
答案是以实际需求来驱动，真正遵循IDEAL(I-初始；D-诊断；E-建立；A-执行；L-学习)组织过程改进模型。
我们不应该过分的追求采用什么方法或工具来做好某件事情，例如设计图我们并不一定需要采用专门的Rose的工具来做；对需求等的跟踪并不一定要采用专门的需求跟踪工具来做，很多时候Excel就能够达到很好的跟踪效果。在以实际需求来驱动的过程中，可以灵活的采用适合的方法或工具，不应该太过拘泥。
2. CMMI与ISO9000存在哪些区别？
取得ISO 9000认证不意味着完全满足CMMI的某等级要求。取得CMMI第二级或第三级也不能笼统地认为可以满足ISO 9000的要求。
3. CMMI过时了吗？
迭代开发技术、软件产业最佳实践、和经济动机推动组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。
分析CMMI和迭代开发之间有什么联系，方法之一就是看每个模型的KPA是否为这种开发方法激发了合理的软件管理原理。CMMI和迭代思想联系得很紧密，所以说CMMI并没有过时。
4．CMMI与敏捷开发的关系？
最近几年来，CMMI已经成为一项主流开发技术。很多成功的企业都在使用这个技术。那么CMMI与敏捷之间存在怎么样的关系呢？分析如下：
使用敏捷式方法要求IT和业务方面的参与者紧密沟通，更快的交付业务需求从而更快的获取效益。降低改变的成本、提高系统的灵活性，以及降低投资的风险。敏捷式开发能在质量上有很大的提高。大概在60年代的时候，软件开发是没有计划性的，基本是写出来，谁也不知道什么时候能交付，但也就是在那个时候，软件工程学的概念在美国召开的一次会议上头一次被提出来，传统工程学通常是把项目分成三步或者四步，先把需求确立起来，进行设计构建。应用到软件里是开始先由分析人员对需求进行分析，然后设计，架构师把整体的东西设计出来，再确定下来交给编程的团队，编程的团队按照需求规约，把东西给做出来，所有的这些东西都是由不同的人在不同的时间完成的。
这种模式的优点是：开发计划性非常强，因为你知道什么人在什么时候做什么事情。但也存在一些缺点，这些缺点主要由软件开发和传统的建筑工程学的不同引起。客户需求的不断变化，特别是商业软件，跟随市场的变化，客户需求也在不断变化。客户本身在脑子里并不是很清楚自身需要什么，在它看到了产品后，在使用的过程中，他对自己想要的东西才有了一些更加确定的想法，知道了怎样的东西才是自己所需要的。但在这个阶段的需求变化使得项目步履维艰、使得成本大幅度增加。所以工程学里一个核心的概念，变化是最可怕的一件事情，从设计角度也好、分析的角度也好，不管怎么，不要变化，这样就使成本增加。
敏捷式开发最核心的东西是它不排斥变化，对变化采取的是适应性的态度。敏捷式的开发针对一小部分进行设计测试，对每一个循环时间非常短，软件从小到大，从很小的一点到不断的增加扩大，而且增长的过程中是对软件不断修改的过程。
敏捷开发还有一个很大的特点就是它是以人为本，而不是以方法为本的。我们的软件开发是脑力劳动，而不是简单的工作。如果你设计出一套方法来，不管什么方法，让每个人去适应的方法，最后开发效应反而不如你组建一个具有进取心的团队，这个团队通常情况下是先选择一种方法，细节也一样，在开发过程中，不断对方法反思，直到达到这个团队的最高开发效应为止。
如果说，要真正赶上最新一轮的创新浪潮有几个重要的标志，一个是要赶上最新的CMMI的转向敏捷开发，从体系架构角度讲，除了一些先进的架构理念，还有一些架构模式等等，还有开源代码的应用，不仅仅是操作系统，包括数据库、应用服务器、各种开发工具等有很多的开源工具。
四．总结
本文对CMMI进行了概述，并分析了实施CMMI给我们带来的好处，以及笔者对CMMI的一些思考。
