論軟件項目管理的創新模式軟件項目管理論文發

　　論文摘要：敏捷項目管理的概念來源于敏捷軟件開發。隨著敏捷軟件開發的發展，極限項目管理(也稱為極端項目管理ExtremeProjectManagement或RadicalPro—jectManagement)和敏捷項目管理(也稱為靈活的項目管理AgileProjectManagement)的概念和方法被相繼提出，并仍在不斷發展。實際上，敏捷項目管理只是各種敏捷軟件開發方法相應項目管理的統稱，只針對于軟件項目，并不是一種通用項目管理方法(也有人提出敏捷項目管理的通用概念，但未被廣泛接受)。本文首先探討了敏捷項目管理的起源及其適應性項目框架;并論述了其在軟件項目中的應用。然后對適應性項目框架的計劃制定對比極限項目管理作了詳細的闡述。本文選自《計算機科學》。《計算機科學》由國家科技部主管，國家科技部西南信息中心主辦，系“中文科技核心期刊”、“中國科技論文統計與分析用期刊”、“中國科學引文數據庫來源期刊”、“中國期刊方陣雙 效期刊”、“中國計算機學會會刊”、“重慶市優秀期刊”。　　《計算機科學》雜志于1974年1月經中華人民共和國新聞出版署批準為公開發行期刊，原刊名為《計算機應用與應用數學》，1979年1月更名為《計算機科學》。主要報導國內外計算機科學與技術的發展動態，涉及面廣的方法論與技術，和反映新苗頭、能起承先啟后作用的研究成果。　《計算機科學》歷年總被引頻次和影響因子兩項指標均列全國(計算技術類)前列，是國內頗具影響力的計算機學術刊物。雜志報導特點是“前沿學科”與“基礎研究”相結合;“核心核術”與“支撐技術”相結合;“倡導”與“爭鳴”相結合。廣采百家之長，博覽計算機世界之態勢。《計算機科學》以其新穎、準確、及時為特色，突出動態性、綜述性、學術性，深受高校教師學生好評。

　　論文關鍵詞：敏捷項目管理;適應性項目框架;極限項目管理,計算機科學

　　一、引言

　　軟件開發中既有高風險、高變化的項目，也有目標明確、解決方案明了的低變化項目。根據不同的項目特點，選用不同的項目管理方式是項目成功的關鍵。敏捷項目管理是應對經常變化的、具有不確定性的軟件項目的管理方法。敏捷即靈活性，是動態的、適應于具體情況、迎合變化和自我完善的。本文針對敏捷項目管理中的極限項目管理和適應性項目框架的軟件應用對比傳統項目管理進行探討，并提出了適應性項目框架的改進和計劃控制的一些建議。

　　二、敏捷項目管理的概念及起源

　　敏捷項目管理的概念來源于敏捷軟件開發。隨著敏捷軟件開發的發展，極限項目管理(也稱為極端項目管理ExtremeProjectManagement或RadicalPro—jectManagement)和敏捷項目管理(也稱為靈活的項目管理AgileProjectManagement)的概念和方法被相繼提出，并仍在不斷發展。實際上，敏捷項目管理只是各種敏捷軟件開發方法相應項目管理的統稱，只針對于軟件項目，并不是一種通用項目管理方法(也有人提出敏捷項目管理的通用概念，但未被廣泛接受)。極限項目管理和適應性項目框架皆源于對DougDe—Carlo于2000年發布的彈性項目模式(FlexiblePorjectMode1)的改編。而彈性項目模式又來自于敏捷軟件開發中的自適應軟件開發方法學的啟發。現在二者已經發展成為一個通用的項目管理理論。極限項目管理適合于變化大、復雜程度高的項目。傳統的項目管理則適合低變化、低不確定性的項目。而在二者之間是適應性項目框架。雖然所有的敏捷軟件開發方法都被認為是屬于極限項目管理的范疇，但從最近的敏捷軟件開發的發展可以看出有些敏捷方法并不全屬于極限項目管理的范疇。而且極限項目管理往往由于過于激進，顯得不夠實際，并不能被高級管理者特別是CIO所接受，且在大型項目中也無法得到有效論證。現在的敏捷項目管理研究大多有轉向適應性項目框架的趨勢。所以，雖然敏捷項目管理通常指的就是極限項目管理，但它被認為應是包括極限項目管理和適應性項目框架兩部分的軟件項目管理的統稱，極限項目管理又是適應性項目框架的特例。

　　三、敏捷項目管理的適應性項目框架

　　通用適應性項目管理框架是以客戶為中心、客戶驅動的管理方法。極限項目管理是處在比適應性項目框架更復雜，更不確定的高變化情況下的一種管理方法。二者區別在于，適應性項目框架是針對有明確的目標但沒有解決方案的項目，而極限項目管理則是針對兩個方面都很模糊的情況下的探索式的方法。適應性項目框架只要求客戶在每個迭代周期的實施結束后參與項目，而不是全程參與到項目中。

　　適應性項目框架主要分為定義項目范圍、制定項目周期計劃、項目實施、客戶檢查、項目后回顧五個階段(圖1)。

　　其中項目范圍包括項目滿意條件、項目概況說明書、功能要求優先排序、中層WBS等。中層工作分解結構只是分解到功能級，而不是任務級，只要可以比較確信地估計每一段功能所需的時間和資源就已足夠。因為對于經常變化無法預計的任務，編寫完整的WBS完全是浪費。制定項目周期計劃是將要進行的下一個周期的詳細計劃，是帶有依賴關系的任務層次的詳細實施計劃。項目實施階段包括制定微觀進度計劃、實現功能、監督并調整實施進度。在這個階段，取消當前周期和調整計劃都是可以執行的，可以減小和避免損失。通過中間三個階段的反復進行，最后可以實現客戶滿意的解決方案。

　　然而適應性項目框架并沒有指出當項目出現變化時，如何在時間成本有限的情況下有效完成任務。它還是沿用極限項目管理的方法，制定詳細的周期計劃，必要時拋棄部分要完成的功能。區別是增加了中層的項目計劃。中層項目計劃根據時間限制范圍內，能夠容納多少迭代周期，并根據特定周期內子功能的數量和質量調整周期時問。雖然也有風險分析，但是并沒有在框架內體現并整合到項目周期中。如果根據這個計劃確定項目的交付日期，則當變化發生時，很容易陷人傳統項目管理的困境，即使采用迭代過程，也很難按期交付。迭代過程唯一能做的就是使變化或風險提前出現，而在以后的迭代周期改進，通常趕進度的方式是加班或者增加資源，這會使成本增加。而且質量的改進也是此類項目的一個不確定因素，這也需要時間和成本。如果低質量的產品延續到項目后期，則由于變化產生的時間和成本的消耗可能是致命的，也會增加維護的成本。適應性項目框架并沒有考慮質量改進過程，而且忽視了初始迭代周期的作用。初始迭代周期完成后是調整計劃的最佳時期，因為它是實際情況的真實體現，即使以后的迭代周期的實際情況會和初始周期有所偏差，但也不會過于偏離，而且隨著迭代的進行，不確定性會減少。所以好的計劃是使收益得到保障的首要因素。對適應性項目框架的軟件應用改進主要是在過程中強調了風險管理和質量管理，并修改了計劃部分，并著重強調了初始周期的作用。影響此類項目完成的最大的風險是需求變更造成的返工成本、時間消耗，需要靠風險緩解和質量控制來共同管理。所以，改進的重點在于適應需求變更。

　　軟件開發項目的適應性項目框架。

　　主要增加了風險緩沖后的基準計劃、功能需求變更周期和質量改進周期。功能需求變更周期和質量改進周期是歷時比較長的足夠影響進度的活動。功能需求變更周期是由于業務需求變化導致的，可能是特定功能完全重新實施或者改進的過程。質量的改進周期區別于在功能需求變更周期的工作，這是在一定時期后，內部人員根據已完成項目功能的學習和經驗總結進行的重新設計，改進已完成工作的質量，或為了適應變化所做的技術改進。風險緩沖后的基準計劃是在中層計劃基礎上增加了風險緩沖的時間，包括功能需求變更周期和質量改進周期的預估時間。分離實施周期和修改周期是因為實施周期的時間和成本的預估是比較準確的，但修改周期的時間和重復次數卻難以預測。在兩個迭代周期的外圍是個質量改進周期，表明在多個功能周期后進行質量改進。在改進前，需要評估改進的風險，作出權衡。這個周期結束后的產品被認為是一個非完全功能的發布版本。每個迭代周期還是和適應性項目框架中的一樣，包括周期計劃、實施和客戶檢查。另外一個區別是適應性框架只要求客戶在客戶檢查點上參與，而這里要求全程參與，至少應在項目的前期階段全程參與需求分析，目的是在一定程度上穩定需求，如果已經完成的功能再出現需求修改，付出的成本和時間將會大得多。如果出現了范圍的變更則和客戶協商調整基準計劃。

　　四、基于敏捷方法的軟件項目管理的計劃與實施

　　(一)項目計劃與風險

　　由于項目過程由傳統的詳細的需求計劃的單一過程變成短的時間區間的具有反饋的多次迭代過程，并且為了對變化具有適應性，敏捷項目管理的計劃方法分成詳細周期計劃與風險計劃和質量計劃結合的兩種分層計劃。

　　項目中的風險分為兩種，一種是必然要發生的常規風險，一種是不確定的致命風險。前者可以通過風險緩解解決，后者則需要風險緩解和風險轉化共同解決。在變化陛比較強的軟件項目中，需求變更必將發生，這是軟件項目所面臨的主要風險，計劃中加入需求變更周期的緩沖時間可減小項目的成本風險。

　　(二)極限項目管理計劃與時間預測

　　極限項目管理是一個無基準計劃的過程，沒有時間和成本的限制，利用數量不定的短周期不斷迭代，最終完成項目，或者在完成前，項目就被取消。傳統的項目管理計劃方法在此時起不到太大的作用，一般采用跟蹤團隊的開發速度和剩余的功能點來進行管理，只制定迭代周期內實施的計劃。

　　圖3是Bum—down圖，顯示的是每個月后剩余的功能點數目。虛線1是要在12月完成的項目的計劃線，虛線2是實際工作后的趨勢線，這表明可能完成的日期。2月剩余的功能點多于初始點，是因為增加了新的功能。可以看到這并不能確定交付的日期，只能作為參考。.

　　(三)基于敏捷方法的軟件開發計劃

　　極限項目管理在某些極端的情況下確實很有效，比如新技術產品的研發。但是大多數軟件項目的技術復雜度不是很高，或者曾有過類似的項目經驗，項目的主要不確定性是業務需求的變化等，并受到時間和成本的限制，這些項目的重點是得到反饋并改進。

　　在這種情況下還需要預估時間，并制定相應的計劃實施。軟件項目由于成本與開發人員的多少和開發持續周期密切相關，所以時間通常是軟件開發項目的一個重要衡量指標。使用改進后的自適應項目框架，利用需求優先級的功能排定和需求成熟度分析進行時間緩沖，可以很好地適應這種狀況。

　　1.需求的優先級

　　根據客戶的要求排定功能的優先級。將有則更好，沒有也不影響系統實用性的功能放在最后實現，是時間緊迫項目通常采用的方法。在進度延期的情況下，舍棄這些浮華的功能，可以確保項目按期完成，也可避免項目因增加了一大堆客戶要求的功能而陷人遙遙無期的悲慘境地。

　　2.需求的成熟度(見表)

　　需求的成熟度指的是需求的穩定程度。由于軟件項目的范圍通常是變化的，與客戶洽談并確定各個功能的需求成熟度并列表，既可以了解客戶對新業務需求的理解程度，也是在需求變更時和客戶談判的依據。需求的成熟度越高，需求的變化程度越低，對需求變化的緩沖也就越小。變化的時間損耗指的是相對于功能實施時間的百分比。因為對原有功能的變更通常會利用已有的模塊，相對時間較短。變化的次數是指決定變更迭代周期的實施次數。

　　3.需求緩沖的計算

　　變化的權值=變更的時間損耗比x變化的次數;

　　功能的需求變更時間緩沖RAT=功能的實施時間x變化的權值;

　　每個功能變化的權值為變更的時間損耗比乘以變化的次數。用此功能的實施周期預估時間乘以變化的權值則得出每個功能的需求變更的可能損耗的時間。將每個迭代周期內所包含的功能的需求變更時間相加，則得出了此迭代周期的需求變更時間，即需求變更周期的時間之和。

　　4.計劃的制定

　　計劃時首先確定出項目范圍后，創建出中層WBS(工作分解結構)，并以此確定項目功能的優先級，并根據風險分析確定每個功能的變化權值。確定好每個迭代周期時間，并根據總時間、成本的限制和功能優先級制定好功能的實施迭代周期數量及相應完成的功能制定計劃。將功能需求變更周期和質量改進周期也考慮到計劃中。由功能變化權值、功能實施周期時間和迭代實施周期內的功能數量決定的總的功能需求變更周期的時間，將時間緩沖合并人計劃中。

　　確定功能周期及修改周期重復的次數定期進行質量改進，一般是3到6次功能周期后進行一次質量改進，改進的具體內容則是實時制定。如果采用的是全程客戶參與的方法，則需求成熟度會隨著項目的進行趨于穩定，后期實現的功能可不設定需求變化的緩沖時間。由于大多數軟件應用開發的變化沒有在極限項目中的劇烈，即使增加了新的功能，修改非任務級的中層計劃也比較容易，而且變更只在用戶檢查階段實施。大多數情況下，在項目緩沖允許范圍內的延遲不需要調整計劃。Bum—down圖可作為一種輔助的管理方法。在短的時間周期內(一般是兩周到五周)，項目可以認為是低變化的，所以可以制定好將要進行的下一個迭代周期的詳細計劃。周期詳細計劃由于時間周期比較短，可不用關鍵鏈法。

　　由于軟件開發項目的大多數模塊都可以并行開發，并行的限制只受限于開發人員的數目，并且周期的時間都很短，所以在周期詳細計劃中使用關鍵路徑并不能收到預期的效果，在項目實施中可應用的是關鍵鏈的項目緩沖機制。

　　由于敏捷項目管理的迭代性，根據已執行完的第一個迭代周期或前幾個周期，可測量出比預估更有效的開發速度，可判定預估的準確度，從而調整基準計劃。

　　五、結束語

　　敏捷方法在軟件項目管理的采用確實提高了軟件開發項目的成功率。但研究剛剛開始，仍然處在未成熟階段。如何對經常變化的不確定性軟件開發項目進行有效的敏捷管理仍是一個需要完善的課題。