基于Scrum方法的軟件項目管理過程度量研究過程度量研究

嚴晶

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

軟件項目管理 瀑布模型 敏捷開發 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 引言

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

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

2 Scrum方法簡介

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

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

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

（1）依據需求的優先級確定項目的需求列表，依據需求列表對工作量進行估算；

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

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

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

3 項目管理過程度量

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

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

軟件項目管理的過程度量能夠幫助項目經理等人員掌握軟件過程的狀態，提供軟件項目管理受控所需的數據和信息。

4 瀑布模型的不足

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

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

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

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

5 引入Scrum方法來解決問題

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

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

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

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

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

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

6 結束語

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

參考文獻：

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

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

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

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

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

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

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

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

5 引入Scrum方法來解決問題

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

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

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

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

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

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

6 結束語

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

參考文獻：

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

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

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

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

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

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

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

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

5 引入Scrum方法來解決問題

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

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

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

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

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

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

6 結束語

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

參考文獻：

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

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

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

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

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