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

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

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

一、引言

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

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

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

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

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

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

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

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

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

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

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

(一)項目計劃與風險

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

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

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

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

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

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

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

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

1．需求的優(yōu)先級

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

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

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

3．需求緩沖的計算

變化的權(quán)值=變更的時間損耗比x變化的次數(shù)；

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

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

4．計劃的制定

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

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

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

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

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

團隊向敏捷的轉(zhuǎn)變

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

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

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

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

在實施敏捷開發(fā)的過程中，團隊的組織也是關(guān)鍵環(huán)節(jié)。敏捷開發(fā)團隊有以下兩個特點:

1. 是跨領(lǐng)域的平行聯(lián)合團隊，團隊中應該有來自各個平行領(lǐng)域的人員，包括測試人員，甚至客戶代表。目的是讓這個團隊能勝任開發(fā)周期中的所有任務(wù)。

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

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

項目管理過渡到敏捷

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

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

1. PMBOK是計劃推動的開發(fā)，一般來說要求有大量的前期規(guī)劃和評估，而敏捷是價值推動，靠經(jīng)驗來優(yōu)化。

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

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

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

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

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

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

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

從實用主義走向敏捷

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

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

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

作者簡介

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

[關(guān)鍵詞] 制造企業(yè) 項目管理 敏捷響應

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

一、制造企業(yè)敏捷響應模式

1.企業(yè)生產(chǎn)經(jīng)營體制的轉(zhuǎn)變

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

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

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

2.業(yè)務(wù)外包格局的出現(xiàn)

實現(xiàn)項目產(chǎn)品的大批量和個性化，關(guān)注質(zhì)量、完工時間和縮短項目的生命周期是制造企業(yè)現(xiàn)階段的重要任務(wù)。在這種情況下，制造企業(yè)的規(guī)模趨于小型化，在保證核心及增值流程事業(yè)領(lǐng)域的基礎(chǔ)上，減少非核心業(yè)務(wù)，增加對于市場的敏捷響應。

業(yè)務(wù)外包已經(jīng)成為制造行業(yè)的一種重要的形式，其特點是業(yè)務(wù)流程中的動態(tài)聯(lián)盟和供應鏈上的協(xié)同。從系統(tǒng)的角度來看，動態(tài)聯(lián)盟實質(zhì)就是一個系統(tǒng)，通過系統(tǒng)的優(yōu)化實現(xiàn)供應鏈上成本的不斷降低。通過信息化平臺實現(xiàn)跟蹤消費的個性化需求，提高敏捷響應的能力。系統(tǒng)的動態(tài)性決定了制造企業(yè)敏捷的特性。

3.敏捷響應模式

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

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

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

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

1.敏捷響應模式框架

制造企業(yè)的敏捷響應，就是企業(yè)建立能夠?qū)ν獠渴袌霏h(huán)境能夠做出快速響應的組織結(jié)構(gòu)和戰(zhàn)略規(guī)劃，通過改造傳統(tǒng)的生產(chǎn)模式來增加對于市場的快速響應能力。敏捷響應不僅僅是一種戰(zhàn)略上的敏捷，更是一種作業(yè)層面的敏捷，這兩種敏捷通過柔性化的組織結(jié)構(gòu)實現(xiàn)。如圖2所示：

從戰(zhàn)略層面，從企業(yè)發(fā)展的戰(zhàn)略出發(fā)，通過項目的優(yōu)選評價，確定項目的優(yōu)先級。

從企業(yè)作業(yè)層面上，實現(xiàn)項目時間、成本、質(zhì)量、設(shè)備利用率和員工安全度等目標的集成控制。

從企業(yè)作業(yè)層面上，進行項目的組合管理實現(xiàn)企業(yè)多項目資源分配的優(yōu)化。

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

2.敏捷模式知識體系

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

(1)項目管理目標

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

(2)項目管理組織

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

(3)項目管理信息系統(tǒng)

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

(4)項目管理系統(tǒng)方法

制造企業(yè)的發(fā)展需要關(guān)注各個利益的相關(guān)體、接近顧客群體，影響企業(yè)經(jīng)營的因素越來越多，系統(tǒng)的觀念對于企業(yè)經(jīng)營的影響日漸顯著。分析研究各要素之間的相互聯(lián)系，需要從系統(tǒng)整體的角度進行優(yōu)化經(jīng)營。

(5)項目管理文化

企業(yè)文化要做相應的調(diào)整以適應企業(yè)戰(zhàn)略項目管理的要求，形成統(tǒng)一標準化的語言，以使企業(yè)項目管理融入企業(yè)戰(zhàn)略、戰(zhàn)術(shù)決策及各項活動之中，成為員工一項自覺的行為。

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

三、制造企業(yè)敏捷響應模式關(guān)鍵技術(shù)

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

1.單項目多目標集成

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

2.項目組合資源優(yōu)化

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

3.項目優(yōu)選評價

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

四、結(jié)語

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

參考文獻：

[1]戴勇馬萬太:生產(chǎn)過程數(shù)字化管理[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篇

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

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

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

舉例來說，配對檢入是個保證代碼質(zhì)量很好的方法。但編程人員不了解其重要性，可能為了進度，常常一個人草草就檢入了。因此，在采用敏捷方法時，若能適當?shù)厥褂霉ぞ邅肀４胬鄯e的知識并固化關(guān)鍵過程，必能使敏捷項目更加成功。我們試以敏捷開發(fā)的幾個主要特點為例，探討工具在敏捷開發(fā)中扮演的角色。

特點一:測試驅(qū)動開發(fā)

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

特點二:簡單設(shè)計

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

特點三:配對編程

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

特點四:小型

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

工具所扮演之角色

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

圖1 工具對敏捷開發(fā)的支持示例

角色1:需求管理的利器

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

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

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

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

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

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

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

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

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

角色2:項目規(guī)劃的利器

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

Smart先生認為，作為敏捷團隊的項目經(jīng)理，他應該從傳統(tǒng)項目經(jīng)理的“工頭”身份中解脫出來，發(fā)揮他的領(lǐng)導力，去監(jiān)控和協(xié)調(diào)開發(fā)過程。雖然項目經(jīng)理還是必須定義和初始化項目，作項目計劃，執(zhí)行計劃，監(jiān)督并控制結(jié)果。

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

角色3:測試管理的利器

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

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

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

角色4:任務(wù)執(zhí)行的利器

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

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

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

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

敏捷團隊的成功案例總結(jié)

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

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

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

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

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

另外，面對面溝通也是個很好的敏捷操作，但是實際上卻不易實現(xiàn)?？蛻艋蚴熘虡I(yè)邏輯的同事通常是無法長時間和開發(fā)設(shè)計人員在一起工作的。若一定要面對面，很可能會以高昂的費用為代價。更實際的方式是通過一定的溝通平臺（如一些即時語音或視頻通訊工具）來達到類似面對面的溝通。

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

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

1.1方法

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

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

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

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

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

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

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

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

1.2觀察指標

設(shè)計護理滿意度調(diào)查表對療養(yǎng)員關(guān)于護理工作的滿意情況進行分析，包含6項內(nèi)容，分為滿意、很滿意、需改進3個等級，同時記錄兩組護理糾紛、跌倒等發(fā)生情況。

1.3統(tǒng)計學方法

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

2.結(jié)果

2.1兩組護理效果比較

2.2兩組療養(yǎng)員對護理服務(wù)滿意度比較。

3.討論