GJB5000B二級與敏捷實(shí)踐的融合技術(shù)

林陽濤

（中國航空研究院研究生院 江蘇省揚(yáng)州市 225000）

軟件定義一切（Software Define Anything）概念的提出了已經(jīng)有了近10年的時間，經(jīng)過多年的理論創(chuàng)新與實(shí)踐運(yùn)用，在各行各業(yè)都產(chǎn)生了深遠(yuǎn)的影響，在軍工領(lǐng)域，由于軟件在現(xiàn)代化武器裝備中的規(guī)模占比急劇提升，“軟件定義裝備”已成為世界軍事強(qiáng)國公認(rèn)的新的裝備發(fā)展模式。如圖1所示。

圖1：航空電子軟件中軟件源代碼行（SLOC）的增長情況

美國防部于2019年發(fā)布了“以相應(yīng)的速度提供彈性軟件能力”為愿景的《國防部軟件現(xiàn)代化戰(zhàn)略》，其中的流程改革、基于DSO 模式的軟件工廠等都與敏捷技術(shù)的運(yùn)用有著緊密的聯(lián)系，這一戰(zhàn)略的落地將對美軍裝備信息化能力的提升發(fā)揮巨大的促進(jìn)作用。

軍用軟件能力成熟度模型（GJB5000）是軟件工程化理論在軍用軟件研制領(lǐng)域的最佳實(shí)踐，也是目前國內(nèi)各軍工集團(tuán)事實(shí)上遵循的軍用軟件研發(fā)標(biāo)準(zhǔn)。繼2003年總裝備部發(fā)布了GJB5000-2003、2008年進(jìn)行修訂并發(fā)布GJB5000A之后，2021年發(fā)布了最新的GJB5000B[1]。但實(shí)施過程中往往存在管理效率降低、管理成本居高不下等問題，如何在研制周期短、需求變化多的情況下保證進(jìn)度和質(zhì)量，是軍用軟件研發(fā)所面臨的重要挑戰(zhàn)[2]。

自20世紀(jì)90年代開始，各種敏捷方法相繼問世以來，由于其在應(yīng)對需求的快速變化、縮短研發(fā)周期等方面的顯著效果在商業(yè)軟件領(lǐng)域取得了極大的成功，2018年發(fā)布的CMMI2.0 版相關(guān)實(shí)踐域中增加了敏捷的要求[3]，2021年發(fā)布的GJB5000B 也提出了對敏捷的支持。

本文通過對GJB5000B、敏捷方法的核心要素、融合意義、融合方法開展研究，提出基于Scrum 方法的需求開發(fā)與管理、項(xiàng)目策劃、項(xiàng)目監(jiān)控等基于GJB5000B 二級的敏捷實(shí)踐。將GJB5000B 的嚴(yán)謹(jǐn)與敏捷的靈活有效融合，使其更容易融入實(shí)際項(xiàng)目研發(fā)過程、為研發(fā)人員所接受，同時帶來管理效能和產(chǎn)品質(zhì)量的提升。

1 敏捷研發(fā)模式

1.1 基于Scrum的軟件研制流程

在軟件工程領(lǐng)域，經(jīng)典的瀑布型開發(fā)流程在一定時期、一定范圍內(nèi)成功的解決了大量軟件項(xiàng)目的開發(fā)質(zhì)量問題，有效應(yīng)對了“軟件危機(jī)”，但隨著軟件開發(fā)所面臨的需求變化越來越快、高度競爭環(huán)境下的交付周期越來越短，“瀑布模型”的“僵化和機(jī)械”在很多領(lǐng)域和項(xiàng)目中也遭遇到了大量的挑戰(zhàn)，包括交付周期長、返工風(fēng)險高、實(shí)施工作量大等典型問題。在此背景之下，敏捷軟件開發(fā)（Agile software development）作為軟件工程領(lǐng)域的重要創(chuàng)新應(yīng)運(yùn)而生，并于2001年美國的雪鳥城會議上被正式提出，敏捷十二原則作為核心理念被發(fā)布出來用以指導(dǎo)敏捷實(shí)踐。

敏捷十二原則：

（1）客戶為先：通過持續(xù)不斷的及早交付有價值的軟件使客戶滿意；

（2）擁抱變化：欣然面對需求變化，為了客戶的競爭優(yōu)勢，敏結(jié)過程掌控變化；

（3）短迭代交付：經(jīng)常交付可工作的軟件，相隔幾個星期或一兩個月，傾向于采取較短的周期；

（4）業(yè)務(wù)參與：業(yè)務(wù)人員和開發(fā)人員相互合作、持續(xù)開展；

（5）以人為本：激發(fā)個體斗志，以人為核心實(shí)施項(xiàng)目；

（6）面對面溝通：不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好、效率最高的方式是面對面的交談；

（7）成果導(dǎo)向：可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)；

（8）保持節(jié)奏：敏結(jié)過程倡導(dǎo)可持續(xù)開發(fā)，責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)；

（9）追求卓越：堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)；

（10）簡單務(wù)實(shí)：以簡潔為本，它是極力減少不必要工作量的藝術(shù)；

（11）團(tuán)隊(duì)自組織：最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)；

（12）持續(xù)改進(jìn)：團(tuán)隊(duì)定期地反思如何能提高成效，并依次調(diào)整自身的舉止表現(xiàn)。

敏捷軟件開發(fā)有不同的模式和方法[4]，包括極限編程XP(Extreme Programming)、Scrum[5]、動態(tài)系統(tǒng)開發(fā)方法DSDM（Dynamic System Development Method）、特性驅(qū)動開發(fā)（Feature-driven development）、測試驅(qū)動開發(fā)（Test-drive development）等，其中Scrum（迭代式增量軟件研發(fā)過程）是使用最為廣泛的敏捷方法，在敏捷開發(fā)項(xiàng)目中被采用的占比超過75%。Scrum 實(shí)施框架如圖2所示。

圖2：Scrum 實(shí)施框架

Scrum 適用于需求難以預(yù)測的復(fù)雜產(chǎn)品的開發(fā)，它定義了一個可以幫助研發(fā)團(tuán)隊(duì)向客戶快速、持續(xù)交付的活動，專注于如何在最短的時間內(nèi)是西安最有價值的部分。

Scrum 包括3 個角色、3 個工件、5 個活動。

3 個角色包含：

（1）Scrum Master（項(xiàng)目負(fù)責(zé)人、項(xiàng)目經(jīng)理），他會負(fù)責(zé)指導(dǎo)團(tuán)隊(duì)在通用的 Scrum 框架上遵循正確的敏捷過程，保護(hù)團(tuán)隊(duì)不受外界干擾，是團(tuán)隊(duì)的領(lǐng)導(dǎo)和推進(jìn)者，負(fù)責(zé)提升Scrum 團(tuán)隊(duì)的工作效率，控制 Scrum 中的“檢視和適應(yīng)”周期過程。與 Product Owner 一起將投資產(chǎn)出最大化，他確保所有的利益相關(guān)者都可以理解敏捷和尊重敏捷的理念。

（2）Team（開發(fā)人員、測試人員、美工設(shè)計(jì)、DBA 等全職能性團(tuán)隊(duì)），團(tuán)隊(duì)負(fù)責(zé)交付產(chǎn)品并對其質(zhì)量負(fù)責(zé)，團(tuán)隊(duì)與所有提出產(chǎn)品需求的人一起工作，包括客戶和最終用戶，并共同創(chuàng)建 Product Backlog 。團(tuán)隊(duì)按照大家的共識來創(chuàng)建功能設(shè)計(jì)、測試 Backlog 條目交付產(chǎn)品。

（3）Product Owner（產(chǎn)品負(fù)責(zé)人、產(chǎn)品經(jīng)理、運(yùn)營人員），從業(yè)務(wù)角度驅(qū)動項(xiàng)目，傳播產(chǎn)品的明確愿景，并定義其主要特性。Product Owner 的主要職責(zé)是確保團(tuán)隊(duì)只開發(fā)對于組織最重要的 Backlog 條目，在 Sprint 中幫助團(tuán)隊(duì)完成自己的工作，不干擾團(tuán)隊(duì)成員，并迅速提供團(tuán)隊(duì)需要的所有信息。

3 個工件包括：

（1）PRODUCT BACKLOG（產(chǎn)品待辦事項(xiàng)列表），他是一個排序的列表，包含所有產(chǎn)品需要的東西，也是產(chǎn)品需求變動的唯一來源。產(chǎn)品負(fù)責(zé)人負(fù)責(zé)產(chǎn)品待辦事項(xiàng)列表的內(nèi)容、可用性和優(yōu)先級。

（2）SPRINT BACKLOG（SPRINT 代辦事項(xiàng)列表），是一組為當(dāng)前 Sprint 選出的產(chǎn)品代辦事項(xiàng)列表?xiàng)l目，外加交付產(chǎn)品增量和實(shí)現(xiàn) Sprint 目標(biāo)的計(jì)劃。Sprint 代辦事項(xiàng)列表是開發(fā)團(tuán)隊(duì)對于哪些功能要包含在下個增量中，以及交付那些功能所需工作的預(yù)計(jì)。

（3）PRODUCT INCREMENT（產(chǎn)品增量），他是一個Sprint 完成的所有產(chǎn)品待辦列表項(xiàng)的總和，以及之前所有 Sprint 所產(chǎn)生的增量的價值總和。在 Sprint 的最后，新的增量必須是“完成”的，這意味著它必須可用并且達(dá)到了Scrum 團(tuán)隊(duì)“完成”的定義的標(biāo)準(zhǔn)。增量是在 Sprint 結(jié)束時支持經(jīng)驗(yàn)主義的可檢視的和已完成的產(chǎn)品組成部分。增量是邁向愿景或目標(biāo)的一步。無論產(chǎn)品負(fù)責(zé)人是否決定發(fā)布它，增量必須可用。

5 個活動包括：

（1）Sprint 計(jì)劃會議（Sprint Planning Meeting）

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

（3）Sprint 評審會議（Sprint Review Meeting）

（4）Sprint 回顧會議（Sprint Retrospective Meeting）

（5）產(chǎn)品Backlog 梳理會議（Product Backlog Refinement）

Scrum 實(shí)施過程如表1所示。

表1：Scrum 實(shí)施過程

1.2 敏捷的核心要素

無論是Scrum 還是其他敏捷方法都遵從敏捷軟件開發(fā)宣言中定義的價值觀：

（1）個體與交互高于過程與工具；

（2）可用的軟件高于復(fù)雜的文檔；

（3）客戶協(xié)作高于客戶談判；

（4）響應(yīng)變化勝于遵循計(jì)劃。

通過這些價值觀，可以加深我們對敏捷本質(zhì)的理解：

敏捷是以高技能團(tuán)隊(duì)為基礎(chǔ)的簡化，是使必要工作最小化的藝術(shù)。

首先，敏捷的前提是高水平的人，只有精通技術(shù)、熟悉流程、了解業(yè)務(wù)的高水平研發(fā)人員才能駕馭功能重要性評估、結(jié)對編程等敏捷活動；其次，所實(shí)施的活動是最小化的，由于人的高能力和用戶的深度參與，研發(fā)團(tuán)隊(duì)更專注于軟件產(chǎn)品本身，對過程記錄等文檔的關(guān)注度相對較弱。

2 軍用軟件能力成熟度模型（GJB5000B）

2.1 GJB5000B二級的實(shí)踐域構(gòu)成

GJB5000B 二級共有十一個實(shí)踐域，從組織管理、項(xiàng)目管理、工程活動、支持活動四個方面對軟件研制過程中需開展的活動進(jìn)行了規(guī)范，如表2所示。

表2：GJB5000B 二級實(shí)踐域分類

其中，RDM 需求開發(fā)與管理、驗(yàn)證與確認(rèn)是二級工程活動中的核心實(shí)踐域，PP 項(xiàng)目策劃和PMC 項(xiàng)目監(jiān)控是二級管理活動中的核心實(shí)踐域。

2.2 GJB5000B的核心要素

由于軍用軟件對高可靠性、高安全性等質(zhì)量特性的特殊要求，GJB5000 標(biāo)準(zhǔn)對研發(fā)過程進(jìn)行了嚴(yán)格的定義，總體上呈現(xiàn)以下幾個核心特點(diǎn)：

過程化：GJB5000 與CMMI 一脈相承，其核心理念是好的產(chǎn)品需要好的過程來支撐；

準(zhǔn)則化：作為重量級的軟件研發(fā)框架，去除模糊、操作級別形成明確的準(zhǔn)則是GJB5000 所追求的重要目標(biāo)；

證據(jù)化：軍用軟件大多屬于對可靠性、安全性要求較高的關(guān)鍵軟件系統(tǒng)，因此，GJB5000 對研發(fā)過程中的各種工作產(chǎn)品有著嚴(yán)格、甚至是苛刻的要求，凡事講證據(jù)、強(qiáng)調(diào)可追溯；

計(jì)劃性：無論是工程類、管理類還是支持類，各類活動都要有明確的計(jì)劃，以確保團(tuán)隊(duì)目標(biāo)明確、步調(diào)一致；

可監(jiān)控：基于計(jì)劃，貫穿項(xiàng)目全生命周期的監(jiān)控協(xié)調(diào)是確保項(xiàng)目順利完成的關(guān)鍵活動；

可度量：有據(jù)可循、數(shù)據(jù)支撐是上述一切活動實(shí)施的基礎(chǔ)，因此，進(jìn)度、質(zhì)量、成本等關(guān)鍵指標(biāo)的量化與數(shù)據(jù)積累是對項(xiàng)目研發(fā)過程影響巨大的重要支撐。

3 GJB5000B與敏捷融合的在科研院所適應(yīng)性

基于上述內(nèi)容我們不難看出，GJB5000B 通過全覆蓋、強(qiáng)管理、證據(jù)化、標(biāo)準(zhǔn)化來確保軟件產(chǎn)品的質(zhì)量可控，但帶來了管理效率低、管理成本高等問題，尤其在一些規(guī)模小、變化多的項(xiàng)目中尤為突出；而敏捷方法則通過以人為核心、必要活動最小化的方式帶來了效率的提升和成本的降低，帶來了更靈活、快速的變化響應(yīng)能力；兩者各具特色，但在理念和方式方法上又有所區(qū)別，如能有效融合將對軍用軟件的研發(fā)能力提升產(chǎn)生非常積極的促進(jìn)作用。

從理論基礎(chǔ)方面看，不論是CMMI 還是GJB5000B 都已經(jīng)從框架上提出了對敏捷方法的支持，這為兩者的融合提供了堅(jiān)實(shí)的理論基礎(chǔ)；從實(shí)際需求來看，軍用軟件雖然總體規(guī)模巨大，但在實(shí)際研發(fā)過程中，中小規(guī)模的軟件項(xiàng)目占比很高，而且研制周期短、需求變化多的特點(diǎn)也很突出，這些都適合敏捷方法發(fā)揮作用，因此敏捷和GJB5000B 的融合在軍工科研院所的實(shí)際軟件研發(fā)過程中具有較強(qiáng)的適應(yīng)性。

4 GJB5000與敏捷融合的方法與實(shí)踐

4.1 融合的方法

（1）頂層融合：GJB5000B 作為實(shí)施框架、敏捷作為實(shí)踐方法，分層融入；

（2）標(biāo)準(zhǔn)融合：GJB5000B 的過程標(biāo)準(zhǔn)、產(chǎn)品標(biāo)準(zhǔn)與敏捷方法的融合（高質(zhì)量的裁剪標(biāo)準(zhǔn)）；

（3）自動化：通過自動化手段將敏捷過程中的記錄自動轉(zhuǎn)換成GJB5000B 要求的工作產(chǎn)品，最大程度減少研發(fā)人員的重復(fù)勞動。

4.2 融合的實(shí)踐

4.2.1 需求開發(fā)與管理（RDM）

（1）RDM 2.1 獲取和開發(fā)顧客需求

敏捷實(shí)踐：需求分析人員與顧客代表充分交流，明確用戶需求，設(shè)定初步的優(yōu)先級，并記錄到Product Backlog（產(chǎn)品待辦列表）中。

（2）RDM 2.2 獲得對需求的理解和承諾

敏捷實(shí)踐：顧客代表需要對需求的定義、優(yōu)先級進(jìn)行確認(rèn)；項(xiàng)目團(tuán)隊(duì)對已批準(zhǔn)的需求進(jìn)行承諾，并最終反映到Product Backlog（產(chǎn)品待辦列表）中。

（3）RDM 2.3 開發(fā)運(yùn)行方案和場景

敏捷實(shí)踐：開發(fā)人員與顧客代表討論運(yùn)行方案及場景，并反映到用戶故事中，明確業(yè)務(wù)目標(biāo)（WHY）、用戶角色（WHO）和如何做（HOW/WHAT），借此幫助用戶及利益相關(guān)方理解、確認(rèn)并認(rèn)可需求。

（4）RDM 2.4 開發(fā)產(chǎn)品和產(chǎn)品部件需求

敏捷實(shí)踐：開發(fā)人員基于與顧客代表的交流結(jié)果，分析產(chǎn)品的功能需求、性能需求、接口需求及約束要求等，形成產(chǎn)品和產(chǎn)品部件需求，并反映到PBI 中。

（5）RDM 2.5 分析并確認(rèn)需求

敏捷實(shí)踐：開發(fā)人員與顧客代表通過評審、分析、驗(yàn)證等手段分析、確認(rèn)需求的必要性與充分性。

（6）RDM 2.6 建立并維護(hù)需求雙向可追溯性

敏捷實(shí)踐：通過自動化工具或特定格式文檔的形式對需求的可追溯性進(jìn)行管理。

（7）RDM 2.7 管理需求變更

敏捷實(shí)踐：開發(fā)人員與顧客代表一起評估變更的必要性與可行性，并將結(jié)果反映在Product Backlog（產(chǎn)品待辦列表）中。

4.2.2 項(xiàng)目策劃（PP）

（1）PP 2.1 估計(jì)項(xiàng)目參數(shù)

敏捷實(shí)踐：采用故事點(diǎn)等敏捷方法估算規(guī)模和工作量，GJB5000B 中已經(jīng)明確提出了對敏捷的支持。

（2）PP 2.2 定義項(xiàng)目生存周期

敏捷實(shí)踐：在發(fā)布計(jì)劃時定義每次迭代所使用的生命周期模型、所覆蓋的開發(fā)、測試等具體活動。

（3）PP 2.3 制定項(xiàng)目進(jìn)度計(jì)劃、

敏捷實(shí)踐：制定頂層的發(fā)布計(jì)劃以明確迭代周期、發(fā)布周期；制定迭代計(jì)劃以明確每次迭代要完成的工作任務(wù)、期限；制定任務(wù)計(jì)劃以明確分工及完成期限；

（4）PP 2.4 制定項(xiàng)目資源計(jì)劃

敏捷實(shí)踐：敏捷方法對本實(shí)踐的要求較弱，距離GJB5000B的要求仍有差距，因此，參照GJB5000B 的要求制定專項(xiàng)資源計(jì)劃。

（5）PP 2.5 制定利益相關(guān)方參與計(jì)劃

敏捷實(shí)踐：顧客代表的活動較為明確，需參與發(fā)布計(jì)劃、迭代計(jì)劃的討論與確認(rèn)，需對迭代結(jié)果和最終交付產(chǎn)品進(jìn)行確認(rèn)，但其他利益相關(guān)方的要求與GJB5000B 仍有差距，因此，需參照GJB5000B 的要求制定完整的利益相關(guān)方計(jì)劃。

（6）PP 2.6 制定及維護(hù)項(xiàng)目計(jì)劃

敏捷實(shí)踐：敏捷計(jì)劃包含了發(fā)布計(jì)劃、迭代計(jì)劃和任務(wù)計(jì)劃，變更需顧客代表的確認(rèn)，但策劃的內(nèi)容和完成標(biāo)準(zhǔn)上距離GJB5000B 仍有差距，需依據(jù)GJB5000B 要求進(jìn)行完善。

4.2.3 項(xiàng)目監(jiān)控（PMC）

（1）PMC 2.1 跟蹤項(xiàng)目策劃參數(shù)的執(zhí)行情況

敏捷實(shí)踐：通過每日站會和迭代評審跟蹤策劃參數(shù)的執(zhí)行情況。

（2）PMC 2.2 跟蹤項(xiàng)目資源計(jì)劃的執(zhí)行情況

敏捷實(shí)踐：通過每日站會和迭代評審跟蹤項(xiàng)目資源計(jì)劃的執(zhí)行情況，跟蹤頻率結(jié)合項(xiàng)目實(shí)際情況進(jìn)行調(diào)整，實(shí)施標(biāo)準(zhǔn)參照GJB5000B 執(zhí)行。

（3）PMC 2.3 協(xié)調(diào)與跟蹤利益相關(guān)方參與項(xiàng)目及履行承諾的情況

敏捷實(shí)踐：通過每日站會和迭代評審跟蹤利益相關(guān)方計(jì)劃的執(zhí)行情況，跟蹤頻率結(jié)合項(xiàng)目實(shí)際情況進(jìn)行調(diào)整，實(shí)施標(biāo)準(zhǔn)參照GJB5000B 執(zhí)行。

（4）PMC 2.4 項(xiàng)目進(jìn)展與計(jì)劃顯著偏離時，采取糾正措施

敏捷實(shí)踐：通過每日站會和迭代評審跟蹤實(shí)際進(jìn)展與計(jì)劃的偏離，當(dāng)發(fā)生時偏離時，及時采取糾正措施。

4.2.4 驗(yàn)證與確認(rèn)（VV）

（1）VV 2.1 選擇要驗(yàn)證與確認(rèn)的產(chǎn)品及方法

敏捷實(shí)踐：在sprint 計(jì)劃中明確驗(yàn)證與確認(rèn)的對象和范圍，實(shí)施方法方面可以通過結(jié)對編程的方式對代碼進(jìn)行評審和自動化測試。

（2）VV 2.2 建立并維護(hù)驗(yàn)證與確認(rèn)的規(guī)程和準(zhǔn)則

敏捷實(shí)踐：按照GJB5000B 要求編寫測試計(jì)劃和測試說明，但引入敏捷開發(fā)模式中的測試驅(qū)動開發(fā)，在編寫代碼前先寫測試；軟件在交付或發(fā)布前需要先通過驗(yàn)收測試。

（3）VV 2.3 建立并維護(hù)驗(yàn)證與確認(rèn)的環(huán)境

敏捷實(shí)踐：參照GJB5000B 標(biāo)準(zhǔn)執(zhí)行，根據(jù)測試需要，搭建測試環(huán)境。

（4）VV 2.4 執(zhí)行驗(yàn)證與確認(rèn)并記錄、溝通和處理結(jié)果

敏捷實(shí)踐：實(shí)施測試驅(qū)動開發(fā)，每日構(gòu)建前進(jìn)行自動化測試，軟件交付或發(fā)布前進(jìn)行驗(yàn)收測試，在測試用例代碼的注釋中參照GJB5000B 要求編寫測試說明，并通過自動化工具提取測試說明，自動生成測試報告。

4.2.5 運(yùn)行維護(hù)（MT）

（1）MT 2.1 策劃運(yùn)行維護(hù)活動

敏捷實(shí)踐：敏捷開發(fā)沒有這方面的實(shí)踐，按照GJB5000B要求進(jìn)行，明確運(yùn)行維護(hù)的對象方位、周期和需求。

（2）MT 2.2 提供技術(shù)支持與服務(wù)

敏捷實(shí)踐：

敏捷開發(fā)采取的是持續(xù)交付模式，在每次交付過程中持續(xù)對客戶進(jìn)行培訓(xùn)，通過自主監(jiān)控和客戶溝通及時發(fā)現(xiàn)軟件問題并高效解決。

（3）MT2.3 開展產(chǎn)品升級與維護(hù)

敏捷實(shí)踐：

通過自主監(jiān)控與客戶溝通及時獲取軟件升級維護(hù)需求；開發(fā)、測試活動使用敏捷開發(fā)中的結(jié)對編程、測試驅(qū)動等方法，但配管、變更控制等依據(jù)GJB5000B 要求進(jìn)行。

5 總結(jié)

通過上述的理論研究與實(shí)踐可以發(fā)現(xiàn)敏捷與GJB5000B可以融合，而且融合得當(dāng)對項(xiàng)目管理效率、產(chǎn)品質(zhì)量會帶來明顯的改進(jìn)，但融合的方針至關(guān)重要，所謂的融合不是對現(xiàn)有軍用軟件研制過程的替代，而是補(bǔ)充和優(yōu)化，軍用軟件研制的特點(diǎn)注定了GJB5000B 能力成熟度模型的必須性，敏捷方法應(yīng)該作為方法級別的實(shí)踐融入到GJB5000B 中，否則將導(dǎo)致軟件產(chǎn)品質(zhì)量失控的風(fēng)險，這對安全性、可靠性要求極高的軍用軟件而言將是致命的。

總體而言，融合得當(dāng)，將帶來的以下的效果，值得各單位在軍用軟件研制過程中持續(xù)實(shí)踐：

（1）豐富實(shí)施方法：故事點(diǎn)、每日站會等敏捷特色方法的引入；

（2）提升活動效率：敏捷方法的高效性會提升各種活動的實(shí)施效率；

（3）降低實(shí)施風(fēng)險：迭代開發(fā)、高頻溝通等敏捷特性大大降低了大量問題集中爆發(fā)的風(fēng)險；

（4）縮短交付周期：增量式開發(fā)、用戶的及時介入會有效減少非必要的返工，進(jìn)而縮短周期；

（5）降低實(shí)施成本：返工的減少，會有效減少人員及設(shè)備等的投入成本。