敏捷項目管理系統的研究

武秋實(北京賽迪信息工程監理有限公司,北京 100048)

敏捷項目管理系統的研究

武秋實(北京賽迪信息工程監理有限公司,北京 100048)

敏捷方法是一種適用于短期的、需求變更頻繁的項目管理方法,同時,敏捷項目管理對軟件項目開發有著不同的方法,每種方法都有自己的優點和缺點。

敏捷 Scrum

1 引言

在20世紀80年代，敏捷化產品開發方法在日本汽車制造公司興起，緊接著這一年年底敏捷概念傳播到北美汽車制造商和IT部門，然后敏捷方法作為軟件開發方法被其他行業迅速采納。在傳統方法中，產品開發過程中的需求變更很容易導致項目產生混亂，而敏捷方法不僅能接受項目中的任何變更，并且能以一定方式控制項目中的變更帶來的風險。

2 不確定需求的項目管理

在項目開發的過程中，應對不斷變化的客戶需求對開發人員來說是一個很大的挑戰，這使得開發人員在開發過程中把項目分成很多個小步驟，可以接受不斷變化的需求。根據2000年議會科學與技術辦公室的報告中的內容，其中提到把項目分解成為小模塊能靈活應對項目中產生的需求變更，分解出來的一部分包含明確的需求和固定的價格，另一部分用來應對變更的需求和價格，從而確保項目能夠更安全和容易地進行。同時，軟件公司在與政府IT部門工作時應該提供優秀的領導能力，更廣泛的部門目標，與供應商良好的關系，適當的風險管理以及考慮到盡可能多的用戶標準。

賽迪監理通過對眾多大型項目的管理研究發現，6到12個月短時間的項目比一年以上的項目成功率要高。持續時間長的項目失敗原因是由于過時的技術導致用戶需求變化。軟件公司把時間為一年以上的項目分解為小模塊來應對項目中的變更。在20世紀90年代后期，敏捷方法就有能力應對客戶的需求變更和不斷變化的技術。目前，有一種常用稱之極限編程(XP)的敏捷方法，它與傳統方法相比較可以應付不斷變化的客戶需求和技術，在客戶有系統需求時，給予及時滿意的可執行程序。這些要求不一定需要在項目的初始階段實施，但隨著項目的發展這些要求是被包括在哪一個階段要取決于項目的環境，客戶的需求可以通過原型法來確定。

E-type模塊在實施過程中通常存在不穩定的需求。這些模塊必須在整個項目中經常使用，以適應不斷變化的環境獲得更好的效果來提高客戶滿意度，軟件公司更新管理技術來適應需求的新變化。由于需求是經常發生變化的，開發人員往往對敏捷過程要進行不斷的驗證，確保整個項目是以正確的方式在進行在每一個開發周期，開發人員通過檢測測試結果，如果有錯誤，則對項目文件進行修正。客戶和開發團隊之間的有效溝通，能夠在不破壞計劃的前提下應對各種變更，并盡快在指定時間內完成項目。此外，開發人員應該對任何可能會影響項目的風險提高警惕。

Scrum是軟件公司用來應對不確定需求的另一種敏捷開發過程。Scrum過程中產生的產品backlog對需求變更具有重要的作用，產品backlog包含了項目中的各類要求和問題，在開發過程中，產品backlog中的要求可以在任何時候做出改變且不會影響該項目。產品負責人確定客戶需求的優先級，然后將確定優先級的需求分配給沖刺backlog。只有是客戶提出的需求才可以對產品backlog進行更改，這避免了軟件公司在項目發生變更時發生混亂。

軟件公司也常使用一些需求管理工具，一般來說，分為兩大類，一類是面向內容的需求管理被稱作為以文檔為中心的工具；另一類是面向過程的管理工具，用來解決結構化信息項目的需求。這些工具能夠與其它系統工程、軟件工具、分類需求，以及其它查詢和搜索關鍵字設備進行接口集成。HERMES是一種可以對需求進行概括的需求管理軟件，它自帶的XML技術可以把需求從文本轉化為對象，而且可以供其它模塊共享。這種管理系統一般應用于需求編制易修改的項目，此系統會檢測需求概括后的關鍵字，有助于開發團隊和設計者把需求考慮到系統及其開發過程中。

3 Scrum方法

Scrum是一種迭代式增量軟件開發過程。整個開發周期包括若干個小的跌代周期，每個小的跌代周期稱為一個Sprint，每個Sprint周期一般為30天。每天有15分鐘的Scrum站會，團隊的成員在會議中輪流回答以下3個問題：昨天我完成了哪些工作？今天我將完成哪些工作？我在工作中遇到了什么困難？團隊成員從產品backlog中自已挑選任務創建沖刺backlog，每天項目的沖刺backlog會提交給管理者，將客戶需求確定優先級順序經過分析得到沖刺任務列表，同時團隊中產生的任何問題或進一步發展的需求管理者都能夠快速提出來。Scrum適用于不確定需求產品的開發，只要使用Scrum在開發過程中發生的任何問題都可以得到快速解決，項目開發中的需求變更會在產品訂單中得到即時更改。每個Sprint周期的產品訂單和團隊人員在一個周期30天內是不變的，以確保迭代結束時能獲得預期的結果。

Scrum Master主持Scrum會議，管理每日Scrum流程，負責為成員解決障礙和問題。在每個迭代周期結束時那些未完成工作量的需求將移到下個月的產品backlog中，下個月團隊成員參考第一個Scrum過程的反饋內容。回顧會議由開發團隊與Scrum負責人共同討論這個迭代過程中哪些地方做得好，哪些需要改進，使團隊持續成長。下圖詳細說明Scrum過程。(圖1)

敏捷開發是一種開發方法學，可以快速應對客戶變更的需求。它強調以人為本，采用迭代的方式，循序漸進地開發軟件。一般來說，迭代周期為1到4周，短期迭代允許項目需求頻繁的變更，產品是在每個迭代周期結束時被逐步交付使用的。在應對不斷變更的需求問題上敏捷開發是最適用的方法，所有由需求變更導致的困難和風險都會在迭代周期中得到有利的控制，并使得客戶利益最大化，團隊成員面對面的交流使得制定決策計劃比通過文檔交流要快速得多。圖2表示了整個敏捷開發過程。

從上論討論中我們可以得出Scrum過程方法和敏捷開發的優缺點比較如下：

1)短期迭代：Scrum過程的短期迭代周期為30天，每天15分鐘的Scrum例會，每個迭代過程必須在30天期限內交付。敏捷開發的迭代周期為1到4周。這兩種短期迭代都適應于需求更改頻繁的項目開發。

2)增量式開發：Scrum過程的迭代周期結束時新增了交付功能，交付的需求進入下個月的迭代周期訂單進行解決，每個Scrum迭代過程的結果可以看作是項目開發中的增量開發。同樣的，敏捷開發也在每個迭代周期產生一個已通過測試的交付軟件。

圖1 Scrum流程

圖2 敏捷開發過程

圖3 Prince2產品交付管理的步驟

圖4 SCRUM 和PRINCE2的集成

3)管理團隊：scrum Master管理整個scrum流程，主持scrum每日例會，并幫助團隊成員解決在項目開發中遇到的問題，這樣避免了迭代結束時的交付延遲的問題。敏捷方法中的團隊成員都擁有解決問題的專業知識。兩種方法都有助于項目在開發過程中避免出現混亂。

4）降低風險：短期迭代使得scrum方法和敏捷過程降低了需求變更帶來的風險。在迭代周期結束時產生的需求變更可能會導致混亂，在下一個迭代周期中會改變技術以及規則來進行調整，使得項目沒有風險的進行最終交付。這樣會使整個項目處于正確的進程上。

5)改進控制：Scrum的每日例會允許利益相關方(一般指產品負責人)參加并對項目開發提出意見，項目開發者在下一步的開發過程中參考客戶提出的意見確認更明確的用戶需求，有益于項目的發展。敏捷開發是由管理者進行控制，它的改進有以下幾種機制：(a)敏捷方法的設計，開發，測試迭代周期為企業帶來了有商業價值的小幅增量。(b)在每次迭代結束時，利益相關者審查項目已完成的工作，如果有任何變化或問題可以直接反饋到下一周期的計劃安排中。(c)越早反饋有助于項目越順利正常進行。(d)每次迭代的測試確保開發商在項目中的贏利。

6)有益的交流：Scrum和敏捷方法都提倡面對面的交流方式，每個成員都對整個項目有很好的了解，這有益于他們進行下一步工作。

7)及時交付：Scrum和敏捷方法都按時交付項目增量，這樣能保證整個項目的最終按時交付。

Scrum和敏捷開發的缺點列舉如下：

1)只適合6至12個月周期的項目。

2)開發人員40以上不適用于此類方法，因為它是否適用于40以上人員是還值得商榷。

3)這兩種方法合適于軟件開發項目，核心是人而不是過程。

4)采用Scrum是昂貴的。

5)Scrum需要培訓。

4 SCRUM和PRINCE2

受控環境中的項目(Prince2)是一種廣泛應用于公共和私人部門的項目管理方法，它是英國項目管理的標準，英國政府項目都實施此方法。 PRINCE2是基于過程的結構化的項目管理方法，在賽迪監理的四控三管一協調理論中也有所體現，它一般包括：項目準備(SU)，項目啟動(IP)，控制階段(CS)，產品交付物管理(MP)，階段邊界管理(SB)，項目收尾(CP)，項目指導(DP)和項目計劃(PL)的過程。由項目委員會來控制項目系統是否值得，計劃是否合理等要點，項目經理來確認項目如何來進行，小組經理來進行工作具體實施。PRINCE2的項目計劃是以產品導向的，也就是說項目計劃強調項目按預期交付結果，而不是簡簡單單計劃在何時該做何事。換句話說，PRINCE2使用產品分解結構。

小組經理和項目經理都與產品交付物管理(MP)過程相關聯。小組經理負責受理，執行及分派工作包，而項目經理授權，評估取得的進展，并回顧已完成的工作包。這一過程包括小組經理和項目經理分別管理的三個子項目。左邊的每個子項目直接與右邊相連，用于通知子項目結束時的進度、質量和其他問題的子項目。圖3顯示了在Prince2產品交付管理的步驟。(圖3)

從上面的圖可以看出，MP1，MP2，MP3是由小組經理完成，而CS1，CS2，CS9過程是由項目經理完成。這整個過程可以在交付工作包的時候與Scrum相結合，Scrum可以在MP2階段幫助團隊進行項目控制，從而在這個過程結束的時候交付一個高質量的工作包。Scrum過程的產品backlog相當于這里的CS1過程中從DP過程中由項目委員會編制的計劃單，Scrum過程的需求優先級排序特征和Prince2中的將工作包授權分配類似。Scrum和MP在團隊中都是交付項目的成品。MP2過程中的工作包都要執行Scrum過程的每一個工作包，在每個驗收點報告給項目經理。同時，小組經理更新質量記錄和時間表給項目經理，不同的是，在Scrum過程中這些情況會在Scrum主管主持的Scrum例會中被反饋。在Scrum過程結束時的潛在的交付增量可以比作MP3過程，雙方都提供一個完成的工作包。Scrum與Prince2的整合是由圖4表示。

同樣的，Scrum可以結合到CS過程中。Scrum可以結合到Prince2的每個工作過程中，并且將每個過程結束時的已完成工作包交付到下一個過程。在結合Scrum之前Prince2過程中的需求是可以進行任意更改的，而一旦結合了Scrum就得對需求變更提高警惕，因為Scrum過程中需求只允許在產品backlog中進行變更，只要產品backlog發展成為沖刺backlog就不再容許任何改變，這也就是為什么要根據客戶需求來對產品訂單進行需求優化級排序，最重要的需求將在第一個迭代周期解決。(圖4)

綜上所述，我們可以得到Scrum和Prince2的相同點與不同點表格如下：(如表1)

表1

5 結語

敏捷方法是一種適用于短期的、需求變更頻繁的項目管理方法，同時，敏捷項目管理對軟件項目開發有著不同的方法，每種方法都有自己的優點和缺點，Scrum和敏捷方法的優缺點也在上文中有進行討論。每個項目團隊要針對不同的項目自身的特點來選擇合適的項目管理方法，給項目提供合適的方法是項目成功的必要前提。

[1]Reed.K,Damiani.E,Gianini.G and Colombo.A(2004)Agile management of uncertain requirements via generalizations:a case study,in:Proceedings of the 2004 workshop on Quantitative techniques for software agile process,ACM Press,NY,USA,pp40-45.

[2]Parliamentary Office of Science and Technology(2000) Government IT projects,Report 200 - [Blackboard Material].

[3]Taylor.A(2001)IT projects sink or swim,British Computer Society-[Blackboard Material].

[4]Mahnic.V and Drnovscek.S(2004)Agile Software Project Management with Scrum,at http://jeffsutherland.com/scrum/FirstScrum2004.pdf/[accessed 05/05/2007].

[5]Mikneus.S and Akinde.A (2003) SCRUM an agile software development methodology,at http://facweb.cti.depaul.edu/jnowotarski/se470/akinde-mikneus pres scrum.ppt/ [accessed 10/05/2007].

[6]SE project : Methodologies amp; Techniques,at http://paul.luon.net/essays/SEP-essay-final.pdf/[accessed 10/05/2007].Tang.Y(2006)IT Project Management and Planning Handout,PRINCE2,slide no:60.