陳申平 顏樂(lè)鳴

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

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

中圖分類(lèi)號(hào)： TP311.5 ? ?文獻(xiàn)標(biāo)識(shí)碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.08.030

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

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

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

1 ?基于Scrum方法的軟件項(xiàng)目管理流程

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

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

基于Scrum方法的軟件項(xiàng)目管理流程活動(dòng)要求如下。

（1）早期策劃

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

（2）頂層策劃

頂層策劃包括定義軟件生存周期模型、頂層WBS分解、頂層估計(jì)和制定軟件項(xiàng)目計(jì)劃。

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

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

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

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

（3）階段策劃

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

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

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

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

（4）每日例會(huì)

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

（5）階段計(jì)劃實(shí)施

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

（6）階段評(píng)審

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

2 ?基于敏捷方法的支持類(lèi)過(guò)程域?qū)嵺`

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

2.1 ?測(cè)量與分析

基于敏捷方法的項(xiàng)目需開(kāi)展的跟測(cè)量與分析過(guò)程域相關(guān)的實(shí)踐可包括。

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

（2）定義并使用測(cè)量項(xiàng)。如：團(tuán)隊(duì)速率的計(jì)算方法，明確計(jì)算公式中使用的故事點(diǎn)是按人計(jì)還是按團(tuán)隊(duì)計(jì)，是否包括中斷的時(shí)間等;團(tuán)隊(duì)使用的機(jī)動(dòng)故事。

（3）明確測(cè)量項(xiàng)的采集、分析和記錄要求。

（4）明確測(cè)量項(xiàng)目和績(jī)效數(shù)據(jù)的發(fā)布對(duì)象。

（5）根據(jù)已定義的目標(biāo)，使用測(cè)量項(xiàng)來(lái)跟蹤和改進(jìn)團(tuán)隊(duì)的績(jī)效。

為開(kāi)展績(jī)效評(píng)估，基于Scrum的項(xiàng)目團(tuán)隊(duì)需采集的測(cè)量項(xiàng)可能包括。

（1）總體跟蹤圖

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

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

（2）階段跟蹤圖

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

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

2.2 ?配置管理

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

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

（1）需求列表。

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

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

（4）回顧記錄。

實(shí)施配置管理活動(dòng)的時(shí)機(jī)主要如下。

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

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

（3）階段評(píng)審。

（4）閉項(xiàng)。

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

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

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

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

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

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

（3）階段評(píng)審中的回顧。

3 ?結(jié)束語(yǔ)

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

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

參考文獻(xiàn)

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

[2] 總裝備部電子信息基礎(chǔ)部技術(shù)基礎(chǔ)局， 總裝備部技術(shù)基礎(chǔ)管理中心， 總裝備部電子信息基礎(chǔ)部標(biāo)準(zhǔn)化研究中心， 等. GJB 5000A-2008軍用軟件研制能力成熟度模型[S]. 北京： 中國(guó)人民解放軍總裝備部， 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] 李國(guó)彪， 譯. Schwaber K. Scrum敏捷項(xiàng)目管理[M]. 北京： 清華大學(xué)出版社， 2007.

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