GJB5000B二级与敏捷实践的融合技术

林阳涛

（中国航空研究院研究生院 江苏省扬州市 225000）

软件定义一切（Software Define Anything）概念的提出了已经有了近10年的时间，经过多年的理论创新与实践运用，在各行各业都产生了深远的影响，在军工领域，由于软件在现代化武器装备中的规模占比急剧提升，“软件定义装备”已成为世界军事强国公认的新的装备发展模式。如图1所示。

图1：航空电子软件中软件源代码行（SLOC）的增长情况

美国防部于2019年发布了“以相应的速度提供弹性软件能力”为愿景的《国防部软件现代化战略》，其中的流程改革、基于DSO 模式的软件工厂等都与敏捷技术的运用有着紧密的联系，这一战略的落地将对美军装备信息化能力的提升发挥巨大的促进作用。

军用软件能力成熟度模型（GJB5000）是软件工程化理论在军用软件研制领域的最佳实践，也是目前国内各军工集团事实上遵循的军用软件研发标准。继2003年总装备部发布了GJB5000-2003、2008年进行修订并发布GJB5000A之后，2021年发布了最新的GJB5000B[1]。但实施过程中往往存在管理效率降低、管理成本居高不下等问题，如何在研制周期短、需求变化多的情况下保证进度和质量，是军用软件研发所面临的重要挑战[2]。

自20世纪90年代开始，各种敏捷方法相继问世以来，由于其在应对需求的快速变化、缩短研发周期等方面的显著效果在商业软件领域取得了极大的成功，2018年发布的CMMI2.0 版相关实践域中增加了敏捷的要求[3]，2021年发布的GJB5000B 也提出了对敏捷的支持。

本文通过对GJB5000B、敏捷方法的核心要素、融合意义、融合方法开展研究，提出基于Scrum 方法的需求开发与管理、项目策划、项目监控等基于GJB5000B 二级的敏捷实践。将GJB5000B 的严谨与敏捷的灵活有效融合，使其更容易融入实际项目研发过程、为研发人员所接受，同时带来管理效能和产品质量的提升。

1 敏捷研发模式

1.1 基于Scrum的软件研制流程

在软件工程领域，经典的瀑布型开发流程在一定时期、一定范围内成功的解决了大量软件项目的开发质量问题，有效应对了“软件危机”，但随着软件开发所面临的需求变化越来越快、高度竞争环境下的交付周期越来越短，“瀑布模型”的“僵化和机械”在很多领域和项目中也遭遇到了大量的挑战，包括交付周期长、返工风险高、实施工作量大等典型问题。在此背景之下，敏捷软件开发（Agile software development）作为软件工程领域的重要创新应运而生，并于2001年美国的雪鸟城会议上被正式提出，敏捷十二原则作为核心理念被发布出来用以指导敏捷实践。

敏捷十二原则：

（1）客户为先：通过持续不断的及早交付有价值的软件使客户满意；

（2）拥抱变化：欣然面对需求变化，为了客户的竞争优势，敏结过程掌控变化；

（3）短迭代交付：经常交付可工作的软件，相隔几个星期或一两个月，倾向于采取较短的周期；

（4）业务参与：业务人员和开发人员相互合作、持续开展；

（5）以人为本：激发个体斗志，以人为核心实施项目；

（6）面对面沟通：不论团队内外，传递信息效果最好、效率最高的方式是面对面的交谈；

（7）成果导向：可工作的软件是进度的首要度量标准；

（8）保持节奏：敏结过程倡导可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定延续；

（9）追求卓越：坚持不懈地追求技术卓越和良好设计；

（10）简单务实：以简洁为本，它是极力减少不必要工作量的艺术；

（11）团队自组织：最好的架构、需求和设计出自自组织团队；

（12）持续改进：团队定期地反思如何能提高成效，并依次调整自身的举止表现。

敏捷软件开发有不同的模式和方法[4]，包括极限编程XP(Extreme Programming)、Scrum[5]、动态系统开发方法DSDM（Dynamic System Development Method）、特性驱动开发（Feature-driven development）、测试驱动开发（Test-drive development）等，其中Scrum（迭代式增量软件研发过程）是使用最为广泛的敏捷方法，在敏捷开发项目中被采用的占比超过75%。Scrum 实施框架如图2所示。

图2：Scrum 实施框架

Scrum 适用于需求难以预测的复杂产品的开发，它定义了一个可以帮助研发团队向客户快速、持续交付的活动，专注于如何在最短的时间内是西安最有价值的部分。

Scrum 包括3 个角色、3 个工件、5 个活动。

3 个角色包含：

（1）Scrum Master（项目负责人、项目经理），他会负责指导团队在通用的 Scrum 框架上遵循正确的敏捷过程，保护团队不受外界干扰，是团队的领导和推进者，负责提升Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

（2）Team（开发人员、测试人员、美工设计、DBA 等全职能性团队），团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

（3）Product Owner（产品负责人、产品经理、运营人员），从业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目，在 Sprint 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息。

3 个工件包括：

（1）PRODUCT BACKLOG（产品待办事项列表），他是一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

（2）SPRINT BACKLOG（SPRINT 代办事项列表），是一组为当前 Sprint 选出的产品代办事项列表条目，外加交付产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包含在下个增量中，以及交付那些功能所需工作的预计。

（3）PRODUCT INCREMENT（产品增量），他是一个Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

5 个活动包括：

（1）Sprint 计划会议（Sprint Planning Meeting）

（2）每日站会（Daily Scrum Meeting）

（3）Sprint 评审会议（Sprint Review Meeting）

（4）Sprint 回顾会议（Sprint Retrospective Meeting）

（5）产品Backlog 梳理会议（Product Backlog Refinement）

Scrum 实施过程如表1所示。

表1：Scrum 实施过程

1.2 敏捷的核心要素

无论是Scrum 还是其他敏捷方法都遵从敏捷软件开发宣言中定义的价值观：

（1）个体与交互高于过程与工具；

（2）可用的软件高于复杂的文档；

（3）客户协作高于客户谈判；

（4）响应变化胜于遵循计划。

通过这些价值观，可以加深我们对敏捷本质的理解：

敏捷是以高技能团队为基础的简化，是使必要工作最小化的艺术。

首先，敏捷的前提是高水平的人，只有精通技术、熟悉流程、了解业务的高水平研发人员才能驾驭功能重要性评估、结对编程等敏捷活动；其次，所实施的活动是最小化的，由于人的高能力和用户的深度参与，研发团队更专注于软件产品本身，对过程记录等文档的关注度相对较弱。

2 军用软件能力成熟度模型（GJB5000B）

2.1 GJB5000B二级的实践域构成

GJB5000B 二级共有十一个实践域，从组织管理、项目管理、工程活动、支持活动四个方面对软件研制过程中需开展的活动进行了规范，如表2所示。

表2：GJB5000B 二级实践域分类

其中，RDM 需求开发与管理、验证与确认是二级工程活动中的核心实践域，PP 项目策划和PMC 项目监控是二级管理活动中的核心实践域。

2.2 GJB5000B的核心要素

由于军用软件对高可靠性、高安全性等质量特性的特殊要求，GJB5000 标准对研发过程进行了严格的定义，总体上呈现以下几个核心特点：

过程化：GJB5000 与CMMI 一脉相承，其核心理念是好的产品需要好的过程来支撑；

准则化：作为重量级的软件研发框架，去除模糊、操作级别形成明确的准则是GJB5000 所追求的重要目标；

证据化：军用软件大多属于对可靠性、安全性要求较高的关键软件系统，因此，GJB5000 对研发过程中的各种工作产品有着严格、甚至是苛刻的要求，凡事讲证据、强调可追溯；

计划性：无论是工程类、管理类还是支持类，各类活动都要有明确的计划，以确保团队目标明确、步调一致；

可监控：基于计划，贯穿项目全生命周期的监控协调是确保项目顺利完成的关键活动；

可度量：有据可循、数据支撑是上述一切活动实施的基础，因此，进度、质量、成本等关键指标的量化与数据积累是对项目研发过程影响巨大的重要支撑。

3 GJB5000B与敏捷融合的在科研院所适应性

基于上述内容我们不难看出，GJB5000B 通过全覆盖、强管理、证据化、标准化来确保软件产品的质量可控，但带来了管理效率低、管理成本高等问题，尤其在一些规模小、变化多的项目中尤为突出；而敏捷方法则通过以人为核心、必要活动最小化的方式带来了效率的提升和成本的降低，带来了更灵活、快速的变化响应能力；两者各具特色，但在理念和方式方法上又有所区别，如能有效融合将对军用软件的研发能力提升产生非常积极的促进作用。

从理论基础方面看，不论是CMMI 还是GJB5000B 都已经从框架上提出了对敏捷方法的支持，这为两者的融合提供了坚实的理论基础；从实际需求来看，军用软件虽然总体规模巨大，但在实际研发过程中，中小规模的软件项目占比很高，而且研制周期短、需求变化多的特点也很突出，这些都适合敏捷方法发挥作用，因此敏捷和GJB5000B 的融合在军工科研院所的实际软件研发过程中具有较强的适应性。

4 GJB5000与敏捷融合的方法与实践

4.1 融合的方法

（1）顶层融合：GJB5000B 作为实施框架、敏捷作为实践方法，分层融入；

（2）标准融合：GJB5000B 的过程标准、产品标准与敏捷方法的融合（高质量的裁剪标准）；

（3）自动化：通过自动化手段将敏捷过程中的记录自动转换成GJB5000B 要求的工作产品，最大程度减少研发人员的重复劳动。

4.2 融合的实践

4.2.1 需求开发与管理（RDM）

（1）RDM 2.1 获取和开发顾客需求

敏捷实践：需求分析人员与顾客代表充分交流，明确用户需求，设定初步的优先级，并记录到Product Backlog（产品待办列表）中。

（2）RDM 2.2 获得对需求的理解和承诺

敏捷实践：顾客代表需要对需求的定义、优先级进行确认；项目团队对已批准的需求进行承诺，并最终反映到Product Backlog（产品待办列表）中。

（3）RDM 2.3 开发运行方案和场景

敏捷实践：开发人员与顾客代表讨论运行方案及场景，并反映到用户故事中，明确业务目标（WHY）、用户角色（WHO）和如何做（HOW/WHAT），借此帮助用户及利益相关方理解、确认并认可需求。

（4）RDM 2.4 开发产品和产品部件需求

敏捷实践：开发人员基于与顾客代表的交流结果，分析产品的功能需求、性能需求、接口需求及约束要求等，形成产品和产品部件需求，并反映到PBI 中。

（5）RDM 2.5 分析并确认需求

敏捷实践：开发人员与顾客代表通过评审、分析、验证等手段分析、确认需求的必要性与充分性。

（6）RDM 2.6 建立并维护需求双向可追溯性

敏捷实践：通过自动化工具或特定格式文档的形式对需求的可追溯性进行管理。

（7）RDM 2.7 管理需求变更

敏捷实践：开发人员与顾客代表一起评估变更的必要性与可行性，并将结果反映在Product Backlog（产品待办列表）中。

4.2.2 项目策划（PP）

（1）PP 2.1 估计项目参数

敏捷实践：采用故事点等敏捷方法估算规模和工作量，GJB5000B 中已经明确提出了对敏捷的支持。

（2）PP 2.2 定义项目生存周期

敏捷实践：在发布计划时定义每次迭代所使用的生命周期模型、所覆盖的开发、测试等具体活动。

（3）PP 2.3 制定项目进度计划、

敏捷实践：制定顶层的发布计划以明确迭代周期、发布周期；制定迭代计划以明确每次迭代要完成的工作任务、期限；制定任务计划以明确分工及完成期限；

（4）PP 2.4 制定项目资源计划

敏捷实践：敏捷方法对本实践的要求较弱，距离GJB5000B的要求仍有差距，因此，参照GJB5000B 的要求制定专项资源计划。

（5）PP 2.5 制定利益相关方参与计划

敏捷实践：顾客代表的活动较为明确，需参与发布计划、迭代计划的讨论与确认，需对迭代结果和最终交付产品进行确认，但其他利益相关方的要求与GJB5000B 仍有差距，因此，需参照GJB5000B 的要求制定完整的利益相关方计划。

（6）PP 2.6 制定及维护项目计划

敏捷实践：敏捷计划包含了发布计划、迭代计划和任务计划，变更需顾客代表的确认，但策划的内容和完成标准上距离GJB5000B 仍有差距，需依据GJB5000B 要求进行完善。

4.2.3 项目监控（PMC）

（1）PMC 2.1 跟踪项目策划参数的执行情况

敏捷实践：通过每日站会和迭代评审跟踪策划参数的执行情况。

（2）PMC 2.2 跟踪项目资源计划的执行情况

敏捷实践：通过每日站会和迭代评审跟踪项目资源计划的执行情况，跟踪频率结合项目实际情况进行调整，实施标准参照GJB5000B 执行。

（3）PMC 2.3 协调与跟踪利益相关方参与项目及履行承诺的情况

敏捷实践：通过每日站会和迭代评审跟踪利益相关方计划的执行情况，跟踪频率结合项目实际情况进行调整，实施标准参照GJB5000B 执行。

（4）PMC 2.4 项目进展与计划显著偏离时，采取纠正措施

敏捷实践：通过每日站会和迭代评审跟踪实际进展与计划的偏离，当发生时偏离时，及时采取纠正措施。

4.2.4 验证与确认（VV）

（1）VV 2.1 选择要验证与确认的产品及方法

敏捷实践：在sprint 计划中明确验证与确认的对象和范围，实施方法方面可以通过结对编程的方式对代码进行评审和自动化测试。

（2）VV 2.2 建立并维护验证与确认的规程和准则

敏捷实践：按照GJB5000B 要求编写测试计划和测试说明，但引入敏捷开发模式中的测试驱动开发，在编写代码前先写测试；软件在交付或发布前需要先通过验收测试。

（3）VV 2.3 建立并维护验证与确认的环境

敏捷实践：参照GJB5000B 标准执行，根据测试需要，搭建测试环境。

（4）VV 2.4 执行验证与确认并记录、沟通和处理结果

敏捷实践：实施测试驱动开发，每日构建前进行自动化测试，软件交付或发布前进行验收测试，在测试用例代码的注释中参照GJB5000B 要求编写测试说明，并通过自动化工具提取测试说明，自动生成测试报告。

4.2.5 运行维护（MT）

（1）MT 2.1 策划运行维护活动

敏捷实践：敏捷开发没有这方面的实践，按照GJB5000B要求进行，明确运行维护的对象方位、周期和需求。

（2）MT 2.2 提供技术支持与服务

敏捷实践：

敏捷开发采取的是持续交付模式，在每次交付过程中持续对客户进行培训，通过自主监控和客户沟通及时发现软件问题并高效解决。

（3）MT2.3 开展产品升级与维护

敏捷实践：

通过自主监控与客户沟通及时获取软件升级维护需求；开发、测试活动使用敏捷开发中的结对编程、测试驱动等方法，但配管、变更控制等依据GJB5000B 要求进行。

5 总结

通过上述的理论研究与实践可以发现敏捷与GJB5000B可以融合，而且融合得当对项目管理效率、产品质量会带来明显的改进，但融合的方针至关重要，所谓的融合不是对现有军用软件研制过程的替代，而是补充和优化，军用软件研制的特点注定了GJB5000B 能力成熟度模型的必须性，敏捷方法应该作为方法级别的实践融入到GJB5000B 中，否则将导致软件产品质量失控的风险，这对安全性、可靠性要求极高的军用软件而言将是致命的。

总体而言，融合得当，将带来的以下的效果，值得各单位在军用软件研制过程中持续实践：

（1）丰富实施方法：故事点、每日站会等敏捷特色方法的引入；

（2）提升活动效率：敏捷方法的高效性会提升各种活动的实施效率；

（3）降低实施风险：迭代开发、高频沟通等敏捷特性大大降低了大量问题集中爆发的风险；

（4）缩短交付周期：增量式开发、用户的及时介入会有效减少非必要的返工，进而缩短周期；

（5）降低实施成本：返工的减少，会有效减少人员及设备等的投入成本。