摘要：敏捷开发和CMMI的过程管理开发是当前关注最多的两种开发模式，其中体现的指导思想和组成内容具有很大的不同，为了更好的再实践中用好两种开发管理模式，促使国内软件企业的开发管理水平的提升，本文通过对两者之间的异同进行比较分析，力求通过明晰两者各自的特点和适用范围，在此基础之上对两者的融合提出建设性方法，希望能够发挥各自方法的优势，形成一个统一高效的开发管理过程来指导今后的应用软件开发管理模式。
1 引 言
基于CMMI模型的过程改进在国内广泛的展开并获得了一定的效果，在过程改进中间会发现基于脑力的开发过程可以管理控制，但是控制力度不足，主要是基于脑力开发创造的生产方式具有其特殊的变动性，但是其中通过强调和固化一个开发管理过程，从而达到提升软件开发质量的方式必须和实际的业务和过程执行人员结合起来，否则组织过程就没有实施的基础，更达不到细化管理，控制过程稳定性和优化过程的目的。
在面对大量的变更和越来越紧的开发周期时，一种敏捷的开发模式被提到许多的软件开发公司的案头，以此希望作为解决当前软件开发项目面临问题的解决方案，希望通过采用敏捷的开发方式，通过充分发挥开发人员的创造性，通过缩短甚至剪裁传统的需求、设计，直接关注软件的核心工作产品－代码，通过开发人员协作，加强测试和协调来获得快速的开发能力，适应需求的频繁的变化。但是软件开发的有其特定的特点，不能盲目的缩减和融合从需求到代码的过程，这个过程对资源和人员技能的倚赖度很高，不能简单的借用和实施，否则会带来灾难性的结果。
应该说这两种开发管理的主导思想时存在冲突的，一个强调固化过程，让程序员遵循过程做事情，另外一个主张必须充分发挥开发人员的创造性和能力，不要约束他们的想法和能力，表面看来似乎是针锋相对。但是在其管理的核心实质都是明确了一种如何通过项目团队的协调统一，加强团队的开发能力，通过高标准的质量管理来制造出高质量，符合客户需要的软件项目产品的目的，所以两者之间就存在一种相互借鉴，互相融合和促进的可能。
1.1 目的
通过对比和分析敏捷和CMMI这两中开发的模式，本文构想了一种如何能够融合两种开发模式的方式，区分各自发挥最大效益的领域，保留各自的效益点，同时通过两者的切分，界定两者配合的接口和方式，促使两种开发方式能够有效的配合，指导下一步的软件开发企业的项目开发，充分发挥两者的作用，从本质上真正解决软件企业开发项目面对的开发管理的问题，从而促进软件企业的发展。
2 CMMI和敏捷开发介绍
2.1 CMM/CMMI简介
CMMI (Capability Maturity Model – Integrated)是卡内基美隆大学 (Carnegie Mellon University) 的软件工程学院 (Software Engineering Institute, SEI) 在成功发展CMM (Capability Maturity Model for Software)之后的最新修订版本。CMM计划起始于1984年，因当时美国国防部对软件公司承接与执行软件投标项目的能力无法做有效的评估，因此委托SEI进行研究，试图在软件行业建立一套管理制度，其目的在评估及改善软件公司的开发过程能力。1997年10月美国国防部下令SEI停止对CMM的研究，转而致力于开发CMMI，帮助企业解决使用多个CMM的问题。SEI同时宣布CMMI产品将取代CMM，故于2000年8月11日颁布CMMI-SE/SW 1.0版本,2001年12月发行1.1版本,2006年6月发布了1.2版本.
其关注点在于评估及改善软件公司的开发过程能力,提供过程质量指导原则，协助开发者持续改善开发技能与软件质量，进而提升软件公司的软件开发管理能力，达到提高软件性能、缩短开发周期、降低开发成本及保证质量等目的。
2.2 敏捷开发简介
2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：
n 单一职责原则(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
n 开放-封闭原则(OCP)
软件实体应该是可以扩展的，但是不可修改。
n Liskov替换原则(LSP)
子类型必须能够替换掉它们的基类型。
n 依赖倒置原则(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
n 接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
n 重用发布等价原则(REP)
重用的粒度就是发布的粒度。
n 共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
n 共同重用原则(CRP)
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
n 无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
n 稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
n 稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，们可以在更高层次的抽象上来理解设计，们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。