CMMI―4体系下的项目敏捷开发模式研究.docVIP

CMMI―4体系下的项目敏捷开发模式研究 　　摘 要：通过对CMMI尤其是CMMI-4体系及敏捷开发模式各自特点的分析，给出符合CMMI-4体系规范的项目敏捷开发模式，使之能在保证项目整体可控情况下，更快地响应用户的需求变化，从而提升用户满意度。 　　关键词：软件产品；质量保证；CMMI认证；敏捷开发 　　本文中涉及的项目类型为可视化实施类项目，此类项目的内容为根据用户的需求，进行展示场景的设计，并使用公司自主开发的可视化平台进行配置实施，其特点为用户的需求不定且变化非常频繁，配置实施的成本/效能为线性关系，因此本质上项目组欢迎变化并有能力进行快速响应，因为这并不会带来额外的成本投入，并可显著提升用户满意度。 　　敏捷软件开发又称敏捷开发，是从 1990 年开始逐渐引起广泛关注的一种新型软件开发方法， 是一种应对快速变化的需求的一种软件开发能力。敏捷开发的核心思想是：以人为本，适应变化。 　　敏捷软件开发突出如下四点： ①个体和交互胜过过程与工具；②可以工作的软件胜过面面俱到的文档；③客户合作胜过合同谈判；④响应变化胜过遵循计划。 　　敏捷过程具有下列五项共通的特性： ①客户与项目组人员形成密切合作的团队，共同努力达成项目目标；②项目最终的目标是提交给客户需要的工作产品， 因此所有的中间产品必须经过审慎评估；③采用增量、迭代方式分阶段进行；④过程可以简单，但规划与执行必须严谨；⑤强调团队合作，赋予高度的责任，团队有自主权得以因应变化做调整。 　　敏捷开发的适用项目的选择条件： ①相对比较成熟的产品团队；②开发技术架构稳定；③项目人员能力较强；④具备较强的自我学习和较高的管理能力；⑤当前进度要求不紧迫。 　　1 敏捷模式的建立 　　可视化实施类项目的敏捷研发模式是参考业界各种敏捷开发流程，经过团队实践总结出的项目开发流程及实施模型。该模式通过产品Backlog整理产品需求，并通过迭代Backlog将需求按照迭代次数分解，每个迭代推荐以2周时间为一个Scrum周期，在迭代过程中团队通过每日站立会议沟通项目进展以及问题，在每个迭代结束时，交付可用的增量产品。该模型引导团队敏捷迭代、小步快跑，持续交付有价值的产品。以反馈→需求→迭代→发布为主线，贯穿整个敏捷开发生命周期。（表1） 　　1.1 需求阶段 　　在项目启动之初，应确定项目的愿景目标，并与用户达成一致。通过关键目标分解和用户反馈，收集所有需求归总需求池；PDM从需求池中整理出一份按重要性排序的需求列表。需求列表至少包括场景编号、描述、目标、重要性等。PDM定期维护需求列表（注：“重要性”是对目标、对用户而言的重要性，不等同于“优先级”）。根据项目的实施计划，由PDM和SM在需求列表的基础上，分解细化扩充关键字段， 把原始需求拆分成最小颗粒度的用户故事，以方便团队拆分任务（Task）、估算开发时间、领取开发任务，从而规划出一份Product Backlog，如：规模、场景内容、优先级等。 　　1.2 计划阶段 　　项目在启动阶段与其他项目类似，需要制定整个项目的总体计划以及其他附属计划，包括：配置管理计划、测量与分析计划、质量保证计划等。需求负责人、项目经理以及项目团队应该对项目的风险进行管理，并在每次迭代中持续进行风险管理。同时，项目经理需要明确各阶段目标，并确定大概的时间范围。 　　在每次迭代规划会议中，项目经理和团队成员根据各阶段目标，对Product Backlog中的用户故事进行排序，选取合适的用户故事进行本轮迭代，并为每一任务分派合适的人员。 　　1.3 配置实施 　　在配置实施阶段，项目组需要每日对配置成果进行检查，它体现的思想是每天都可以交付新功能，每天都可以展示产品现状，交付产品价值，及时获取反馈。鼓励团队提交工作成果，帮助团队及时收到反馈并修正错误，持续、频繁的集成将集成化风险降到最低点。可视化实施类项目直接在用户环境中进行配置，用户会持续对配置的阶段成果进行验证及确认。 　　1.4 测试阶段及用户反馈 　　在项目进行过程中，时刻保持用户的积极参与，能有效地降低项目的风险，避免不必要的理解偏差与变更。因此，项目组在配置实施阶段，定期召集用户方相关人员进行阶段成果评审，并持续跟踪用户反馈，由需求负责人整理后，以邮件、Excel等方式转给项目团队跟进处理，并把反馈转为Bug或需求。 　　1.5 过程跟进与总结阶段 　　因为敏捷模式下每个迭代周期都非常短，因此及时的沟通显得尤为重要。除项目组集中办公外，项目组必须进行每日站立会议，在会议上每个项目组成员都要发言，以Sprint Backlog为核心，每个人说三句话，昨天做了什么，今天准备做什么，有没有需要协调的问题。会议必须在15分钟内结束，因此在会议过程中只记录问题