摘 要：本文首先探討了敏捷項目管理的起源及其適應(yīng)性項目框架；并論述了其在軟件項目中的應(yīng)用。然后對適應(yīng)性項目框架的計劃制定對比極限項目管理作了詳細(xì)的闡述。

　　一、引言

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

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

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

　　三、敏捷項目管理的適應(yīng)性項目框架

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

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

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

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

　　軟件開發(fā)項目的適應(yīng)性項目框架如圖2。

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