敏捷的項目管理

前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇敏捷的項目管理范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

敏捷的項目管理范文第1篇

論文關鍵詞：敏捷項目管理；適應性項目框架；極限項目管理

一、引言

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

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

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

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

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

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

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

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

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

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

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

(一)項目計劃與風險

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

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

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

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

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

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

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

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

1．需求的優先級

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

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

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

3．需求緩沖的計算

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

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

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

4．計劃的制定

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

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

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

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

敏捷的項目管理范文第2篇

團隊向敏捷的轉變

向敏捷開發轉換，管理層的支持是關鍵，而團隊的認同則決定了敏捷執行的程度和結果。這個轉換過程可以分幾步、有選擇性地在一些項目中開始。

許多企業走向敏捷是從組織培訓開始的。培訓可以是內部的，也可以聘請外部顧問，最重要的是負責培訓的講師一定要有豐富的敏捷經驗。因為敏捷開發是一種經驗科學，書本上的知識只能幫助了解，真正的掌握需要在實踐中訓練。

培訓一般從公司的管理層開始，尤其是負責開發或工程的副總裁、經理等。培訓的過程是一個認知的過程，也是一個取得管理層支持的重要步驟。開發團隊的負責人是培訓的重點。這些階段比較典型的培訓是兩天的Scrum培訓，培訓以Scrum為主，但會涉及敏捷的方方面面。

項目實施是敏捷思想落地的過程。一般應選擇在小型新項目中實踐敏捷開發，這樣可以降低風險。也有公司不得不從項目的中間開始實施敏捷開發，同樣也有很多成功的例子。一般只要有上層的支持和得力的指導，并完成一兩個敏捷周期，團隊一般會完全轉入敏捷開發的模式并不斷提高。

在實施敏捷開發的過程中，團隊的組織也是關鍵環節。敏捷開發團隊有以下兩個特點:

1. 是跨領域的平行聯合團隊，團隊中應該有來自各個平行領域的人員，包括測試人員，甚至客戶代表。目的是讓這個團隊能勝任開發周期中的所有任務。

2. 團隊的職責和功能除了日常的開發任務外，還要完成各種自我管理和組織功能。大多數的管理和決策不再由管理層單獨掌握，而是整個團隊商議決定。每個成員都要對項目管理中的范圍、時間、成本、風險等管理負責，每個成員在一定程度上成為項目經理。

課堂上的培訓對團隊來說只是個很好的開始，實踐中的指導和訓練更為重要。項目中的問題各種各樣，所以，在敏捷項目的進行中最好能由經驗豐富的敏捷顧問指導。由敏捷顧問帶團隊走完一個或幾個開發周期，幫助團隊解決、糾正敏捷實施中的具體問題，這樣開發團隊會更快地進入敏捷的思維和模式。

項目管理過渡到敏捷

開發團隊按項目管理類型來分有兩種。一類是比較正規、有不同程度的過程和方法管理的團隊。由于PMBOK在中國有很多的應用，下面主要介紹如何從PMBOK的方法過渡到敏捷。另一類是無序的或介于有序和無序之間的團隊，其管理基本依賴領隊人員的經驗，并無成型和穩定的套路。

PMBOK定義和描述了一套有關項目管理的知識體系。這套知識體系比較全面，涉及項目計劃的集成以及項目的范圍、質量、成本、風險、人力和物流等各個方面，與敏捷開發相比，PMBOK的主要不同點體現在以下方面:

1. PMBOK是計劃推動的開發，一般來說要求有大量的前期規劃和評估，而敏捷是價值推動，靠經驗來優化。

2. PMBOK重視文檔，每個階段都有正式的文檔要求，敏捷重視結果，文檔往往被認為是一種浪費。

3. PMBOK的項目管理是自上而下的命令式管理，而敏捷的管理是團隊的自我管理和經理們的服務式管理。

值得注意的是，盡管PMBOK和敏捷有以上原則性區別，但并不等于說PMBOK在敏捷開發中就沒有價值。實際上，PMBOK中的大多數知識、概念和過程在敏捷中都被用到。

在PMBOK中，項目開始前要在范圍、執行、成本等方面制定出詳細的計劃。在轉向敏捷的過程中，這些計劃并不是完全不用，而是被分散到各個短小的開發周期中了。例如，PMBOK要求項目開始前有盡可能詳細的需求，并制定正規的需求更改規范和過程。而在敏捷開發中，項目開始前只有一個關于產品的遠景規劃，產品的功能需求是在開發過程中由用戶的反饋和開發團隊反饋一起來推動并逐步明確和細化的。正式的需求文檔變成了分散的多個需求條目、功能或用戶使用案例等。至于需求變動規范，大多數敏捷方法都積極預期這種變化并把對變化的管理嵌入到每個周期甚至每天的開發過程中了。

還有一點經常被用來當做敏捷的不足，即敏捷開發不能在一開始給出項目的成本計劃，因此敏捷項目似乎無法進行成本的控制和管理，讓許多外包性的項目無法采用敏捷。而實際上，PMBOK也無法做到準確的項目成本評估。PMBOK的做法是把所有的需求細化，然后把每個最小單位的估計總和起來。這樣看似合理，但由于要對很久以后的開發作出估計，往往有很大的偏差。敏捷項目中的成本預算和管理可以用由上而下的方法。項目開始前，從總體的規劃出發，討論評估出一個大概的范圍。在每個周期開始前，團隊和用戶再對周期的成本進行比較準確的預估和管理，這時PMBOK中的由下而上的方法就完全適用了。此后，在每個周期結束時再次根據當時的狀況來調整對整個項目的成本估計。這樣的成本控制和管理往往更準確、實用。

PMBOK對時間、質量、風險等的計劃和管理可以遵循同樣的原則轉化為敏捷中的階段性計劃和管理來實施。

管理方式的轉變是比較難的一方面。PMBOK中的項目管理風格是由上而下的計劃、分配、指定、跟蹤、評估和管理; 在敏捷開發中，團隊要自我管理，計劃的制定、任務的分配、質量的管理、項目的執行等都由整個團隊協作進行。項目經理的職責是協調團隊完成這些自我管理任務，并幫助團隊排除遇到的障礙。項目經理要從命令式的管理思維轉換成服務式的思維和行為。換句話說就是，原來PMBOK的項目經理是靠自己指揮一些人完成一項任務，而在敏捷中項目經理可能更需要做的是建立一種機制使所有的人能在其中自我協調完成某種任務，項目經理主要負責維護這種機制的正常運作和不斷改進。

從實用主義走向敏捷

實用主義經常被處于無序或半無序狀態的團隊拿來標識自己。實際上，其中很多團隊也并非都沒有實施任何有序的方法，很多時候，其技術負責人會憑經驗或自己掌握的一些方法來進行管理，有的也會采用敏捷中的一些方法。這些團隊如果能和經驗豐富的顧問或其他運用敏捷比較成功的團隊交流，往往會認識到自己的局限性和離高層次敏捷開發的差距。

這些差距往往不在于敏捷的形式，例如故事或需求條目墻、站立會議等，而在于團隊的開發和應變的速度、效率和自我管理能力。一旦決定采用敏捷開發，由于這些團隊通常比較小而且沒有任何成型的包袱，也沒有擺脫固有過程的障礙，可能會更容易地過渡到敏捷開發。

總體而言，敏捷模式繼承和發展了以往的軟件工程理論和實踐，并融入了人們對于軟件開發的新的理解和理念。我們相信敏捷是為我國的軟件企業帶來高效率、高質量并促使開發團隊職業化，推動我們趕超世界軟件先鋒的一個很好的機會。

作者簡介

敏捷的項目管理范文第3篇

[關鍵詞] 制造企業 項目管理 敏捷響應

我國已經成為世界級的加工制造中心。在全球化的競爭背景下，面對跨國公司的強勢進入，我國制造業的競爭優勢和持續發展，僅僅靠低勞動力成本是不夠的。目前，我國的制造業整體上在產品的創新能力、成套能力、生產的自動化和優化水平、企業的管理和協作能力及競爭核心技術的開發等方面和國際先進水平方面還存在不小的差距[1]。更為嚴重的是多數的制造企業缺少現代化管理的理念、方法和手段，眾多的企業處于經驗管理階段。小而全、大而全的莊園式企業缺乏快速響應市場的能力，嚴重制約著企業的生存和發展。企業持久的競爭優勢和持續的發展源泉是不斷的企業創新，管理模式創新作為企業創新的一個重要方面，對我國制造企業發展具有重要的意義。一個國家如果沒有企業管理創新機制和現代化的企業管理模式，就不可能產生具有國際競爭力的現代制造業。為此，我國要適應世界管理發展趨勢，探索自己的制造企業管理模式，不斷提升制造企業參與國際市場的能力，進一步提高我國制造行業的整體競爭能力。

一、制造企業敏捷響應模式

1.企業生產經營體制的轉變

近十幾年來，信息技術的發展和企業組織結構的變化沖擊了原有的生產經營體系，推動了制造企業生產經營體制的變革。制造行業買方市場的形成，使企業由單純的經營管理領域逐漸地向服務拓展，產品越來越受到消費者個性化需求的影響。消費需求個性化增加了產品的復雜性，功能的多樣化，單一或者幾個企業難以通過簡單的聯盟來完成產品的生產。制造企業要想實現競爭中的持續性發展，必須在生產經營體制上實現一種轉變。越來越多的企業意識到實現由傳統的物流體制向先導物流與供應鏈管理方向的重要性。物流（Logistics）和供應鏈（Supply Chain）如今已經成為企業尋求長遠發展，提高競爭力的主要源泉。企業在充分利用電子商務和現代物流管理的成果，增加生產的快速響應能力。從企業的戰略角度上重視物流的再構筑和供應鏈體系上的聯盟活動，在企業發展戰略的基礎上，實現企業生產經營體制的轉變。

企業的生產體制實現了推式經營（Push Marketing）向拉式經營（Pull Marketing）的轉變。從本質上講，推式經營體制通過大量生產、伴隨大規模物流體制而實現的批量商品處理和商品的運輸，實現單位成本的下降。推式經營體制利用大規模集中生產、物流和流通庫存達到規模經濟效應。但是，在交易過程中產生的交易費用卻很大。

隨著競爭的加劇，推式經濟體制的制度安排出現了較為嚴重的缺陷，同時，市場環境在消費者需求行為的變化、流通格局的變化和產品生產線的融合與經營網絡的形成等幾個方面的變革催生了企業生產經營理念從強調以正確的價格提供正確的商品過渡到提供正確的價格（right price）、提供正確的商品（right commodity）、在正確的操作成本（right cost）前提下，以正確的時間（right time）送到正確的地點（right place），實現依靠的是商流、物流、信息流和資金流的完美結合的拉式生產經營體制。拉式生產經營體制強調市將銷售地點信息同步的傳輸給商品策劃、設計、生產以及庫存地點，通過銷售地點的信息設計、生產、物流和經營決策。

2.業務外包格局的出現

實現項目產品的大批量和個性化，關注質量、完工時間和縮短項目的生命周期是制造企業現階段的重要任務。在這種情況下，制造企業的規模趨于小型化，在保證核心及增值流程事業領域的基礎上，減少非核心業務，增加對于市場的敏捷響應。

業務外包已經成為制造行業的一種重要的形式，其特點是業務流程中的動態聯盟和供應鏈上的協同。從系統的角度來看，動態聯盟實質就是一個系統，通過系統的優化實現供應鏈上成本的不斷降低。通過信息化平臺實現跟蹤消費的個性化需求，提高敏捷響應的能力。系統的動態性決定了制造企業敏捷的特性。

3.敏捷響應模式

生產經營體制的轉變使企業的視角轉向銷售導向，業務外包格局的出現加強了企業之間的協同，實現發展戰略和靈活生產經營形成敏捷響應模式。制造企業的市場敏捷響以核心競爭能力為基礎。通過信息化平臺，總裝項目產品在虛擬企業范疇內進行。制造企業敏捷響應實現的基礎――項目團隊在不同產權主體形成的動態聯盟中成為基礎的單元。敏捷模式的核心――項目團隊不僅僅是制造計劃的執行者和制造信息的快速響應者，還是大量制造實時信息的集散地。這些制造實施信息的快速采集、傳遞和利用的效率體現敏捷能力，在很大程度上決定了企業的生產進展、上市時間、生產成本、生產質量等關鍵目標，決定了企業對于市場的整體響應能力。

圖1顯示了聯盟制造企業與項目產品對應的結構圖。項目團隊在項目辦公室的領導，既要符合動態聯盟，又要符合制造企業公司層面戰略需要，具有虛擬性和繼承性[4]。美國著名的科學家David I. Cleland指出，在應對全球化的市場變動中，戰略管理和項目管理將起到關鍵性的作用[2]。在20世紀90年代提出的企業項目管理和項目組合管理正是項目管理理論和方法在企業中應用的一種體現。結合圖1，在動態聯盟中，以項目團隊運作的方式把項目訂單當作項目進行運作形成制造企業項目管理運作模式，在一定程度上實現敏捷響應。

制造企業項目管理是一種敏捷模式下制造企業運作的基礎，它拓展了傳統的項目管理理論，集成其他先進管理模式形成的面向整個項目產品供應鏈的戰略，以提供客戶個性化需求產品為宗旨，通過跟蹤虛擬產業鏈上主制造企業總裝項目產品的生產計劃，實現企業對于需求的敏捷響應，通過按項目進行管理，實現產品成本、交貨期和質量等因素的集成以及項目組合資源分配，以達到資源的優化、降低成本、縮短功能集成單元的生產周期，從而整體上提高總裝項目產品上市的時間。

二、制造企業敏捷響應模式框架與知識體系

1.敏捷響應模式框架

制造企業的敏捷響應，就是企業建立能夠對外部市場環境能夠做出快速響應的組織結構和戰略規劃，通過改造傳統的生產模式來增加對于市場的快速響應能力。敏捷響應不僅僅是一種戰略上的敏捷，更是一種作業層面的敏捷，這兩種敏捷通過柔性化的組織結構實現。如圖2所示：

從戰略層面，從企業發展的戰略出發，通過項目的優選評價，確定項目的優先級。

從企業作業層面上，實現項目時間、成本、質量、設備利用率和員工安全度等目標的集成控制。

從企業作業層面上，進行項目的組合管理實現企業多項目資源分配的優化。

通過以上的分析我們可以看出，制造企業項目管理圍繞作業層面展開，通過改善生產流程，優化過程管理，提高企業敏捷響應能力，實現敏捷響應戰略。

2.敏捷模式知識體系

敏捷模式下制造企業項目管理注重人的因素、顧客、柔性、變革。本文認為，敏捷模式下的制造企業項目管理知識框架包含以下五個要素：項目管理目標、項目管理組織、項目管理信息系統、項目管理系統方法和項目管理文化。

(1)項目管理目標

項目管理目的是在企業敏捷戰略指引下制定企業項目管理目標，即企業項目管理者的著眼點應以企業戰略目標的達成為指導，而非局限于作業層面的“項目交付”。企業的戰略目標是一種成果性的目標，比如持續的發展和企業績效的提升等等。

(2)項目管理組織

項目管理組織是維持持續不斷的企業管理活動，是項目成功實施的必要條件。項目管理組織的重要特征是柔性化。

(3)項目管理信息系統

信息系統通過優化整個信息流程，在合適的時間把合適的信息傳遞給需要信息的人員，這些信息包括項目管理理論與方法的管理支持信息，企業自身及其外部可以提供支持的信息，是一種全方位立體性的信息網絡。

(4)項目管理系統方法

制造企業的發展需要關注各個利益的相關體、接近顧客群體，影響企業經營的因素越來越多，系統的觀念對于企業經營的影響日漸顯著。分析研究各要素之間的相互聯系，需要從系統整體的角度進行優化經營。

(5)項目管理文化

企業文化要做相應的調整以適應企業戰略項目管理的要求，形成統一標準化的語言，以使企業項目管理融入企業戰略、戰術決策及各項活動之中，成為員工一項自覺的行為。

敏捷模式下制造企業項目管理知識框架如圖3所示。

三、制造企業敏捷響應模式關鍵技術

圖2可以看出，制造企業敏捷響應模式解決、作業層面的單項目多目標集成、項目組合資源優化和公司戰略層面的項目優選評價。

1.單項目多目標集成

項目訂單中涉及成本、質量、交貨期、設備利用率和員工安全度五個方面的目標構成一個系統，目標的完成是一個系統集成優化的過程。作業層面的多目標集成管理包含主動控制、被動控制和項目評估三個方面的內容。本質上看，多目標集成管理是一種多目標決策，由于目標的不可公度性，可以通過多極模糊評判法找到各因素的相對權重實施控制。

2.項目組合資源優化

資源的有限性促使企業不斷的提高資源利用的效率。項目資源的優化通過釋放關鍵資源，降低項目組合中單個項目占用資源的無效時間。

3.項目優選評價

在敏捷響應模式下,保證項目的組合能夠綜合有效的利用企業的資源。因此，確定項目執行的優選次序是制造企業項目管理的關鍵工作。項目評價標準直接影響到項目的優先順序，進而影響到項目執行的順序。對企業待選項目進行評價排序將保證實施的項目與企業敏捷戰略緊密相連，項目優選順序的確定也將影響到企業的持續發展。因此，科學實用的項目組合優選評價體系將是項目組合管理和制造企業項目管理成功的重要保證。一般地，需要從與企業戰略的協同程度、競爭優勢、降低運營成本、滿足客戶的需要或期望和對企業的價值貢獻幾個方面出發進行評價。

四、結語

項目管理作為一種近些年發展起來的一種新的管理模式，已經成為制造企業應對激烈競爭的市場環境的一種有效的方法。從戰略的角度，通過戰略管理和項目管理的結合的制造企業項目管理將成為企業實現持續發展，保持核心競爭能力的必經之路。這一模式的深入研究和應用將有助于實現組織、技術和人三者的有機結合，有效的應對制造企業面臨的激烈競爭。

參考文獻：

[1]戴勇馬萬太:生產過程數字化管理[M].科學出版社，2004年第一版

[2]Yang Xiaoyuan，Song Guanxing. On the intelligent evaluation system for agility of enterprises. In∶Proceedings of 1st International Conferenceon Engineering Design and Automation,EDA’97,Bangkok Thailand,1997, KY40026 USA∶Integrated Technology Systems Inc,1997

敏捷的項目管理范文第4篇

敏捷開發強調以人為本，認為面對面溝通是軟件項目成功的一個重要因素。

當我詢問一個研發經理關于敏捷開發所需的工具時，他開玩笑地說，一張白板和兩杯咖啡。這也反映出開發人員對于敏捷方法的普遍認知。

事實上，許多開發項目主管雖然認同敏捷開發所強調的快速反應和溝通的理念，卻擔心它的“雜亂無章”帶來的“不安定因素”。因為它極度地強調人的因素，使得人員的素質對敏捷團隊的影響，遠比對其他團隊更大。

舉例來說，配對檢入是個保證代碼質量很好的方法。但編程人員不了解其重要性，可能為了進度，常常一個人草草就檢入了。因此，在采用敏捷方法時，若能適當地使用工具來保存累積的知識并固化關鍵過程，必能使敏捷項目更加成功。我們試以敏捷開發的幾個主要特點為例，探討工具在敏捷開發中扮演的角色。

特點一:測試驅動開發

傳統的瀑布方法先編碼再測試，等到發現需求和設計上的問題，為了節省費用，常常不了了之。測試驅動開發是在需求產生后，設計模塊和其之間的接口，并將單元測試代碼完成。在此過程中，需求和設計上的偏差將會被發現。由于編碼尚未進行，只需更改需求和設計即可，避免造成太大浪費。

特點二:簡單設計

敏捷開發崇尚簡單的漸進設計，而不是劇烈的顛覆式設計。其目標是首先只設計我們所了解的那些部分，然后使該設計隨著時間的推移而逐漸改進，這有助于提高靈活性并將變化導致的成本最小化。

特點三:配對編程

盡管兩人一組的配對編程從理論上看使眼前目標和長遠目標都得以保證，這卻是敏捷方法中備受爭議的做法，反對者普遍認為它會導致耗時加倍。廣義的配對編程也包括前面提到的配對檢入(Pair Check-in)，也就是由兩人一起檢驗代碼的正確性，然后才檢入。

特點四:小型

周期短可使對項目的評估提前，進而降低了風險性。但這所帶來是大量的可執行文檔，造成管理上的困難。

工具所扮演之角色

現在讓我們以一個典型的敏捷團隊DevAgile為例，看看該如何用工具實現其敏捷過程和設想（圖1）。Smart先生是DevAgile團隊的項目經理，他被要求在開發過程中體現我們以上所列的幾方面特點，在配對編程方面還要求配對檢入。

圖1 工具對敏捷開發的支持示例

角色1:需求管理的利器

對項目需求和設計文檔的管理是DevAgile必須首先面對的問題。他們要完成的，恰恰是一個需求變更很快的項目，這也是他們選擇敏捷開發的重要原因。在敏捷開發中，需求的變化常常是為下一次迭代提供信息和進度計劃的依據。

因此，DevAgile的大多數成員認為，記錄下每一次關鍵的需求變更很重要，盡管最初有些人堅持敏捷開發并不需要文檔。

同時，他們也注意到，要遵循簡單設計的原則，并非意味著設計文檔不需管理。相反，文檔的數量和版本都會比采用其他開發方式更多。這些設計文檔及其歷史應該被妥善地管理，也要和相對應的配置項鏈接。

另外，小型意味著整個生命周期中有更多的，如何對這些進行系統化管理也是DevAgile團隊必須解決的問題。

綜合以上這幾點考慮，Smart先生認為，應該找到一種需求管理的武器。DevAgile團隊在進行了一番市場調研后，決定嘗試TechExcel DevSpec這種需求管理工具。它不僅提出“以知識為核心”的概念，滿足需求和設計文檔管理的要求，還實現了真正的“功能驅動開發”。

盡管DevAgile目前沒有清楚的看到后者如何實現，但DevSpec對產品需求、產品功能及知識文檔的系統管理還是吸引了他們。

它成全了設計團隊的敏捷性，支持簡單設計，并對他們經常修改設計的做法提供了管理上的幫助。一些成員還指出，在敏捷開發的道路上，太多的不確定因素和靈活性難免會影響大家對最終產品的認識，有一個這樣的工具能夠時時刻刻描繪出要產品的清晰輪廓，記錄下產品需求和功能變更的每一步，實在是很令人欣慰。

另外，為了配合數量多的小型，DevSpec還有整理功能點的能力。也就是說，將和某一有關的新功能、功能變更，以及缺陷修復，全都進行統一組織和管理。

例如，要完成6.1的，他們只需把6.1功能文件夾里所有的新功能、功能變更，以及缺陷修復全都做完，6.1版本也就可以了。為了更大程度上提高開發效率，Smart先生還別出心裁的對這些功能及缺陷設定了優先級，優先級低的任務可能被延緩執行。實踐證明，這種具靈活性且針對來管理的系統使小型越發容易。

角色2:項目規劃的利器

Smart先生發現敏捷的項目管理要能做到隨機應變，應付各種可能出現的情況，也是建立在對任務的細分，并對任務的狀態采取高頻度的探測并及時調整的基礎上。DevAgile選擇了TechExcel DevPlan作為項目規劃工具，因為它能夠圍繞DevSpec中管理的功能點進行迭代計劃，對人力資源進行管理，既把握了正確的宏觀方向，又能對任務細分。任務若被耽延，還可以反饋回來。

Smart先生認為，作為敏捷團隊的項目經理，他應該從傳統項目經理的“工頭”身份中解脫出來，發揮他的領導力，去監控和協調開發過程。雖然項目經理還是必須定義和初始化項目，作項目計劃，執行計劃，監督并控制結果。

但是完成這些步驟的方式卻是不同的。具體來說，敏捷項目的計劃不再是詳細的完整的項目實施步驟和資源分配，而更多的表現為一種迭代計劃。在開發人員與客戶或其他團隊溝通的每一次迭代中，計劃和資源分配隨時可能被調整，以不斷適應項目進展的需要。在DevPlan的幫助下，這種調整變得方向明確、清晰和有據可查。它將每一次迭代的框架確定下來，剩下的工作就是根據這個框架實施了。

角色3:測試管理的利器

有了DevPlan，測試計劃和開發計劃開始制定，項目在一種既有序又敏捷的機制下運有序地轉著。為了實現“測試驅動開發”，DevAgile不可避免的遇到了測試管理的問題。他們注意到，需求管理工具DevSpec內的需求，可被直接導入測試管理工具TechExcel DevTest，并自動生成測試任務。所有測試任務可以遵照既定的工作流執行，保證測試工作的有序開展和管理，并在編碼之前發現設計偏差。

另外，他們以往是用光盤來存儲可執行版本，文件柜的每一個抽屜里都裝滿了光盤。在進行敏捷開發以后，光盤的數量更是與日俱增，要找某版本的光盤時，多半是很困難的。

DevTest能夠保存和管理的軟件版本，而且和DevSpec內的功能及缺陷文件夾相對應。也就是說，若在需求管理工具DevSpec內有個6.1功能文件夾，那么在測試管理工具DevTest中也有個相對應的6.1文件夾。這顯然比用其他方式來存儲軟件版本更加科學和方便。

角色4:任務執行的利器

有了以上這些項目管理的利器之后，DevAgile團隊的工作并非一帆風順，因為新的問題又出現了:一些成員片面的認為敏捷開發是一種松散型開發模式，也就是不需要遵守固定的流程。這直接導致了很多開發任務的執行效果糟糕，有些任務被提出以后就失去了蹤跡，就連Smart先生也難以追蹤每一個任務的結果。

于是，DevAgile團隊又引入了與DevSpec和DevTest可以集成的DevTrack。這是一個開發任務的跟蹤管理工具，提供既固化又可靈活更改的流程，對每一個任務的生命周期進行嚴格管理。它保證該走的過程一定走過;該反饋的一定反饋;該提醒的一定提醒;若任務需被升級，那就一定會被自動升級。更令人興奮的是，當任務完成之后，其結果會自動返回需求管理工具DevSpec或測試管理工具DevTest。Smart先生可以輕易地由DevSpec看到針對6.1版本的所有功能和開發任務是否全部做完，對的管理省時省事。

直到實施了任務執行管理工具DevTrack，Smart先生才逐漸認識到由DevSpec引導的“功能驅動開發”是如何實現的。DevPlan中的迭代計劃、DevTest中的測試任務和DevTrack中的開發任務，都是圍繞DevSpec中的功能展開的。這不僅使整個敏捷過程都嚴格圍繞最終產品進行，而且其中的可追溯性和可核查性，也正是敏捷開發思想的有益補充。

現在，當項目成員在會議室和用戶討論得熱火朝天的時候，Smart先生可以悠閑地在電腦前喝咖啡了，他知道整個過程都是可以控制的，需求和設計變化再多再大，經歷再多的迭代和小型，只要所有功能都按照計劃被開發和測試，項目還是會如期完成。

敏捷團隊的成功案例總結

毫無疑問，DevAgile團隊最終用敏捷開發方式取得了項目成功。讓我們再來總結一下，他們是如何具體做到的呢？首先，需求被搜集和整理，產品功能和簡單設計產生，將這些結構框架和相關文檔存入DevSpec之后，開始制定迭代計劃，并定義模塊接口。緊跟著，針對接口做出測試代碼。這些知識文檔全由DevSpec來管理，因此DevSpec中形成了由需求、功能和知識文檔組成的“概念產品”。

最后，功能點被導入DevTest而產生一個或多個測試任務，每一個測試任務都能按照DevTrack中定義的工作流（圖2）進行。

圖2 DevTrack中定義的測試任務工作流示例

圖2的工作流被啟動之后，編碼人員在第一狀態負責編寫代碼、重構和白盒測試。項目經理為了實現配對檢入，把第二狀態設為需有A和B兩人一起檢入的“配對檢入”。每一個狀態都有明確的負責人。A可以是第一狀態負責人，而與A配對的人員則可以是跟A 所做的任務有關的人員。第三狀態負責人可以是測試人員，在單元測試成功后便完成了整個流程。反之，則重新回到第一狀態。

以上的案例中，對所提到的四個敏捷特點都有所注解。當然，這是一個可行的方案，而絕非唯一。

另外，面對面溝通也是個很好的敏捷操作，但是實際上卻不易實現。客戶或熟知商業邏輯的同事通常是無法長時間和開發設計人員在一起工作的。若一定要面對面，很可能會以高昂的費用為代價。更實際的方式是通過一定的溝通平臺（如一些即時語音或視頻通訊工具）來達到類似面對面的溝通。

無論采用何種方式，溝通后的結果都要能妥善地記錄下來。知識的分類和歷史的記錄會使清晰度達到最高，進而使后來的一切活動，包括編碼、測試、分析等，都變得容易。

敏捷的項目管理范文第5篇

1.1方法

對照組行傳統護理，觀察組行項目管理法，具體措施如下:

1.1.1科室中組成“智能團隊”:由療養護理經驗豐富、反應迅速、思維敏捷的護理人員為團隊成員，通過有效溝通對老年療養院住院期間的安全隱患進行溝通，制定項目管理計劃并對各部門、相關人員責任加以明確，制定詳細實施方法［2］。經討論，老年療養院住院期間的風險因素包括療養員因素、環境因素、護理人員因素、護理管理因素等內容。

1.1.2制定管理目標與具體實施:

①制定并不斷完善規章制度:以老年療養員特征與護理工作特點制定合理到了管理目標，積極探尋存在的風險并制定護理質量評價標準，對考核標準予以細化。建立療養員跌倒墜床評估表和療養員意外風險評估表，及時填寫評估表，對于評分高者，護士給予重點關注、重點巡視，制定護理質量監督機制并加強監督、考核，實行彈性排班制度。

②不斷增強專業素質:定期展開專業知識培訓，通過板報、觀看宣傳片、標語等加大護理安全宣傳力度，鼓勵護理人員參與學術交流，不斷提高其專業理論知識掌握程度，增強其安全意識。新上崗護理人員應給予充分崗前培訓，增強其和療養員溝通的技巧，待各項考核均合格后才可上崗。

③創造舒適的療區環境:療養房間應保持整潔、舒適溫馨，溫度及濕度應適宜且應保證空氣流通］，為療養員營造家的氛圍。入院時詳細介紹療養房間內的設施，房間設計合理，物品擺放整齊。衛生間設有安全扶手，做好防滑標識張貼、防滑墊安裝等，為療養員安全提供最大限度保障］。

④對療養員展開全面健康教育:護理人員保證儀容整潔大方，以親切和藹的態度主動為療養員講解醫院環境，根據療養員性格、家庭背景、職業、學歷展開針對性的健康教育，同時給予有效的心理干預。護理人員要對隨員介紹療養員用藥指導、飲食指導、運動指導、養生保健知識及療養期間的注意事項等，增強其養成健康的生活方式和行為。

⑤提高護理人員責任意識:護理人員應主動引導療養員逐步熟悉醫院環境，耐心講解各項設施使用方法及效果，建立和諧的護患關系，給予療養員充分的尊重與關懷。對療養員疑問應耐心解答，同時應針對老年療養員不安全因素制定意外風險防范措施、預防跌倒措施，減少突發事件，在應對突發事件時具備相應的應急能力。

1.2觀察指標

設計護理滿意度調查表對療養員關于護理工作的滿意情況進行分析，包含6項內容，分為滿意、很滿意、需改進3個等級，同時記錄兩組護理糾紛、跌倒等發生情況。

1.3統計學方法

以SPSS16.0軟件對數據進行分析，計數資料行χ2檢驗，等級資料采用兩獨立樣本的Wilcoxon秩和檢驗檢驗水準=0.05。

2.結果

2.1兩組護理效果比較

2.2兩組療養員對護理服務滿意度比較。

3.討論