敏捷的項目管理精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的敏捷的項目管理主題范文，僅供參考，歡迎閱讀并收藏。

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

關鍵詞：關鍵鏈項目管理；敏捷軟件開發；進度管理

前言

隨著軟件行業的深度發展，軟件開發項目的復雜性大大提高。軟件項目開發中的需求變化性較強，開發的資金、技術支持等條件不斷變化，導致傳統的軟件開發項目管理方法已經不能滿足日益進步的開發需求。基于關鍵鏈項目管理思想的敏捷軟件開發就是在這一大背景下產生的，敏捷開發能夠實時根據需求變更改變開發進度管理，注重人才價值與軟件價值的互通，注重團隊合作，注重與需求方客戶合作，所以越來越多的軟件行業、企業與開發團隊開始采用這種軟件開發模式。

1 基于關鍵鏈項目管理的敏捷軟件開發項目現狀研究

1.1 關鍵鏈項目管理綜述

關鍵鏈項目管理提出于1997年，是根據項目管理發展狀況將項目管理中的約束理論與實際管理工作實踐相結合所提出的創新型的、適用性較強的管理模式，對各行業的項目管理工作都能起到很好的推廣和借鑒作用。[1]關鍵鏈項目管理法通過對項目的進度計劃及約束項目管理因素的分析，合理調度項目計劃中的全部資源，消除影響項目進度的約束性因素，減少不合理的工作計劃對項目本身的影響，集中管理項目時間進度，控制項目整體進度。關鍵鏈項目管理是一種新型的管理模式，包含科學的項目進度管理方法及項目整體資源的合理調配方法，既能滿足項目發開中進度計劃的需求又能保證項目目標的完成，同時又能有效的解決項目進行中影響項目進度的風險性因素，這些有效的項目進度管理方式都給敏捷軟件開發項目提供了很好的管理參考。

1.2 敏捷軟件開發項目的現狀

我國的敏捷軟件開發項目由于起步晚，缺乏實踐經驗，正處于探索研究階段，其過程中必然出現很多問題。其中，造成敏捷軟件開發項目管理出現問題的最重要缺陷因素就是項目進度的管理，體現在以下幾個方面：第一，忽略外界因素對項目開發進度管理的約束性因素。[2]敏捷軟件開發是一個涉及面廣，復雜性高的項目工作，很多外界因素包括資金、技術、資源、人員等都會對項目進度造成重大影響，而現在的敏捷軟件開發項目并沒有對其產生足夠重視。第二，約束因素問題得不到有效解決。制約敏捷軟件開發項目進度的因素有很多，在得不到重視的情況下解決問題變得更加困難，這就大大延長了項目的工期，同時又帶來了新的不可預計的影響因素出現的風險幾率。第三，對項目參與人員的主觀能動性重視不足。主觀能動性不強，工作態度不積極，缺少創新思考，缺乏解決問題的創新思路，這些都會大大延緩項目的進度，拖慢項目工期，使得敏捷軟件開發項目整體失敗。

2 基于關鍵鏈的敏捷軟件開發項目進度管理建議

2.1 改變管理模式

敏捷軟件開發項目環節多，項目運行復雜，因此要改變舊式的分散管理模式，將成本管理、資源管理、風險管理及進度管理進行集中控制，做到管理統一。這樣有利于項目成本的節約，項目資源的合理調配，項目風險的有效控制，保證項目的正常運行并順利完成。[3]在做到集中管理的同時要側重項目進度管理，對項目進度管理保持高度的重視。因為項目進度管理是整個敏捷軟件開發項目的重點工作，各種因素都會對項目進度產生嚴重甚至決定性的影響，只有側重項目進度管理工作，保持高度重視才能保證項目進度的順利完成，避免項目延期甚至項目失敗的情況。

2.2 合理調配項目資源

敏捷軟件開發項目進度的管理離不開項目資源的支持，其中最重要的就是資金、技術及人員的支持。資金支持不及時會導致項目進度的拖延；技術更新支持不及時會拖慢甚至暫停項目進度；管理人員及技術人員落實不到位會嚴重影響項目的整體進度，給敏捷軟件開發項目的進度管理造成極大困難。所以，要合理調配項目資源，將整體項目的資金、技術、人員更多的投入到項目進度管理環節，保證項目進度的良好進行進而保障敏捷軟件開發項目的順利完成。

2.3 及時處理約束因素

在敏捷軟件開發項目的進度管理中要及時解決制約進度的各種因素問題，避免因項目資金、技術、人員、管理等項目資源的匱乏問題產生的進度滯后現象。出現影響項目進度的因素必須加大各種資源的投入，及時解決，保證項目進度。同時，問題的解決方式要在盡量滿足項目進度的前提下尋找針對性的或者可替代性的解決方法，杜絕因困難問題難以解決而進行進度計劃修改，保證項目進度，更好的做好項目進度管理工作。

2.4 發揮人員主觀能動性

在敏捷軟件開發項目進度管理工作中要重視人的作用，激發其工作積極性與創造性，解決敏捷軟件開發項目進程中的技術難題及工作適應性問題，豐富項目的人員、技術資源，保障項目進度的按期進行甚至因技術創新、管理有序而提前完成項目工期任務。

3 結束語

關鍵鏈項目管理是一種先進的項目管理模式，能夠為項目的正常運行直至順利完成提供管理保障?；陉P鍵鏈的敏捷軟件開發項目進度管理，要做到側重進度管理，及時解決阻礙進度管理工作的資源問題，合理調配項目資源，保證項目進度管理工作的順利進行，進而保障項目的順利完成。同時要結合實際情況，對敏捷軟件開發項目進度管理進行科學合理的調整，保證項目完成的高質、高效。

參考文獻

[1]胡丹.基于關鍵鏈的敏捷軟件開發項目進度管理研究[D].浙江工業大學，2013.

[2]張雪嬌.基于關鍵鏈技術的敏捷軟件開發項目管理研究[D].華中科技大學，2011.

[3]楊光.軟件開發項目進度管理模型構造與系統仿真[D].北京郵電大學，2009.

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

關鍵字：：敏捷項目管理；敏捷；KANBAN

互聯網運維項目專門面向互聯網數據中心和云計算服務平臺，項目范圍包括數據中心容量和性能提升、設備替換、技術改造、產品部署等等。由于互聯網運維項目的獨特性，很多企業仍然沿用傳統瀑布式的項目管理方法，無法快速交付高質量的運維項目。如何提升互聯網運維項目管理的整體水平，對敏捷運維項目管理的方法論研究和實踐的重要性就不言而喻。

互聯網運維項目的敏捷項目管理方法研究

KANBAN（看板）是敏捷的一種方法論，是一種敏捷的變更管理方法。目前它被用于最廣泛地管理 IT支持和維護工作。也更適合于有一個恒定的正在進行的工作流程的IT部門或互聯網運維中心，而不是項目的可交付成果。

KANBAN的核心是要賦予項目團隊管理工作量，定期交付業務價值，團隊要提交真正可以交付的工作：不多也不少，KANBAN也是一種時間驅動器，來管理任何點的工作 （WIP，working in process）。如果業務要求解決更高優先級的工作，利益相關者必須確定當前的哪些工作可以騰出足夠的人力資源來滿足高優先級業務需求。同樣在開放 的WIP 隊列中，團隊和利害關系方可以確定應該專注的下一步的最高優先工作。

KANBAN也是組織和團隊解決工作瓶頸，克服障礙，以及持續改善的文化，最大限度地提高他們的生產力?？窗遄岉椖繄F隊基于部門的具體要求建立審查周期和釋放時間。為了適應敏捷文化，許多從業者也已經開始使用混合的方法，如結合SCRUM的KANBAN，將有效的敏捷實踐，如每日站立會議，也吸收進KANBAN。

互聯網運維項目的敏捷項目管理方法實踐成果

在經過對敏捷KANBAN方法論的研究和多個項目進行實踐后，作者本人作為云服務運維項目經理就開始和團隊一起進行了實踐，成果分享如下：

第一， 敏捷KANBAN項目管理方法最適合互聯網運維項目

我們云服務項目團隊在KANBAN實踐過程中吸收了SCRUM思想。管理方法以KANBAN為主，SCRUM為輔，主要以KANBAN搭載互聯網運維工作流程，同時采用SCRUM敏捷框架中的3個角色（PO，Team member，SCRUM Master）。

使用KANBAN方法符合了互聯網運維項目的多種特征，完全包容了具有高度依賴性和突發性特征的運維項目工作，是精益現場工作管理方式的又一種行業應用。另外KANBAN所搭載的工作流就如水流一樣，要向前不停流動。項目團隊所追求的就是水流的速度越來越快，水流的管道越來越粗，其實也就滿足了運維項目的業務目標和客戶價值需求。同時KANBAN方法里面的工作項有優先級排序，有交付物驗收和質量要求，并不僅僅是追求項目速度和交付物數量。

使用SCRUM的思想主要是體現敏捷思想的價值觀，期望每個成員在信任、開放、尊重、承諾的意識下積極主動的工作。我們在實踐中的KANBAN也有daily standup meeting，每天或適時的進行多個項目的狀態同步和問題同步，會后進行問題分析和解決應對。并且項目經理與團隊一起確認工作的輕重緩急，實時協調人力資源，把人力集中在優先級最高的任務上。

第二，互聯網運維項目使用的敏捷KANBAN工作板

我們知道，吸取了SCRUM敏捷思想的KANBAN項目管理方法，最直接的體現方式就KANBAN工作板，我們云服務項目團隊的KANBAN工作板如圖所示。

橫軸是互聯網運維項目工作流，任務從左向右流動，大的流動過程分別是：計劃好的項目任務清單，任務文檔和設計準備、任務實驗室階段完成、任務在產線階段實現、 任務Done。豎軸是按照優先級排序的并在進行中的工作任務（WIP）。豎軸的WIP容納多個運維項目任務便簽條，并且用不用的便簽條顏色來區分不同的項目。每個便簽條有3項內容：任務描述、任務擁有人、交付物開始日期和期望的結束時間。最下面放的是任務庫存。右下角是多個項目在一年之內的路線圖。

接近1年的敏捷KANBAN項目管理實踐后， 團隊的凝聚體不斷提升，項目效率和質量也明顯提高，同時也大大提升了項目交付度和滿意度。

結語

互聯網運維項目本身具有工作清晰性、變化隨時性，協調復雜性的特征。為了能夠最大化的避免運維項目的失敗，提升項目的效率和質量，讓運維項目走上成功之大道，那我們就要未雨綢繆，以正確理念為指導，使用正確的敏捷項目管理方法，正確建立項目團隊，恰當使用資源，做好項目監控。只有這樣，才是企業互聯網運維項目管理良性發展的重要保障。

參考文獻：

[1]羅伯特?K?威索基.《有效的項目管理（第五版）》.（美）電子工業出版社，2012

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

【關鍵字】軟件工程；熱點問題；探索

目前，人類已經進入了信息社會的階段，軟件工程在計算機科學中競爭激烈，是處于前沿的學科。文章主要在目前的軟件工程中，分析其熱點技術及難題，并闡述其發展方向與研究現狀。

一、軟件工程的發展歷程

計算機硬件技術在二十世紀末得到了廣泛的應用發展，為微電子計算機的推廣打下了堅實的基礎，而計算機軟件技術也應運而生。那時生產的軟件有著作坊式、個體化的特征，單一的開發平臺，落后的開發工具，具備較差的程序設計語言功能。特別是在軟件維護工作方面，損耗巨額的物力、人力與計算機資源，不少程序具有編寫者的個性化特征，使其難以得到維護與修改。有的甚至放棄原來的計算機系統，對新軟件重新編寫。此外，各類軟件的結構及規模差異性大，很難對軟件進行全面的維護，提高了軟件開發的成本。這種滯后的軟件開發工具、開發技術與生產方式落后的條件和飛速普及的電腦應用及對軟件與日俱增的需求導致了不可調和的矛盾，導致形成了“軟件危機”。

當前，軟件工程已經發展了五十多年，逐步深入到社會生活的各個方面，應當說，當代生活社會，基本上在每一個方面都關系到軟件工程。

二、軟件工程的研究熱點及現狀

軟件工程的熱點問題伴著軟件技術的發展而隨之變化的。即使在軟件工程的內部領域，研究的熱點區域也處在變動之中。軟件工程的建設隊伍將由兩部分構成，部分人是做軟件評估，另而另一部分人做的是軟件集成，主要是對軟構件進行集成。

近年來軟構件的應用也慢慢興起。在一些公共的應用方面，比如說軟件的初始化界面，通用軟構件的應用較為廣泛。但是，在各行各業的專業領域應用方面，軟構件的研發及推廣在我國仍屬于空白。這一工作的推行，首先是表明了各行各業對該專業領域中的知識形態予以分析歸類，并通過最新軟件的形式進行描述。假如這個全面展開這個工作，將會是一個浩大規模的系統工程，亟需各行各業的軟件專家與領域專家全力協作方可完成。

在開發軟件的過程中研發者開始應用與研發軟件工具，以便對軟件項目管理與技術生產進行輔助，研發者還把軟件各階段的生命周期使用的軟件工具機動性地整合為一個團體，構成可以持續性地支持軟件維護和研發整個過程的集成化軟件環境支援，以便從技術與管理兩個維度解決軟件危機的問題。

三、軟件工程的發展趨勢

（一）需求工程漸成熱點

需求工程將成為軟件工程發展的熱點，當前業務創新日益復雜，同時分工更加專業化，區域組織的全球化以及互聯網級的交付速度，這些均對獲取需求的準確性及有效性提出了進一步的要求，其中Use Case技術（用例分析，也就是嘗試通過分析類來在理想狀態下完成用例）將會被大大的推廣應用，而有關工具的研究也會變成熱點（如IBM Rational Requirements Composer，，Ravenflow等）。

用例的優點在于它本身是未知的，它使用的是自然語言對用戶與目標系統的交互進行抽象，防止了混入設計、分析與完成細節，來確保用例能夠被不明白具體技術的測試人員和業務人員所真正掌握。此外，需求分析員又能夠便捷地經由用例分析，把需求體系精簡為分析的模型。在這一進程中，需求分析員能夠更進一步地建立起基于用例的需求體系，而不用擔心分析模型會對需求造成干擾，進而達成分析和需求的隔離及高效互動。

（二）基于領域的構架（DSSA）與模型驅動的開發（MDD）

伴著軟件應用的發展和成熟，軟件已經不再是以往的把手動流程自動化的要求，而漸漸變成業務創新的重要促進力量。所以，導入捕獲指定領域內最先進需求及其實現架構的DSSA變成行業客戶的關注重點之一。此外，DSSA的導入將大大降低模型驅動的開發（MDD）的門檻，也使得基于DSSA的MDD支撐工具變為了可能，進而能夠大大地促進開發效率并確保軟件的質量，譬如，Telelogic的Rhapsody就為一個成功的基于實時嵌入式系統構架的MDD工具。

（三）迭代/敏捷漸成標準

伴著越來越快的軟件交付的周期，迭代化開發漸漸變成大多數軟件開發團隊的關注熱點。同時，迭代對整個團隊的架構、需求、測試能力及協同均帶來了較高的要求，目前不少開發團隊均在嘗試在軟件開發中導入迭代化開發的過程，敏捷目前被當作是迭代化開發的一種導入方案，而敏捷的使用范圍其實比迭代化開發更加廣大。敏捷的三個要素為坦誠合作、迭代開發與自適應性。而敏捷的核心即為坦誠合作，如不少軟件工程師所言，敏捷實質上是與Social Engineering相關的。敏捷的重大作用在于它更多地考慮到了怎樣去激起開發人員工作的熱情，這是在軟件工程過去幾十年發展過程中沒有被重視和開發的領域。

（四）持續集成蓄勢待發

確保迭代化開發質量的主要條件之一為持續集成，經由持續集成能夠利用自動化的形式來盡可能自主地、盡快地確保代碼的質量。伴著敏捷與迭代的發展，相關的持續集成工具變成目前市場上新的發展趨勢（如持續集成框架IBM Rational BuildForge， 開源軟件CruiseControl，代碼靜態分析工具Klocwork Insight，IBM Rational Software Analyzer等）。

持續集成為一項復雜的系統工程，組織首先亟需把目前的配置管理/變更管理工具與Build環境緊密集成，并達到自動化Build過程，再依照企業/項目/產品的狀況，定義怎樣自動化地對軟件質量進行檢測（單元測試、代碼靜態分析或冒煙測試），并確定所需的自動化生成的管理報表。

（五）基于實踐的過程框架方興未艾

開發角色的專業化的與分布的全球化均需要軟件開發過程愈加規范，而敏捷又指出過程一定緊密符合項目的實際需求，而以為傳統的大一統的過程難以滿足這個需求。新一代的過程將是以實踐為重點的，項目可以經由組裝所需的不同實踐來得到貼近項目所需的過程。當前，逐步求精式的過程改進已經成為了可能，對于一個軟件組織來說，倘若已經成立一個較為成熟的軟件開發過程，但認為這一過程并不符合所有項目的實際需求，那么當前能夠考慮的是用實踐的方法去重新組織現有的流程，以便項目組能夠通過實踐為單位來達成符合項目實際的流程。此外，該組織也能夠把適用于本組織的業界流行的實踐引入到現有的流程當中。

參考文獻：

[1]尹峰. 軟件工程的若干熱點技術發展現狀與展望[J].長沙大學學報，2006（09）.

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

 

世界五大軟件開發教父之一的Matin Fowler認為，當前只有敏捷的軟件開發模式才能夠使IT跟上業務變化的腳步，只有敏捷的開發模式才能使軟件實現快速交付的同時又能成為一個高質量、低成本的軟件。

 

敏捷開發作為一個新的軟件開發模式的新名詞，其中蘊涵著無限的商機，同時，也是對中國軟件企業的一次嚴峻的考驗。對于起步遠遠滯后于西方的中國軟件業而言，各種提高軟件開發速度及降低軟件開發成本的方式和措施都是值得探討與借鑒的。筆者認為敏捷開發模式對于中國的軟件企業正是一個行之有效的開發方式。

 

問題纏繞軟件開發

 

軟件開發過程中問題多多，這不是新發現。早在上世紀60年代，北約(NATO)就提出了軟件危機這一概念。在《人月神話》一書中，軟件開發則被喻為讓眾多史前巨獸痛苦掙扎，卻無力擺脫的焦油坑。隨著需求和應用的日趨深入與復雜化，軟件開發的難度和遇到的問題以幾何級數形式增長，焦油坑也由此變得更深、更大。

 

復雜程度高、開發周期長、結果無保證，這是軟件開發的通病。針對這些問題，人們創造了N種方法，并由此產生了軟件工程學。而在實際工作過程中，軟件開發的多變性和不可控制性，仍可輕易摧垮項目開始時項目組苦心經營的開發體系和方法，無論是業界公認的需求、變更、人員流動，還是各種看起來并不起眼的小事件。

 

以人為本的敏捷開發

 

敏捷開發(Agile Software Development)是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，就如同項目管理中將工作任務及工作目標層層分解一樣，把軟件項目的構建切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。簡言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

 

通過上面的定義可以看出，敏捷開發其實借鑒了大量軟件工程中的方法。是傳統軟件開發意義上的改善，而非創新。例如在傳統的軟件開發中，把設計和構建這兩個過程分開進行，設計完成之后，再按照設計構建。

 

實際上，由于需求在不斷變化，因此在軟件開發的過程中，很難把設計和編程完全區分開來。而在敏捷開發中，先搭建一個比較粗的主構建框架，只對用戶目前感興趣的部分詳細開發，并很快交付使用，在使用過程中，按用戶的需求進行疊蓋修正，周而復始，循序漸進的開發軟件產品直到完成。

 

正如ThoughtWorks的首席科學家Matin Flower所說：“在敏捷軟件開發的過程中，我們每兩周都會得到一個可以工作的軟件，這種非常短的循環，使終端客戶可以及時、快速地看到花錢構建的軟件是一個什么樣的結果?！币虼嗣艚蓍_發也可理解為在原有軟件開發方法基礎上的整合——取其精華，去其糟粕。

 

敏捷開發的特點

 

敏捷方法主要有兩個特點，這也是其區別于其他方法，尤其是重型方法的最主要特征:

 

敏捷開發方法是“適應性”(Adaptive)而非“預設性” (Predictive)。

 

這里說的預設性，可以通過一般性工程項目的做法理解，比如土木工程，在這類工程實踐中，有比較穩定的需求，同時建設項目的要求也相對固定，所以此類項目通常非常強調施工前的設計規劃。只要圖紙設計得合理并考慮充分，施工隊伍可以完全遵照圖紙順利建造，并且可以很方便地把圖紙劃分為許多更小的部分交給不同的施工人員分別完成。

 

然而，在軟件開發的項目中，這些穩定的因素卻很難尋求。軟件的設計難處在于軟件需求的不穩定，從而導致軟件過程的不可預測。但是傳統的控制項目模式都是試圖對一個軟件開發項目在很長的時間跨度內做出詳細的計劃，然后依計劃進行開發。所以，這類方法在不可預測的環境下，很難適應變化，甚至是拒絕變化。

 

與之相反的敏捷方法則是歡迎變化，目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。所以稱之為適應性方法。

 

敏捷開發方法是“面向人” (people oriented)而非“面向過程”(process oriented)。

 

Matin Flower認為：“在敏捷開發過程中，人是第一位的，過程是第二位的。所以就個人來說，應該可以從各種不同的過程中找到真正適合自己的過程。”這與軟件工程理論提倡的先過程后人正好相反。

 

在傳統的軟件開發工作中，項目團隊分配工作的重點是明確角色的定義，以個人的能力去適應角色，而角色的定義就是為了保證過程的實施，即個人以資源的方式被分配給角色，同時，資源是可以替代的，而角色不可以替代。

 

然而，傳統軟件開發的這些方法在敏捷開發方式中被完全顛覆。敏捷開發試圖使軟件開發工作能夠利用人的特點，充分發揮人的創造能力。

 

敏捷開發的目的是建立起一個項目團隊全員參與到軟件開發中，包括設定軟件開發流程的管理人員，只有這樣軟件開發流程才有可接受性。同時敏捷開發要求研發人員獨立自主在技術上進行決策，因為他們是最了解什么技術是需要和不需要的。再者，敏捷開發特別重視項目團隊中的信息交流，有調查顯示：“項目失敗的原因最終都可追溯到信息沒有及時準確地傳遞到應該接受它的人?！?/p>

 

敏捷開發的問題和思考

 

雖然敏捷開發是個行之有效的軟件開發模式，但是任何模式和方法的建立都是基于理論的基礎，往往和現實的情況存在差異，這樣就會對軟件企業操作及執行帶來很大的困難，甚至是誤導。所以，僅僅提出敏捷開發的模式是不夠的，對敏捷開發的議題的討論并沒有終結。下面僅就筆者理解基礎上提出一些問題的參考。

 

項目內部協調的困難加大

 

敏捷開發要求將大項目分解成為很多小項目，這樣雖然易于考察、易于管理和易于控制，但是這樣也帶來了項目內部各個小項目協調問題。對于各個小項目的執行，人員分配及其他資源分配的沖突及進度的沖突是最主要的沖突，而且這些沖突如果解決不徹底，將會對整個大項目帶來難以預測的負面結果。

 

對管理水平的要求提高

 

敏捷開發的問題最后就是管理的問題。這和很多軟件企業重技術輕管理的做法是截然相反的，企業的這種心智模式一方面是源自管理人才的缺乏和項目組成員對管理制度的排斥;另一方面則是因為現行規范和管理制度與實際工作中的不合拍。從這一層面而言，敏捷開發對管理水平要求提高對軟件企業領導者的觀念是一種挑戰。

 

對執行力的要求

 

任何理論只有落到實處，才能為企業為社會創造財富。這是永恒不變的道理。敏捷開發模式需要經驗豐富、配合良好而又異常穩定的項目組、積極而富有成效的溝通、良好的管理手段和流程、有效的工具與平臺，只有滿足這些條件我們才能實現敏捷開發模式帶給我們的益處。

 

敏捷開發的出現，同樣讓以人為本還是以過程為本的爭論上升到了理論層面。在敏捷開發過程中，人是第一位的，過程是第二位的，所以就個人而言，應該可以從各種不同的過程中找到真正適合自己的過程。這與軟件工程理論提倡的先過程后人正好相反，因而被不少人戲稱為對工程學原理的叛逆。

 

敏捷方法對需求不確定或常常變更的情形是有效的。但是，沒有哪一種開發方法是適用于所有項目開發的，正如上文所說，敏捷方法給傳統軟件開發帶來了一種新的思路和開發模式，但也給企業帶來了軟件研發項目管理開發過程的整合困難。

 

所以，在實際開發過程中，需要根據實際項目的需要選擇合適的開發方法，并盡最大可能發揮人的創造性和潛能，利用不同人的不同特點，充分溝通，這才是在敏捷方法中真正需要學習的。

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

關鍵詞：DevOps 開發與運維 DevOps軟件開發流程

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2016）11-0184-04

1 引言

1.1 DevOp概念

DevOps（Development和Operations）是一個關于組織文化、自動化、持續監控與共享等各元素的集合。是軟件開發、運維和質量保證三個部門之間進行溝通、協作的流程、方法和體系。它源于2009年歐洲傳統IT模式的運維之痛，為了填補開發與運維之間的鴻溝，將開發、運維與測試聯合在一起。專家們曾經總結出一個能力環來解釋DevOps的概念，如圖1所示。

DevOps能讓開發團隊以同樣的方式操控他們的開發環境、測試環境以及生產環境，并且任何時候都能將數據包部署到任何一個環境中。DevOps從軟件交付的全局出發，加強各角色之前的合作；同時，自動化減少了大量的手工操作和人機交互，因此，需要選擇那些支持腳本化、無需人機交互界面的強大管理工具。這些工具和程序涉及環境中的各種函數，而這些函數包含不同領域的專業知識，并且可以根據組件中出現的問題以不同的方式運用?？紤]到各種函數復雜性，根據它們的作用建立一個框架來將它們形象化并分成不同的種類將會很有幫助。在DevOps環境下，將全局系統的視角運用到一個高層次的模型中，將在應用、操作系統服務、網絡服務、數據庫四個層面產生核心變化[1]。

1.2 DevOp優勢

傳統的瀑布開發模型由溫斯頓?羅伊斯（Winston Royce）在1970年提出，一直是最被廣泛采用的軟件開發模型。瀑布模型核心思想是將功能的實現與設計分開，將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，并且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。它為項目提供了按階段劃分的檢查點，但缺點也顯而易見――即只有在項目生命周期的后期才能看到結果，且極不適應需求的變化[2]。

于是新的理念應運而生――敏捷。敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。

然而單單敏捷開發也并未解決開發與運維之間的鴻溝。DevOps在敏捷的基礎上，將運維并入進來，是軟件開發、運維和質量保證三個部門之間的溝通、協作和集成所采用的流程、方法和體系的一個集合。圖2可以清晰地說明軟件開發模式的進化過程。

在傳統行業的數據中心，數據的穩定性和安全性是重中之重。IT 管理人員對數據中心的管理主要偏重于兩個方面：首先是為了確保數據中心的穩定性而對數據中心各個環節進行維護；其次當數據中心內出現問題時，能夠及時定位問題并且解決，以縮短故障時間。

而運維工具的開發和數據故障的解決都需要快速的響應和交付能力。目前傳統數據中心的ITIL管理模式和普遍應用于開發工具中的瀑布開發模型，都無法保證最快的交付和最佳的成果。DevOps集開發、運維和質量保證于一體，通過促進開發團隊和運營團隊之間的溝通、協作和整合，不僅提高了效率，也同時促進了運維的自動化。

DevOps本質上是開發，運維和質量保證部門之間的溝通協作。它將解決傳統IT運維管理模式信息溝通效率低下的缺點，提高整個IT部門效率，適應云時代不同類型用戶對IT運維管理的需求，也是未來的發展方向。

1.3 DevOp應用現狀

在目前這個瞬息萬變、信息爆炸的時代，一分鐘之內就會發生很多事情：超過兩百萬條的Google搜索、兩億封郵件的傳送……在這個應用經濟備受關注的時代，企業需要靠各種創新應用獲得持續發展。而業務的靈活創新依靠的是快速、持續、高質量的軟件應用交付。

目前在國外，互聯網巨頭如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，傳統軟件公司如Adobe、IBM、Microsoft、SAP等，亦或是網絡業務非核心企業如蘋果、沃爾瑪、索尼影視娛樂、星巴克等都在采用DevOps或提供相關支持產品。

在云計算、大數據和移動互聯這三大浪潮面前，更有效地管理和整合現有資源，進行更快速的應用交付對于任何一個企業來說都是一個挑戰。目前，DevOps 在國內并不算流行，很多傳統企業還沒有認識到開發與運維協作所能產生的“化學反應”。

不過，依托DevOps中國社區成員的積極參與支持，南京大學發起《DevOps中國2016年度調查》活動。期望通過本次問卷調查，收集DevOps的率先實踐者們關于DevOps實踐及經驗的相關信息，從而了解DevOps在中國推廣應用的狀況，并匯總在DevOps實踐中可能遇到的障礙、挑戰和最佳實踐，最終將通過調查報告進一步促進DevOps在中國的認知和推廣。

2 DevOps流程

Devops開發流程大約分為以下幾個部分：持續的管理與計劃，持續的集成與測試，持續的交付與部署，持續的監控與運維，持續的分析與計劃。

在此前我們要介紹DevOps開發流程中的幾個角色：功能負責人（敏捷中的Product Owner），開發人員，測試人員，運維人員，流程負責人（敏捷中的Scrum Master）

2.1 持續的管理與計劃

功能負責人將聚集開發、測試與運維一起進行功能討論并制定交付計劃。每個人都會從自身的角度考慮可行性并作出適當的建議。流程負責人會在這個階段協調討論進度，并在流程的每一階段對功能進度與狀態進行全程跟進。整體的計劃及相應的各人任務將被創建在管理平臺上對所有人可見。

2.2 持續集成與測試

運用一系列開發實踐的方法確保代碼可以快速并安全地部署到產品中。每一次代碼的改動，都提交到一個模擬的產品環境中，使用嚴格的自動化測試，來確保功能和服務能夠達到預期。

2.3 持續交付與部署

當模擬環境中的代碼通過自動化測試，它們將自動被部署到真實的產品環境中（即生產環境）。由于部署腳本與測試用例都是在開發前有著充分的溝通，且部署和測試都是通過自動化實現，投產過程出問題的可能性將大大減少，且即使出現，大家也會在一起找到原因并解決。

2.4 持續監測與運維

投產后，運維人員在自動化監控工具的幫助下持續地監控功能狀態。

2.5 持續的分析與計劃

由于整個開發流程進度及具體任務對所有人可見，每人在每天登錄管理平臺都可以具體感受到目前功能的進度。因此每天的站立會中每人都可以提出對產品功能及整體計劃的分析和建議。

3 DevOps常用工具

以下是以某數據中心的K運維自動化管理平臺（以下簡稱“K平臺”）為例的DevOps常用工具。該平臺的DevOps工具中包含了項目管理、開發工具、持續集成與測試、持續交付與部署、持續監控與運維這幾個部分。

3.1 項目管理

Agiler：Agiler是原HP公司開發的一套敏捷管理系統。該團隊運用系統進行日常的項目管理工作。項目經理運用該工具建立backlog與Sprint；團隊Leader給團隊成員建立Sprint下的具體任務；而開發與運維團隊成員在每天的站立會中運用工具中的敏捷看板功能，對各自的任務進行跟進與狀態更新；項目助理則全程在該平臺上看到項目的進展。

3.2 開發工具

Subversion：Subversion是一個開源的版本管理系統。它將文件存放在中心版本庫，可以記錄每一次文件和目錄的修改情況。K平臺不僅用Subversion管理開發的代碼，也同時管理著運維腳本，項目文檔，設計圖，測試用例等任何與K平臺項目相關的文件。與普通的文件服務器之間的區別在于，由于它記錄了每一次文件和目錄的修改情況，可以將數據恢復到以前的版本，并可以查看數據的更改細節。

3.3 持續集成與測試

Maven：Maven是一個軟件項目構建工具。K平臺運用它進行管理項目的jar包依賴，開發，測試，打包的一系列生命周期的管理。

CasperJS：CasperJS是一個基于PhantomJS（前端自動化測試工具）編寫的腳本處理和測試工具，提供了完成常見任務的方法和函數。K平臺使用CasperJS編寫平臺系統測試案例，用于自動化測試系統功能。

Jeckins：Jenkins 是基于Java開發的持續集成工具，K平臺利用它來持續地軟件版本并測試項目。

3.4 持續交付與部署

Ansible：Ansible是一個基于Python開發的自動化運維工具，集合了puppet， cfengine、chef、func、fabric的優點，實現批量運行命令、批量系統配置、批量程序部署等功能。K平臺利用Ansible實現流程編排與批量操作系統配置。

3.5 持續監控與運維

Zabbix：zabbix 是一個基于WEB界面的提供分布式系統監視以及網絡監視功能的開源工具。K平臺利用Zabbix來實現網絡狀況監控、服務器端口監控、數據庫監控及日志監視。

4 DevOps應用實例

K運維自動化管理平臺DevOps開發實例。

K平臺是某數據中心的K運維自動化管理平臺，K平臺的DevOps架構圖如圖3。

4.1 制定計劃

由客戶及項目經理等領導層制定K平臺本年度的backlog并添加至Agiler工具中。并交于項目實施團隊進行自行實施。功能負責人將在計劃階段確定大概的功能點及完成時間，在Agiler工具中的相應的Backlog下確定Sprint。每個實施團隊的成員在Sprint下為自己建立相應的任務，使Agiler工具中的敏捷看板任務情況一目了然。項目助理會去跟進Sprint及Sprint下任務的分配情況。

4.2 定義工作內容

即瀑布模型中的需求分析階段。功能負責人、開發、測試，甚至運維將聚集在一起討論需求細節。功能負責人完成設計圖，測試人員編寫測試用例與自動化測試代碼，開發人員進行數據庫表結構設計等詳細設計，運維人員開始思考該功能上線后如何進行監控配置。

相關的設計文檔、測試用例、運維腳本等都將放在SVN（Subversion）中進行管理。

根據功能討論的情況，功能負責人可能會Agiler工具中更新backlog下的Sprint，進行名稱修改，功能重新劃分，時間點更新等操作。其他實施人員――包含開發人員，測試人員，運維人員也將在Agiler中去更新自己的任務及完成狀態。

項目助理會在全程跟進Agiler中的更新情況并提出相應的分配建議。

4.3 開發

開發人員運用Maven來管理代碼的生命周期。代碼的創建者在配置文件pom.xml中配置jar包的依賴關系，這樣每個開發人員都可以自動下載jar包在我們的項目中。

每一位開發人員都在SVN主干下開發自己的模塊代碼，Jeckins中的構建任務保證開發環境的代碼不斷被提交到模擬產品環境（即測試環境中），并進行嚴格的自動化測試。

開發人員在完成自己的相應任務后將會在Agiler工具中更新自己的任務狀態。于是在第二天的站立會中大家將看到開發進度的更新。

4.4 構建-部署-測試（測試環境）

Jeckins定期從Subversion指定目錄取得最新的代碼進行自動化構建操作，保證開發人員的代碼不斷被提交到模擬測試環境中，以進行自動化測試。

第6篇：敏捷的項目管理范文

何謂廣義的ASP

ASP（Application Service Provider），譯為“應用服務提供商”。顧名思義，它可以對企業提供在線業務應用服務和管理服務。具體的操作過程是：企業將有關生產經營活動的數據信息及生產經營特點傳遞給ASP，由ASP通過軟件處理后，傳遞給企業使用。ASP負擔軟件、硬件的購買、安裝、構造、維護，企業通過軟件租用或租賃形式來獲得服務。ASP實際上是一些為第三方提供服務的公司，它們擁有自己的主機，在自己的主機上部署、管理和維護各種應用系統，然后通過網絡Internet或VPN（虛擬專用網絡）向遠端客戶提供軟件的計算能力。簡單說ASP就是支持和幫助任何客戶進行電子商務的專業企業。

ASP是針對中小企業產生發展起來的，主要是為了解決中小企業普遍存在的資金困難和渴望信息化管理這一矛盾，通過直接租用ASP的計算機及軟件系統實施信息管理，既可以節省一筆用于IT產品、技術購買和維護運行的資金，又能使中小企業利用信息化壯大自身實力。ASP模式無疑為這類企業提供了較好的解決方案，企業無需配備專門的人員和大規模資金投入亦可獲得專業的服務和技術支持。

基于ASP的這種思想，拓展開來，它實際上就是為其它企業提供服務的供應商，這種服務是一種“大服務”的概念，它不僅僅是一種應用軟件的服務，更多意義上應該是一種企業的管理、信息的服務。我們不妨把這種模式稱為廣義ASP模式。

廣義ASP模式的應用

傳統的ASP通過Web，除提供應用租賃外，只提供很少幾種服務。廣義ASP則使這種模式又前進了一步。它為企業非核心商務業務提供更多的外包選擇，這種模式對于內部資源配置很薄弱的中小企業具有特殊的魅力。例如，美國加利福尼亞的eConvergent公司就是采用這種模式。該公司不僅租用E.piphany公司開發的CRM客戶關系軟件，而且還提供咨詢服務，包括針對客戶個性化需求的定制工作、特殊軟件產品培訓以及有關CRM軟件的一般培訓。該公司還提供外包客戶服務代表等服務。

廣義ASP向用戶提供的服務內容無疑比傳統ASP多，但他們也存在著與傳統ASP同樣的問題。這些問題主要表現在網絡應用、復雜的價格模式、遇到停機或故障時缺乏向客戶報告情況的聯系手段等，這些問題都有可能影響廣義ASP作用的發揮。但是，廣義ASP的投資回報率比傳統ASP要高，這一優點有可能使長期購買應用軟件致使成本過高的局面宣告結束。

廣義ASP的優點并不只是出租應用，其主要優點是為企業用戶提供非核心業務的整體外包服務，這樣就可讓企業用戶專注于核心業務，從而增強其競爭實力。

案例分析——SP－ASP模式

正是基于廣義ASP的思想，北京桑普電器有限公司提出了獨具特色的SP－ASP管理模式。

1. SP－ASP模式的提出

北京桑普電器公司成立于1992年，經過近十年的創業歷程，已經成為全國知名的“桑普”系列及“丹普”系列電熱設備生產廠家。目前，公司正經歷從創業向發展的過渡。在激烈的市場經濟體制的競爭中，公司一方面利用自己積累的經驗進行企業的重組改造和技術創新，另一方面積極利用新的管理模式、借助先進的計算機技術來提高企業的生產經營管理。公司于1999年成功實施了SP-CIMS工程，該工程的實施與應用使企業在管理和技術創新方面上了一個臺階，提高了工作效率，降低了運營成本，取得了較為理想的效果。

面對激烈的市場競爭壓力及中國加入WTO后小家電行業所面臨的巨大挑戰，為了使公司成為一個在供應鏈管理的哲理、方法和技術的指導下的開放的、敏捷的、合作的、有競爭力的企業，桑普公司積極調整戰略決策，提出了SP－ASP管理模式。

SP-ASP模式就是樹立以品牌、管理為主的企業核心競爭力，利用“大資源、大整合”的思路，逐漸把生產、采購、儲運的環節交給社會完成，以客戶服務為中心，應用供應鏈管理與敏捷制造的概念，把過去的單個企業擴大到利用社會資源的范疇，使企業為了共同的市場利益結成戰略聯盟。

桑普公司將通過與供應鏈上、中、下游企業之間建立戰略伙伴關系，利用其他企業的資源達到企業擴展的目的。桑普公司已在全國形成合作（協作）廠商、經銷代銷點、售后服務網點的供應鏈，以桑普公司作為企業動態聯盟盟主，基于ASP方式實現供應鏈管理的網絡化。ASP成為供應鏈式企業聯盟中的一員，它的核心是電子化服務。由ASP服務的內容包括：項目管理，資源組織與配置，質量保障、仲裁與認證，數據交換與標準，使能工具及產品，宣傳廣告等。由桑普公司組建ASP，開發供應鏈管理網絡的“服務、維保平臺”。

SP-ASP模式的主導思想是：

①以供需鏈思想指導企業的經營生產過程，降低企業的流通成本，構造企業敏捷的、彈性的營銷網絡；

②利用網絡技術，構架企業與外部的信息通道，建立資源信息庫，為企業對市場變化的科學決策提供有用的信息支持；

③建立面向資源的管理模式，對社會資源進行分析、規劃及管理，為企業參與社會資源的重組提供一個有效的手段。

④以客戶服務為中心，建立穩定的、有價值的用戶網絡。

從桑普公司構建的SP－ASP模式中我們可以看出，這種模式已經不僅僅是提供一種軟件服務，而是一種滿足于中小企業的全方位的信息服務。這種模式正是我們在前面提出的廣義ASP模式。

2. SP－ASP運作模型

根據SP－ASP管理模式，可以構造出SP－ASP的運作模型（如圖所示）。SP－ASP的運作模型

從該運作模型可以看出，由桑普公司搭建SP－ASP系統平臺，而其它異地生產、采購、儲運等均運作于此平臺上，從而實現生產、銷售的外包。該模型基于B/S架構，利用本地生產的成熟管理體系，異地通過遠程瀏覽器來使用該系統，系統則通過生產、質量數據等進行遠程監控，從而發揮各個企業的核心優勢。

3. 結論

第7篇：敏捷的項目管理范文

【關鍵詞】項目管理；施工產品；質量管理

一、前言

建筑工程的質量不僅影響著人民生活，而且直接關系到工程企業的長遠發展。施工產品是工程企業的品牌，它直接影響著工程企業的信譽，影響著其市場地位。在項目管理模式盛行的背景下，如何提高工程的質量是每個工程企業亟待解決的問題。發揮項目管理模式中的項目質量管理人員的作用、提高職工對施工產品質量重要性的認識對于切實提高工程質量有重要影響。

二、工程質量控制階段

工程的質量受各階段施工質量的影響，為此，項目質量管理人員應切實加強工程施工每個環節上的質量 管理，確保各個環節上的施工質量

三、目前項目管理模式下工程質量管理中存在的問題

1.過分注重定性評價

在以往的工程質量監控過程中，質量監控人員往往通過一些較為簡單、直觀的方式進行工程質量的檢查與控制，往往將個人經驗作為管理控制工程質量的標準，以至于在工程質量檢查與評定上缺乏科學依據。這種過分注重定性評價的評價方式將會導致工程質量控制的隨機性增大，降低了工程質量控制的科學性、穩定性。

2.缺乏量化管理

長期以來，項目管理模式缺乏量化管理，工程施工的責任分工不能具體到個人，這不僅影響了問題工程的責任追究，而且不利于提高工程建設職工的工作積極性，不利于提高職工的責任意識。

3.缺乏科學評價方法

如今的工程建設日趨復雜化，影響工程質量的因素較多，工程施工的具體環境也較為復雜，工程質量管理人員在進行工程質量評價時缺乏科學、統一的評價標準，這在一定程度上影響了評價的客觀性、公正性。

四、加強項目管理模式下質量管理的措施

1.提高項目經理管理水平

項目經理的管理水平直接關系到職工的施工積極性，影響到工程的施工效率與施工質量。首先，一個合格的項目經理不僅要具備較高的組織、協調能力，而且應具備較強的責任意識與敏捷的思維。其次，項目經理需具備較強的施工技術，他們應具有豐富的實踐經驗，掌握工程各個環節上的施工技術，這樣才能夠對工程的總體施工進行合理規劃并有效監督，同時，當工程質量出現問題時，能夠了解問題的關鍵所在，以便及時采取相關措施進行補救，以確保工程質量。第三，應樹立全局意識。項目部門在工程建設過程中并不是孤立存在的，它與工程建設單位、設計單位、工程主管部門、政府相關行政部門等有著密切聯系，因此，項目經理應樹立全局意識，與上述單位搞好關系，共同維護彼此的利益關系，在相互合作中提高工程質量。

2.加強職工培訓力度，提高其質量意識

工程建設職工的質量意識對工程建設的質量起著重要作用，因此，提高職工的質量意識是提高工程質量的重要舉措。首先，各項目部應定期召開質量專題會議。通過專題會議向職工講解有關工程質量的知識，讓每個職工充分認識到自身在工程建設過程中的重要作用，讓他們意識到自己的一舉一動都直接影響著工程的質量，讓“工程質量無小事”的觀念深入到每個職工的內心，讓職工在具體工作過程中切實樹立質量意識。第二，各項目部應加強對職工的培訓力度。讓職工通過培訓及時了解、掌握工程建設信息，提高施工技術，為提高工程建設質量打下基礎。第三，及時開展作業質量研討會。在工程建設過程中，應針對工程施工的實際情況及時開展作業質量研討會。例如，針對焊接技術達不到相關施工設計要求的問題，項目部應及時開展焊接質量研討會，邀請具有豐富焊接經驗的電焊工對具體施工過程中的焊接問題進行原因分析，并就焊接技術、焊接材料、防護措施等方面展開交流，促進職工在相互交流中提高施工技術，確保工程質量。第四，嚴格要求工程施工人員持證上崗。各項目部應要求各作業人員持證上崗，尤其是那些需要特殊技術、高空作業的崗位，務必要求有資質者上崗，這不僅是滿足工程技術上的需要，而且是確保工程質量的重要手段。

3.建立健全質量管理體系

建立一整套完善的施工產品質量管理體系是提高項目管理模式下質量管理水平的重要措施

首先，應建立完善的施工產品質量檢驗程序，遵循職工自檢——彼此互檢——專業檢查的程序，鼓勵職工對自己每日完成的工作主動進行檢查，確保自身工作符合相關標準及施工合同要求，同時做好詳細記錄，以供日后檢查、參考使用。在此基礎上，各項目部應組織從事相同作業的職工對彼此的施工質量進行檢查、評價，吸取對方的優勢，并就產品質量中存在的問題進行交流、探討，促進共同進步。最后，在完成自檢、互檢程序后，專門負責質量檢查的項目質量監管人員應嚴格按照產品質量標準及施工合同要求對施工產品進行質量檢查，嚴把產品質量關，切實做好產品質量監督、檢查工作。

4.做好施工材料質量控制工作

施工材料質量的好壞直接影響著施工產品的質量，為此，各項目部門嚴把施工材料質量關，按照相關標準、通過正當渠道采購施工材料。首先，應按照企業采購標準、規定，工程施工合同，工程設計方案等要求進行采購。在采購過程中，相關采購人員應嚴格審查產品說明書、產品質量檢測報告、質量鑒定書、質量檢測部門的檢測報告等，確保采購產品的質量。其次，重要材料應先進行取樣試驗，而且樣本的選取必須具有代表性。第三，尤其要注重新材料的使用，在其投入使用前，應先對其進行質量鑒定與試驗，并將鑒定試驗報告呈送給項目設計部門批準，經項目設計部門批準后才能進行采使用。

5.加強對施工設備的維護

施工設備是工程施工順利進行的物質保障，它對施工產品的質量產生重要影響。各項目部門應加強對施工設備的質量控制，具體來說就是嚴格控制施工設備的類型、性能參數與施工的具體要求相匹配。首先，應選用符合規定的施工設備，確保設備質量。其次，應根據工程施工的實際需要設定合理的性能參數，保證施工質量。第三，應定期對施工設備進行檢查、維護，這不僅有利于確保施工質量，而且有利于維護職工人身安全。

6.完善相關制度，加強質量管理

施工產品的質量保證離不開健全的制度建設，各項目部門應完善質量管理制度，促進質量管理的規范化。首先，項目部門應建立嚴格的施工現場管理制度與部門生產紀律，規范職工的作業活動，提高部門質量管理人員的管理水平。其次，各部門應建立質量獎懲制度。對符合施工要求的職工進行一定的獎勵，對違背施工標準、破壞施工質量的員工進行懲罰，通過獎罰分明的獎懲制度，切實提高職工的工作積極性，提高職工的質量責任意識。

五、結語

工程產品的質量直接關系到工程企業的切身利益，提高項目管理模式下的質量管理水平是目前工程企業亟待解決的問題。為此，各項目管理部門應采取相關措施切實加強質量管理，通過提高項目經理素質、健全質量管理體系、完善質量管理制度、提高職工質量意識等方法加強工程產品質量的監管力度，為提高工程產品質量創造條件。

參考文獻

[1]李必丹.“53”工程項目管理模式——建筑施工階段質量控制及評價方法[j].建筑科學，2007（06）：8-11.

第8篇：敏捷的項目管理范文

企業合同管理審計是改善企業內部管理水平，預防和降低經營、管理風險，維護企業的合法權益，促進企業價值的增加及目標的實現。在我國，對于包含合同管理審計的管理審計或增值型內部審計的理論研究還處于起步階段，其在實踐中的應用缺乏理論指導。我國加入WTO后，對外貿易的不斷增長，合同的種類和數量不斷增加，因合同而起的糾紛或造成的損失屢見不鮮。因此，在我國開展合同管理審計有著十分重要的意義。

(一)合同管理審計是企業發展的內在需要在市場經濟條件下，合同是連接各經濟主體、處理經濟關系的重要法律依據和經濟紐帶，同時也是產生糾紛的根源。企業合同的順利簽訂和履行，是企業得以發展的前提和基礎，是企業經營目標得以實現的重要保證。企業合同管理既是一種為了取得經營效益的經濟行為，也是一種保障企業經營活動順利進行的法律行為，是現代企業經營管理活動中的重要內容，是企業控制風險，增加價值、增強市場競爭力的基礎和保證。因此，在企業內部進行合同管理審計，促進企業加強和改善合同管理，是企業發展的必然選擇。

(二)合同管理審計是內部審計向增值型內部審計發展的需要國際內部審計師協會(ⅡA)在《內部審計職業實務準則》中對內部審計作了重新定義：內部審計是一種獨立、客觀的確認和咨詢活動，旨在增加組織價值和改善組織的運營。其通過運用系統的、規范的方法評價并改善風險管理、控制和治理過程的效果，幫助組織實現其目標。這一新定義表明內部審計是一項確認和咨詢活動，是為增加組織價值和改進經營、實現組織的目標服務的，同時也表明內部審計已進入了增值型內部審計的新時代。內部審計要充分發揮自己獨特的作用，充分體現自身的價值，須積極開展合同管理審計，為增加企業價值服務。

二、企業合同管理審計的方法與內容

根據企業的管理模式和要求、合同數量的多寡、內部審計機構資源等的不同，合同管理審計可以采取項目管理式審計和過程參與式審計兩種模式。

(一)項目管理式審計項目管理式審計是有重點、有目的地將合同管理納入年度審計計劃，形成特定審計項目，并實施相應審計程序的審計模式。項目管理式審計主要審查合同的管理是否規范、有效，其主要內容包括四個方面：一是合同管理機構或管理網絡的審查。企業的合同管理應首先建立健全管理機構或管理網絡，審計時應著重審計企業合同管理機構或管理網絡的設置是否合理；各機構之間的分工和職責是否明確，上下左右關系是否協調；組織最高領導層與合同管理機構及各個機構之間、各機構相互之間的信息交流是否充分；合同管理流轉是否科學、有效；相互之間的控制是否有效；合同的履行是否受到定期檢查等合同。二是管理人員素質的審查。企業合同管理人員的素質關系到企業合同管理工作的優劣，必須重視對合同管理人員素質的審查。首先應審查合同管理人員是否具備專業知識；其次應審查合同管理人員是否熟悉企業的內部運作流程和外部信息。此外，還應審查其是否具有較強的組織能力和協調能力，敏捷的洞察、分析能力，嚴密的邏輯思維能力，較強的責任心等。三是合同管理制度的審查。首先審查合同管理制度是否健全，尤其是一些重要的合同管理制度是否是根據企業實際而制定，包括：合同歸口管理和分類專項管理制度、合同示范文本制度、合同授權委托制度、合同的審查制度或審計審簽制度、合同的鑒證、公證制度、合同專用章管理制度、合同臺賬制度、合同檔案制度、市場調研制度、大件大宗企業采購(包括物資、服務、工程等)或資產處置的制度。在對合同管理制度的健全性進行測試和評價后，還應對這些制度的執行情況進行檢查。四是合同執行結果和管理效果的審查。主要審查合同內容是否得到全面、嚴格地履行；審查有無合同違約、違約的原因及違約處理結果，如對方違約，是否及時組織索賠；如本方違約，責任人是否向分管領導提交書面報告，經審批后辦理賠償手續，并追究相關責任；協商不成的合同糾紛是否及時上報上級領導和法律部門，通過申請仲裁或向人民法院解決合同糾紛。另外，還要審查合同管理效果是否達到合法、規范、效率、效益的要求。

(二)過程參與式審計過程參與式審計是由專職內部審計人員對企業內部所簽合同進行審計審簽，參與監督合同管理的部分重要過程，實現合同審計審簽的日常化。其審計的主要內容包括以下幾方面：一是審“該不該簽”，即對合同項目的可行性審查和效益性審查。應該檢查合同項目是否列入年度計劃，或經組織內有批準權的部門或領導批準；檢查合同項目是否經過可行性研究或項目評估，其技術性、經濟性是否達到了先進、合理；檢查與立項有關的文件資料的真實性、可靠性；檢查合同標的數量是否適當，企業的生產、經營能力是否能滿足對方的要求，或者合同標的數量是否能滿足企業的生產、經營的需求；檢查合同履行時間是否充分考慮了企業的實際生產經營能力或實際需要。二是審“跟誰簽”和“以什么樣的價格簽”，即對合同簽約主體的選擇和合同價格選擇的合理性、適當性進行的審查。首先，對合同經辦部門是否進行市場調研，是否采用了一定的合理方式確定合同主體和合同價格進行審查。其次，應對合同簽約主體的合法性進行審查。當事人在訂立合同時必須具有相應的民事行為能力。三是審“怎么簽”，即對合同的形式、文本格式和合同條款進行審查。按照民法一般原則，合同屬于不要式行為。審查時，首先注意合同形式是否符合法律、行政法規等規定。其次應審查合同文本的規范性。簽訂合同應當盡可能使用國家推行的示范文本，以保證合同條款的完備。對企業有特殊要求的，示范文本不能滿足的，企業可以自行制定合同文本，但應向工商行政管理部門辦理審批備案手續。對其他沒有示范文本的，采用手寫或微機打印的合同，要特別注意一式多份合同條款的一致性，防止被他人篡改內容，引起合同糾紛。在審查合同形式的合法性和文本格式的規范性后，要重點對合同條款的完備性進行審查。《合同法》規定，合同的內容由當事人約定，一般包括以下條款：當事人的名稱或者姓名和住所；標的；數量；質量；價款或者報酬；履行期限、地點和方式；違約責任；解決爭議的方法。因此，審計人員應當按照合同的性質，依據相應的法律、法規對合同條款進行認真審查，確定合同主要條款有無遺漏，各條款內容是否具體、明確、切實可行，避免因合同條款不全或過于簡單、抽象、原則，給合同履行帶來困難。

三、企業合同管理審計應注意的問題

企業合同管理審計過程中不可避免也存著以下方面的問題，為提高合同管理審計的效率應其予以重視。

第9篇：敏捷的項目管理范文

【關鍵詞】工程項目 動態聯盟 運作機制

1 工程項目組織動態聯盟概述

1.1傳統工程項目組織模式的困境

在傳統的建筑企業組織管理中，我國的建筑企業紛紛采用了集團化的組織模式。隨著市場需求不確定性的加劇和市場機遇把握難度的日益提高，這種傳統的組織結構己經越來越不能適應。

1.1.1建筑企業龐大且固定的集團化組織結構，使其難以對變化著的市場做出敏捷的反應。由于工程項目產品的單一性，建筑企業需要針對不同的項目分析其由于地域、技術條件、文化等因素造成對工程實施的影響。

1.1.2工程成本高。激烈的競爭己經使企業利潤大幅下降，不能形成規模經濟進一步造成了項目利潤的急劇下降，將嚴重影響建筑企業在面對國際市場時的生存能力。

1.1.3集團化組織模式在其組織結構上的不足。平級項目部之間缺乏必要的溝通，共分利益且互相推卸責任，只考慮自身承擔的項目部分的實際情況，而不考慮整個項目的最終成果。

1.2動態聯盟的概念

動態聯盟這一提法從產生到現在只有10多年的時間，許多學者對企業動態聯盟進行了研究，但對于動態聯盟的概念，至今還沒有形成一個完全的統一的定義。本文給出的定義為：動態聯盟是兩個或兩個以上的企業或者特定的事業部門或職能部門，為了實現共同的目標，通過公司協議或聯合組織等方式而結成的一種網絡式的聯合體；是那些欲結盟的企業在自愿互利的原則下，出于降低交易費用、減少不確定性、實現優勢互補等目的，以契約的方式結合起來的共同提高企業市場競爭力的合作模式。

1.3工程項目組織動態聯盟的定義及其優勢

工程項目組織動態聯盟就是立足于建筑行業的特點，以施工聯合體為基礎，吸收動態聯盟的思想，針對具體的大型施工項目，突破原有建筑企業的有形界限，充分利用外部資源，通過建筑企業之間的最佳資源組合，創造出超常的競爭優勢而進行的臨時組合，依靠現代化的網絡通訊設施達到資源共享、優勢互補，項目結束后，原來的資源組合方式予以解散。它相比于傳統的集團化組織模式在作用效果上有明顯的優勢：

第一，聯盟借助現代信息和通訊技術的強大支持，采用無層級、扁平化的管理組織方式，提高決策效率。第二，扁平化的網絡組織使權力由垂直變為水平，組織成因獲得極大的自由而形成和諧、相互信任的關系。第三，通過信息技術進行溝通和協調，使信息傳遞實時、動態化，同時能極大地降低組織成本。第四，針對工程項目的建筑產品單件性，建筑企業的動態聯盟強調合作的一次性，暫時性。動態聯盟強調時效性，具有高度的彈性和靈活性。

2 工程項目組織動態聯盟模式的構建

2.1動態聯盟的組建原則

工程項目組織動態聯盟結構的確定應該充分考慮具體工程項目的特點、所需資源的分布情況、聯盟活動的環境基礎條件等因素，并在一定的原則下實施結構組建。

2.1.1目標導向原則。動態聯盟構建的目標是抓住市場機遇，提高組織在市場中的競爭力。據此，應該根據工程項目的資源需要對各個盟員企業的資源進行整合，獲得生產的有效形式，實現建筑制造所追求的目標。

2.1.2學習性原則。通過動態聯盟，盟員企業要互相借鑒彼此的經驗，專心培養自己的核心能力。

2.1.3共享理念原則。動態聯盟的思想是各個盟員企業資源能力的整合共享思想，強調企業的雙贏理念。依靠盟員企業的整合力量實現整體優勢，從而創造出1+1＞2的利益。

2.1.4信譽原則。在動態聯盟中，特別注意加盟各方的信譽。若盟員的信譽等級高，則它將有更多的機會參與到聯盟中，贏得更多的利益機會。

2.2項目動態聯盟的組織模式

作為工程項目管理的建筑業企業群體的動態聯盟組織，它的運營方式一般是面向建筑產品的全過程。動態聯盟組織的描述可分為四個層次：動態聯盟組織、項目部、專業承包隊伍和勞務分包組織。但無論哪一個層次，其伙伴合作的形式具有多樣性和靈活性。概括起來主要有五種方式：

2.2.1供應鏈式。供應鏈式是對整個供應鏈系統進行計劃、協調、操作、控制、和優化的活動和過程，這種合作形式是以建筑產品為主線進行的，并建立在建筑產品的價格、質量、進度等基礎上相當穩定的合作，合作企業之間是上下游的關系。在工程項目建設中，以在建工程項目所需人、材、機為主要的對象展開合作，由設備供應商、原材料供應商、項目建造商組建成聯盟。

2.2.2總承包式。對總承包發包的項目，可在招標前若干施工企業、設計單位和材料供應商以動態聯盟方式組建施工聯合體進行總承包投標，中標后根據聯合協議以動態聯盟的方式進行工程建設。也可在中標后，由總承包企業組建設計單位、施工分包單位和材料設備供應商的動態聯盟，以動態聯盟方式進行工程建設。

2.2.3轉包分包式。由于工程項目的工程量一般都很大，總承包商不可能獨立完成整個項目，而會將項目中的一部分工作量轉包給一個或多個分包商。業主只與總承包商進行溝通，不直接與分包商聯系。總承包商對工程項目提出質量、價格、進度等的要求，各分包企業組織完成，總承包商負責管理協調各分包商。

2.2.4插入兼容式。租賃市場、勞務建設工程管理的企業聯盟的承包商可以通過項目管理過程的需要，通過設備市場、人才市場等建立二級市場，使之與企業的自身核心資源結合，這種合作是動態聯盟具有很強的可塑性和靈活性。

2.2.5網絡式。網絡式動態聯盟是建立在自愿合作和信息與活動交互基礎上的，動態聯盟體內的各方未必有合同關系，各方之間根據聯盟協議進行合作，這使合作各方能夠在平等地位上真正實現資源共享和風險共擔。項目參與各方之間通過聯盟體內部的信息溝通，及時了解施工進度，協調解決施工過程中出現圖紙提供和材料設備的供應延誤、施工工期拖延、專業工程的交接與配合等問題。這是一種真正意義上的動態聯盟模式，是項目組織模式未來發展的趨勢。

3 建筑企業動態聯盟模式的運作

3.1聯盟的利潤分配機制

動態聯盟是一個以市場機遇為主要驅動力的、暫時的組織結合體，對參與動態聯盟的伙伴來說，其根本目的是為了取得一定的經濟利益，而對于動態聯盟的每一個盟員企業來說，收益和風險是不可分割的。因此，科學、合理的利益分配機制是決定動態聯盟成敗的關鍵因素。

對于基于大型工程項目而組建的建筑企業動態聯盟，我們不能僅僅從投資額的大小出發確定收益比例，而需要充分考慮動態聯盟企業中盟員企業投資所承擔的風險大小，從而保證動態聯盟能夠真正實現“風險分擔，收益共享”。

3.2聯盟利潤分配模式

3.2.1產出分享模式，參與合作的所有成員(包括盟主和盟員) 按一定的分配比例系數從合作最終的總利潤中分得自己應得部分，是一種利益共享、風險共擔的分配模式。

3.2.2固定支付模式，盟主企業根據其他成員承擔的任務按事先協商好的酬金給其從合作最終的總利潤中支付固定的報酬，而其享有合作的其余全部剩余，同時也承擔全部風險。這種分配模式接近市場交易的模式。

3.2.3混合模式，動態聯盟成員既從聯盟取得固定的報酬，同時也從總利潤產出中按一定分配比例取得剩余。

模式的具體選用視實際的市場機遇的性質、產品競爭力、發展戰略和風險態度等因素而決定。

3.3聯盟協調溝通機制

建筑企業動態聯盟體聯盟各方既有合作的愿望，又有目標的差異，在項目的運行中，盟員們都力圖擴大自身的收益，同時一方利益的取得又依賴于各方的合作，因而動態聯盟體的協調可以看作具有聯盟性質的合作式協調，協調的內容廣泛并且存在于聯盟創立、運行、解散整個生命周期，協調的過程就是盟員在各種方案上反復移動的過程，直到在某一個方案達成妥協一致。

3.4聯盟的風險控制機制

風險與收益是共存的，有收益的項目就必然有風險。如何建立風險控制機制，從事前、事中、事后全方位的控制風險，對項目的全過程進行有效的控制，是項目管理的關鍵。

3.4.1聯盟體內部的風險管理措施

（1）慎重選擇合作伙伴。在組建動態聯盟時，合作伙伴的選擇是首要的任務。因為工程建設是風險事業，所選擇的伙伴應該能夠“同舟共濟”，共同承擔風險，這對是否完成工程、能否盈利至關重要。

（2）簽訂責權利明確的聯盟體協議。聯盟體協議是指為了投標獲取項目、實施項目進行協作，就各盟員企業的職責、權利和義務達成的協議。

3.4.2與工程有關的風險管理措施

與業主簽訂公平的工程合同。工程合同是連接業主和動態聯盟體的法律紐帶，業主和聯盟體在合同風險和利益分配中相互約束。工程合同必須公平，聯盟體應該說服業主采納工程合同條件，如FIDIC合同條件。聯盟體應該特別重視工程合同中的支付、報價、變更及索賠等條款，特別是在合同實施期間發生通貨膨脹、變更、不可抗力等事件而導致的費用以及工期損失的補償。

3.4.3與外部環境有關的風險管理措施

動態聯盟在承攬某一個具體的工程項目時，應該適應當地的環境，了解當地出現的新的法律、規章制度、對手，同時與當地政府以及相關部門建立良好的關系，在項目執行過程中，聯盟體有必要建立各種渠道與項目各個參與方進行良好的溝通，并且維護好這些交流渠道。

4 結論

通過對我國工程項目的現行組織模式進行了深入的分析，揭示了其傳統組織模式轉變的原因。在充分借鑒制造業動態聯盟思想的基礎上，根據我國建筑企業的自身特征，提出了建筑企業動態聯盟組織模式。研究結論如下：

4.1通過對我國建筑業傳統組織模式的分析及入世之后我國建筑企業發展方向的研究得出:我國建筑企業目前最根本的任務是增強自身的核心競爭力，變傳統的單個競爭為聯合競爭，借助外部資源來發展自身優勢，轉向動態聯盟組織模式。

4.2從建筑企業從事工程項目建設的過程和方式分析，建筑企業動態聯盟是可行的，符合我國建筑企業發展的需要。

4.3針對具體的工程項目，本文建立了動態聯盟的利潤分配機制、協調溝通機制、風險控制機制。

參考文獻：

[1]賈平.企業動態聯盟[M].北京:經濟管理出版社，2003.

[2]林鳴，馬士華.動態聯盟——項目管理新模式[M].北京，電子工業出版社，2003.

[3]宋金昭，動態聯盟在建筑企業中的應用研究[A].管理科學與工程，2004.

[4]金維興，21世紀中國建筑企業管理模式的總體構思[J].中國科學基金，NO.2， 2000.

[5]趙艷萍，王棟.動態聯盟管理協作風險的分析[J].商場現代化，2006，(33).

[6]陳一鳴，高陽.動態聯盟企業的一種組織結構[J].技術經濟與管理研究，2001， (06).