敏捷方法在GJB5000A二级中的应用研究

来源:用户上传      作者:

　　摘  要： 为寻求既适用于军用软件研制特征又能满足军方用户特殊要求的敏捷方法与GJB 5000A的结合应用，本文基于Scrum敏捷方法，结合国内军工企业文化，建立了基于Scrum方法的软件项目管理流程。同时，说明了基于敏捷方法的测量与分析、配置管理、过程和产品质量保证过程域实践。
　　关键词： GJB 5000A;敏捷;迭代;Scrum
　　中图分类号： TP311.5    文献标识码： A    DOI：10.3969/j.issn.1003-6970.2020.08.030
　　本文著录格式：陈申平，颜乐鸣. 敏捷方法在GJB 5000A二级中的应用研究[J]. 软件，2020，41（08）：107-109+164
　　【Abstract】： In order to find the combination of agile method and GJB 5000A， which is suitable for military software development characteristics and can meet the special requirements of military users， this paper establishes a software project management process based on scrum agile method and domestic military enterprise culture. At the same time， it explains the practice of measurement and analysis， configuration management， process and product quality assurance process area based on agile method.
　　【Key words】： GJB 5000A; Agile; Iteration; Scrum
　　0  引言
　　2003年，总装备部发布了GJB5000-2003《军用软件研制能力成熟度模型》[1]，2008年进行修订并发布了GJB 5000A[2]。GJB 5000A建立在CMMI-DEV 1.2版[3]的基础上，与CMMI的相似度很高。目前，2008年发布的GJB 5000A已成为我国军用软件研制能力评价和军用软件研制单位进行软件过程改进的主要依据。但是，各软件研制单位实施GJB 5000A后普遍存在管理效率降低、管理成本居高不下等问题，难以持续有效实施和推广。如何能在资源有限且制约较多的情况下保证质量和进度，在控制并实现复杂多变的用户需求的同时降低管理成本，是目前军用嵌入式软件实施GJB5000A过程中面临的最大挑战。
　　20世纪90年代开始，各种敏捷方法相继问世并在软件研制过程中迅速普及。随着敏捷方法的日益普及，其与CMMI之间的关系也逐渐引起国际软件业的重视，众多研究人员相继开展了CMM/CMMI与敏捷方法的结合研究，B. Boehm、R. Turner、M. Pikkarainen、A. Mar?al等的研究成果充分证明[4-7]：CMMI和敏捷方法是相互兼容，且完全可以结合。2010年11月发布的CMMI1.3版[8]增加了对敏捷方法的支持，这标志着敏捷方法和CMMI的结合已成为必然。2018年发布的CMMI2.0版相关实践域中增加敏捷的要求，实现敏捷方法和CMMI的结合。
　　本文通过开展敏捷方法和GJB 5000A二级结合的实施方法研究，提出基于Scrum方法的软件项目管理流程及基于敏捷方法的测量与分析、配置管理、过程和产品质量保证等GJB 5000A二级支持类过程域实践。从而精简管理活动，缩短响应时间，使过程更为有效、高效，以规范软件研制和管理活动，减少软件人对实施GJB 5000A的抵触，从而解决实施过程中“两张皮”的问题，有助于项目的质量和进度目标。
　　1  基于Scrum方法的软件项目管理流程
　　主流的敏捷方法有极限编程、Scrum、模型驱动开发、DevOps等，其中Scrum是目前使用最广泛且最有效的敏捷项目管理方法[9]。该方法将软件研制过程分解为多个2到4周的短周期的迭代，一个迭代称为一个sprint。该方法使用产品backlog来管理产品的需求，并对产品backlog中的需求按业务价值进行排序，通常先实现价值较高的需求。在每个sprint初期根据本次迭代要实现的需求建立sprint backlog。每個sprint结束时完成可交付的产品增量，并对迭代进行回顾[10]。Scrum方法的应用情况表明，尽管该方法起源于软件开发，但同样适用于复杂产品及创新性产品的开发。也就是说，Scrum方法适用于任何规模、任何类型的项目。
　　图1描述了基于Scrum方法的软件项目管理流程，覆盖GJB 5000A二级中的项目策划和项目监控两个过程域。图中实线框为项目管理实施方法中定义的活动，虚线框为项目组按阶段计划实施的活动。将每一个迭代作为一个阶段，每次阶段结束后需进行阶段评审，阶段评审中除常规的技术评审和管理评审外，还包含回顾，即分析本次迭代（本阶段）的最佳实践和存在问题，为后续的过程改进提供依据。
　　基于Scrum方法的软件项目管理流程活动要求如下。
　　（1）早期策划
　　软件所属项目的立项阶段，软件人员参与软件所属上层项目的策划和系统方案设计，从软件实现的角度审查软件研制任务书的需求，并对软件项目的策划活动进行策划。
　　（2）顶层策划
　　顶层策划包括定义软件生存周期模型、顶层WBS分解、顶层估计和制定软件项目计划。 　　基于Scrum方法的项目管理流程在传统迭代模型的基础上，结合Scrum的迭代思想建立快速迭代模型，迭代周期在项目的生存周期中固定不变，通常为2至4周，每次迭代输出的工作产品均是可交付的，并且是在上次迭代产品基础上的增量。软件开发团队可根据软件的质量要求、安全级别和团队人员的能力等特征，灵活定义每次迭代中的工程活动及每项活动的完成准则。
　　顶层WBS分解的输出为按优先级排序的需求列表，策划时应确保先实现高优先级的需求。根据团队成员能力、管理成本及系统计划确定迭代周期和迭代次数。综合考虑如下四方面因素确定每个阶段需完成的任务及其完成准则：a）需求的完备和稳定程度;b）需求优先级;c）迭代周期和估计工作量;d）硬件平台的研制进度。
　　采用故事点估计等方法对软件的需求、用户故事（顾客和开发团队以共同协商的方式对特性进行分解后形成的更小粒度、独立、有价值、可测试的功能模块）和工作量进行估计，并记录估计假设（理由）和估计结果，以确保团队对估计项和承诺的理解达成共识。在进行每一类估计前，先从所有估计项中选择适当规模的某个估计项作为基准估计项，对其他估计项的估计结果是基准估计项的倍数。采用相对值作为估计结果可以使估计人员将关注点从估计值转到对估计项的理解上，可通过估计发现需求问题及对需求理解的不一致，在一定程度上起到评审的效果。
　　综合考虑项目软件过程定义和选择、项目组成员及职责分配、进度计划、资源计划、知识和技能计划、利益相关方计划、数据管理计划、采用的方法及标准、安全保密计划、风险管理计划等内容制定软件项目的总体计划，即软件开发计划。
　　（3）阶段策划
　　阶段策划包括阶段WBS分解、阶段估计和阶段计划制定。
　　阶段WBS分解是按本阶段需完成的所有需求的优先级，对迭代内需要完成的任务进行进一步细化分解。阶段任务分解的粒度需满足每日跟踪的要求。
　　阶段估计采用故事点等估计方法对阶段WBS分解得到的所有任务的工作量进行估计。
　　制定阶段计划首先确定每条任务的优先级。优先级表示每项任务相对于其他任务的优先程度，数值越大，优先级越高。确定阶段进度时，应综合考虑软件阶段的活动WBS、当前阶段或时段的规模和工作量估计结果、人员可用率等因素，并确保任务进度与软件顶层进度计划一致。
　　（4）每日例会
　　用图2所示的燃尽图等形式对前一天计划中需求和任务的完成情况进行监控，识别并分析前一天工作中遇到的问题，记录问题、解决措施和解决情况。
　　（5）阶段计划实施
　　阶段跟踪的控制粒度通常为2至4周，阶段跟踪对象为需求的故事点数。采用总体跟踪图记录阶段跟踪的进度、工作量、规模、资源、知识技能的实际情况及相关信息。
　　（6）阶段评审
　　每个阶段结束时，基于监督数据与利益方一起评审项目的承诺、计划、状态和风险。阶段评审时，通过回顾活动识别本阶段的最佳实践和存在的问题，超出明显偏差时，记录并跟踪更改申请，确定并跟踪纠正措施直至结束。监控并记录风险变化情况，修正风险参数，必要时采取相应措施监督。识别是否有新增风险，标识重大变化，确定并落实缓解措施。
　　2  基于敏捷方法的支持类过程域实践
　　本章将介绍敏捷方法在GJB 5000A二级的测量与分析、配置管理、过程和产品质量保证三个过程域中的具体实践。
　　2.1  测量与分析
　　基于敏捷方法的项目需开展的跟测量与分析过程域相关的实践可包括。
　　（1）定义并使用明确的目标：不限于某次迭代的目标，还可包括在规定期限内完成指定的任务，如在多次迭代中达到一定的速率以满足业务需求。
　　（2）定义并使用测量项。如：团队速率的计算方法，明确计算公式中使用的故事点是按人计还是按团队计，是否包括中断的时间等;团队使用的机动故事。
　　（3）明确测量项的采集、分析和记录要求。
　　（4）明确测量项目和绩效数据的发布对象。
　　（5）根据已定义的目标，使用测量项来跟踪和改进团队的绩效。
　　为开展绩效评估，基于Scrum的项目团队需采集的测量项可能包括。
　　（1）总体跟踪图
　　总体跟踪图用于描述每次迭代结束时随迭代周期变化的剩余故事点数，以及已完成的所有迭代的实际计划完成情况。
　　通过对总体跟踪图的分析，找到产生计划偏差的原因，如计划的工作量过大、员工因计划外承担其他工作影响了项目计划的执行等。同时，根据偏差原因有针对地制定并采取纠正措施，如调整计划、增加资源等。
　　（2）階段跟踪图
　　阶段跟踪图用于描述本次迭代每个工作日结束时剩余任务的工作量，以及本次迭代已完成的实际任务完成情况。
　　通过对阶段跟踪图的分析，可判断当天任务的完成情况及偏差大小，并推算出对阶段进度的影响，从而采取适当的纠正措施，保证项目按计划进行。
　　2.2  配置管理
　　在基于敏捷方法的项目中，对工作产品进行分级配置管理，如将工作产品分为基线配置项、非基线配置项、记录等类型，并制定每类配置项的配置管理要求。根据项目的实际情况来识别配置项，设置基线。
　　除常规的软件文档、代码和记录外，基于敏捷的项目需纳入配置管理的工作产品还可能包括。
　　（1）需求列表。
　　（2）迭代任务列表/阶段计划。
　　（3）任务跟踪表和跟踪图。
　　（4）回顾记录。
　　实施配置管理活动的时机主要如下。
　　（1）需求列表发布。
　　（2）迭代任务列表/阶段计划发布。
　　（3）阶段评审。
　　（4）闭项。 　　在基于敏捷方法的项目中，合理定义并正确理解迭代的输出工作产品和完成准则有助于确保每个阶段完成的工作产品的版本的正确性。迭代输出的工作产品不一定是完整的软件文档和代码，可以是文档片段、分析设计图、组件或函数的代码等。
　　2.3  过程和产品质量保证
　　在基于敏捷方法的项目中，应根据活动时机及活动间的依赖关系对质量保证活动的时机进行相应调整，使质量保证审查与项目活动的节奏相适应。
　　此外，敏捷团队的部分活动中包含了质量保证活动，且由非质量保证人员完成。这些活动包括。
　　（1）软件负责人对项目研制过程提供的指导和纠偏措施。
　　（2）阶段技术评审时对工作产品进行的审查。
　　（3）阶段评审中的回顧。
　　3  结束语
　　在实施GJB 5000A的过程中采用敏捷方法，通过每日例会、阶段跟踪和总体跟踪活动，能及时体现团队成员完成的工作，尽早发现偏差和问题，确保实际的过程与需求和目标保持一致。
　　本文介绍了基于Scrum方法的GJB 5000A软件项目管理流程，同时，给出了敏捷方法在GJB 5000A二级测量与分析、配置管理、过程和产品质量保证过程域的应用。在软件项目中的应用情况表明，该方法适用于基于敏捷方法实施GJB 5000A的组织和团队。在后续工作中，将进一步结合GJB 5000A实施中存在的问题，将软件生存周期从目前的软件开发周期扩展到包括运维在内的全生命周期，对敏捷工程技术方法进行研究。
　　参考文献
　　[1] 总装电子信息基础部标准化研究中心， 总装系统所， 航天科工集团二院204所， 等. GJB 5000-2003军用软件研制能力成熟度模型[S]. 北京： 中国人民解放军总装备部， 2003.
　　[2] 总装备部电子信息基础部技术基础局， 总装备部技术基础管理中心， 总装备部电子信息基础部标准化研究中心， 等. GJB 5000A-2008军用软件研制能力成熟度模型[S]. 北京： 中国人民解放军总装备部， 2008.
　　[3] Carnegie Mellon University. Software Engineering Institute. CMMI for Development. 1.2版[S]. CMU/SEI-2006-TR-008. Pittsburg： Software Engineering Institute， 2006.
　　[4] Boehm B， Turner R. Balancing Agility and Discipline： A Guide for the Perplexed. Addison-Wesley Professional[M]. 2003.
　　[5] Turner R， Jain A. Agile Meets CMMI：Culture Clash or Common Cause//Proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods XP/Agile Universe， 2002： 153-165.
　　[6] Pikkarainen M， M?ntyniemi A. An approach for using CMMI in agile software development assessments： experiences from three case studies[C]//SPICE 2006 conference. Luxemburg， 2006.
　　[7] Mar?al A C， Freitas B C， Soares F S， et al. Blending Scrum practices and CMMI project management process areas[J]. Innovations Syst Softw Eng， 2008（4）： 17-29.
　　[8] Carnegie Mellon University. Software Engineering Institute. CMMI： Capability Maturity Model Integration. 1.3版[S]. Pittsburg： Carnegie Mellon University， Software Engineering Institute， 2010.
　　[9] 李国彪， 译. Schwaber K. Scrum敏捷项目管理[M]. 北京： 清华大学出版社， 2007.
　　[10] 刘从越， 孙刚， 仲里. Scrum与CMMI在中小型安全关键软件中的应用[J]. 计算机工程与应用， 2011， 47（13）： 55-58.
转载注明来源:https://www.xzbu.com/8/view-15321632.htm