嚴(yán)晶

通過分析軟件項目管理中傳統(tǒng)瀑布模型常用的掙值分析法的不足，引入敏捷開發(fā)的Scrum方法到項目實踐中來解決問題，從而更好地實施軟件項目管理，提高開發(fā)效率，達到項目進度和產(chǎn)品質(zhì)量可控的目的。

軟件項目管理 瀑布模型 敏捷開發(fā) Scrum 掙值法

Research on Measurement of Software Project Management Process Based on Scrum Method

YAN Jing

（China Electronics Technology Group Corporation No.7 Research Institute， Guangzhou 510310， China）

By analyzing the shortage of earned value method commonly used in traditional waterfall model of software project management， the Scrum method of agile development is introduced into the project practice to solve the problems in order to better carry out the software project management and improve development efficiency， which achieves to control the project progress and product quality.

software project management waterfall model agile development Scrum earned value method

1 引言

軟件項目管理能力的高低是軟件項目最終能否成功的關(guān)鍵因素。目前軟件行業(yè)所面臨的最重要的軟件開發(fā)問題莫過于如何用一種有效的方法來管理軟件過程，確保軟件開發(fā)的高效率和產(chǎn)品的高質(zhì)量。隨著軟件開發(fā)復(fù)雜性的日益增大以及軟件行業(yè)規(guī)范管理經(jīng)驗的逐漸積累，軟件項目管理無論是在理論上還是在實踐中都取得了很大的進展。CMMI（Capability Maturity Model Integration，軟件能力成熟度模型集成）中的項目監(jiān)控、項目策劃、測量與分析這三個過程域，也對如何規(guī)范有效地開展項目管理有所指引。

本文對軟件業(yè)界常用的瀑布模型和配套的掙值法的不足進行了分析，并引入敏捷開發(fā)中的最佳實踐Scrum方法，通過全周期和階段兩層跟蹤方式來實施軟件項目管理。

2 Scrum方法簡介

敏捷開發(fā)（Agile Development）是以提高軟件開發(fā)效率和響應(yīng)速率為目的，針對傳統(tǒng)瀑布模型開發(fā)的弊端而研發(fā)的一種開發(fā)模式，是以人為核心的多次迭代循序漸進的開發(fā)方法。敏捷方法試圖通過小型的、自我管理的團隊使用短小的合作發(fā)布周期來鼓勵迭代式軟件開發(fā)方法。軟件的質(zhì)量貫穿敏捷軟件開發(fā)的每一個階段，并提出很多關(guān)鍵的規(guī)則來保證能在每一個迭代周期內(nèi)及早地發(fā)現(xiàn)并及時消滅開發(fā)過程中出現(xiàn)的錯誤。敏捷開發(fā)將軟件開發(fā)劃分為多個迭代開發(fā)的過程和階段，通過迭代式的增量開發(fā)，保證軟件一直處于可使用的狀態(tài)。

Scrum是敏捷開發(fā)的方法之一，也是目前軟件業(yè)界的敏捷最佳實踐之一。Scrum通過可視化、檢驗和適應(yīng)來管理復(fù)雜、不可確認(rèn)和變更。Scrum思想將工業(yè)過程控制中的概念應(yīng)用到軟件開發(fā)中來，認(rèn)為軟件開發(fā)過程不是確定性過程，而是將傳統(tǒng)軟件開發(fā)中的分析、設(shè)計和編碼等子過程視為一個黑箱，充分發(fā)揮軟件人員的創(chuàng)造力，使項目組工作在一種模糊狀態(tài)增強適應(yīng)力，以此來替代傳統(tǒng)瀑布模型將經(jīng)驗性過程按確定性過程來處理所缺乏的適應(yīng)力。

Scrum是一種工作管理的方法，它不僅僅限于軟件開發(fā)，也可以用來管理硬件開發(fā)、系統(tǒng)工程等各種開發(fā)活動。Scrum開發(fā)模型圖如圖1所示。

（1）依據(jù)需求的優(yōu)先級確定項目的需求列表，依據(jù)需求列表對工作量進行估算；

（2）假設(shè)每次的迭代周期為4周，確定單次迭代的工作目標(biāo)，并對任務(wù)進行細化形成迭代任務(wù)列表，子任務(wù)的跟蹤粒度小于2天；

（3）迭代中進行每日例會，每次會議控制在15分鐘左右，并且每個成員要向團隊匯報昨天完成了什么、今天要完成什么，同時遇到不能解決的問題也可以提出，匯報完成后更新迭代任務(wù)的燃盡圖；

（4）當(dāng)一個迭代的功能完成時，進行迭代演示也稱為評審會議，會議中演示本次迭代所完成的軟件產(chǎn)品。

3 項目管理過程度量

軟件項目管理是為了使軟件項目能夠按照預(yù)定的成本、進度和質(zhì)量順利完成，而對人員（People）、產(chǎn)品（Product）、過程（Process）、項目（Project）進行分析和管理的活動。軟件項目管理的目的是為了讓軟件項目尤其是大型項目的整個軟件生命周期（從分析、設(shè)計、編碼到測試、維護全過程）都能在管理者的控制之下，了解軟件項目進展，以預(yù)定成本按期、按質(zhì)的完成軟件并交付用戶使用。當(dāng)項目績效明顯偏離計劃時，能采取適當(dāng)?shù)募m正措施。

軟件度量是對軟件開發(fā)項目、過程及其產(chǎn)品進行數(shù)據(jù)定義、收集和分析的持續(xù)性定量化過程，目的在于對此加以理解、預(yù)測、評估、控制和改善。通過軟件度量可以改進軟件開發(fā)過程，促進項目成功，開發(fā)高質(zhì)量的軟件產(chǎn)品。

軟件項目管理的過程度量能夠幫助項目經(jīng)理等人員掌握軟件過程的狀態(tài)，提供軟件項目管理受控所需的數(shù)據(jù)和信息。

4 瀑布模型的不足

軟件開發(fā)中傳統(tǒng)的瀑布模型是一種較為理想化線性的開發(fā)過程。其強調(diào)文檔的作用，以文檔為驅(qū)動，在整個開發(fā)過程中各階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，一切以文檔為依據(jù)，并要求每個階段都要仔細驗證。由于瀑布模型具有線性的特性，用戶往往只有等到項目的末期才能見到開發(fā)成果，早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，這樣既增加了開發(fā)的風(fēng)險，也給項目帶來了嚴(yán)重的后果。endprint

具體到瀑布模型的項目管理方面，項目通過跟蹤里程碑和階段完成日期的方式來跟蹤項目進度。通常使用掙值分析法的計算來顯示和分析項目是否在按計劃進行，但掙值的績效指標(biāo)可能帶有誤導(dǎo)性，并經(jīng)常掩蓋掉某些進度延誤。在進度、范圍和財政預(yù)算上，比起為傳統(tǒng)瀑布項目提供的“掙值（EV）”和“進度績效指標(biāo)（SPI）”，Scrum能為項目利益相關(guān)方提供更為準(zhǔn)確的預(yù)測。

例如，一個項目周期為12個月，某階段的計劃工作量為1 000人時，項目在跟蹤頻率為雙周時對項目的SPI進行度量。當(dāng)實際工作量為800人時，SPI=800/1 000=0.8，意味著SPI小于1即延遲于原計劃20%；當(dāng)實際工作量為1 200人時，SPI=1.2，意味著項目比原計劃超前20%。在對項目的跟蹤分析數(shù)據(jù)進行分析時會發(fā)現(xiàn)，這樣的延遲或超前對項目進度本身的影響并沒有太多的實際意義，只要不影響階段的周期進度就是可行的。假設(shè)還是這個項目，前期的系統(tǒng)分析和軟件需求分析占用了全周期工作量的20%，但因為瀑布的線性特性，這個階段項目的輸出僅僅是大量的研制任務(wù)書、軟件需求、討論記錄、會議紀(jì)要等，并沒有可使用的軟件產(chǎn)品的雛形。上述的項目管理跟蹤方式往往掩蓋了項目的實際問題，有可能造成項目在臨近結(jié)束時才暴露出開發(fā)過程中產(chǎn)生的問題。即使從掙值分析的數(shù)據(jù)來看，項目能夠按照預(yù)定的計劃穩(wěn)步開展，并不能確保最終能夠生成預(yù)期的軟件產(chǎn)品。如果此時出現(xiàn)了顛覆性的重大設(shè)計問題，但從掙值分析數(shù)據(jù)來看并不一定能夠發(fā)現(xiàn)，對項目的影響也許只能通過調(diào)整計劃等決策來進行挽救。

綜上所述，掙值分析這樣的項目管理方法雖然有著光鮮的外表，但對軟件產(chǎn)品開發(fā)過程度量的實質(zhì)意義不大，不能較好地通過對軟件項目管理過程度量達到對項目進度和軟件產(chǎn)品質(zhì)量監(jiān)控的目的，促進項目的最終成功交付。

5 引入Scrum方法來解決問題

Scrum方法能更快、更高效地交付可工作的軟件產(chǎn)品，并提供更準(zhǔn)確的進度、預(yù)算和范圍的預(yù)測。使用Scrum方法將范例12個月項目分成12次迭代，即每次迭代周期是1個月。在第3個迭代完成時，完成了3個可交付軟件產(chǎn)品，而不是瀑布模型的一堆文檔和記錄表。Scrum方法也寫文檔，但只寫有必要且盡量少的文檔和記錄。Scrum注重的是人與人之間面對面的交流，強調(diào)以人為核心，例如每日例會中當(dāng)場記錄項目成員的工作量數(shù)據(jù)，就可以替代掙值分析法中的個人工作日志、工作周報等。

Scrum相較于傳統(tǒng)的掙值分析法，度量數(shù)據(jù)的數(shù)量和種類有了大幅度的減少，約占掙值分析法度量數(shù)據(jù)的50%，同時也大大降低了數(shù)據(jù)統(tǒng)計分析的難度。主要的度量數(shù)據(jù)包括：任務(wù)計劃工作量（人時）、任務(wù)實際工作量（人時）、迭代次數(shù)、迭代周期（工作日）、計劃總工作量（人時）、計劃剩余工作量（人時）、實際剩余工作量（人時）和工作量偏差（%）。

采用Scrum方法，項目仍然需要按照傳統(tǒng)的方式劃分軟件里程碑，從而把控項目階段的全周期進度，防止由于迭代次數(shù)過多或是迭代內(nèi)容的更改以至于對項目的整體進度造成影響。項目采用全周期進度和每次迭代階段任務(wù)兩層跟蹤的方法，同步對全周期進度和階段進度進行管理。

范例項目周期12個月，每個月1次共12次迭代，每次迭代的任務(wù)計劃總工作量為620人時，項目全周期計劃總工作量為7 440人時。

表1和圖2是項目全周期項目管理過程度量的數(shù)據(jù)及跟蹤圖，其中的度量數(shù)據(jù)有偏差百分比、計劃剩余工作量和實際剩余工作量。計劃剩余工作量是由計劃總工作量開始遞減的等差數(shù)列，偏差百分比=（計劃剩余工作量-實際剩余工作量）/任務(wù)計劃總工作量* 100%。數(shù)據(jù)及跟蹤圖使用Excel工具來定制，跟蹤圖可以通過數(shù)據(jù)自動刷新生成。這里的跟蹤圖使用了Scrum常用的燃盡圖的表達形式。

表2和圖3是項目一次迭代階段的項目管理過程度量的數(shù)據(jù)及跟蹤圖。數(shù)據(jù)的類型和計算方式與全周期的記錄表類似，只是偏差百分比的分母基數(shù)替換為這次迭代階段的計劃總工作量。從跟蹤圖的數(shù)據(jù)分布情況來看，當(dāng)實際剩余工作量小于計劃剩余工作量時，進度提前；當(dāng)實際剩余工作量大于計劃剩余工作量時，進度延期。為了增強與CMMI標(biāo)準(zhǔn)的適應(yīng)性，增加偏差百分比這個度量項，偏差可根據(jù)項目計劃中制定的閾值范圍采取措施進行糾偏。每次迭代的跟蹤保證了度量數(shù)據(jù)與軟件產(chǎn)品實現(xiàn)間的直觀性，全周期跟蹤圖中尤其是對里程碑節(jié)點的重點把控，從而實現(xiàn)了對全周期的各個階段的監(jiān)控。

6 結(jié)束語

基于敏捷思想的Scrum方法，能夠改善傳統(tǒng)瀑布模型和掙值分析法的項目管理方法數(shù)據(jù)分析的誤導(dǎo)，針對項目進度和產(chǎn)品質(zhì)量無法準(zhǔn)確預(yù)測、項目重大問題容易在項目后期才暴露等問題，通過迭代、增量式的開發(fā)，加強項目各種角色間的溝通，提高開發(fā)效率，簡化項目的文檔和過程記錄。通過對迭代目標(biāo)和迭代進度的把控，每次迭代生成可提交用戶的軟件產(chǎn)品，從而把控全周期進度，迭代增量式完成軟件產(chǎn)品的開發(fā)。當(dāng)然，Scrum在項目實踐中可能還存在不足，需要軟件從業(yè)人員不斷深入地探索和研究。

參考文獻：

[1] Schwaber K. Scrum敏捷項目管理[M]. 李國彪，譯. 北京： 清華大學(xué)出版社， 2007.

[2] Mike Cohn. Scrum敏捷軟件開發(fā)[M]. 廖靖斌，呂梁岳，陳爭云，等譯. 北京： 清華大學(xué)出版社， 2010.

[3] Robert C Martin. 敏捷軟件開發(fā)（原則、模式與實踐）[M]. 鄧輝，譯. 北京： 清華大學(xué)出版社， 2003.

[4] Ken Schwaber， Jeff Sutherland. 30天軟件開發(fā)：告別瀑布擁抱敏捷[M]. 王軍，李麟德，譯. 北京： 人民郵電出版社， 2014.

[5] Andrew Pham， Phuong-Van Pham. Scrum實戰(zhàn)：敏捷軟件項目管理與開發(fā)[M]. 崔康，譯. 北京： 清華大學(xué)出版社， 2013.endprint

具體到瀑布模型的項目管理方面，項目通過跟蹤里程碑和階段完成日期的方式來跟蹤項目進度。通常使用掙值分析法的計算來顯示和分析項目是否在按計劃進行，但掙值的績效指標(biāo)可能帶有誤導(dǎo)性，并經(jīng)常掩蓋掉某些進度延誤。在進度、范圍和財政預(yù)算上，比起為傳統(tǒng)瀑布項目提供的“掙值（EV）”和“進度績效指標(biāo)（SPI）”，Scrum能為項目利益相關(guān)方提供更為準(zhǔn)確的預(yù)測。

例如，一個項目周期為12個月，某階段的計劃工作量為1 000人時，項目在跟蹤頻率為雙周時對項目的SPI進行度量。當(dāng)實際工作量為800人時，SPI=800/1 000=0.8，意味著SPI小于1即延遲于原計劃20%；當(dāng)實際工作量為1 200人時，SPI=1.2，意味著項目比原計劃超前20%。在對項目的跟蹤分析數(shù)據(jù)進行分析時會發(fā)現(xiàn)，這樣的延遲或超前對項目進度本身的影響并沒有太多的實際意義，只要不影響階段的周期進度就是可行的。假設(shè)還是這個項目，前期的系統(tǒng)分析和軟件需求分析占用了全周期工作量的20%，但因為瀑布的線性特性，這個階段項目的輸出僅僅是大量的研制任務(wù)書、軟件需求、討論記錄、會議紀(jì)要等，并沒有可使用的軟件產(chǎn)品的雛形。上述的項目管理跟蹤方式往往掩蓋了項目的實際問題，有可能造成項目在臨近結(jié)束時才暴露出開發(fā)過程中產(chǎn)生的問題。即使從掙值分析的數(shù)據(jù)來看，項目能夠按照預(yù)定的計劃穩(wěn)步開展，并不能確保最終能夠生成預(yù)期的軟件產(chǎn)品。如果此時出現(xiàn)了顛覆性的重大設(shè)計問題，但從掙值分析數(shù)據(jù)來看并不一定能夠發(fā)現(xiàn)，對項目的影響也許只能通過調(diào)整計劃等決策來進行挽救。

綜上所述，掙值分析這樣的項目管理方法雖然有著光鮮的外表，但對軟件產(chǎn)品開發(fā)過程度量的實質(zhì)意義不大，不能較好地通過對軟件項目管理過程度量達到對項目進度和軟件產(chǎn)品質(zhì)量監(jiān)控的目的，促進項目的最終成功交付。

5 引入Scrum方法來解決問題

Scrum方法能更快、更高效地交付可工作的軟件產(chǎn)品，并提供更準(zhǔn)確的進度、預(yù)算和范圍的預(yù)測。使用Scrum方法將范例12個月項目分成12次迭代，即每次迭代周期是1個月。在第3個迭代完成時，完成了3個可交付軟件產(chǎn)品，而不是瀑布模型的一堆文檔和記錄表。Scrum方法也寫文檔，但只寫有必要且盡量少的文檔和記錄。Scrum注重的是人與人之間面對面的交流，強調(diào)以人為核心，例如每日例會中當(dāng)場記錄項目成員的工作量數(shù)據(jù)，就可以替代掙值分析法中的個人工作日志、工作周報等。

Scrum相較于傳統(tǒng)的掙值分析法，度量數(shù)據(jù)的數(shù)量和種類有了大幅度的減少，約占掙值分析法度量數(shù)據(jù)的50%，同時也大大降低了數(shù)據(jù)統(tǒng)計分析的難度。主要的度量數(shù)據(jù)包括：任務(wù)計劃工作量（人時）、任務(wù)實際工作量（人時）、迭代次數(shù)、迭代周期（工作日）、計劃總工作量（人時）、計劃剩余工作量（人時）、實際剩余工作量（人時）和工作量偏差（%）。

采用Scrum方法，項目仍然需要按照傳統(tǒng)的方式劃分軟件里程碑，從而把控項目階段的全周期進度，防止由于迭代次數(shù)過多或是迭代內(nèi)容的更改以至于對項目的整體進度造成影響。項目采用全周期進度和每次迭代階段任務(wù)兩層跟蹤的方法，同步對全周期進度和階段進度進行管理。

范例項目周期12個月，每個月1次共12次迭代，每次迭代的任務(wù)計劃總工作量為620人時，項目全周期計劃總工作量為7 440人時。

表1和圖2是項目全周期項目管理過程度量的數(shù)據(jù)及跟蹤圖，其中的度量數(shù)據(jù)有偏差百分比、計劃剩余工作量和實際剩余工作量。計劃剩余工作量是由計劃總工作量開始遞減的等差數(shù)列，偏差百分比=（計劃剩余工作量-實際剩余工作量）/任務(wù)計劃總工作量* 100%。數(shù)據(jù)及跟蹤圖使用Excel工具來定制，跟蹤圖可以通過數(shù)據(jù)自動刷新生成。這里的跟蹤圖使用了Scrum常用的燃盡圖的表達形式。

表2和圖3是項目一次迭代階段的項目管理過程度量的數(shù)據(jù)及跟蹤圖。數(shù)據(jù)的類型和計算方式與全周期的記錄表類似，只是偏差百分比的分母基數(shù)替換為這次迭代階段的計劃總工作量。從跟蹤圖的數(shù)據(jù)分布情況來看，當(dāng)實際剩余工作量小于計劃剩余工作量時，進度提前；當(dāng)實際剩余工作量大于計劃剩余工作量時，進度延期。為了增強與CMMI標(biāo)準(zhǔn)的適應(yīng)性，增加偏差百分比這個度量項，偏差可根據(jù)項目計劃中制定的閾值范圍采取措施進行糾偏。每次迭代的跟蹤保證了度量數(shù)據(jù)與軟件產(chǎn)品實現(xiàn)間的直觀性，全周期跟蹤圖中尤其是對里程碑節(jié)點的重點把控，從而實現(xiàn)了對全周期的各個階段的監(jiān)控。

6 結(jié)束語

基于敏捷思想的Scrum方法，能夠改善傳統(tǒng)瀑布模型和掙值分析法的項目管理方法數(shù)據(jù)分析的誤導(dǎo)，針對項目進度和產(chǎn)品質(zhì)量無法準(zhǔn)確預(yù)測、項目重大問題容易在項目后期才暴露等問題，通過迭代、增量式的開發(fā)，加強項目各種角色間的溝通，提高開發(fā)效率，簡化項目的文檔和過程記錄。通過對迭代目標(biāo)和迭代進度的把控，每次迭代生成可提交用戶的軟件產(chǎn)品，從而把控全周期進度，迭代增量式完成軟件產(chǎn)品的開發(fā)。當(dāng)然，Scrum在項目實踐中可能還存在不足，需要軟件從業(yè)人員不斷深入地探索和研究。

參考文獻：

[1] Schwaber K. Scrum敏捷項目管理[M]. 李國彪，譯. 北京： 清華大學(xué)出版社， 2007.

[2] Mike Cohn. Scrum敏捷軟件開發(fā)[M]. 廖靖斌，呂梁岳，陳爭云，等譯. 北京： 清華大學(xué)出版社， 2010.

[3] Robert C Martin. 敏捷軟件開發(fā)（原則、模式與實踐）[M]. 鄧輝，譯. 北京： 清華大學(xué)出版社， 2003.

[4] Ken Schwaber， Jeff Sutherland. 30天軟件開發(fā)：告別瀑布擁抱敏捷[M]. 王軍，李麟德，譯. 北京： 人民郵電出版社， 2014.

[5] Andrew Pham， Phuong-Van Pham. Scrum實戰(zhàn)：敏捷軟件項目管理與開發(fā)[M]. 崔康，譯. 北京： 清華大學(xué)出版社， 2013.endprint

具體到瀑布模型的項目管理方面，項目通過跟蹤里程碑和階段完成日期的方式來跟蹤項目進度。通常使用掙值分析法的計算來顯示和分析項目是否在按計劃進行，但掙值的績效指標(biāo)可能帶有誤導(dǎo)性，并經(jīng)常掩蓋掉某些進度延誤。在進度、范圍和財政預(yù)算上，比起為傳統(tǒng)瀑布項目提供的“掙值（EV）”和“進度績效指標(biāo)（SPI）”，Scrum能為項目利益相關(guān)方提供更為準(zhǔn)確的預(yù)測。

例如，一個項目周期為12個月，某階段的計劃工作量為1 000人時，項目在跟蹤頻率為雙周時對項目的SPI進行度量。當(dāng)實際工作量為800人時，SPI=800/1 000=0.8，意味著SPI小于1即延遲于原計劃20%；當(dāng)實際工作量為1 200人時，SPI=1.2，意味著項目比原計劃超前20%。在對項目的跟蹤分析數(shù)據(jù)進行分析時會發(fā)現(xiàn)，這樣的延遲或超前對項目進度本身的影響并沒有太多的實際意義，只要不影響階段的周期進度就是可行的。假設(shè)還是這個項目，前期的系統(tǒng)分析和軟件需求分析占用了全周期工作量的20%，但因為瀑布的線性特性，這個階段項目的輸出僅僅是大量的研制任務(wù)書、軟件需求、討論記錄、會議紀(jì)要等，并沒有可使用的軟件產(chǎn)品的雛形。上述的項目管理跟蹤方式往往掩蓋了項目的實際問題，有可能造成項目在臨近結(jié)束時才暴露出開發(fā)過程中產(chǎn)生的問題。即使從掙值分析的數(shù)據(jù)來看，項目能夠按照預(yù)定的計劃穩(wěn)步開展，并不能確保最終能夠生成預(yù)期的軟件產(chǎn)品。如果此時出現(xiàn)了顛覆性的重大設(shè)計問題，但從掙值分析數(shù)據(jù)來看并不一定能夠發(fā)現(xiàn)，對項目的影響也許只能通過調(diào)整計劃等決策來進行挽救。

綜上所述，掙值分析這樣的項目管理方法雖然有著光鮮的外表，但對軟件產(chǎn)品開發(fā)過程度量的實質(zhì)意義不大，不能較好地通過對軟件項目管理過程度量達到對項目進度和軟件產(chǎn)品質(zhì)量監(jiān)控的目的，促進項目的最終成功交付。

5 引入Scrum方法來解決問題

Scrum方法能更快、更高效地交付可工作的軟件產(chǎn)品，并提供更準(zhǔn)確的進度、預(yù)算和范圍的預(yù)測。使用Scrum方法將范例12個月項目分成12次迭代，即每次迭代周期是1個月。在第3個迭代完成時，完成了3個可交付軟件產(chǎn)品，而不是瀑布模型的一堆文檔和記錄表。Scrum方法也寫文檔，但只寫有必要且盡量少的文檔和記錄。Scrum注重的是人與人之間面對面的交流，強調(diào)以人為核心，例如每日例會中當(dāng)場記錄項目成員的工作量數(shù)據(jù)，就可以替代掙值分析法中的個人工作日志、工作周報等。

Scrum相較于傳統(tǒng)的掙值分析法，度量數(shù)據(jù)的數(shù)量和種類有了大幅度的減少，約占掙值分析法度量數(shù)據(jù)的50%，同時也大大降低了數(shù)據(jù)統(tǒng)計分析的難度。主要的度量數(shù)據(jù)包括：任務(wù)計劃工作量（人時）、任務(wù)實際工作量（人時）、迭代次數(shù)、迭代周期（工作日）、計劃總工作量（人時）、計劃剩余工作量（人時）、實際剩余工作量（人時）和工作量偏差（%）。

采用Scrum方法，項目仍然需要按照傳統(tǒng)的方式劃分軟件里程碑，從而把控項目階段的全周期進度，防止由于迭代次數(shù)過多或是迭代內(nèi)容的更改以至于對項目的整體進度造成影響。項目采用全周期進度和每次迭代階段任務(wù)兩層跟蹤的方法，同步對全周期進度和階段進度進行管理。

范例項目周期12個月，每個月1次共12次迭代，每次迭代的任務(wù)計劃總工作量為620人時，項目全周期計劃總工作量為7 440人時。

表1和圖2是項目全周期項目管理過程度量的數(shù)據(jù)及跟蹤圖，其中的度量數(shù)據(jù)有偏差百分比、計劃剩余工作量和實際剩余工作量。計劃剩余工作量是由計劃總工作量開始遞減的等差數(shù)列，偏差百分比=（計劃剩余工作量-實際剩余工作量）/任務(wù)計劃總工作量* 100%。數(shù)據(jù)及跟蹤圖使用Excel工具來定制，跟蹤圖可以通過數(shù)據(jù)自動刷新生成。這里的跟蹤圖使用了Scrum常用的燃盡圖的表達形式。

表2和圖3是項目一次迭代階段的項目管理過程度量的數(shù)據(jù)及跟蹤圖。數(shù)據(jù)的類型和計算方式與全周期的記錄表類似，只是偏差百分比的分母基數(shù)替換為這次迭代階段的計劃總工作量。從跟蹤圖的數(shù)據(jù)分布情況來看，當(dāng)實際剩余工作量小于計劃剩余工作量時，進度提前；當(dāng)實際剩余工作量大于計劃剩余工作量時，進度延期。為了增強與CMMI標(biāo)準(zhǔn)的適應(yīng)性，增加偏差百分比這個度量項，偏差可根據(jù)項目計劃中制定的閾值范圍采取措施進行糾偏。每次迭代的跟蹤保證了度量數(shù)據(jù)與軟件產(chǎn)品實現(xiàn)間的直觀性，全周期跟蹤圖中尤其是對里程碑節(jié)點的重點把控，從而實現(xiàn)了對全周期的各個階段的監(jiān)控。

6 結(jié)束語

基于敏捷思想的Scrum方法，能夠改善傳統(tǒng)瀑布模型和掙值分析法的項目管理方法數(shù)據(jù)分析的誤導(dǎo)，針對項目進度和產(chǎn)品質(zhì)量無法準(zhǔn)確預(yù)測、項目重大問題容易在項目后期才暴露等問題，通過迭代、增量式的開發(fā)，加強項目各種角色間的溝通，提高開發(fā)效率，簡化項目的文檔和過程記錄。通過對迭代目標(biāo)和迭代進度的把控，每次迭代生成可提交用戶的軟件產(chǎn)品，從而把控全周期進度，迭代增量式完成軟件產(chǎn)品的開發(fā)。當(dāng)然，Scrum在項目實踐中可能還存在不足，需要軟件從業(yè)人員不斷深入地探索和研究。

參考文獻：

[1] Schwaber K. Scrum敏捷項目管理[M]. 李國彪，譯. 北京： 清華大學(xué)出版社， 2007.

[2] Mike Cohn. Scrum敏捷軟件開發(fā)[M]. 廖靖斌，呂梁岳，陳爭云，等譯. 北京： 清華大學(xué)出版社， 2010.

[3] Robert C Martin. 敏捷軟件開發(fā)（原則、模式與實踐）[M]. 鄧輝，譯. 北京： 清華大學(xué)出版社， 2003.

[4] Ken Schwaber， Jeff Sutherland. 30天軟件開發(fā)：告別瀑布擁抱敏捷[M]. 王軍，李麟德，譯. 北京： 人民郵電出版社， 2014.

[5] Andrew Pham， Phuong-Van Pham. Scrum實戰(zhàn)：敏捷軟件項目管理與開發(fā)[M]. 崔康，譯. 北京： 清華大學(xué)出版社， 2013.endprint