敏捷开发应用于CMMI3体系的实践探讨.doc

CMMI 能帮助整合以往各自为政的组织功能， 建立 过程改进的目标及优先级，指导组织进行质量改进， 还提供了评价现有过程的参照点。 敏捷开发来源于实践，是一个高度协作的、演进 的以及关注质量的软件开发方法， 是一种允许快速 业务变更的开发实践。 2001 年 2 月由 17 位方法学 家共同起草了敏捷宣言， 敏捷的核心是 4 个核心价 值观和 12 条准则，敏捷更关注团队协作、关注质量、 公司一直关注和跟踪 CMMI 的发展，2009 年成 立工程过程组（EPG），开始进行自发的 CMMI 过程 改进探索。 2010 年 5 月公司正式启动 CMMI3 实施 认证， 引入了咨询商来协助公司过程导入和认证。 2011 年 2 月， 完成了整个 CMMI3 过程体系文件的 编写工作，共发布体系文件 160 余份，约 300 万字， 初 步 形 成 了 CMMI DEV V1.3 L3 的 过 程 体 系 。 2011 年 5 月，完成了 CMMI3 的试点，对过程体系的 可行性、完整性进行了实战检验。 2011 年 6 月，向其 他部门开始制度化推广，通过近 3 个月的推广实施， 基本达到了 CMMI3 过程体系的制度化工作， 并对 现有的 CMMI3 过程体系文件进行了完善和固化， 最终形成了 176 份文件， 约 330 万字的标准过程库 和组织财富库， 积累了初步的项目过程数据。 2011 年 10 月，公司各部门参加了软件工程学会（SEI）的 正式评估，最终通过 CMMI DEV V1.3 L3 的认证， 覆盖人员比例达到了 92%。 关注可工作的软件，而不是理论。 ［1］ 对很多敏捷实践者来说，CMMI 很庞大， 过于关 注过程而削弱了应付日益严峻的需求变更的能力。 很 多 CMMI 的拥趸也批评敏捷对开发过程控制不力， 导致隐性的变更和混乱。 似乎两者无法融合共存。 CMMI 和敏捷开发的目标都是为了解决在软件 生产过程中出现的质量低下、进度延迟、预算超支等 问题，只是它们的关注点有所不同。CMMI 关注为了 实现组织软件生产目标应该做什么， 而不关注如何  品质等方面的要求越来越高，市场竞争日趋激烈。 在进行 CMMI3 的试点过程中我们发现， 如果 完全按照 CMMI3 规范的过程来要求软件二次开发 合同项目，不仅周期长，编写的文档多，无法适应用 户在时间、功能等方面的快速灵活多变的要求，而且 开发人员对此也颇有怨言，开发效率反而降低。为了 适应市场环境，我们在导入 CMMI3 过程的同时，引 入了敏捷开发方法，借鉴敏捷方法中迭代反馈、拥抱 变化的理念，开发出高质量软件产品。 通过全面引入敏捷开发方法， 将此方法定义到 CMMI3 的相关过程体系文件中，对敏捷开发方法进 行实践和验证，取得了丰硕成果，掌握了灵活使用敏 捷开发方法的经验，在此基础上，在公司所有承担软 件合同项目开发的部门中导入了敏捷开发方法。 在项目获取到初步需求后， 根据 CMMI3 的项 目裁剪过程指导， 项目组根据实际情况和敏捷开发 生命周期模型对以上 12 个过程域进行裁剪，在组织 标准过程框架下选定最适合的项目过程。 4 敏捷过程具体实践 4.1 需求获取 在敏捷开发过程中， 如何准确获取市场需求是 开发高质量软件的前提。 实践中发现， 用户对于长篇大论的需求规格说 明书往往不感兴趣，文档写得再清晰，用户通常也想 象不出软件将来究竟呈现出什么样子， 这样的需求 规格说明书用户通常难以签字确认， 导致需求沟通 周期长、需求多变、需求分析人员有强烈挫折感等一 系列问题。 我公司在公安、消防、城市应急等行业应用中都 有对应的产品， 并在全国各地实施了很多 “标杆应 用”，因此在每个项目的需求获取阶段，业务分析人 员带着公司的“标杆应用”和产品，向客户展示产品 功能，获取用户反馈。 在初步获取需求后，强调一切 从业务流程和业务功能角度出发， 项目团队首先进 行针对性的项目原型开发， 业务分析人员和项目经 理再用最新的项目原型跟客户确认项目需求。 以上 过程多次迭代，最终完成需求获取。 敏捷过程模型 3 在敏捷开发中采取迭代反馈的原理， 通过一系 列的方法把市场和客户的需求和期望分散到整个软 件的生命周期中， 最终开发出来的软件产品质量风 险小，能较大概率地符合市场和客户的需求。 我们在参考外部成功经验的基础上， 制定了符 合我公司软件项目特点的敏捷过程（见图 1）。 在该 快速迭代模型中， 主要覆盖 CMMI3 中 12 个过程 域，在需求、代码、测试、发布等几个阶段进行控制。 最能符合市场的模块。 这样就紧紧地抓住了客户真 正价值的需求。 在项目需求审核中如发现对产品研发有价值的 需求，将直接传递给产品经理