陳申平 顏樂鳴

摘 ?要： 為尋求既適用于軍用軟件研制特征又能滿足軍方用戶特殊要求的敏捷方法與GJB 5000A的結(jié)合應(yīng)用，本文基于Scrum敏捷方法，結(jié)合國內(nèi)軍工企業(yè)文化，建立了基于Scrum方法的軟件項目管理流程。同時，說明了基于敏捷方法的測量與分析、配置管理、過程和產(chǎn)品質(zhì)量保證過程域?qū)嵺`。

關(guān)鍵詞： GJB 5000A;敏捷;迭代;Scrum

中圖分類號： TP311.5 ? ?文獻標(biāo)識碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.08.030

本文著錄格式：陳申平，顏樂鳴. 敏捷方法在GJB 5000A二級中的應(yīng)用研究[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年，總裝備部發(fā)布了GJB5000-2003《軍用軟件研制能力成熟度模型》[1]，2008年進行修訂并發(fā)布了GJB 5000A[2]。GJB 5000A建立在CMMI-DEV 1.2版[3]的基礎(chǔ)上，與CMMI的相似度很高。目前，2008年發(fā)布的GJB 5000A已成為我國軍用軟件研制能力評價和軍用軟件研制單位進行軟件過程改進的主要依據(jù)。但是，各軟件研制單位實施GJB 5000A后普遍存在管理效率降低、管理成本居高不下等問題，難以持續(xù)有效實施和推廣。如何能在資源有限且制約較多的情況下保證質(zhì)量和進度，在控制并實現(xiàn)復(fù)雜多變的用戶需求的同時降低管理成本，是目前軍用嵌入式軟件實施GJB5000A過程中面臨的最大挑戰(zhàn)。

20世紀(jì)90年代開始，各種敏捷方法相繼問世并在軟件研制過程中迅速普及。隨著敏捷方法的日益普及，其與CMMI之間的關(guān)系也逐漸引起國際軟件業(yè)的重視，眾多研究人員相繼開展了CMM/CMMI與敏捷方法的結(jié)合研究，B. Boehm、R. Turner、M. Pikkarainen、A. Mar?al等的研究成果充分證明[4-7]：CMMI和敏捷方法是相互兼容，且完全可以結(jié)合。2010年11月發(fā)布的CMMI1.3版[8]增加了對敏捷方法的支持，這標(biāo)志著敏捷方法和CMMI的結(jié)合已成為必然。2018年發(fā)布的CMMI2.0版相關(guān)實踐域中增加敏捷的要求，實現(xiàn)敏捷方法和CMMI的結(jié)合。

本文通過開展敏捷方法和GJB 5000A二級結(jié)合的實施方法研究，提出基于Scrum方法的軟件項目管理流程及基于敏捷方法的測量與分析、配置管理、過程和產(chǎn)品質(zhì)量保證等GJB 5000A二級支持類過程域?qū)嵺`。從而精簡管理活動，縮短響應(yīng)時間，使過程更為有效、高效，以規(guī)范軟件研制和管理活動，減少軟件人對實施GJB 5000A的抵觸，從而解決實施過程中“兩張皮”的問題，有助于項目的質(zhì)量和進度目標(biāo)。

1 ?基于Scrum方法的軟件項目管理流程

主流的敏捷方法有極限編程、Scrum、模型驅(qū)動開發(fā)、DevOps等，其中Scrum是目前使用最廣泛且最有效的敏捷項目管理方法[9]。該方法將軟件研制過程分解為多個2到4周的短周期的迭代，一個迭代稱為一個sprint。該方法使用產(chǎn)品backlog來管理產(chǎn)品的需求，并對產(chǎn)品backlog中的需求按業(yè)務(wù)價值進行排序，通常先實現(xiàn)價值較高的需求。在每個sprint初期根據(jù)本次迭代要實現(xiàn)的需求建立sprint backlog。每個sprint結(jié)束時完成可交付的產(chǎn)品增量，并對迭代進行回顧[10]。Scrum方法的應(yīng)用情況表明，盡管該方法起源于軟件開發(fā)，但同樣適用于復(fù)雜產(chǎn)品及創(chuàng)新性產(chǎn)品的開發(fā)。也就是說，Scrum方法適用于任何規(guī)模、任何類型的項目。

圖1描述了基于Scrum方法的軟件項目管理流程，覆蓋GJB 5000A二級中的項目策劃和項目監(jiān)控兩個過程域。圖中實線框為項目管理實施方法中定義的活動，虛線框為項目組按階段計劃實施的活動。將每一個迭代作為一個階段，每次階段結(jié)束后需進行階段評審，階段評審中除常規(guī)的技術(shù)評審和管理評審?fù)?，還包含回顧，即分析本次迭代（本階段）的最佳實踐和存在問題，為后續(xù)的過程改進提供依據(jù)。

基于Scrum方法的軟件項目管理流程活動要求如下。

（1）早期策劃

軟件所屬項目的立項階段，軟件人員參與軟件所屬上層項目的策劃和系統(tǒng)方案設(shè)計，從軟件實現(xiàn)的角度審查軟件研制任務(wù)書的需求，并對軟件項目的策劃活動進行策劃。

（2）頂層策劃

頂層策劃包括定義軟件生存周期模型、頂層WBS分解、頂層估計和制定軟件項目計劃。

基于Scrum方法的項目管理流程在傳統(tǒng)迭代模型的基礎(chǔ)上，結(jié)合Scrum的迭代思想建立快速迭代模型，迭代周期在項目的生存周期中固定不變，通常為2至4周，每次迭代輸出的工作產(chǎn)品均是可交付的，并且是在上次迭代產(chǎn)品基礎(chǔ)上的增量。軟件開發(fā)團隊可根據(jù)軟件的質(zhì)量要求、安全級別和團隊人員的能力等特征，靈活定義每次迭代中的工程活動及每項活動的完成準(zhǔn)則。

頂層WBS分解的輸出為按優(yōu)先級排序的需求列表，策劃時應(yīng)確保先實現(xiàn)高優(yōu)先級的需求。根據(jù)團隊成員能力、管理成本及系統(tǒng)計劃確定迭代周期和迭代次數(shù)。綜合考慮如下四方面因素確定每個階段需完成的任務(wù)及其完成準(zhǔn)則：a）需求的完備和穩(wěn)定程度;b）需求優(yōu)先級;c）迭代周期和估計工作量;d）硬件平臺的研制進度。

采用故事點估計等方法對軟件的需求、用戶故事（顧客和開發(fā)團隊以共同協(xié)商的方式對特性進行分解后形成的更小粒度、獨立、有價值、可測試的功能模塊）和工作量進行估計，并記錄估計假設(shè)（理由）和估計結(jié)果，以確保團隊對估計項和承諾的理解達成共識。在進行每一類估計前，先從所有估計項中選擇適當(dāng)規(guī)模的某個估計項作為基準(zhǔn)估計項，對其他估計項的估計結(jié)果是基準(zhǔn)估計項的倍數(shù)。采用相對值作為估計結(jié)果可以使估計人員將關(guān)注點從估計值轉(zhuǎn)到對估計項的理解上，可通過估計發(fā)現(xiàn)需求問題及對需求理解的不一致，在一定程度上起到評審的效果。

綜合考慮項目軟件過程定義和選擇、項目組成員及職責(zé)分配、進度計劃、資源計劃、知識和技能計劃、利益相關(guān)方計劃、數(shù)據(jù)管理計劃、采用的方法及標(biāo)準(zhǔn)、安全保密計劃、風(fēng)險管理計劃等內(nèi)容制定軟件項目的總體計劃，即軟件開發(fā)計劃。

（3）階段策劃

階段策劃包括階段WBS分解、階段估計和階段計劃制定。

階段WBS分解是按本階段需完成的所有需求的優(yōu)先級，對迭代內(nèi)需要完成的任務(wù)進行進一步細(xì)化分解。階段任務(wù)分解的粒度需滿足每日跟蹤的要求。

階段估計采用故事點等估計方法對階段WBS分解得到的所有任務(wù)的工作量進行估計。

制定階段計劃首先確定每條任務(wù)的優(yōu)先級。優(yōu)先級表示每項任務(wù)相對于其他任務(wù)的優(yōu)先程度，數(shù)值越大，優(yōu)先級越高。確定階段進度時，應(yīng)綜合考慮軟件階段的活動WBS、當(dāng)前階段或時段的規(guī)模和工作量估計結(jié)果、人員可用率等因素，并確保任務(wù)進度與軟件頂層進度計劃一致。

（4）每日例會

用圖2所示的燃盡圖等形式對前一天計劃中需求和任務(wù)的完成情況進行監(jiān)控，識別并分析前一天工作中遇到的問題，記錄問題、解決措施和解決情況。

（5）階段計劃實施

階段跟蹤的控制粒度通常為2至4周，階段跟蹤對象為需求的故事點數(shù)。采用總體跟蹤圖記錄階段跟蹤的進度、工作量、規(guī)模、資源、知識技能的實際情況及相關(guān)信息。

（6）階段評審

每個階段結(jié)束時，基于監(jiān)督數(shù)據(jù)與利益方一起評審項目的承諾、計劃、狀態(tài)和風(fēng)險。階段評審時，通過回顧活動識別本階段的最佳實踐和存在的問題，超出明顯偏差時，記錄并跟蹤更改申請，確定并跟蹤糾正措施直至結(jié)束。監(jiān)控并記錄風(fēng)險變化情況，修正風(fēng)險參數(shù)，必要時采取相應(yīng)措施監(jiān)督。識別是否有新增風(fēng)險，標(biāo)識重大變化，確定并落實緩解措施。

2 ?基于敏捷方法的支持類過程域?qū)嵺`

本章將介紹敏捷方法在GJB 5000A二級的測量與分析、配置管理、過程和產(chǎn)品質(zhì)量保證三個過程域中的具體實踐。

2.1 ?測量與分析

基于敏捷方法的項目需開展的跟測量與分析過程域相關(guān)的實踐可包括。

（1）定義并使用明確的目標(biāo)：不限于某次迭代的目標(biāo)，還可包括在規(guī)定期限內(nèi)完成指定的任務(wù)，如在多次迭代中達到一定的速率以滿足業(yè)務(wù)需求。

（2）定義并使用測量項。如：團隊速率的計算方法，明確計算公式中使用的故事點是按人計還是按團隊計，是否包括中斷的時間等;團隊使用的機動故事。

（3）明確測量項的采集、分析和記錄要求。

（4）明確測量項目和績效數(shù)據(jù)的發(fā)布對象。

（5）根據(jù)已定義的目標(biāo)，使用測量項來跟蹤和改進團隊的績效。

為開展績效評估，基于Scrum的項目團隊需采集的測量項可能包括。

（1）總體跟蹤圖

總體跟蹤圖用于描述每次迭代結(jié)束時隨迭代周期變化的剩余故事點數(shù)，以及已完成的所有迭代的實際計劃完成情況。

通過對總體跟蹤圖的分析，找到產(chǎn)生計劃偏差的原因，如計劃的工作量過大、員工因計劃外承擔(dān)其他工作影響了項目計劃的執(zhí)行等。同時，根據(jù)偏差原因有針對地制定并采取糾正措施，如調(diào)整計劃、增加資源等。

（2）階段跟蹤圖

階段跟蹤圖用于描述本次迭代每個工作日結(jié)束時剩余任務(wù)的工作量，以及本次迭代已完成的實際任務(wù)完成情況。

通過對階段跟蹤圖的分析，可判斷當(dāng)天任務(wù)的完成情況及偏差大小，并推算出對階段進度的影響，從而采取適當(dāng)?shù)募m正措施，保證項目按計劃進行。

2.2 ?配置管理

在基于敏捷方法的項目中，對工作產(chǎn)品進行分級配置管理，如將工作產(chǎn)品分為基線配置項、非基線配置項、記錄等類型，并制定每類配置項的配置管理要求。根據(jù)項目的實際情況來識別配置項，設(shè)置基線。

除常規(guī)的軟件文檔、代碼和記錄外，基于敏捷的項目需納入配置管理的工作產(chǎn)品還可能包括。

（1）需求列表。

（2）迭代任務(wù)列表/階段計劃。

（3）任務(wù)跟蹤表和跟蹤圖。

（4）回顧記錄。

實施配置管理活動的時機主要如下。

（1）需求列表發(fā)布。

（2）迭代任務(wù)列表/階段計劃發(fā)布。

（3）階段評審。

（4）閉項。

在基于敏捷方法的項目中，合理定義并正確理解迭代的輸出工作產(chǎn)品和完成準(zhǔn)則有助于確保每個階段完成的工作產(chǎn)品的版本的正確性。迭代輸出的工作產(chǎn)品不一定是完整的軟件文檔和代碼，可以是文檔片段、分析設(shè)計圖、組件或函數(shù)的代碼等。

2.3 ?過程和產(chǎn)品質(zhì)量保證

在基于敏捷方法的項目中，應(yīng)根據(jù)活動時機及活動間的依賴關(guān)系對質(zhì)量保證活動的時機進行相應(yīng)調(diào)整，使質(zhì)量保證審查與項目活動的節(jié)奏相適應(yīng)。

此外，敏捷團隊的部分活動中包含了質(zhì)量保證活動，且由非質(zhì)量保證人員完成。這些活動包括。

（1）軟件負(fù)責(zé)人對項目研制過程提供的指導(dǎo)和糾偏措施。

（2）階段技術(shù)評審時對工作產(chǎn)品進行的審查。

（3）階段評審中的回顧。

3 ?結(jié)束語

在實施GJB 5000A的過程中采用敏捷方法，通過每日例會、階段跟蹤和總體跟蹤活動，能及時體現(xiàn)團隊成員完成的工作，盡早發(fā)現(xiàn)偏差和問題，確保實際的過程與需求和目標(biāo)保持一致。

本文介紹了基于Scrum方法的GJB 5000A軟件項目管理流程，同時，給出了敏捷方法在GJB 5000A二級測量與分析、配置管理、過程和產(chǎn)品質(zhì)量保證過程域的應(yīng)用。在軟件項目中的應(yīng)用情況表明，該方法適用于基于敏捷方法實施GJB 5000A的組織和團隊。在后續(xù)工作中，將進一步結(jié)合GJB 5000A實施中存在的問題，將軟件生存周期從目前的軟件開發(fā)周期擴展到包括運維在內(nèi)的全生命周期，對敏捷工程技術(shù)方法進行研究。

參考文獻

[1] 總裝電子信息基礎(chǔ)部標(biāo)準(zhǔn)化研究中心， 總裝系統(tǒng)所， 航天科工集團二院204所， 等. GJB 5000-2003軍用軟件研制能力成熟度模型[S]. 北京： 中國人民解放軍總裝備部， 2003.

[2] 總裝備部電子信息基礎(chǔ)部技術(shù)基礎(chǔ)局， 總裝備部技術(shù)基礎(chǔ)管理中心， 總裝備部電子信息基礎(chǔ)部標(biāo)準(zhǔn)化研究中心， 等. 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]. 北京： 清華大學(xué)出版社， 2007.

[10] 劉從越， 孫剛， 仲里. Scrum與CMMI在中小型安全關(guān)鍵軟件中的應(yīng)用[J]. 計算機工程與應(yīng)用， 2011， 47（13）： 55-58.