CMM与敏捷开发融合的软件过程改进研究与实践.doc

CMM与敏捷开发融合的软件过程改进研究与实践 硕士学位论文 THESIS OF MASTER DEGREE 论文题目: CMM 与敏捷开发融合的软件过程改进研究与实践(英文): The Research and Practice of Software Process Improvement Based On the Fusion of CMM and Agile Development作 者:郭敏指导教师:杨 小 平教 授 2008 年 6 月 2 日论文题目:(中文)CMM与敏捷开发融合的软件过程改进研究与实践 (外文) The Research and Practice of SoftwareProcess Improvement Based On the Fusion ofCMM and Agile Development所在院、系、所 : 信 息 学 院专 业 名 称 : 计算机应用技术 指 导 教 师姓 名、职 称 : 杨 小 平 教 授论 文 主 题 词 :软件过程;CMM ;敏捷开发;融合原则 学 习 期 限 :2005年 3月至 2008 年 3 月论文提交时间:2008年 4月 独 创 性 声 明本人郑重声明:所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知,除了文中特别加以标注和致谢的地方外,论文中不包含其他人已经发表或撰写的研究成果,也不包含为获得中国人民大学或其他教育机构的学位或证书所使用过的材料。 与我一同工作的同志对本研究所做的任何贡献已在论文中作了明确地说明并表示了谢意。签名: 郭 敏日期: 2008 年 4月 15日 关于论文使用授权的说明本人完全了解中国人民大学有关保留、使用学位论文的规定,即:学校有权保留送交论文的复印件,允许论文被查阅和借阅;学校可以公布论文的全部或部分内容,可以采用影印、缩印或其他复制手段保存论文。签名: 郭敏 导师签名: 杨小平日期:2008年 4 月 16日 CMM 与敏捷开发融合的软件过程改进研究与实践摘 要 CMM 和敏捷开发是软件过程改进领域两个代表性理论,分别代表着软件过程改进的“重量级”和“轻量级”思想。然而,无论是 CMM 还是敏捷,都尺有所短、寸有所长,不能解决软件生产领域的所有问题。 本文通过分析两种理论的理论起源和实践支持,合理的进行融合与裁减,在两种理论的基础之上构建出一个理论框架,实现将两种理论有机地融合在一起。论文分别对 CMM 和敏捷论进行了介绍,并研究了它们在实施过程中出现的问题与局限性。针对这些问题,将两者的理论来源进行了对照与分析,得出两者在项目实践中的昀佳作用域,提出了 融合原则。在融合原则的基础上,构建基于融合原则的实用框架,并从两个阶段和两个层面对该框架进行阐述说明及定量分析。同时结合实际项目,研究了基于该框架的开发实践。 本文将 CMM 与敏捷开发两种看似对立的理论进行合理融合,提出基于融合原则的软件过程改进框架,并通过案例和数据进行实证分析,从而对软件过程进行有效改进。本文通过融合与裁减,构建出一个理论框架,中小软件组织可以根据具体项目,对该框架加以融合应用,从而形成一种适合中小型项目团队,在复杂和不确定的环境中使用的软件过程改进方法。同时,为提高软件产品质量,提高软件组织能力成熟度提供支持,具有一定的实践意义。关键字:软件过程,CMM,敏捷开发,融合原则 CMM 与敏捷开发融合的软件过程改进研究与实践Abstract As two representative theories in the software process domain,CMM and Agile Development respectively stand for two opposite thoughts in the software improvement process-“heavyweight” and “lightweight”. However, both CMM and Agile has their own advantage and disadvantage,and neither of them could solve all the problems in the production fieldBased on the analysis of theoretical origin and practical support of the two theories, the paper logically introjects and dismisses some parts of the two thoughts, and builds a new theoretical framework, so that the two theories are organically fused into a whole. Aiming at the problems, the paper makes a meticulous analysis and contrast over the theoretical origin of the two theories , and it finally finds out the best effect-gaining field in the practice of projects , and brings forward the fusion theory. Moreover, grounded on the fusion principle, the practical framework comes to birth. It is expounded and illuminated from two phases and layers. At the same time ,combined with the practical projects, the development and practice of the framework is investigatedThe innovative point in this paper can find itself in the logical fusion of two theories though seemingly contradicted, and the formation of the improved framework based on the fusion principle in the software process. The paper gives a practical analysis of the case and data, so the software process is efficiently improvedBy introjecting and dismissing, the paper builds a theoretical framework which can be syncretically utilized by some medium- sized and small-sized software organizations in terms of their specific projects, so that a improved method suitable for the medium- and small-sized project team is put forward in the software processAt the same time, this method is meaningful and helpful to improve the quality of the software products, and offer support for the maturity of the organizing ability of the softwareKey words: Software Process, CMM, Agile Development, Fusion Principle CMM 与敏捷开发融合的软件过程改进研究与实践目 录 1 第1章 引言1.1 论文研究背景1 1.1.1 研究背景1 1.1.2 相关研究动态. 3 1.1.3 研究意义3 1.2 研究方法和目标 4 1.3 论文研究内容4 1.3.1 主要研究内容. 4 1.3.2 论文结构5 第2 章 理论基础.6 2.1 CMM理论 6 2.1.1 CMM的出现. 6 2.1.2 CMM的用途. 7 2.1.3 CMM结构 7 2.2 敏捷理论10 2.2.1 敏捷开发. 10 2.2.2 敏捷开发的特点. 12 第3 章 融合原则与改进框架 14 3.1 问题的出现 14 3.1.1 CMM在我国的实践及遇到的问题 14 3.1.2 敏捷开发在我国的实践及其局限性 16 3.1.3 小结18 3.2 融合原则的提出18 3.2.1 CMM与敏捷开发的理论来源. 18 3.2.2 来源的对比与分析21 3.2.3 两者的昀佳作用域21 CMM 与敏捷开发融合的软件过程改进研究与实践 3.2.4 融合原则. 25 3.3 基于融合原则的改进框架 26 3.3.1 框架结构. 26 3.3.2 试探分析阶段对两个层面的分析27 3.3.3 执行阶段对两个层面管理方式的确定. 30 3.3.4 对融合框架的分析41 第4 章 基于改进框架的开发实践48 4.1 项目背景与客户需求. 48 4.2 试探分析阶段的工作. 49 4.2.1 团队管理层面的分析 49 4.2.2 过程管理层面的分析 49 4.2.3 该阶段管理决策的制定. 51 4.3 执行阶段的工作52 4.3.1 团队A的工作 52 4.3.2 团队B的工作 56 4.4 项目总结66 结 论 67 参 考 文 献. 69 致 谢 71 72攻读硕士学位期间取得的研究成果CMM 与敏捷开发融合的软件过程改进研究与实践第1章 引言 1.1 论文研究背景 1.1.1 研究背景 近年来,随着我国软件产业的不断发展,软件制作规模日益扩大,开发风险也随之逐渐增加。软件企业不断遇到了诸如产品质量低下、进度延误、费用超支等不可预知的开发难题。透过这些现象,人们逐渐意识到,软件的过程监控和过程管理等环节的薄弱,是导致项目处于混乱状态的直接原因。因此,如何有效地控制软件过程,提高软件生产率和软件质量,降低开发成本,缩短开发周期己成为软件业面临的难题,同时也是软件工程近年来的一个研究热点。 CMMCapability Maturity Model for Software是90年代初由美国卡内基?梅隆大学Carnegie Mellon 软件工程研究院 SEI 提出的一套关于软件过程改进与评估方法的模型。软件能力成熟度模型基于众多软件专家的实践经验,为软件组织进行软件过程改善和软件过程评估提供了一个有效的指导框架,成为国际上公认的软件生产过程标准和软件企业成熟度等级认证标准。 CMM 理论起源于戴明W. Edwards Deming和朱兰Joseph M. Juran提出的质量管理理论,并且与泰勒Frederick Taylor的科学管理理论和德鲁克Peter FDrucker的现代管理学一脉相承。其核心就是:精细化+标准化+数量化。 CMM实际上就是要将软件开发过程工业化,通过从每一个程序员抓起,从每一个模块、每一道工序抓起,在度量、分析的基础上,设计出昀合理的劳动定额和昀适合的工具以及标准化的操作方法,并将这一方法写成书面的规程和标准的操作流程。 CMM 其优势在于:1CMM 与敏捷开发融合的软件过程改进研究与实践 1. 打破了软件生产的神秘性,把这种生产过程从某些“天才”的神秘创造过程降格成为一般的人类生产过程,使之可测量、可控、可复制。 2. 强调持续改进,并通过过程固化这种改进,保证生产过程稳步提升。 但是,软件的生产过程虽然与人类社会的其它生产过程有类似之处,但完全将其类比为一般制造业的过程来探讨,也会使 CMM 在具体实施到中暴露出一些固有的缺陷: 1. 把人作为部件,忽略其在创造性劳动中的能动性。 2. 大量的文档工作提高了创造性、探索性活动中的变更成本,使得生产组织变得迟钝、不灵活。 相对于CMM这种重量级方法,软件业有另一种思路,那就是轻量级方法(Light Weight) ,即敏捷开发。敏捷方法学强调持续交付软件产品,拥抱变化,注重团队交流和用户即时反馈,其目标是以较小的代价获得重量级相当的效果。 敏捷开发植根于上个世纪 80年代后期的 Smalltalk社区。 90年代, Kent Beck和 Ward Cunningham把他们使用 Smalltalk 开发软件的项目经验总结和扩展,逐步形成了一种强调适应和以人为导向的软件开发方法。 敏捷宣言作为敏捷开发思潮的纲领性文件,提出如下四点主张: 1. 人和交互重于过程和工具。 2. 可以工作的软件重于求全责备的文档。 3. 客户合作重于合同谈判。 4. 随时应对变化重于循规蹈矩。 从软件业的实践来看,敏捷理论确实在某些创造性、探索性极强的软件过程中极大的解放了开发者的生产力。按照敏捷理论的领军人物之一 Jim Highsmith1的说法,敏捷使得一个组织能够产生“可靠的创新” 。1但是,也是引用 Jim Highsmith 的说法: “敏捷不是过程而是一种氛围” 。敏捷需要人的全情投入,这与美国管理学家麦格雷戈(Douglas MC Gregor)提出的 XY理论中的“Y理论”有共同之处,当然也存在共同的局限: 1. 对参与者的要求高,除了技能外,还要有实施该方法的热情。 2. 目标是形成软性的“氛围”,缺乏硬性的步骤指导与可操作性、可复制性。 3. 在一些“非创造性”的软件开发工作中,如:简单模块的实现,界面绘制工作中,引入了过多的随意性,反而使其变得不可控制。2CMM 与敏捷开发融合的软件过程改进研究与实践 1.1.2 相关研究动态 通过查阅各类文献,笔者发现目前对于 CMM 和“敏捷开发”多是以分立的研究为主。 对于 CMM 的相关研究,一部分集中在基于 CMM/CMMI的软件过程改进研究。以 CMM/CMMI 为基础,研究 CMM 在具体应用过程中,如何进行剪裁,形成一种适合应用的框架结构。另一部分研究着重于软件质量保证体系,从技术角度出发,重点研究和论述如何有效控制软件质量。 另外,随着近几年“敏捷理论”的不断升温, “敏捷开发”的相关研究也逐渐被应用在软件开发中。其中主要集中在对于“敏捷”理论的整合与扩充以及基于“敏捷”的软件过程改进方面,例如:敏捷制造思想、敏捷项目管理思想等,尤其是在一些项目中,在使用 CMM 管理方式没有取得预期效果的情况下,逐步引入了敏捷式的管理和开发,并取得了良好的效果。 虽然两种理论的研究各有偏重、各有特点,但是在对两种理论的研究中却始终有一种排他倾向,认为这两种理念根本无法相互借鉴,甚至水火不容,对于以相互融合为主导思路的研究尚不多见。思特沃克 Thought Works 软件公司西安有限公司总经理郭晓,在软博会上作的关于“敏捷开发的成功应用以及对中国2软件产业的影响”的演讲中提到 : “要真正赶上昀新一轮的创新浪潮有几个重要的标志,一个是要赶上昀新的 CMM 转向敏捷开发,印度已经开始这方面的工作。从体系架构角度讲,除了一些先进的架构理念,还有一些架构模式,开源代码的应用,不仅仅是操作系统,包括数据库、应用服务器、各种开发工具等等有很多的开源工具。” 1.1.3 研究意义 软件生产的实践永远是鲜活多变的,虽然 CMM 和敏捷理论它们在某些特定的软件生产过程中具有显而易见的优势,但是两者都不能一劳永逸的解决软件生产领域的所有问题。 论文通过分析这两种看似对立的理论起源和实践支持,通过合理的融合与裁减,构建出一个理论框架。软件组织可以根据自身及软件项目实际情况,将该框架加以融合应用,从而形成一种适合中小型项目团队,在复杂和不确定的环3CMM 与敏捷开发融合的软件过程改进研究与实践 境中使用的软件过程改进方法,为提高软件产品质量,提高企业的软件过程能力成熟度提供支持,从而推动软件过程的改进。 1.2 研究方法和目标 通过比较软件生产过程与其它制造业生产过程的异同,分析 CMM 理论与敏捷理论的理论起源与实践情况,笔者认为:两种理论对不同类型的软件生产过程以及软件生产过程中的不同阶段有着不同的侧重,在某种条件下具备融合使用的可能性。 3软件过程改进的目的是帮助软件组织不断的改进其软件过程。 因此,笔者在研究中试图确立一种以“能力成熟度模型”(CMM)和“敏捷开发”为基本素材,以符合国内软件开发实际情况的“裁减原则”为尺度的软件生产过程的理论框架。通过该框架的应用,来更加有效地指导软件生产过程,进一步提高软件生产效率,促进软件过程的改进。 1.3 论文研究内容 1.3.1 主要研究内容 本文主要从以下几个方面进行了研究: 1. CMM 和敏捷开发在我国的实践以及在中小软件组织实施过程中出现的问题和局限性。 2. 针对问题和局限性,对 CMM 和敏捷开发的理论来源进行深入分析与对比,创新性地提出使用设计成本和构建成本的观点分析两者的昀佳作用域,并以此为基础提出基于两种理论的融合原则。 3. 在融合原则的基础上,构建软件过程的改进框架,分别从试探分析和执行两个阶段以及团队管理和过程管理两个层面对软件过程进行控制和改进,并对框架进行定量分析。 4. 通过详实的案例和数据对改进框架进行实证分析,有效地指导软件过4CMM 与敏捷开发融合的软件过程改进研究与实践 程,进一步提高软件生产效率。 1.3.2 论文结构 论文共分为五部分: 第 1章:引言。主要阐述论文的研究背景和内容。 第 2章:理论基础。对 CMM 和敏捷开发分别进行了简单介绍。 第 3 章:融合原则与改进框架。针对实践中遇到的问题,充分对比和分析CMM 和敏捷开发的理论来源。从设计成本和构建成本的角度,得到两者的昀佳作用域,并以此为基础提出融合原则和改进框架,并从两个阶段、两个层面分别对框架进行详细分析和说明,同时进行框架要素的定量分析。 第 4 章:基于改进框架的开发实践。采用案例和数据对改进框架进行进一步实证分析和说明,通过该框架的应用,来更加有效地指导软件生成过程,进一步提高软件生产效率,保证软件质量。 结 论:总结全文,明确作者观点。指出在具体问题具体分析的原则下,从特定项目的特定矛盾出发,不断探索、裁剪、应用各种方法论中的合理因素,才能更加经济、快捷、有效地改进软件过程。5CMM 与敏捷开发融合的软件过程改进研究与实践第2章 理论基础 2.1 CMM理论 2.1.1 CMM的出现 SEI 是美国国防部出资于 1984年设立的。从 1986年开始,SEI 开始针对软件组织改善其软件过程,特别是美国国防部对软件承包商的能力评价问题,研究“过程成熟度框架”。1987 年,SEI 发表了以 Watts Humphrey 为首的研究组的成果?过程成熟度框架的简要说明和成熟度提问单。以此为蓝本,SEI 于1987 年到 1991 年间,对美国的一些大公司的软件组织进行了软件过程评估实践。根据这 4 年的实践经验,特别是从美国政府和工业界反馈的关于软件过程评估的信息,软件过程成熟度框架进化为软件能力成熟度模型,并在 1991年 8月 15日首次公开发布 CMM1.0 版本。其后的两年里,先后产生了 30多稿草案,并在应用中不断总结经验,进行模型改进,之后于 1993年 2月 10日发布 CMM 41.1版本。 由 SEI 提出的软件能力成熟度模型Capability Maturity Model for Software,CMM是软件开发机构用于定义、实施、测量、控制和改进软件过程的一种阶段性描述。该模型为选择过程改进策略提供指南。CMM 针对软件开发过程建立了一组公开而有效的描述成熟软件组织特征的准则,组织能运用这些准则去改进其开发和维护软件的过程,软件用户能用它去评价与某一软件企业签订软件项目合同时的风险。 实践证明,CMM 能够较为准确地反映软件企业的质量管理水平,并为企业的进一步改进提供指导。 6CMM 与敏捷开发融合的软件过程改进研究与实践 2.1.2 CMM的用途 根据能力成熟度模型的设计目标,CMM 有两个基本用途:一是软件过程改进与评估,为此 SEI 专门为软件组织进行内部过程改进而建立了一套评估方法 5? BAIPI(CMM Based Appraisal for Internal Process Improvement) ,这主要是用于软件机构的自我改进与发展;二是软件能力评价,主要是外部对软件机构进行评价以做出软件制造商选择。本文所探讨的,是 CMM 的第一种用途。6SEI 推荐 IDEAL模型为软件过程改进模型。 2.1.3 CMM结构 CMM 结构分为 5个成熟度级别,每个成熟度级别表示了过程能力的水平。除了级别 1之外,每个成熟度级都分别由关键过程域组成。7图 2.1 CMM 成熟度等级及其关键过程域 CMM 的基本结构及各级别如图 2.1 所示。CMM 五个成熟度等级共有 18个关键过程域KPA。除了初始级外,其余每一个级别都被分解为若干个关键过程域KPA。关键过程域以目标来表示,当所有目标都达到之后,则关键过程域7CMM 与敏捷开发融合的软件过程改进研究与实践 被满足。每个关键过程域又被划分为共同特性的五个部分,即执行约定、执行能力、执行活动、测量和分析及验证执行。共同特性之下包含各个关键实践KP。当某一成熟度等级中所有关键实践均已在组织中完成,则组织具备了该成熟度等级的所有共同特性,完成了该成熟度级别关键过程域的所有目标,从而组织达到该成熟度等级。CMM 结构示意图如图 2.2所示。图 2.2 CMM 结构示意图 CMM 的各个级别是在多个关键实践的保证之下实现各阶段的目标,从而使软件过程达到各成熟度要求。在第 2 级通过建立基本的项目管理过程来跟踪成本、进度和功能特性。通过制定必要的过程纪律,以达到能够重复应用早先类似项目所取得的成功经验的目的。第 3 级将管理和工程活动两方面的软件过程文档化、标准化,并综合成机构的软件过程,以用于机构的所有项目。第 4 级通过收集对软件过程和产品质量的详细测量数据以用于对软件过程和产品进行定量的理解。第 5 级通过定量的过程反馈信息和试验新思想、新技术的反馈信息,使得持续的过程改进成为可能。18个关键过程域的目的如表 2.1所示。 8 CMM 与敏捷开发融合的软件过程改进研究与实践 表 2.1 各关键过程域目的关键过程域 目的 在客户和遵循客户需求的软件项目之间建立一种共需求管理 同的理解。 软件项目计划 为实施软件工程和管理软件项目制定合理的计划。 可软件项目跟踪和重能够随时掌握软件项目的实际开发过程。 监督 复软件子合同管理 选择软件开发的合格分承制方,并进行有效管理。 级为管理者提供有关软件项目过程和产品的适当可见软件质量保证 性。 保证软件项目生产的产品在软件生命周期中的完整软件配置管理 性。 组织(机构)过 为能改进机构整体软件过程能力的软件过程活动建程焦点 立机构的职责。 组织(机构)过 开发和维护一个可用的软件过程资源集,以提高整个程定义 项目的软件过程效能。 已培训大纲 提高个人的知识和技能,使其有效地履行职责。 定将软件工程和管理活动结合成密切相关、定义完整的义集成软件管理 软件过程。 级一致地执行一个经过完整定义的工程过程以高效生软件产品工程 产出正确而一致的软件产品。 建立软件工程组与其他小组积极协作的一种工作方组间协调 式。 同行专家评审 尽早而有效的排除软件工作产品中的缺陷。 定量管理级定量过程管理 定量地控制软件项目的过程运行效能。 定量了解项目的软件产品的质量并实现具体的质量软件质量管理 目标。 缺陷预防 识别产生缺陷的原因并预防它们再次发生。 优化级识别新技术(如工具、方法和过程)并有序地将其引技术更新管理 入机构。 不断改进机构中所使用的软件过程从而提高软件质过程变更管理 量和生产率,缩短产品开发周期。9CMM 与敏捷开发融合的软件过程改进研究与实践 2.2 敏捷理论 2.2.1 敏捷开发 敏捷开发植根于上个世纪80年代后期的Smalltalk社区。90年代,Kent Beck和Ward Cunningham把他们使用Smalltalk开发软件的项目经验总结和扩展,逐步形成了一种强调适应和以人为导向的软件开发方法。 敏捷开发Agile Software Development是一种以人为核心,采用迭代、循序渐进的软件开发方法。在敏捷开发中,就如同项目管理中将工作任务及工作目标层层分解一样,把软件项目的构建切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成。在此过程中软件一直处于可使用状态。正如Thought Works的首席科学家Martin Fowler所说:“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,这种非常短的循环,使终端客户可以及时、快速地看到花钱构建的软件是一个什么样的结果。”因此敏捷开发也可理解为在原有软件开发方法基础上的整合?取其精华,去其8糟粕。 敏捷开发借鉴了大量软件工程的方法,是传统软件开发意义上的改善,而9非创新。 例如在传统的软件开发中,把设计和构建这两个过程分开进行,设计完成之后,再按照设计进行构建。实际上,由于需求在不断变化,因此在软件开发的过程中,很难把设计和编程完全区分开来。而在敏捷开发中,先搭建一个比较粗的主框架,只对用户目前需求昀迫切的部分详细开发,并很快交付使用,在使用过程中,按用户的需求进行不断修正,周而复始,循序渐进的开发,直到完成。 敏捷开发是由一些业界专家针对一些企业现状提出的一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001年初成立了敏捷联盟。他们认为:? 个体和交互 胜过 过程和工具? 可以工作的软件 胜过 面面俱到的文档 10CMM 与敏捷开发融合的软件过程改进研究与实践 客户合作 胜过 合同谈判? 响应变化 胜过 遵循计划并提出了以下遵循的原则:? 昀优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。? 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。? 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。? 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。? 围绕被激励起来的个体来构建项目,给他们提供所需的环境和支持,并且信任他们能够完成工作。? 在团队内部,昀具有效果并富有效率的传递信息的方法,就是面对面的交谈。? 工作的软件是首要的进度度量标准。? 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。? 不断地关注优秀的技能和好的设计会增强敏捷能力。? 简单是昀根本的。? 昀好的构架、需求和设计出自于组织团队。? 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。实际上“敏捷宣言”的主要规则之一就是:个人之间的交流比过程、工具更重要。团队中的个人以及协同工作的方式是项目成功的两个重要因素 比对过10程和工具的选择要重要得多。 敏捷开发方法在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。敏捷型与“重”型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不注重面向文档,对于一项任务,它们通常只要求尽可能少的文档。 极限编程XPeXtreme Programming是敏捷开发的代表,它通过较短的迭代11CMM 与敏捷开发融合的软件过程改进研究与实践 周期来应对需求的不断变化。XP的四个核心价值包括了沟通、简单、反馈和勇11 13气。 它倡导快速反馈、假设简单性、递增更改、拥抱变化和优质工作。 XP优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意,其运作项目的方法是将项目分成多次迭代,每一次的迭代交付一个通过质量检验、可投入12使用、包含一些新实现的软件。 在具体开发过程中,往往通过测试驱动、整体团队、小型发布、结对编程等进行。 2.2.2 敏捷开发的特点 敏捷方法主要有两个特点,这也是其区别于其他方法,尤其是区别重量级8 14方法CMM的昀主要特征: 1. 敏捷开发方法是“适应性”Adaptive而非“预设性” Predictive。 这里说的预设性,可以通过一般性工程项目的做法理解,比如土木工程,在这类工程实践中,有比较稳定的需求,同时建设项目的要求也相对固定,所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分,施工队伍可以完全遵照图纸顺利建造,并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。 然而,在软件开发的项目中,这些稳定的因素却很难寻求。软件的设计难点在于软件需求的不稳定,从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。所以,这类方法在不可预测的环境下,很难适应变化,甚至是拒绝变化。与之相反的敏捷方法则是欢迎变化,其目的就是成为适应变化的过程,甚至能允许改变自身来适应变化,所以称之为适应性方法。 2.敏捷方法是面向人的(People oriented)而非面向过程Processoriented。 Martin Fowler认为:“在敏捷开发过程中,人是第一位的,过程是第二位的。所以就个人来说,应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的“先过程后人”正好相反。在传统的软件开发工作中,项目团队分配工作的重点是明确角色的定义,以个人的能力去适应角色,而角色的定义就是为了保证过程的实施,即个人以资源的方式被分配给角色,同时,12CMM 与敏捷开发融合的软件过程改进研究与实践 资源是可以替代的,而角色不可以替代。 然而,传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。13CMM 与敏捷开发融合的软件过程改进研究与实践第3章 融合原则与改进框架 在本章中,针对在实践过程中遇到的困难和问题,笔者从理论来源,昀佳作用域两个方面对两种方法论进行分析与比对,并在此基础上探讨两种方法论融合的可能性及具体方式。 3.1 问题的出现 3.1.1 CMM在我国的实践及遇到的问题 近年来,CMM 在我国获得了各界越来越多关注,业界有过多次关于 CMM的讨论。2000年6月国务院颁发的鼓励软件产业和集成电路产业发展的若干政策中对中国软件企业申请 CMM 认证给予了积极的支持和推动作用,第 17条规定“对软件出口型企业 CMM 认证费用予以适当支持。”一些规模软件企业开始尝试 CMM 认证。到 2004 年 3 月,全国通过 CMM2 级以上认证的软件企业超过100家,比2002年的50多家翻了一番,其中,通过 CMM3级以上评估的己超过40家,通过 CMM4, CMM5级评估的有9家,其中摩托罗拉中国、15东软集团、大连华信等都先后通过 CMM5级。 总体上讲,国内对软件过程理论的讨论与实践正在展开,目标是使软件的质量管理和控制达到国际先进水平,使中国的软件产业获得可持续发展的能力。近两三年内,国内软件业出现实施 CMM 的高潮。从这一趋势看,中国的软件企业已经开始走上标准化、规范化、国际化的发展道路,中国软件业已经面临一个整体突破的时代。 CMM 是目前比较成熟,应用也比较广泛的软件过程改进模型,它是软件开发和维护中有关过程管理和质量改进的一般应用。与物理和化学学科不同,CMM 并不是建立在通用的自然规则基础上的。CMM 代表的是软件界对于好的14CMM 与敏捷开发融合的软件过程改进研究与实践 工程和管理实践广泛一致的认同,但 CMM 也不是“板上钉钉”的事,更不是放之四海而皆准的。它本身仍在不断地发展和完善之中。在我国软件企业,实16施 CMM 也存在着一些不容忽视的问题。 1.不理解 CMM 实质,因为“拿证”而认证 从目前国内企业对 CMM 的理解来看,许多企业已经走入了这样的一个误区: CMM 是一个标准,企业只要通过了认证,企业软件开发的水平就会提高了。而要想通过认证,只要能够拿到认证证书就可以了,而从来不关心企业真正的质量管理水平和能力的提高。针对企业而言,认证在一定程度上提升了企业的形象也提高了企业的品牌知名度,同时提高了组织市场占有率,但是许多软件组织一味的去追求认证和获取证书,把 CMM 证书当成了项目招标的金字招牌。 2.大多数中、小软件组织对 CMM 实施力不从心 据资料统计国内企业通过 CMM 认证的费用相当昂贵,聘请 CMM 专家评估做一次比较完整的 CMM2?3 级咨询和评估,大约要花费 50 万至 60 万元。然而 CMM 评估师只能起到参谋咨询的作用,解决实际问题还得靠企业自己。另一方面,CMM 实施的周期也相当长。一般企业从 CMM1升级到 CMM2,大约要 2至 3年,从 CMM2到 CMM3也要 1至 2年。一些中、小公司往往由于资金、资源和规模等方面的原因不可能花巨额资金聘请好的咨询公司或者国际的主任评估师,造成了心有余而力不足,不知道如何进行过程改进,无法实施的尴尬境地。对于中、小企业的主要的目标是先生存、再发展。它们往往承接的项目比较小,时间要求比较急,并且人力、设备资源的限制,如果完全照搬 CMM中 KPA 的要求去实施往往难度较大,造成公司员工的抵触情绪。因此,CMM的实施在中、小企业进展困难。 3.对中、小型软件企业不适用 由于 CMM 昀初设计的目的是用于政府及军方采购,因此主要针对的是大型的软件企业。1993年 SEI 提出了 CMM l. l 版本技术报告文本,有 70页之多,对关键实践的描述文本有 450 页。这就决定了当中、小型软件企业采用 CMM进行过程改进时,需要进行大量的裁剪工作。虽然 SEI 同时给出了中、小型软件企业的裁剪指南,但在实施中仍然存在着极大的困难。 64.表达晦涩15CMM 与敏捷开发融合的软件过程改进研究与实践 在 CMM 的描述中,大量使用许多晦涩的独创的术语,这给软件企业应用时的理解造成了一定的困难,使 CMM 的理解难度更大。这主要表现在 CMM对各个角色人员及小组的定义与分派上。如在 CMM 2级中给出的具体人员便有上级管理部门、软件负责人、项目负责人、其他软件负责人、软件管理人员、项目软件负责人、一线软件负责人、责任重大的软件负责人、客户的 SQA代表、上级负责人等等十余个角色,这些角色的定义并不明确,要求各企业根据自身情况设立或确定相应人员,各角色之间也存在着一定的职责重复。 5. 复杂的模型,繁杂的文件 CMM 给出了一个相当复杂的模型,模型的复杂一方面虽然能够比较全面的反映软件过程,但另一方面也使软件企业在实施该模型时对达到任何一个关键过程域的要求都显得心有余而力不足。实施 CMM 的组织将产生大量的文件,更多的检查点,更多的结果,更长的会议,这与软件企业生产所要求的时效性的确存在着一定的冲突。 3.1.2 敏捷开发在我国的实践及其局限性 敏捷软件开发是一种面临迅速变化的需求,快速开发出高质量软件产品的新方法。由于软件在规模、复杂度、功能上的极大扩展和提高,以及在需求和技术不断变化的过程中实现软件自身开发的需求,敏捷开发正逐渐成为软件开发的新模式,正在被越来越多的软件企业应用到软件产品的开发过程中。 随着企业信息化的不断进步,电子商务在我国也越来越得到更多的认可,电子商务的应用也越来越多,但是很多企业对电子商务的概念和应用还不是很清楚,没有很多成熟的模式可以参考,行业内对电子商务的研究模式和实施方法也存在很多问题。因此很多企业在实施电子商务系统的过程中都处在探索和摸索当中。缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。更长时间的工作却生产出更加低劣的软件产品,也使得开发人员感到沮丧。对于项目开发方来说也有着极大的风险性和挑战性。因此,在电子商务类的软件开发中,不少企业使用敏捷开发方法,有效地提高开发效率,减少诸多不确定性对项目质量的影响。 16CMM 与敏捷开发融合的软件过程改进研究与实践 除了在电子商务方面的应用,其他如项目人数不太多、开发过程中有较多的不确定性等一些中小项目也都采用了敏捷方法进行开发和项目管理。近年来,敏捷方法受到了越来越多的软件企业的关注与青睐。 与 CMM 相比,敏捷开发是目前比较年轻,应用也比较有限的软件过程改进方法。尽管在近几年,它受到了越来越多业界人士的认同和实践,但是敏捷17同样也有其自身的局限性。它本身仍在不断地发展和完善之中 。 1. 缺乏对大型团队开发的支持。敏捷过程支持“小规模管理”的过程,其中采用的协调、控制、交流机制适应于小型到中等规模的团队。对于更大的团队,必须维护的交流线索会降低诸如“面对面交流”和“评审会议”等实践所带来的效果。大团队很少需要敏捷方法来处理针对“大规模管理”的问题,传统的强调控制文档变化和以架构为中心的开发更适应这种情况。这并不是说敏捷不适应这种环境