基于CMMI质量管理体系引入敏捷方法的实践

孙春艳 刘颖 赵殿奎

（天津神舟通用数据技术有限公司北京100094）

1 引言

从2006年开始采用CMMI模型进行企业的质量管理活动，从依据模型建立组织的标准过程开始，经历了最初少数项目的试用、逐步普及至不同类型的项目和体系的持续适用性维护，这其中得到了提升规范化管理水平的赞许，也遭遇了由于管理方式不适合项目特点而引发的抱怨，如何才能在规范的同时，兼顾项目不同规模和不同用户等特征，让项目在企业标准体系的大框架下，有更多以及更有针对性的选择，是质量体系建立和维护者必须面对的课题。

最近几年，在软件开发领域越来越多企业在使用敏捷方法，2011年初为外部用户开发软件产品的应用开发团队提出希望使用敏捷方法进行开发的要求。那么原有的以CMMI模型为依据建立起来的质量管理体系，引入敏捷的方法后，会不会与现有的质量体系的管理策略冲突？如果策略不冲突，如何将使用的敏捷方法融合到现有框架中，与现有的实践活动相得益彰。

2 CMMI模型和敏捷方法的互补

CMMI是软件能力成熟度模型集成，不同的企业，采用模型进行质量管理时，由于企业背景，生产的产品，面对的用户等诸多不同的特征，虽然都是依据同样的CMMI模型，但是每个企业产生的标准过程一定也必须是各不相同的。不同可能体现在流程设计、流程中的活动个数、活动顺利、活动的执行人以及活动输出的工作产品等方面。

同样，企业在编制标准过程中，要面对不同类型的项目，这些项目在规模、目标和最终用户类型等等方面存在差异，要达到规范管理的目的，如果使用相同的标准和相同的流程，不一定能起到同样的效果。必须针对项目具体特征，具体问题具体分析，才能在统一的标准指导下，建立适宜多数项目的管理流程。

CMMI是质量管理框架，是指导思想，它的作用是指导企业实施质量管理时如何思考，要进行哪些过程管理，每个过程要达到哪些目标，并没有要求各过程必须用什么方法，也没有给出具体的方法。2010年10月出版的CMMIV1.3模型中增加对敏捷方法的说明，有10个过程域的解释说明中提到了敏捷方法在这些过程域中的特征3，这说明CMMI模型本身就具备能够融入多种不同方法的开放性。

2.1 关于CMMI

2.1.1目标是CMMI模型必需的部件

CMMI产生于几十年的研究和实践应用的总结，是组织过程改进时，期望的动作集合。这些过程集合分布在22个过程域中，每个过程域由不同个数的特定目标和相同个数的共性目标构成，每个目标被推荐了不同个数的实践，这些实践活动是被期望的，每个实践下面给出了子实践作为资料性的部件。

以配置管理为例说明，配置管理过程域有3个特定目标：①SG1：建立已确定的工作产品的基线；②SG2：跟踪并控制已纳入配置管理下的工作产品的变更；③SG3：建立并维护基线的完整性。其中SG1有3个期望的特定实践活动：①确定配置项：确定将纳入配置管理下的配置项、构件及相关的工作产品；②建立配置管理系统：建立并维护配置管理和变更管理系统，来控制工作产品；③建立或发布基线：建立或发布供内部使用和交付给客户的基线。

目标是必需的部件，目标下的实践都是期望的部件,这意味着目标是要满足的。当某种特定项目背景下，可能某些形式的活动必须被替代。缺少或者替换某些实践活动并不重要，重要的是要满足目标。此外，为了满足组织的不断改进，替代实践也是被推荐的。

2.1.2使用CMMI模型常见的问题

尽管CMMI允许替代实践满足目标，但是没有明确这些实践，这样导致了很多使用者有这样的担忧：如果使用替代实践在评估中将被如何看待。

当CMMI的使用者为组织和项目建立标准过程时，往往不能确保：①过程对所有部署的项目都是适应的；②根据使用情况，周期性的修订标准过程；③兼容个体和团队的实践并且有足够的灵活性支持团队根据他们的需要和经验采用过程集。

组织、项目和员工之间在项目目标、商务目标和企业文化等方面存在利益冲突，要做到有效管理，争取一定条件下各方利益最大化，必须找到平衡点。平衡倾向于组织的利益，项目可能缺乏灵活性；另一方面，太多的项目灵活性将给组织带来诸多风险，使组织失去成长机会，长期下去将导致质量和生产率降低等后果。到达合适的平衡是很困难的，也是每个企业要克服的难题。

2.2 关于敏捷

2.2.1敏捷特征

敏捷方法的基石是75年前就已经被工程实践使用的迭代和增量的设计和开发（IIDD）。早在五十年代中期，IIDD就被应用于软件开发活动，到了九十年代，IIDD在软件行业通过各种快速应用开发（RAD）、统一过程（RUP）形式得到广泛的应用。极限编程（XP）是由KentBeck在1996年提出的，包括13个核心实践如：功能驱动开发（FDD）、结对编程、测试驱动开发（TDD）和持续集成等。

2.2.2使用敏捷方法常见的问题

敏捷开发是一种以人为核心、迭代和循序渐进的开发方法，它以灵活、适用多变的需求以及频繁交付等优点受到越来越多软件开发人员的推崇，但是，不可否认，敏捷方法在使用中也存在诸多问题：

①敏捷开发可以对不断变化的需求进行快速响应，它的策划是短期对项目的策划，但是对于项目的整体目标并没有完整的计划；

②敏捷开发对人员的要求极高。对于开发需要全能型开发者，需同时具备设计、编码和测试的能力，并对频繁变更的需求做出快速的响应；对于测试人员不但要熟悉开发语言和自动化测试工具，能够编写自动化测试脚本或者用工具录制，而且要参与项目的需求分析和架构设计。但是大多数项目存在开发人员和测试人员均达不到上述要求的现象；

③敏捷开发是在不断的沟通中进行的，所以团队的成员需要非常好的沟通技能。但往往一个优秀的程序员是不善于社交与沟通的，这必然造成团队成员无法有效的传递他们的想法给团队的其他成员；

④敏捷开发更注重代码，而非文档，更多的依赖于人，而非流程；对于人员流动性大的公司，势必会造成人员离职后，继任者不能很快了解项目情况，造成项目拖延；

⑤对于大型而复杂的项目，如何把项目分割成能相对独立的模块、团队与团队之间如何沟通和代码之间如何共享也是敏捷需要面对的问题。

2.3 CMMI和敏捷的互补

CMMI和敏捷是可以并存和互补的。在项目级，CMMI关注高等级的抽象过程即项目做什么，而不是使用的开发方法，敏捷方法刚好是关注如何开发产品，开发方法的具体内容。因此，CMMI和敏捷方法能够并存和互补。

CMMI和敏捷可以通过协调彼此互补让使用他们的组织受益。敏捷方法提供了软件开发"how-to"，这正是CMMI最佳实践所缺少的。CMMI提供的系统工程实践能够在大型项目上帮助敏捷方法，CMMI也提供过程管理和支持实践以帮助部署、支撑和持续提高敏捷方法的执行[1]。

敏捷方法对人员能力的要求极高，但是又没有给出如何提高人员能力的方法，CMMI的每个过程域都有一个对培训人员能力共性实践 (GP2.5)的要求，同时，组织培训过程域（OT）要求识别每个岗位的人员能力要求并根据现有人员的能力和能力要求之间的差距，分析、制定和实施培训活动[2]。

CMMI每个过程域的共性实践GP2.7要求项目按照计划确定并管理与项目有关的利益相关人员，同时在项目策划（PP）、项目监控（PMC）集成项目管理（IPM）过程域都有特定实践活动要求在过程中策划和实施利益相关方的协调管理[3]，这有利于敏捷方法实现团队成员及团队之间的沟通。

CMMI注重流程的遵守和文档的保留，敏捷更注重人员的自我管理和隐性知识的传播，通过二者的结合，通过CMMI把团队的隐性知识逐步转换为组织的显性知识，吸收敏捷方式，使CMMI的流程更加灵活。

敏捷和CMMI同时使用，能获得更多的价值。当今，很多使用CMMI的组织拥有敏捷开发团队，通过迭代等方法的引入，敏捷方法可以完美的融合于基于CMMI建立的质量管理体系[4]。

3 PDP为牵引，为各类项目定义过程

3.1 项目已定义过程

CMMI模型有一个过程域-集成项目管理，这个过程域的目的是裁剪组织的一系列管理过程、产品过程及其过程产生的工作产品后形成项目定义的过程集[5]，来管理项目和项目的相关干系人。裁剪活动的工作产品就是项目已定义过程（PDP）。PDP在项目的整个生命周期被使用以管理各类活动、工作产品和相关干人员，项目通过这种形式定义了管理和执行方式。项目的裁剪活动如图1所示。

图1 裁剪组织的标准过程形成项目已定义过程

3.2 引用敏捷方法的项目已定义过程

初次使用敏捷方式时，组织级的项目已定义过程中是没有对应的过程和工作产品描述的，所以使用敏捷方法的项目在产生项目的已定义过程时，需要在对应的过程活动中进行替代和删除等裁剪说明。随着使用敏捷方法的项目增多，组织的标准过程中会增加相关的过程描述，这时，敏捷项目进行裁剪时，可以直接选择不需要进行裁剪说明。下面介绍在组织的标准过程中没有对应敏捷活动的情况下，项目如何在项目已定义过程中体现相关活动的实例。该项目采用了敏捷方法中的Scrum，测试驱动开发（TDD）和持续集成3种活动，下面展示Scrum和持续集成方法在项目已定义过程中的描述。

3.2.1 Scrum在项目已定义过程中的描述

Scrum是一种迭代式增量软件开发过程，包括了一系列实践和预定义角色的过程框架，把产品需求的实现分为若干个Sprint来完成，每个Sprint完成后进行产品演示，以便更好的收集和细化用户需求。

Scrum引入计划会议来代替需求的估计、设计以及任务的划分；引入每日站立会来代替任务的分配和跟踪；引入演示会，快速交付产品给用户；引入总结会，对团队出现的问题进行解决。Scrum引入了3个文档，Product Backlog(产品列表)来体现整个产品需求，Sprint Backlog(迭代需求列表)来体现每个迭代的需求，burn down chart(向下燃尽图)来体现任务的完成情况，特征在项目已定义过程中部分项目管理过程的描述如表1所示。

表1.包含Scr um方法的部分项目已定义过程

3.2.2持续集成在项目已定义过程中的描述

持续集成的方法是对项目成员开发的代码每天至少集成一次，每次集成都通过自动化的构建（包括编译、发布和自动化测试）来验证，尽快地发现集成错误。传统的软件开发模式，通常把集成放在代码全部编写完才进行。采用持续集成的方法，可以每天对代码进行集成，并针对测出的问题进行修改，修改后再与其他代码集成，保证问题及时解决。持续集成的最大好处是任何时间都可以发布部署的软件，达到快速交付的目的。持续集成和普通的集成，产生的工作产品是一样的，特征在项目已定义过程中的描述如表2所示。

表2包含持续集成的部分项目已定义过程

4 结束语

通过引入敏捷中Scrum、测试驱动开发及持续集成等具体方法，丰富了组织的管理方法的同时，对于其他项目也有启迪作用，比如有的项目组没有采用完整的Scrum规程，但采用了每日站立会的管理形式，把原来每周进行的监控粒度缩短到每日，增强项目经理对项目进展的可控性。

质量管理体系是依据CMMI模型要求建立的，但是对于能提高产品质量、提高生产率的任何方法和模型，都可以通过对组织标准过程适当裁剪和审批的途径进行试用[6]，验证其有效性后，成为组织的标准过程之一，以此方式持续丰富管理方法，提升组织能力。

[1]GLAZER H,DALTON J,ANDERSON D,et al.CMMIor Agile:Why Not Embrace Both[R].USA:SEI,2008.

[2]GJB5000A-2008,军用软件研制能力成熟度模型[S].

[3]CMMIProduct Team.CMMIfor Development,Version1.3.[R].USA:SEI,2010.

[4]MCMAHON PE.Integrating CMMIand Agile Development:Case Studiesand Proven Techniquesfor Faster Performance Improvement[M].USA:Addison Wesley,2010.

[5]ANSI/PMI99-001-2008,A Guide to the Project Management Body of Knowledge:Fourth Edition[S].

[6]GARCIA S,TURNER R.CMMI生存指南:最佳过程改进方法[M].北京:电子工业出版社,2010.