论文部分内容阅读
摘 要：通过对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分钟内结束，因此在会议过程中只记录问题，不解决问题。会议不需要有详细的会议记录，但是必须有会议问题的列表及跟踪情况。
在每个Scrum周期结束后，需要有正式的迭代回顾会议，在会议上对本次迭代的数据进行分析，Review本次迭代过程中的所有障碍和问题及上个迭代针对过程改进措施的改进效果，对下个迭代中重点改进的问题及解决方案进行讨论。
2 敏捷模式与CMMI-4活动的对照
如表2所示，分析了一个迭代周期内主要项目活动与CMMI过程域的对照关系，可以看出，敏捷开发模式与传统的软件开发模型并无本质区别，也同样经历有需求设计实现测试的环节；而CMMI-4着重于对项目进行量化管理，而因为敏捷开发在工作量评估上采用故事点估算，且在迭代过程中使用燃尽图进行进度控制，因此敏捷模式与CMMI-4具有天然的亲和性。
3 具体实践及成果
在刚开始对可视化实施类项目进行规范管理时，因为使用的是适用于软件开发的瀑布模型，因此对项目进行中发生的变更应对不及时，项目过程中或多或少地存在着实际项目工作与流程不符的情况，有效的项目管控工作很难开展；尤其是在公司推行CMMI-4体系管理后，因为各项目执行阶段的无序性，导致很难收集到准确的度量数据，对建立准确的量化模型及实施量化管理带来了很大的难度。在尝试建立敏捷开发模式并采用其进行项目实施后，因强调“持续构建，阶段交付”，用户可以随时看到最新的工作成果。
参考文献：
[1]徐俊，彭章纲.敏捷开发过程与CMMI实施融合研究[J].现代计算
机，2011.12.
[2]James Shore， Shane Warden.敏捷开发的艺术[M].机械工业出版社，2009.
[3]张敬周.Agile方法研究综述[J].计算机应用与软件，2002.06.
关键词：软件产品；质量保证；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分钟内结束，因此在会议过程中只记录问题，不解决问题。会议不需要有详细的会议记录，但是必须有会议问题的列表及跟踪情况。
在每个Scrum周期结束后，需要有正式的迭代回顾会议，在会议上对本次迭代的数据进行分析，Review本次迭代过程中的所有障碍和问题及上个迭代针对过程改进措施的改进效果，对下个迭代中重点改进的问题及解决方案进行讨论。
2 敏捷模式与CMMI-4活动的对照
如表2所示，分析了一个迭代周期内主要项目活动与CMMI过程域的对照关系，可以看出，敏捷开发模式与传统的软件开发模型并无本质区别，也同样经历有需求设计实现测试的环节；而CMMI-4着重于对项目进行量化管理，而因为敏捷开发在工作量评估上采用故事点估算，且在迭代过程中使用燃尽图进行进度控制，因此敏捷模式与CMMI-4具有天然的亲和性。
3 具体实践及成果
在刚开始对可视化实施类项目进行规范管理时，因为使用的是适用于软件开发的瀑布模型，因此对项目进行中发生的变更应对不及时，项目过程中或多或少地存在着实际项目工作与流程不符的情况，有效的项目管控工作很难开展；尤其是在公司推行CMMI-4体系管理后，因为各项目执行阶段的无序性，导致很难收集到准确的度量数据，对建立准确的量化模型及实施量化管理带来了很大的难度。在尝试建立敏捷开发模式并采用其进行项目实施后，因强调“持续构建，阶段交付”，用户可以随时看到最新的工作成果。
参考文献：
[1]徐俊，彭章纲.敏捷开发过程与CMMI实施融合研究[J].现代计算
机，2011.12.
[2]James Shore， Shane Warden.敏捷开发的艺术[M].机械工业出版社，2009.
[3]张敬周.Agile方法研究综述[J].计算机应用与软件，2002.06.