敏捷的項目管理精選(九篇)
前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的敏捷的項目管理主題范文，僅供參考，歡迎閱讀并收藏。
第1篇：敏捷的項目管理范文
關(guān)鍵詞：關(guān)鍵鏈項目管理；敏捷軟件開發(fā)；進度管理
前言
隨著軟件行業(yè)的深度發(fā)展，軟件開發(fā)項目的復(fù)雜性大大提高。軟件項目開發(fā)中的需求變化性較強，開發(fā)的資金、技術(shù)支持等條件不斷變化，導(dǎo)致傳統(tǒng)的軟件開發(fā)項目管理方法已經(jīng)不能滿足日益進步的開發(fā)需求?；陉P(guān)鍵鏈項目管理思想的敏捷軟件開發(fā)就是在這一大背景下產(chǎn)生的，敏捷開發(fā)能夠?qū)崟r根據(jù)需求變更改變開發(fā)進度管理，注重人才價值與軟件價值的互通，注重團隊合作，注重與需求方客戶合作，所以越來越多的軟件行業(yè)、企業(yè)與開發(fā)團隊開始采用這種軟件開發(fā)模式。
1 基于關(guān)鍵鏈項目管理的敏捷軟件開發(fā)項目現(xiàn)狀研究
1.1 關(guān)鍵鏈項目管理綜述
關(guān)鍵鏈項目管理提出于1997年，是根據(jù)項目管理發(fā)展?fàn)顩r將項目管理中的約束理論與實際管理工作實踐相結(jié)合所提出的創(chuàng)新型的、適用性較強的管理模式，對各行業(yè)的項目管理工作都能起到很好的推廣和借鑒作用。[1]關(guān)鍵鏈項目管理法通過對項目的進度計劃及約束項目管理因素的分析，合理調(diào)度項目計劃中的全部資源，消除影響項目進度的約束性因素，減少不合理的工作計劃對項目本身的影響，集中管理項目時間進度，控制項目整體進度。關(guān)鍵鏈項目管理是一種新型的管理模式，包含科學(xué)的項目進度管理方法及項目整體資源的合理調(diào)配方法，既能滿足項目發(fā)開中進度計劃的需求又能保證項目目標的完成，同時又能有效的解決項目進行中影響項目進度的風(fēng)險性因素，這些有效的項目進度管理方式都給敏捷軟件開發(fā)項目提供了很好的管理參考。
1.2 敏捷軟件開發(fā)項目的現(xiàn)狀
我國的敏捷軟件開發(fā)項目由于起步晚，缺乏實踐經(jīng)驗，正處于探索研究階段，其過程中必然出現(xiàn)很多問題。其中，造成敏捷軟件開發(fā)項目管理出現(xiàn)問題的最重要缺陷因素就是項目進度的管理，體現(xiàn)在以下幾個方面：第一，忽略外界因素對項目開發(fā)進度管理的約束性因素。[2]敏捷軟件開發(fā)是一個涉及面廣，復(fù)雜性高的項目工作，很多外界因素包括資金、技術(shù)、資源、人員等都會對項目進度造成重大影響，而現(xiàn)在的敏捷軟件開發(fā)項目并沒有對其產(chǎn)生足夠重視。第二，約束因素問題得不到有效解決。制約敏捷軟件開發(fā)項目進度的因素有很多，在得不到重視的情況下解決問題變得更加困難，這就大大延長了項目的工期，同時又帶來了新的不可預(yù)計的影響因素出現(xiàn)的風(fēng)險幾率。第三，對項目參與人員的主觀能動性重視不足。主觀能動性不強，工作態(tài)度不積極，缺少創(chuàng)新思考，缺乏解決問題的創(chuàng)新思路，這些都會大大延緩項目的進度，拖慢項目工期，使得敏捷軟件開發(fā)項目整體失敗。
2 基于關(guān)鍵鏈的敏捷軟件開發(fā)項目進度管理建議
2.1 改變管理模式
敏捷軟件開發(fā)項目環(huán)節(jié)多，項目運行復(fù)雜，因此要改變舊式的分散管理模式，將成本管理、資源管理、風(fēng)險管理及進度管理進行集中控制，做到管理統(tǒng)一。這樣有利于項目成本的節(jié)約，項目資源的合理調(diào)配，項目風(fēng)險的有效控制，保證項目的正常運行并順利完成。[3]在做到集中管理的同時要側(cè)重項目進度管理，對項目進度管理保持高度的重視。因為項目進度管理是整個敏捷軟件開發(fā)項目的重點工作，各種因素都會對項目進度產(chǎn)生嚴重甚至決定性的影響，只有側(cè)重項目進度管理工作，保持高度重視才能保證項目進度的順利完成，避免項目延期甚至項目失敗的情況。
2.2 合理調(diào)配項目資源
敏捷軟件開發(fā)項目進度的管理離不開項目資源的支持，其中最重要的就是資金、技術(shù)及人員的支持。資金支持不及時會導(dǎo)致項目進度的拖延；技術(shù)更新支持不及時會拖慢甚至?xí)和ｍ椖窟M度；管理人員及技術(shù)人員落實不到位會嚴重影響項目的整體進度，給敏捷軟件開發(fā)項目的進度管理造成極大困難。所以，要合理調(diào)配項目資源，將整體項目的資金、技術(shù)、人員更多的投入到項目進度管理環(huán)節(jié)，保證項目進度的良好進行進而保障敏捷軟件開發(fā)項目的順利完成。
2.3 及時處理約束因素
在敏捷軟件開發(fā)項目的進度管理中要及時解決制約進度的各種因素問題，避免因項目資金、技術(shù)、人員、管理等項目資源的匱乏問題產(chǎn)生的進度滯后現(xiàn)象。出現(xiàn)影響項目進度的因素必須加大各種資源的投入，及時解決，保證項目進度。同時，問題的解決方式要在盡量滿足項目進度的前提下尋找針對性的或者可替代性的解決方法，杜絕因困難問題難以解決而進行進度計劃修改，保證項目進度，更好的做好項目進度管理工作。
2.4 發(fā)揮人員主觀能動性
在敏捷軟件開發(fā)項目進度管理工作中要重視人的作用，激發(fā)其工作積極性與創(chuàng)造性，解決敏捷軟件開發(fā)項目進程中的技術(shù)難題及工作適應(yīng)性問題，豐富項目的人員、技術(shù)資源，保障項目進度的按期進行甚至因技術(shù)創(chuàng)新、管理有序而提前完成項目工期任務(wù)。
3 結(jié)束語
關(guān)鍵鏈項目管理是一種先進的項目管理模式，能夠為項目的正常運行直至順利完成提供管理保障?；陉P(guān)鍵鏈的敏捷軟件開發(fā)項目進度管理，要做到側(cè)重進度管理，及時解決阻礙進度管理工作的資源問題，合理調(diào)配項目資源，保證項目進度管理工作的順利進行，進而保障項目的順利完成。同時要結(jié)合實際情況，對敏捷軟件開發(fā)項目進度管理進行科學(xué)合理的調(diào)整，保證項目完成的高質(zhì)、高效。
參考文獻
[1]胡丹.基于關(guān)鍵鏈的敏捷軟件開發(fā)項目進度管理研究[D].浙江工業(yè)大學(xué)，2013.
[2]張雪嬌.基于關(guān)鍵鏈技術(shù)的敏捷軟件開發(fā)項目管理研究[D].華中科技大學(xué)，2011.
[3]楊光.軟件開發(fā)項目進度管理模型構(gòu)造與系統(tǒng)仿真[D].北京郵電大學(xué)，2009.
第2篇：敏捷的項目管理范文
關(guān)鍵字：：敏捷項目管理；敏捷；KANBAN
互聯(lián)網(wǎng)運維項目專門面向互聯(lián)網(wǎng)數(shù)據(jù)中心和云計算服務(wù)平臺，項目范圍包括數(shù)據(jù)中心容量和性能提升、設(shè)備替換、技術(shù)改造、產(chǎn)品部署等等。由于互聯(lián)網(wǎng)運維項目的獨特性，很多企業(yè)仍然沿用傳統(tǒng)瀑布式的項目管理方法，無法快速交付高質(zhì)量的運維項目。如何提升互聯(lián)網(wǎng)運維項目管理的整體水平，對敏捷運維項目管理的方法論研究和實踐的重要性就不言而喻。
互聯(lián)網(wǎng)運維項目的敏捷項目管理方法研究
KANBAN（看板）是敏捷的一種方法論，是一種敏捷的變更管理方法。目前它被用于最廣泛地管理 IT支持和維護工作。也更適合于有一個恒定的正在進行的工作流程的IT部門或互聯(lián)網(wǎng)運維中心，而不是項目的可交付成果。
KANBAN的核心是要賦予項目團隊管理工作量，定期交付業(yè)務(wù)價值，團隊要提交真正可以交付的工作：不多也不少，KANBAN也是一種時間驅(qū)動器，來管理任何點的工作 （WIP，working in process）。如果業(yè)務(wù)要求解決更高優(yōu)先級的工作，利益相關(guān)者必須確定當(dāng)前的哪些工作可以騰出足夠的人力資源來滿足高優(yōu)先級業(yè)務(wù)需求。同樣在開放 的WIP 隊列中，團隊和利害關(guān)系方可以確定應(yīng)該專注的下一步的最高優(yōu)先工作。
KANBAN也是組織和團隊解決工作瓶頸，克服障礙，以及持續(xù)改善的文化，最大限度地提高他們的生產(chǎn)力?？窗遄岉椖繄F隊基于部門的具體要求建立審查周期和釋放時間。為了適應(yīng)敏捷文化，許多從業(yè)者也已經(jīng)開始使用混合的方法，如結(jié)合SCRUM的KANBAN，將有效的敏捷實踐，如每日站立會議，也吸收進KANBAN。
互聯(lián)網(wǎng)運維項目的敏捷項目管理方法實踐成果
在經(jīng)過對敏捷KANBAN方法論的研究和多個項目進行實踐后，作者本人作為云服務(wù)運維項目經(jīng)理就開始和團隊一起進行了實踐，成果分享如下：
第一， 敏捷KANBAN項目管理方法最適合互聯(lián)網(wǎng)運維項目
我們云服務(wù)項目團隊在KANBAN實踐過程中吸收了SCRUM思想。管理方法以KANBAN為主，SCRUM為輔，主要以KANBAN搭載互聯(lián)網(wǎng)運維工作流程，同時采用SCRUM敏捷框架中的3個角色（PO，Team member，SCRUM Master）。
使用KANBAN方法符合了互聯(lián)網(wǎng)運維項目的多種特征，完全包容了具有高度依賴性和突發(fā)性特征的運維項目工作，是精益現(xiàn)場工作管理方式的又一種行業(yè)應(yīng)用。另外KANBAN所搭載的工作流就如水流一樣，要向前不停流動。項目團隊所追求的就是水流的速度越來越快，水流的管道越來越粗，其實也就滿足了運維項目的業(yè)務(wù)目標和客戶價值需求。同時KANBAN方法里面的工作項有優(yōu)先級排序，有交付物驗收和質(zhì)量要求，并不僅僅是追求項目速度和交付物數(shù)量。
使用SCRUM的思想主要是體現(xiàn)敏捷思想的價值觀，期望每個成員在信任、開放、尊重、承諾的意識下積極主動的工作。我們在實踐中的KANBAN也有daily standup meeting，每天或適時的進行多個項目的狀態(tài)同步和問題同步，會后進行問題分析和解決應(yīng)對。并且項目經(jīng)理與團隊一起確認工作的輕重緩急，實時協(xié)調(diào)人力資源，把人力集中在優(yōu)先級最高的任務(wù)上。
第二，互聯(lián)網(wǎng)運維項目使用的敏捷KANBAN工作板
我們知道，吸取了SCRUM敏捷思想的KANBAN項目管理方法，最直接的體現(xiàn)方式就KANBAN工作板，我們云服務(wù)項目團隊的KANBAN工作板如圖所示。
橫軸是互聯(lián)網(wǎng)運維項目工作流，任務(wù)從左向右流動，大的流動過程分別是：計劃好的項目任務(wù)清單，任務(wù)文檔和設(shè)計準備、任務(wù)實驗室階段完成、任務(wù)在產(chǎn)線階段實現(xiàn)、 任務(wù)Done。豎軸是按照優(yōu)先級排序的并在進行中的工作任務(wù)（WIP）。豎軸的WIP容納多個運維項目任務(wù)便簽條，并且用不用的便簽條顏色來區(qū)分不同的項目。每個便簽條有3項內(nèi)容：任務(wù)描述、任務(wù)擁有人、交付物開始日期和期望的結(jié)束時間。最下面放的是任務(wù)庫存。右下角是多個項目在一年之內(nèi)的路線圖。
接近1年的敏捷KANBAN項目管理實踐后， 團隊的凝聚體不斷提升，項目效率和質(zhì)量也明顯提高，同時也大大提升了項目交付度和滿意度。
結(jié)語
互聯(lián)網(wǎng)運維項目本身具有工作清晰性、變化隨時性，協(xié)調(diào)復(fù)雜性的特征。為了能夠最大化的避免運維項目的失敗，提升項目的效率和質(zhì)量，讓運維項目走上成功之大道，那我們就要未雨綢繆，以正確理念為指導(dǎo)，使用正確的敏捷項目管理方法，正確建立項目團隊，恰當(dāng)使用資源，做好項目監(jiān)控。只有這樣，才是企業(yè)互聯(lián)網(wǎng)運維項目管理良性發(fā)展的重要保障。
參考文獻：
[1]羅伯特?K?威索基.《有效的項目管理（第五版）》.（美）電子工業(yè)出版社，2012
第3篇：敏捷的項目管理范文
【關(guān)鍵字】軟件工程；熱點問題；探索
目前，人類已經(jīng)進入了信息社會的階段，軟件工程在計算機科學(xué)中競爭激烈，是處于前沿的學(xué)科。文章主要在目前的軟件工程中，分析其熱點技術(shù)及難題，并闡述其發(fā)展方向與研究現(xiàn)狀。
一、軟件工程的發(fā)展歷程
計算機硬件技術(shù)在二十世紀末得到了廣泛的應(yīng)用發(fā)展，為微電子計算機的推廣打下了堅實的基礎(chǔ)，而計算機軟件技術(shù)也應(yīng)運而生。那時生產(chǎn)的軟件有著作坊式、個體化的特征，單一的開發(fā)平臺，落后的開發(fā)工具，具備較差的程序設(shè)計語言功能。特別是在軟件維護工作方面，損耗巨額的物力、人力與計算機資源，不少程序具有編寫者的個性化特征，使其難以得到維護與修改。有的甚至放棄原來的計算機系統(tǒng)，對新軟件重新編寫。此外，各類軟件的結(jié)構(gòu)及規(guī)模差異性大，很難對軟件進行全面的維護，提高了軟件開發(fā)的成本。這種滯后的軟件開發(fā)工具、開發(fā)技術(shù)與生產(chǎn)方式落后的條件和飛速普及的電腦應(yīng)用及對軟件與日俱增的需求導(dǎo)致了不可調(diào)和的矛盾，導(dǎo)致形成了“軟件危機”。
當(dāng)前，軟件工程已經(jīng)發(fā)展了五十多年，逐步深入到社會生活的各個方面，應(yīng)當(dāng)說，當(dāng)代生活社會，基本上在每一個方面都關(guān)系到軟件工程。
二、軟件工程的研究熱點及現(xiàn)狀
軟件工程的熱點問題伴著軟件技術(shù)的發(fā)展而隨之變化的。即使在軟件工程的內(nèi)部領(lǐng)域，研究的熱點區(qū)域也處在變動之中。軟件工程的建設(shè)隊伍將由兩部分構(gòu)成，部分人是做軟件評估，另而另一部分人做的是軟件集成，主要是對軟構(gòu)件進行集成。
近年來軟構(gòu)件的應(yīng)用也慢慢興起。在一些公共的應(yīng)用方面，比如說軟件的初始化界面，通用軟構(gòu)件的應(yīng)用較為廣泛。但是，在各行各業(yè)的專業(yè)領(lǐng)域應(yīng)用方面，軟構(gòu)件的研發(fā)及推廣在我國仍屬于空白。這一工作的推行，首先是表明了各行各業(yè)對該專業(yè)領(lǐng)域中的知識形態(tài)予以分析歸類，并通過最新軟件的形式進行描述。假如這個全面展開這個工作，將會是一個浩大規(guī)模的系統(tǒng)工程，亟需各行各業(yè)的軟件專家與領(lǐng)域?qū)＜胰f(xié)作方可完成。
在開發(fā)軟件的過程中研發(fā)者開始應(yīng)用與研發(fā)軟件工具，以便對軟件項目管理與技術(shù)生產(chǎn)進行輔助，研發(fā)者還把軟件各階段的生命周期使用的軟件工具機動性地整合為一個團體，構(gòu)成可以持續(xù)性地支持軟件維護和研發(fā)整個過程的集成化軟件環(huán)境支援，以便從技術(shù)與管理兩個維度解決軟件危機的問題。
三、軟件工程的發(fā)展趨勢
（一）需求工程漸成熱點
需求工程將成為軟件工程發(fā)展的熱點，當(dāng)前業(yè)務(wù)創(chuàng)新日益復(fù)雜，同時分工更加專業(yè)化，區(qū)域組織的全球化以及互聯(lián)網(wǎng)級的交付速度，這些均對獲取需求的準確性及有效性提出了進一步的要求，其中Use Case技術(shù)（用例分析，也就是嘗試通過分析類來在理想狀態(tài)下完成用例）將會被大大的推廣應(yīng)用，而有關(guān)工具的研究也會變成熱點（如IBM Rational Requirements Composer，，Ravenflow等）。
用例的優(yōu)點在于它本身是未知的，它使用的是自然語言對用戶與目標系統(tǒng)的交互進行抽象，防止了混入設(shè)計、分析與完成細節(jié)，來確保用例能夠被不明白具體技術(shù)的測試人員和業(yè)務(wù)人員所真正掌握。此外，需求分析員又能夠便捷地經(jīng)由用例分析，把需求體系精簡為分析的模型。在這一進程中，需求分析員能夠更進一步地建立起基于用例的需求體系，而不用擔(dān)心分析模型會對需求造成干擾，進而達成分析和需求的隔離及高效互動。
（二）基于領(lǐng)域的構(gòu)架（DSSA）與模型驅(qū)動的開發(fā)（MDD）
伴著軟件應(yīng)用的發(fā)展和成熟，軟件已經(jīng)不再是以往的把手動流程自動化的要求，而漸漸變成業(yè)務(wù)創(chuàng)新的重要促進力量。所以，導(dǎo)入捕獲指定領(lǐng)域內(nèi)最先進需求及其實現(xiàn)架構(gòu)的DSSA變成行業(yè)客戶的關(guān)注重點之一。此外，DSSA的導(dǎo)入將大大降低模型驅(qū)動的開發(fā)（MDD）的門檻，也使得基于DSSA的MDD支撐工具變?yōu)榱丝赡埽M而能夠大大地促進開發(fā)效率并確保軟件的質(zhì)量，譬如，Telelogic的Rhapsody就為一個成功的基于實時嵌入式系統(tǒng)構(gòu)架的MDD工具。
（三）迭代/敏捷漸成標準
伴著越來越快的軟件交付的周期，迭代化開發(fā)漸漸變成大多數(shù)軟件開發(fā)團隊的關(guān)注熱點。同時，迭代對整個團隊的架構(gòu)、需求、測試能力及協(xié)同均帶來了較高的要求，目前不少開發(fā)團隊均在嘗試在軟件開發(fā)中導(dǎo)入迭代化開發(fā)的過程，敏捷目前被當(dāng)作是迭代化開發(fā)的一種導(dǎo)入方案，而敏捷的使用范圍其實比迭代化開發(fā)更加廣大。敏捷的三個要素為坦誠合作、迭代開發(fā)與自適應(yīng)性。而敏捷的核心即為坦誠合作，如不少軟件工程師所言，敏捷實質(zhì)上是與Social Engineering相關(guān)的。敏捷的重大作用在于它更多地考慮到了怎樣去激起開發(fā)人員工作的熱情，這是在軟件工程過去幾十年發(fā)展過程中沒有被重視和開發(fā)的領(lǐng)域。
（四）持續(xù)集成蓄勢待發(fā)
確保迭代化開發(fā)質(zhì)量的主要條件之一為持續(xù)集成，經(jīng)由持續(xù)集成能夠利用自動化的形式來盡可能自主地、盡快地確保代碼的質(zhì)量。伴著敏捷與迭代的發(fā)展，相關(guān)的持續(xù)集成工具變成目前市場上新的發(fā)展趨勢（如持續(xù)集成框架IBM Rational BuildForge， 開源軟件CruiseControl，代碼靜態(tài)分析工具Klocwork Insight，IBM Rational Software Analyzer等）。
持續(xù)集成為一項復(fù)雜的系統(tǒng)工程，組織首先亟需把目前的配置管理/變更管理工具與Build環(huán)境緊密集成，并達到自動化Build過程，再依照企業(yè)/項目/產(chǎn)品的狀況，定義怎樣自動化地對軟件質(zhì)量進行檢測（單元測試、代碼靜態(tài)分析或冒煙測試），并確定所需的自動化生成的管理報表。
（五）基于實踐的過程框架方興未艾
開發(fā)角色的專業(yè)化的與分布的全球化均需要軟件開發(fā)過程愈加規(guī)范，而敏捷又指出過程一定緊密符合項目的實際需求，而以為傳統(tǒng)的大一統(tǒng)的過程難以滿足這個需求。新一代的過程將是以實踐為重點的，項目可以經(jīng)由組裝所需的不同實踐來得到貼近項目所需的過程。當(dāng)前，逐步求精式的過程改進已經(jīng)成為了可能，對于一個軟件組織來說，倘若已經(jīng)成立一個較為成熟的軟件開發(fā)過程，但認為這一過程并不符合所有項目的實際需求，那么當(dāng)前能夠考慮的是用實踐的方法去重新組織現(xiàn)有的流程，以便項目組能夠通過實踐為單位來達成符合項目實際的流程。此外，該組織也能夠把適用于本組織的業(yè)界流行的實踐引入到現(xiàn)有的流程當(dāng)中。
參考文獻：
[1]尹峰. 軟件工程的若干熱點技術(shù)發(fā)展現(xiàn)狀與展望[J].長沙大學(xué)學(xué)報，2006（09）.
第4篇：敏捷的項目管理范文
世界五大軟件開發(fā)教父之一的Matin Fowler認為，當(dāng)前只有敏捷的軟件開發(fā)模式才能夠使IT跟上業(yè)務(wù)變化的腳步，只有敏捷的開發(fā)模式才能使軟件實現(xiàn)快速交付的同時又能成為一個高質(zhì)量、低成本的軟件。
敏捷開發(fā)作為一個新的軟件開發(fā)模式的新名詞，其中蘊涵著無限的商機，同時，也是對中國軟件企業(yè)的一次嚴峻的考驗。對于起步遠遠滯后于西方的中國軟件業(yè)而言，各種提高軟件開發(fā)速度及降低軟件開發(fā)成本的方式和措施都是值得探討與借鑒的。筆者認為敏捷開發(fā)模式對于中國的軟件企業(yè)正是一個行之有效的開發(fā)方式。
問題纏繞軟件開發(fā)
軟件開發(fā)過程中問題多多，這不是新發(fā)現(xiàn)。早在上世紀60年代，北約(NATO)就提出了軟件危機這一概念。在《人月神話》一書中，軟件開發(fā)則被喻為讓眾多史前巨獸痛苦掙扎，卻無力擺脫的焦油坑。隨著需求和應(yīng)用的日趨深入與復(fù)雜化，軟件開發(fā)的難度和遇到的問題以幾何級數(shù)形式增長，焦油坑也由此變得更深、更大。
復(fù)雜程度高、開發(fā)周期長、結(jié)果無保證，這是軟件開發(fā)的通病。針對這些問題，人們創(chuàng)造了N種方法，并由此產(chǎn)生了軟件工程學(xué)。而在實際工作過程中，軟件開發(fā)的多變性和不可控制性，仍可輕易摧垮項目開始時項目組苦心經(jīng)營的開發(fā)體系和方法，無論是業(yè)界公認的需求、變更、人員流動，還是各種看起來并不起眼的小事件。
以人為本的敏捷開發(fā)
敏捷開發(fā)(Agile Software Development)是一種以人為核心、迭代、循序漸進的開發(fā)方法。在敏捷開發(fā)中，就如同項目管理中將工作任務(wù)及工作目標層層分解一樣，把軟件項目的構(gòu)建切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。簡言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。
通過上面的定義可以看出，敏捷開發(fā)其實借鑒了大量軟件工程中的方法。是傳統(tǒng)軟件開發(fā)意義上的改善，而非創(chuàng)新。例如在傳統(tǒng)的軟件開發(fā)中，把設(shè)計和構(gòu)建這兩個過程分開進行，設(shè)計完成之后，再按照設(shè)計構(gòu)建。
實際上，由于需求在不斷變化，因此在軟件開發(fā)的過程中，很難把設(shè)計和編程完全區(qū)分開來。而在敏捷開發(fā)中，先搭建一個比較粗的主構(gòu)建框架，只對用戶目前感興趣的部分詳細開發(fā)，并很快交付使用，在使用過程中，按用戶的需求進行疊蓋修正，周而復(fù)始，循序漸進的開發(fā)軟件產(chǎn)品直到完成。
正如ThoughtWorks的首席科學(xué)家Matin Flower所說：“在敏捷軟件開發(fā)的過程中，我們每兩周都會得到一個可以工作的軟件，這種非常短的循環(huán)，使終端客戶可以及時、快速地看到花錢構(gòu)建的軟件是一個什么樣的結(jié)果。”因此敏捷開發(fā)也可理解為在原有軟件開發(fā)方法基礎(chǔ)上的整合——取其精華，去其糟粕。
敏捷開發(fā)的特點
敏捷方法主要有兩個特點，這也是其區(qū)別于其他方法，尤其是重型方法的最主要特征:
敏捷開發(fā)方法是“適應(yīng)性”(Adaptive)而非“預(yù)設(shè)性” (Predictive)。
這里說的預(yù)設(shè)性，可以通過一般性工程項目的做法理解，比如土木工程，在這類工程實踐中，有比較穩(wěn)定的需求，同時建設(shè)項目的要求也相對固定，所以此類項目通常非常強調(diào)施工前的設(shè)計規(guī)劃。只要圖紙設(shè)計得合理并考慮充分，施工隊伍可以完全遵照圖紙順利建造，并且可以很方便地把圖紙劃分為許多更小的部分交給不同的施工人員分別完成。
然而，在軟件開發(fā)的項目中，這些穩(wěn)定的因素卻很難尋求。軟件的設(shè)計難處在于軟件需求的不穩(wěn)定，從而導(dǎo)致軟件過程的不可預(yù)測。但是傳統(tǒng)的控制項目模式都是試圖對一個軟件開發(fā)項目在很長的時間跨度內(nèi)做出詳細的計劃，然后依計劃進行開發(fā)。所以，這類方法在不可預(yù)測的環(huán)境下，很難適應(yīng)變化，甚至是拒絕變化。
與之相反的敏捷方法則是歡迎變化，目的就是成為適應(yīng)變化的過程，甚至能允許改變自身來適應(yīng)變化。所以稱之為適應(yīng)性方法。
敏捷開發(fā)方法是“面向人” (people oriented)而非“面向過程”(process oriented)。
Matin Flower認為：“在敏捷開發(fā)過程中，人是第一位的，過程是第二位的。所以就個人來說，應(yīng)該可以從各種不同的過程中找到真正適合自己的過程?！边@與軟件工程理論提倡的先過程后人正好相反。
在傳統(tǒng)的軟件開發(fā)工作中，項目團隊分配工作的重點是明確角色的定義，以個人的能力去適應(yīng)角色，而角色的定義就是為了保證過程的實施，即個人以資源的方式被分配給角色，同時，資源是可以替代的，而角色不可以替代。
然而，傳統(tǒng)軟件開發(fā)的這些方法在敏捷開發(fā)方式中被完全顛覆。敏捷開發(fā)試圖使軟件開發(fā)工作能夠利用人的特點，充分發(fā)揮人的創(chuàng)造能力。
敏捷開發(fā)的目的是建立起一個項目團隊全員參與到軟件開發(fā)中，包括設(shè)定軟件開發(fā)流程的管理人員，只有這樣軟件開發(fā)流程才有可接受性。同時敏捷開發(fā)要求研發(fā)人員獨立自主在技術(shù)上進行決策，因為他們是最了解什么技術(shù)是需要和不需要的。再者，敏捷開發(fā)特別重視項目團隊中的信息交流，有調(diào)查顯示：“項目失敗的原因最終都可追溯到信息沒有及時準確地傳遞到應(yīng)該接受它的人。”
敏捷開發(fā)的問題和思考
雖然敏捷開發(fā)是個行之有效的軟件開發(fā)模式，但是任何模式和方法的建立都是基于理論的基礎(chǔ)，往往和現(xiàn)實的情況存在差異，這樣就會對軟件企業(yè)操作及執(zhí)行帶來很大的困難，甚至是誤導(dǎo)。所以，僅僅提出敏捷開發(fā)的模式是不夠的，對敏捷開發(fā)的議題的討論并沒有終結(jié)。下面僅就筆者理解基礎(chǔ)上提出一些問題的參考。
項目內(nèi)部協(xié)調(diào)的困難加大
敏捷開發(fā)要求將大項目分解成為很多小項目，這樣雖然易于考察、易于管理和易于控制，但是這樣也帶來了項目內(nèi)部各個小項目協(xié)調(diào)問題。對于各個小項目的執(zhí)行，人員分配及其他資源分配的沖突及進度的沖突是最主要的沖突，而且這些沖突如果解決不徹底，將會對整個大項目帶來難以預(yù)測的負面結(jié)果。
對管理水平的要求提高
敏捷開發(fā)的問題最后就是管理的問題。這和很多軟件企業(yè)重技術(shù)輕管理的做法是截然相反的，企業(yè)的這種心智模式一方面是源自管理人才的缺乏和項目組成員對管理制度的排斥;另一方面則是因為現(xiàn)行規(guī)范和管理制度與實際工作中的不合拍。從這一層面而言，敏捷開發(fā)對管理水平要求提高對軟件企業(yè)領(lǐng)導(dǎo)者的觀念是一種挑戰(zhàn)。
對執(zhí)行力的要求
任何理論只有落到實處，才能為企業(yè)為社會創(chuàng)造財富。這是永恒不變的道理。敏捷開發(fā)模式需要經(jīng)驗豐富、配合良好而又異常穩(wěn)定的項目組、積極而富有成效的溝通、良好的管理手段和流程、有效的工具與平臺，只有滿足這些條件我們才能實現(xiàn)敏捷開發(fā)模式帶給我們的益處。
敏捷開發(fā)的出現(xiàn)，同樣讓以人為本還是以過程為本的爭論上升到了理論層面。在敏捷開發(fā)過程中，人是第一位的，過程是第二位的，所以就個人而言，應(yīng)該可以從各種不同的過程中找到真正適合自己的過程。這與軟件工程理論提倡的先過程后人正好相反，因而被不少人戲稱為對工程學(xué)原理的叛逆。
敏捷方法對需求不確定或常常變更的情形是有效的。但是，沒有哪一種開發(fā)方法是適用于所有項目開發(fā)的，正如上文所說，敏捷方法給傳統(tǒng)軟件開發(fā)帶來了一種新的思路和開發(fā)模式，但也給企業(yè)帶來了軟件研發(fā)項目管理開發(fā)過程的整合困難。
所以，在實際開發(fā)過程中，需要根據(jù)實際項目的需要選擇合適的開發(fā)方法，并盡最大可能發(fā)揮人的創(chuàng)造性和潛能，利用不同人的不同特點，充分溝通，這才是在敏捷方法中真正需要學(xué)習(xí)的。
第5篇：敏捷的項目管理范文
關(guān)鍵詞：DevOps 開發(fā)與運維 DevOps軟件開發(fā)流程
中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2016）11-0184-04
1 引言
1.1 DevOp概念
DevOps（Development和Operations）是一個關(guān)于組織文化、自動化、持續(xù)監(jiān)控與共享等各元素的集合。是軟件開發(fā)、運維和質(zhì)量保證三個部門之間進行溝通、協(xié)作的流程、方法和體系。它源于2009年歐洲傳統(tǒng)IT模式的運維之痛，為了填補開發(fā)與運維之間的鴻溝，將開發(fā)、運維與測試聯(lián)合在一起。專家們曾經(jīng)總結(jié)出一個能力環(huán)來解釋DevOps的概念，如圖1所示。
DevOps能讓開發(fā)團隊以同樣的方式操控他們的開發(fā)環(huán)境、測試環(huán)境以及生產(chǎn)環(huán)境，并且任何時候都能將數(shù)據(jù)包部署到任何一個環(huán)境中。DevOps從軟件交付的全局出發(fā)，加強各角色之前的合作；同時，自動化減少了大量的手工操作和人機交互，因此，需要選擇那些支持腳本化、無需人機交互界面的強大管理工具。這些工具和程序涉及環(huán)境中的各種函數(shù)，而這些函數(shù)包含不同領(lǐng)域的專業(yè)知識，并且可以根據(jù)組件中出現(xiàn)的問題以不同的方式運用?？紤]到各種函數(shù)復(fù)雜性，根據(jù)它們的作用建立一個框架來將它們形象化并分成不同的種類將會很有幫助。在DevOps環(huán)境下，將全局系統(tǒng)的視角運用到一個高層次的模型中，將在應(yīng)用、操作系統(tǒng)服務(wù)、網(wǎng)絡(luò)服務(wù)、數(shù)據(jù)庫四個層面產(chǎn)生核心變化[1]。
1.2 DevOp優(yōu)勢
傳統(tǒng)的瀑布開發(fā)模型由溫斯頓?羅伊斯（Winston Royce）在1970年提出，一直是最被廣泛采用的軟件開發(fā)模型。瀑布模型核心思想是將功能的實現(xiàn)與設(shè)計分開，將軟件生命周期劃分為制定計劃、需求分析、軟件設(shè)計、程序編寫、軟件測試和運行維護等六個基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。它為項目提供了按階段劃分的檢查點，但缺點也顯而易見――即只有在項目生命周期的后期才能看到結(jié)果，且極不適應(yīng)需求的變化[2]。
于是新的理念應(yīng)運而生――敏捷。敏捷開發(fā)是針對傳統(tǒng)的瀑布開發(fā)模式的弊端而產(chǎn)生的一種新的開發(fā)模式，目標是提高開發(fā)效率和響應(yīng)能力。以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構(gòu)建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備可視、可集成和可運行使用的特征。
然而單單敏捷開發(fā)也并未解決開發(fā)與運維之間的鴻溝。DevOps在敏捷的基礎(chǔ)上，將運維并入進來，是軟件開發(fā)、運維和質(zhì)量保證三個部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個集合。圖2可以清晰地說明軟件開發(fā)模式的進化過程。
在傳統(tǒng)行業(yè)的數(shù)據(jù)中心，數(shù)據(jù)的穩(wěn)定性和安全性是重中之重。IT 管理人員對數(shù)據(jù)中心的管理主要偏重于兩個方面：首先是為了確保數(shù)據(jù)中心的穩(wěn)定性而對數(shù)據(jù)中心各個環(huán)節(jié)進行維護；其次當(dāng)數(shù)據(jù)中心內(nèi)出現(xiàn)問題時，能夠及時定位問題并且解決，以縮短故障時間。
而運維工具的開發(fā)和數(shù)據(jù)故障的解決都需要快速的響應(yīng)和交付能力。目前傳統(tǒng)數(shù)據(jù)中心的ITIL管理模式和普遍應(yīng)用于開發(fā)工具中的瀑布開發(fā)模型，都無法保證最快的交付和最佳的成果。DevOps集開發(fā)、運維和質(zhì)量保證于一體，通過促進開發(fā)團隊和運營團隊之間的溝通、協(xié)作和整合，不僅提高了效率，也同時促進了運維的自動化。
DevOps本質(zhì)上是開發(fā)，運維和質(zhì)量保證部門之間的溝通協(xié)作。它將解決傳統(tǒng)IT運維管理模式信息溝通效率低下的缺點，提高整個IT部門效率，適應(yīng)云時代不同類型用戶對IT運維管理的需求，也是未來的發(fā)展方向。
1.3 DevOp應(yīng)用現(xiàn)狀
在目前這個瞬息萬變、信息爆炸的時代，一分鐘之內(nèi)就會發(fā)生很多事情：超過兩百萬條的Google搜索、兩億封郵件的傳送……在這個應(yīng)用經(jīng)濟備受關(guān)注的時代，企業(yè)需要靠各種創(chuàng)新應(yīng)用獲得持續(xù)發(fā)展。而業(yè)務(wù)的靈活創(chuàng)新依靠的是快速、持續(xù)、高質(zhì)量的軟件應(yīng)用交付。
目前在國外，互聯(lián)網(wǎng)巨頭如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，傳統(tǒng)軟件公司如Adobe、IBM、Microsoft、SAP等，亦或是網(wǎng)絡(luò)業(yè)務(wù)非核心企業(yè)如蘋果、沃爾瑪、索尼影視娛樂、星巴克等都在采用DevOps或提供相關(guān)支持產(chǎn)品。
在云計算、大數(shù)據(jù)和移動互聯(lián)這三大浪潮面前，更有效地管理和整合現(xiàn)有資源，進行更快速的應(yīng)用交付對于任何一個企業(yè)來說都是一個挑戰(zhàn)。目前，DevOps 在國內(nèi)并不算流行，很多傳統(tǒng)企業(yè)還沒有認識到開發(fā)與運維協(xié)作所能產(chǎn)生的“化學(xué)反應(yīng)”。
不過，依托DevOps中國社區(qū)成員的積極參與支持，南京大學(xué)發(fā)起《DevOps中國2016年度調(diào)查》活動。期望通過本次問卷調(diào)查，收集DevOps的率先實踐者們關(guān)于DevOps實踐及經(jīng)驗的相關(guān)信息，從而了解DevOps在中國推廣應(yīng)用的狀況，并匯總在DevOps實踐中可能遇到的障礙、挑戰(zhàn)和最佳實踐，最終將通過調(diào)查報告進一步促進DevOps在中國的認知和推廣。
2 DevOps流程
Devops開發(fā)流程大約分為以下幾個部分：持續(xù)的管理與計劃，持續(xù)的集成與測試，持續(xù)的交付與部署，持續(xù)的監(jiān)控與運維，持續(xù)的分析與計劃。
在此前我們要介紹DevOps開發(fā)流程中的幾個角色：功能負責(zé)人（敏捷中的Product Owner），開發(fā)人員，測試人員，運維人員，流程負責(zé)人（敏捷中的Scrum Master）
2.1 持續(xù)的管理與計劃
功能負責(zé)人將聚集開發(fā)、測試與運維一起進行功能討論并制定交付計劃。每個人都會從自身的角度考慮可行性并作出適當(dāng)?shù)慕ㄗh。流程負責(zé)人會在這個階段協(xié)調(diào)討論進度，并在流程的每一階段對功能進度與狀態(tài)進行全程跟進。整體的計劃及相應(yīng)的各人任務(wù)將被創(chuàng)建在管理平臺上對所有人可見。
2.2 持續(xù)集成與測試
運用一系列開發(fā)實踐的方法確保代碼可以快速并安全地部署到產(chǎn)品中。每一次代碼的改動，都提交到一個模擬的產(chǎn)品環(huán)境中，使用嚴格的自動化測試，來確保功能和服務(wù)能夠達到預(yù)期。
2.3 持續(xù)交付與部署
當(dāng)模擬環(huán)境中的代碼通過自動化測試，它們將自動被部署到真實的產(chǎn)品環(huán)境中（即生產(chǎn)環(huán)境）。由于部署腳本與測試用例都是在開發(fā)前有著充分的溝通，且部署和測試都是通過自動化實現(xiàn)，投產(chǎn)過程出問題的可能性將大大減少，且即使出現(xiàn)，大家也會在一起找到原因并解決。
2.4 持續(xù)監(jiān)測與運維
投產(chǎn)后，運維人員在自動化監(jiān)控工具的幫助下持續(xù)地監(jiān)控功能狀態(tài)。
2.5 持續(xù)的分析與計劃
由于整個開發(fā)流程進度及具體任務(wù)對所有人可見，每人在每天登錄管理平臺都可以具體感受到目前功能的進度。因此每天的站立會中每人都可以提出對產(chǎn)品功能及整體計劃的分析和建議。
3 DevOps常用工具
以下是以某數(shù)據(jù)中心的K運維自動化管理平臺（以下簡稱“K平臺”）為例的DevOps常用工具。該平臺的DevOps工具中包含了項目管理、開發(fā)工具、持續(xù)集成與測試、持續(xù)交付與部署、持續(xù)監(jiān)控與運維這幾個部分。
3.1 項目管理
Agiler：Agiler是原HP公司開發(fā)的一套敏捷管理系統(tǒng)。該團隊運用系統(tǒng)進行日常的項目管理工作。項目經(jīng)理運用該工具建立backlog與Sprint；團隊Leader給團隊成員建立Sprint下的具體任務(wù)；而開發(fā)與運維團隊成員在每天的站立會中運用工具中的敏捷看板功能，對各自的任務(wù)進行跟進與狀態(tài)更新；項目助理則全程在該平臺上看到項目的進展。
3.2 開發(fā)工具
Subversion：Subversion是一個開源的版本管理系統(tǒng)。它將文件存放在中心版本庫，可以記錄每一次文件和目錄的修改情況。K平臺不僅用Subversion管理開發(fā)的代碼，也同時管理著運維腳本，項目文檔，設(shè)計圖，測試用例等任何與K平臺項目相關(guān)的文件。與普通的文件服務(wù)器之間的區(qū)別在于，由于它記錄了每一次文件和目錄的修改情況，可以將數(shù)據(jù)恢復(fù)到以前的版本，并可以查看數(shù)據(jù)的更改細節(jié)。
3.3 持續(xù)集成與測試
Maven：Maven是一個軟件項目構(gòu)建工具。K平臺運用它進行管理項目的jar包依賴，開發(fā)，測試，打包的一系列生命周期的管理。
CasperJS：CasperJS是一個基于PhantomJS（前端自動化測試工具）編寫的腳本處理和測試工具，提供了完成常見任務(wù)的方法和函數(shù)。K平臺使用CasperJS編寫平臺系統(tǒng)測試案例，用于自動化測試系統(tǒng)功能。
Jeckins：Jenkins 是基于Java開發(fā)的持續(xù)集成工具，K平臺利用它來持續(xù)地軟件版本并測試項目。
3.4 持續(xù)交付與部署
Ansible：Ansible是一個基于Python開發(fā)的自動化運維工具，集合了puppet， cfengine、chef、func、fabric的優(yōu)點，實現(xiàn)批量運行命令、批量系統(tǒng)配置、批量程序部署等功能。K平臺利用Ansible實現(xiàn)流程編排與批量操作系統(tǒng)配置。
3.5 持續(xù)監(jiān)控與運維
Zabbix：zabbix 是一個基于WEB界面的提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視功能的開源工具。K平臺利用Zabbix來實現(xiàn)網(wǎng)絡(luò)狀況監(jiān)控、服務(wù)器端口監(jiān)控、數(shù)據(jù)庫監(jiān)控及日志監(jiān)視。
4 DevOps應(yīng)用實例
K運維自動化管理平臺DevOps開發(fā)實例。
K平臺是某數(shù)據(jù)中心的K運維自動化管理平臺，K平臺的DevOps架構(gòu)圖如圖3。
4.1 制定計劃
由客戶及項目經(jīng)理等領(lǐng)導(dǎo)層制定K平臺本年度的backlog并添加至Agiler工具中。并交于項目實施團隊進行自行實施。功能負責(zé)人將在計劃階段確定大概的功能點及完成時間，在Agiler工具中的相應(yīng)的Backlog下確定Sprint。每個實施團隊的成員在Sprint下為自己建立相應(yīng)的任務(wù)，使Agiler工具中的敏捷看板任務(wù)情況一目了然。項目助理會去跟進Sprint及Sprint下任務(wù)的分配情況。
4.2 定義工作內(nèi)容
即瀑布模型中的需求分析階段。功能負責(zé)人、開發(fā)、測試，甚至運維將聚集在一起討論需求細節(jié)。功能負責(zé)人完成設(shè)計圖，測試人員編寫測試用例與自動化測試代碼，開發(fā)人員進行數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計等詳細設(shè)計，運維人員開始思考該功能上線后如何進行監(jiān)控配置。
相關(guān)的設(shè)計文檔、測試用例、運維腳本等都將放在SVN（Subversion）中進行管理。
根據(jù)功能討論的情況，功能負責(zé)人可能會Agiler工具中更新backlog下的Sprint，進行名稱修改，功能重新劃分，時間點更新等操作。其他實施人員――包含開發(fā)人員，測試人員，運維人員也將在Agiler中去更新自己的任務(wù)及完成狀態(tài)。
項目助理會在全程跟進Agiler中的更新情況并提出相應(yīng)的分配建議。
4.3 開發(fā)
開發(fā)人員運用Maven來管理代碼的生命周期。代碼的創(chuàng)建者在配置文件pom.xml中配置jar包的依賴關(guān)系，這樣每個開發(fā)人員都可以自動下載jar包在我們的項目中。
每一位開發(fā)人員都在SVN主干下開發(fā)自己的模塊代碼，Jeckins中的構(gòu)建任務(wù)保證開發(fā)環(huán)境的代碼不斷被提交到模擬產(chǎn)品環(huán)境（即測試環(huán)境中），并進行嚴格的自動化測試。
開發(fā)人員在完成自己的相應(yīng)任務(wù)后將會在Agiler工具中更新自己的任務(wù)狀態(tài)。于是在第二天的站立會中大家將看到開發(fā)進度的更新。
4.4 構(gòu)建-部署-測試（測試環(huán)境）
Jeckins定期從Subversion指定目錄取得最新的代碼進行自動化構(gòu)建操作，保證開發(fā)人員的代碼不斷被提交到模擬測試環(huán)境中，以進行自動化測試。
第6篇：敏捷的項目管理范文
何謂廣義的ASP
ASP（Application Service Provider），譯為“應(yīng)用服務(wù)提供商”。顧名思義，它可以對企業(yè)提供在線業(yè)務(wù)應(yīng)用服務(wù)和管理服務(wù)。具體的操作過程是：企業(yè)將有關(guān)生產(chǎn)經(jīng)營活動的數(shù)據(jù)信息及生產(chǎn)經(jīng)營特點傳遞給ASP，由ASP通過軟件處理后，傳遞給企業(yè)使用。ASP負擔(dān)軟件、硬件的購買、安裝、構(gòu)造、維護，企業(yè)通過軟件租用或租賃形式來獲得服務(wù)。ASP實際上是一些為第三方提供服務(wù)的公司，它們擁有自己的主機，在自己的主機上部署、管理和維護各種應(yīng)用系統(tǒng)，然后通過網(wǎng)絡(luò)Internet或VPN（虛擬專用網(wǎng)絡(luò)）向遠端客戶提供軟件的計算能力。簡單說ASP就是支持和幫助任何客戶進行電子商務(wù)的專業(yè)企業(yè)。
ASP是針對中小企業(yè)產(chǎn)生發(fā)展起來的，主要是為了解決中小企業(yè)普遍存在的資金困難和渴望信息化管理這一矛盾，通過直接租用ASP的計算機及軟件系統(tǒng)實施信息管理，既可以節(jié)省一筆用于IT產(chǎn)品、技術(shù)購買和維護運行的資金，又能使中小企業(yè)利用信息化壯大自身實力。ASP模式無疑為這類企業(yè)提供了較好的解決方案，企業(yè)無需配備專門的人員和大規(guī)模資金投入亦可獲得專業(yè)的服務(wù)和技術(shù)支持。
基于ASP的這種思想，拓展開來，它實際上就是為其它企業(yè)提供服務(wù)的供應(yīng)商，這種服務(wù)是一種“大服務(wù)”的概念，它不僅僅是一種應(yīng)用軟件的服務(wù)，更多意義上應(yīng)該是一種企業(yè)的管理、信息的服務(wù)。我們不妨把這種模式稱為廣義ASP模式。
廣義ASP模式的應(yīng)用
傳統(tǒng)的ASP通過Web，除提供應(yīng)用租賃外，只提供很少幾種服務(wù)。廣義ASP則使這種模式又前進了一步。它為企業(yè)非核心商務(wù)業(yè)務(wù)提供更多的外包選擇，這種模式對于內(nèi)部資源配置很薄弱的中小企業(yè)具有特殊的魅力。例如，美國加利福尼亞的eConvergent公司就是采用這種模式。該公司不僅租用E.piphany公司開發(fā)的CRM客戶關(guān)系軟件，而且還提供咨詢服務(wù)，包括針對客戶個性化需求的定制工作、特殊軟件產(chǎn)品培訓(xùn)以及有關(guān)CRM軟件的一般培訓(xùn)。該公司還提供外包客戶服務(wù)代表等服務(wù)。
廣義ASP向用戶提供的服務(wù)內(nèi)容無疑比傳統(tǒng)ASP多，但他們也存在著與傳統(tǒng)ASP同樣的問題。這些問題主要表現(xiàn)在網(wǎng)絡(luò)應(yīng)用、復(fù)雜的價格模式、遇到停機或故障時缺乏向客戶報告情況的聯(lián)系手段等，這些問題都有可能影響廣義ASP作用的發(fā)揮。但是，廣義ASP的投資回報率比傳統(tǒng)ASP要高，這一優(yōu)點有可能使長期購買應(yīng)用軟件致使成本過高的局面宣告結(jié)束。
廣義ASP的優(yōu)點并不只是出租應(yīng)用，其主要優(yōu)點是為企業(yè)用戶提供非核心業(yè)務(wù)的整體外包服務(wù)，這樣就可讓企業(yè)用戶專注于核心業(yè)務(wù)，從而增強其競爭實力。
案例分析——SP－ASP模式
正是基于廣義ASP的思想，北京桑普電器有限公司提出了獨具特色的SP－ASP管理模式。
1. SP－ASP模式的提出
北京桑普電器公司成立于1992年，經(jīng)過近十年的創(chuàng)業(yè)歷程，已經(jīng)成為全國知名的“桑普”系列及“丹普”系列電熱設(shè)備生產(chǎn)廠家。目前，公司正經(jīng)歷從創(chuàng)業(yè)向發(fā)展的過渡。在激烈的市場經(jīng)濟體制的競爭中，公司一方面利用自己積累的經(jīng)驗進行企業(yè)的重組改造和技術(shù)創(chuàng)新，另一方面積極利用新的管理模式、借助先進的計算機技術(shù)來提高企業(yè)的生產(chǎn)經(jīng)營管理。公司于1999年成功實施了SP-CIMS工程，該工程的實施與應(yīng)用使企業(yè)在管理和技術(shù)創(chuàng)新方面上了一個臺階，提高了工作效率，降低了運營成本，取得了較為理想的效果。
面對激烈的市場競爭壓力及中國加入WTO后小家電行業(yè)所面臨的巨大挑戰(zhàn)，為了使公司成為一個在供應(yīng)鏈管理的哲理、方法和技術(shù)的指導(dǎo)下的開放的、敏捷的、合作的、有競爭力的企業(yè)，桑普公司積極調(diào)整戰(zhàn)略決策，提出了SP－ASP管理模式。
SP-ASP模式就是樹立以品牌、管理為主的企業(yè)核心競爭力，利用“大資源、大整合”的思路，逐漸把生產(chǎn)、采購、儲運的環(huán)節(jié)交給社會完成，以客戶服務(wù)為中心，應(yīng)用供應(yīng)鏈管理與敏捷制造的概念，把過去的單個企業(yè)擴大到利用社會資源的范疇，使企業(yè)為了共同的市場利益結(jié)成戰(zhàn)略聯(lián)盟。
桑普公司將通過與供應(yīng)鏈上、中、下游企業(yè)之間建立戰(zhàn)略伙伴關(guān)系，利用其他企業(yè)的資源達到企業(yè)擴展的目的。桑普公司已在全國形成合作（協(xié)作）廠商、經(jīng)銷代銷點、售后服務(wù)網(wǎng)點的供應(yīng)鏈，以桑普公司作為企業(yè)動態(tài)聯(lián)盟盟主，基于ASP方式實現(xiàn)供應(yīng)鏈管理的網(wǎng)絡(luò)化。ASP成為供應(yīng)鏈式企業(yè)聯(lián)盟中的一員，它的核心是電子化服務(wù)。由ASP服務(wù)的內(nèi)容包括：項目管理，資源組織與配置，質(zhì)量保障、仲裁與認證，數(shù)據(jù)交換與標準，使能工具及產(chǎn)品，宣傳廣告等。由桑普公司組建ASP，開發(fā)供應(yīng)鏈管理網(wǎng)絡(luò)的“服務(wù)、維保平臺”。
SP-ASP模式的主導(dǎo)思想是：
①以供需鏈思想指導(dǎo)企業(yè)的經(jīng)營生產(chǎn)過程，降低企業(yè)的流通成本，構(gòu)造企業(yè)敏捷的、彈性的營銷網(wǎng)絡(luò)；
②利用網(wǎng)絡(luò)技術(shù)，構(gòu)架企業(yè)與外部的信息通道，建立資源信息庫，為企業(yè)對市場變化的科學(xué)決策提供有用的信息支持；
③建立面向資源的管理模式，對社會資源進行分析、規(guī)劃及管理，為企業(yè)參與社會資源的重組提供一個有效的手段。
④以客戶服務(wù)為中心，建立穩(wěn)定的、有價值的用戶網(wǎng)絡(luò)。
從桑普公司構(gòu)建的SP－ASP模式中我們可以看出，這種模式已經(jīng)不僅僅是提供一種軟件服務(wù)，而是一種滿足于中小企業(yè)的全方位的信息服務(wù)。這種模式正是我們在前面提出的廣義ASP模式。
2. SP－ASP運作模型
根據(jù)SP－ASP管理模式，可以構(gòu)造出SP－ASP的運作模型（如圖所示）。SP－ASP的運作模型
從該運作模型可以看出，由桑普公司搭建SP－ASP系統(tǒng)平臺，而其它異地生產(chǎn)、采購、儲運等均運作于此平臺上，從而實現(xiàn)生產(chǎn)、銷售的外包。該模型基于B/S架構(gòu)，利用本地生產(chǎn)的成熟管理體系，異地通過遠程瀏覽器來使用該系統(tǒng)，系統(tǒng)則通過生產(chǎn)、質(zhì)量數(shù)據(jù)等進行遠程監(jiān)控，從而發(fā)揮各個企業(yè)的核心優(yōu)勢。
3. 結(jié)論
第7篇：敏捷的項目管理范文
【關(guān)鍵詞】項目管理；施工產(chǎn)品；質(zhì)量管理
一、前言
建筑工程的質(zhì)量不僅影響著人民生活，而且直接關(guān)系到工程企業(yè)的長遠發(fā)展。施工產(chǎn)品是工程企業(yè)的品牌，它直接影響著工程企業(yè)的信譽，影響著其市場地位。在項目管理模式盛行的背景下，如何提高工程的質(zhì)量是每個工程企業(yè)亟待解決的問題。發(fā)揮項目管理模式中的項目質(zhì)量管理人員的作用、提高職工對施工產(chǎn)品質(zhì)量重要性的認識對于切實提高工程質(zhì)量有重要影響。
二、工程質(zhì)量控制階段
工程的質(zhì)量受各階段施工質(zhì)量的影響，為此，項目質(zhì)量管理人員應(yīng)切實加強工程施工每個環(huán)節(jié)上的質(zhì)量 管理，確保各個環(huán)節(jié)上的施工質(zhì)量
三、目前項目管理模式下工程質(zhì)量管理中存在的問題
1.過分注重定性評價
在以往的工程質(zhì)量監(jiān)控過程中，質(zhì)量監(jiān)控人員往往通過一些較為簡單、直觀的方式進行工程質(zhì)量的檢查與控制，往往將個人經(jīng)驗作為管理控制工程質(zhì)量的標準，以至于在工程質(zhì)量檢查與評定上缺乏科學(xué)依據(jù)。這種過分注重定性評價的評價方式將會導(dǎo)致工程質(zhì)量控制的隨機性增大，降低了工程質(zhì)量控制的科學(xué)性、穩(wěn)定性。
2.缺乏量化管理
長期以來，項目管理模式缺乏量化管理，工程施工的責(zé)任分工不能具體到個人，這不僅影響了問題工程的責(zé)任追究，而且不利于提高工程建設(shè)職工的工作積極性，不利于提高職工的責(zé)任意識。
3.缺乏科學(xué)評價方法
如今的工程建設(shè)日趨復(fù)雜化，影響工程質(zhì)量的因素較多，工程施工的具體環(huán)境也較為復(fù)雜，工程質(zhì)量管理人員在進行工程質(zhì)量評價時缺乏科學(xué)、統(tǒng)一的評價標準，這在一定程度上影響了評價的客觀性、公正性。
四、加強項目管理模式下質(zhì)量管理的措施
1.提高項目經(jīng)理管理水平
項目經(jīng)理的管理水平直接關(guān)系到職工的施工積極性，影響到工程的施工效率與施工質(zhì)量。首先，一個合格的項目經(jīng)理不僅要具備較高的組織、協(xié)調(diào)能力，而且應(yīng)具備較強的責(zé)任意識與敏捷的思維。其次，項目經(jīng)理需具備較強的施工技術(shù)，他們應(yīng)具有豐富的實踐經(jīng)驗，掌握工程各個環(huán)節(jié)上的施工技術(shù)，這樣才能夠?qū)こ痰目傮w施工進行合理規(guī)劃并有效監(jiān)督，同時，當(dāng)工程質(zhì)量出現(xiàn)問題時，能夠了解問題的關(guān)鍵所在，以便及時采取相關(guān)措施進行補救，以確保工程質(zhì)量。第三，應(yīng)樹立全局意識。項目部門在工程建設(shè)過程中并不是孤立存在的，它與工程建設(shè)單位、設(shè)計單位、工程主管部門、政府相關(guān)行政部門等有著密切聯(lián)系，因此，項目經(jīng)理應(yīng)樹立全局意識，與上述單位搞好關(guān)系，共同維護彼此的利益關(guān)系，在相互合作中提高工程質(zhì)量。
2.加強職工培訓(xùn)力度，提高其質(zhì)量意識
工程建設(shè)職工的質(zhì)量意識對工程建設(shè)的質(zhì)量起著重要作用，因此，提高職工的質(zhì)量意識是提高工程質(zhì)量的重要舉措。首先，各項目部應(yīng)定期召開質(zhì)量專題會議。通過專題會議向職工講解有關(guān)工程質(zhì)量的知識，讓每個職工充分認識到自身在工程建設(shè)過程中的重要作用，讓他們意識到自己的一舉一動都直接影響著工程的質(zhì)量，讓“工程質(zhì)量無小事”的觀念深入到每個職工的內(nèi)心，讓職工在具體工作過程中切實樹立質(zhì)量意識。第二，各項目部應(yīng)加強對職工的培訓(xùn)力度。讓職工通過培訓(xùn)及時了解、掌握工程建設(shè)信息，提高施工技術(shù)，為提高工程建設(shè)質(zhì)量打下基礎(chǔ)。第三，及時開展作業(yè)質(zhì)量研討會。在工程建設(shè)過程中，應(yīng)針對工程施工的實際情況及時開展作業(yè)質(zhì)量研討會。例如，針對焊接技術(shù)達不到相關(guān)施工設(shè)計要求的問題，項目部應(yīng)及時開展焊接質(zhì)量研討會，邀請具有豐富焊接經(jīng)驗的電焊工對具體施工過程中的焊接問題進行原因分析，并就焊接技術(shù)、焊接材料、防護措施等方面展開交流，促進職工在相互交流中提高施工技術(shù)，確保工程質(zhì)量。第四，嚴格要求工程施工人員持證上崗。各項目部應(yīng)要求各作業(yè)人員持證上崗，尤其是那些需要特殊技術(shù)、高空作業(yè)的崗位，務(wù)必要求有資質(zhì)者上崗，這不僅是滿足工程技術(shù)上的需要，而且是確保工程質(zhì)量的重要手段。
3.建立健全質(zhì)量管理體系
建立一整套完善的施工產(chǎn)品質(zhì)量管理體系是提高項目管理模式下質(zhì)量管理水平的重要措施
首先，應(yīng)建立完善的施工產(chǎn)品質(zhì)量檢驗程序，遵循職工自檢——彼此互檢——專業(yè)檢查的程序，鼓勵職工對自己每日完成的工作主動進行檢查，確保自身工作符合相關(guān)標準及施工合同要求，同時做好詳細記錄，以供日后檢查、參考使用。在此基礎(chǔ)上，各項目部應(yīng)組織從事相同作業(yè)的職工對彼此的施工質(zhì)量進行檢查、評價，吸取對方的優(yōu)勢，并就產(chǎn)品質(zhì)量中存在的問題進行交流、探討，促進共同進步。最后，在完成自檢、互檢程序后，專門負責(zé)質(zhì)量檢查的項目質(zhì)量監(jiān)管人員應(yīng)嚴格按照產(chǎn)品質(zhì)量標準及施工合同要求對施工產(chǎn)品進行質(zhì)量檢查，嚴把產(chǎn)品質(zhì)量關(guān)，切實做好產(chǎn)品質(zhì)量監(jiān)督、檢查工作。
4.做好施工材料質(zhì)量控制工作
施工材料質(zhì)量的好壞直接影響著施工產(chǎn)品的質(zhì)量，為此，各項目部門嚴把施工材料質(zhì)量關(guān)，按照相關(guān)標準、通過正當(dāng)渠道采購施工材料。首先，應(yīng)按照企業(yè)采購標準、規(guī)定，工程施工合同，工程設(shè)計方案等要求進行采購。在采購過程中，相關(guān)采購人員應(yīng)嚴格審查產(chǎn)品說明書、產(chǎn)品質(zhì)量檢測報告、質(zhì)量鑒定書、質(zhì)量檢測部門的檢測報告等，確保采購產(chǎn)品的質(zhì)量。其次，重要材料應(yīng)先進行取樣試驗，而且樣本的選取必須具有代表性。第三，尤其要注重新材料的使用，在其投入使用前，應(yīng)先對其進行質(zhì)量鑒定與試驗，并將鑒定試驗報告呈送給項目設(shè)計部門批準，經(jīng)項目設(shè)計部門批準后才能進行采使用。
5.加強對施工設(shè)備的維護
施工設(shè)備是工程施工順利進行的物質(zhì)保障，它對施工產(chǎn)品的質(zhì)量產(chǎn)生重要影響。各項目部門應(yīng)加強對施工設(shè)備的質(zhì)量控制，具體來說就是嚴格控制施工設(shè)備的類型、性能參數(shù)與施工的具體要求相匹配。首先，應(yīng)選用符合規(guī)定的施工設(shè)備，確保設(shè)備質(zhì)量。其次，應(yīng)根據(jù)工程施工的實際需要設(shè)定合理的性能參數(shù)，保證施工質(zhì)量。第三，應(yīng)定期對施工設(shè)備進行檢查、維護，這不僅有利于確保施工質(zhì)量，而且有利于維護職工人身安全。
6.完善相關(guān)制度，加強質(zhì)量管理
施工產(chǎn)品的質(zhì)量保證離不開健全的制度建設(shè)，各項目部門應(yīng)完善質(zhì)量管理制度，促進質(zhì)量管理的規(guī)范化。首先，項目部門應(yīng)建立嚴格的施工現(xiàn)場管理制度與部門生產(chǎn)紀律，規(guī)范職工的作業(yè)活動，提高部門質(zhì)量管理人員的管理水平。其次，各部門應(yīng)建立質(zhì)量獎懲制度。對符合施工要求的職工進行一定的獎勵，對違背施工標準、破壞施工質(zhì)量的員工進行懲罰，通過獎罰分明的獎懲制度，切實提高職工的工作積極性，提高職工的質(zhì)量責(zé)任意識。
五、結(jié)語
工程產(chǎn)品的質(zhì)量直接關(guān)系到工程企業(yè)的切身利益，提高項目管理模式下的質(zhì)量管理水平是目前工程企業(yè)亟待解決的問題。為此，各項目管理部門應(yīng)采取相關(guān)措施切實加強質(zhì)量管理，通過提高項目經(jīng)理素質(zhì)、健全質(zhì)量管理體系、完善質(zhì)量管理制度、提高職工質(zhì)量意識等方法加強工程產(chǎn)品質(zhì)量的監(jiān)管力度，為提高工程產(chǎn)品質(zhì)量創(chuàng)造條件。
參考文獻
[1]李必丹.“53”工程項目管理模式——建筑施工階段質(zhì)量控制及評價方法[j].建筑科學(xué)，2007（06）：8-11.
第8篇：敏捷的項目管理范文
企業(yè)合同管理審計是改善企業(yè)內(nèi)部管理水平，預(yù)防和降低經(jīng)營、管理風(fēng)險，維護企業(yè)的合法權(quán)益，促進企業(yè)價值的增加及目標的實現(xiàn)。在我國，對于包含合同管理審計的管理審計或增值型內(nèi)部審計的理論研究還處于起步階段，其在實踐中的應(yīng)用缺乏理論指導(dǎo)。我國加入WTO后，對外貿(mào)易的不斷增長，合同的種類和數(shù)量不斷增加，因合同而起的糾紛或造成的損失屢見不鮮。因此，在我國開展合同管理審計有著十分重要的意義。
(一)合同管理審計是企業(yè)發(fā)展的內(nèi)在需要在市場經(jīng)濟條件下，合同是連接各經(jīng)濟主體、處理經(jīng)濟關(guān)系的重要法律依據(jù)和經(jīng)濟紐帶，同時也是產(chǎn)生糾紛的根源。企業(yè)合同的順利簽訂和履行，是企業(yè)得以發(fā)展的前提和基礎(chǔ)，是企業(yè)經(jīng)營目標得以實現(xiàn)的重要保證。企業(yè)合同管理既是一種為了取得經(jīng)營效益的經(jīng)濟行為，也是一種保障企業(yè)經(jīng)營活動順利進行的法律行為，是現(xiàn)代企業(yè)經(jīng)營管理活動中的重要內(nèi)容，是企業(yè)控制風(fēng)險，增加價值、增強市場競爭力的基礎(chǔ)和保證。因此，在企業(yè)內(nèi)部進行合同管理審計，促進企業(yè)加強和改善合同管理，是企業(yè)發(fā)展的必然選擇。
(二)合同管理審計是內(nèi)部審計向增值型內(nèi)部審計發(fā)展的需要國際內(nèi)部審計師協(xié)會(ⅡA)在《內(nèi)部審計職業(yè)實務(wù)準則》中對內(nèi)部審計作了重新定義：內(nèi)部審計是一種獨立、客觀的確認和咨詢活動，旨在增加組織價值和改善組織的運營。其通過運用系統(tǒng)的、規(guī)范的方法評價并改善風(fēng)險管理、控制和治理過程的效果，幫助組織實現(xiàn)其目標。這一新定義表明內(nèi)部審計是一項確認和咨詢活動，是為增加組織價值和改進經(jīng)營、實現(xiàn)組織的目標服務(wù)的，同時也表明內(nèi)部審計已進入了增值型內(nèi)部審計的新時代。內(nèi)部審計要充分發(fā)揮自己獨特的作用，充分體現(xiàn)自身的價值，須積極開展合同管理審計，為增加企業(yè)價值服務(wù)。
二、企業(yè)合同管理審計的方法與內(nèi)容
根據(jù)企業(yè)的管理模式和要求、合同數(shù)量的多寡、內(nèi)部審計機構(gòu)資源等的不同，合同管理審計可以采取項目管理式審計和過程參與式審計兩種模式。
(一)項目管理式審計項目管理式審計是有重點、有目的地將合同管理納入年度審計計劃，形成特定審計項目，并實施相應(yīng)審計程序的審計模式。項目管理式審計主要審查合同的管理是否規(guī)范、有效，其主要內(nèi)容包括四個方面：一是合同管理機構(gòu)或管理網(wǎng)絡(luò)的審查。企業(yè)的合同管理應(yīng)首先建立健全管理機構(gòu)或管理網(wǎng)絡(luò)，審計時應(yīng)著重審計企業(yè)合同管理機構(gòu)或管理網(wǎng)絡(luò)的設(shè)置是否合理；各機構(gòu)之間的分工和職責(zé)是否明確，上下左右關(guān)系是否協(xié)調(diào)；組織最高領(lǐng)導(dǎo)層與合同管理機構(gòu)及各個機構(gòu)之間、各機構(gòu)相互之間的信息交流是否充分；合同管理流轉(zhuǎn)是否科學(xué)、有效；相互之間的控制是否有效；合同的履行是否受到定期檢查等合同。二是管理人員素質(zhì)的審查。企業(yè)合同管理人員的素質(zhì)關(guān)系到企業(yè)合同管理工作的優(yōu)劣，必須重視對合同管理人員素質(zhì)的審查。首先應(yīng)審查合同管理人員是否具備專業(yè)知識；其次應(yīng)審查合同管理人員是否熟悉企業(yè)的內(nèi)部運作流程和外部信息。此外，還應(yīng)審查其是否具有較強的組織能力和協(xié)調(diào)能力，敏捷的洞察、分析能力，嚴密的邏輯思維能力，較強的責(zé)任心等。三是合同管理制度的審查。首先審查合同管理制度是否健全，尤其是一些重要的合同管理制度是否是根據(jù)企業(yè)實際而制定，包括：合同歸口管理和分類專項管理制度、合同示范文本制度、合同授權(quán)委托制度、合同的審查制度或?qū)徲媽徍炛贫取⒑贤蔫b證、公證制度、合同專用章管理制度、合同臺賬制度、合同檔案制度、市場調(diào)研制度、大件大宗企業(yè)采購(包括物資、服務(wù)、工程等)或資產(chǎn)處置的制度。在對合同管理制度的健全性進行測試和評價后，還應(yīng)對這些制度的執(zhí)行情況進行檢查。四是合同執(zhí)行結(jié)果和管理效果的審查。主要審查合同內(nèi)容是否得到全面、嚴格地履行；審查有無合同違約、違約的原因及違約處理結(jié)果，如對方違約，是否及時組織索賠；如本方違約，責(zé)任人是否向分管領(lǐng)導(dǎo)提交書面報告，經(jīng)審批后辦理賠償手續(xù)，并追究相關(guān)責(zé)任；協(xié)商不成的合同糾紛是否及時上報上級領(lǐng)導(dǎo)和法律部門，通過申請仲裁或向人民法院解決合同糾紛。另外，還要審查合同管理效果是否達到合法、規(guī)范、效率、效益的要求。
(二)過程參與式審計過程參與式審計是由專職內(nèi)部審計人員對企業(yè)內(nèi)部所簽合同進行審計審簽，參與監(jiān)督合同管理的部分重要過程，實現(xiàn)合同審計審簽的日?；?。其審計的主要內(nèi)容包括以下幾方面：一是審“該不該簽”，即對合同項目的可行性審查和效益性審查。應(yīng)該檢查合同項目是否列入年度計劃，或經(jīng)組織內(nèi)有批準權(quán)的部門或領(lǐng)導(dǎo)批準；檢查合同項目是否經(jīng)過可行性研究或項目評估，其技術(shù)性、經(jīng)濟性是否達到了先進、合理；檢查與立項有關(guān)的文件資料的真實性、可靠性；檢查合同標的數(shù)量是否適當(dāng)，企業(yè)的生產(chǎn)、經(jīng)營能力是否能滿足對方的要求，或者合同標的數(shù)量是否能滿足企業(yè)的生產(chǎn)、經(jīng)營的需求；檢查合同履行時間是否充分考慮了企業(yè)的實際生產(chǎn)經(jīng)營能力或?qū)嶋H需要。二是審“跟誰簽”和“以什么樣的價格簽”，即對合同簽約主體的選擇和合同價格選擇的合理性、適當(dāng)性進行的審查。首先，對合同經(jīng)辦部門是否進行市場調(diào)研，是否采用了一定的合理方式確定合同主體和合同價格進行審查。其次，應(yīng)對合同簽約主體的合法性進行審查。當(dāng)事人在訂立合同時必須具有相應(yīng)的民事行為能力。三是審“怎么簽”，即對合同的形式、文本格式和合同條款進行審查。按照民法一般原則，合同屬于不要式行為。審查時，首先注意合同形式是否符合法律、行政法規(guī)等規(guī)定。其次應(yīng)審查合同文本的規(guī)范性。簽訂合同應(yīng)當(dāng)盡可能使用國家推行的示范文本，以保證合同條款的完備。對企業(yè)有特殊要求的，示范文本不能滿足的，企業(yè)可以自行制定合同文本，但應(yīng)向工商行政管理部門辦理審批備案手續(xù)。對其他沒有示范文本的，采用手寫或微機打印的合同，要特別注意一式多份合同條款的一致性，防止被他人篡改內(nèi)容，引起合同糾紛。在審查合同形式的合法性和文本格式的規(guī)范性后，要重點對合同條款的完備性進行審查。《合同法》規(guī)定，合同的內(nèi)容由當(dāng)事人約定，一般包括以下條款：當(dāng)事人的名稱或者姓名和住所；標的；數(shù)量；質(zhì)量；價款或者報酬；履行期限、地點和方式；違約責(zé)任；解決爭議的方法。因此，審計人員應(yīng)當(dāng)按照合同的性質(zhì)，依據(jù)相應(yīng)的法律、法規(guī)對合同條款進行認真審查，確定合同主要條款有無遺漏，各條款內(nèi)容是否具體、明確、切實可行，避免因合同條款不全或過于簡單、抽象、原則，給合同履行帶來困難。
三、企業(yè)合同管理審計應(yīng)注意的問題
企業(yè)合同管理審計過程中不可避免也存著以下方面的問題，為提高合同管理審計的效率應(yīng)其予以重視。
第9篇：敏捷的項目管理范文
【關(guān)鍵詞】工程項目 動態(tài)聯(lián)盟 運作機制
1 工程項目組織動態(tài)聯(lián)盟概述
1.1傳統(tǒng)工程項目組織模式的困境
在傳統(tǒng)的建筑企業(yè)組織管理中，我國的建筑企業(yè)紛紛采用了集團化的組織模式。隨著市場需求不確定性的加劇和市場機遇把握難度的日益提高，這種傳統(tǒng)的組織結(jié)構(gòu)己經(jīng)越來越不能適應(yīng)。
1.1.1建筑企業(yè)龐大且固定的集團化組織結(jié)構(gòu)，使其難以對變化著的市場做出敏捷的反應(yīng)。由于工程項目產(chǎn)品的單一性，建筑企業(yè)需要針對不同的項目分析其由于地域、技術(shù)條件、文化等因素造成對工程實施的影響。
1.1.2工程成本高。激烈的競爭己經(jīng)使企業(yè)利潤大幅下降，不能形成規(guī)模經(jīng)濟進一步造成了項目利潤的急劇下降，將嚴重影響建筑企業(yè)在面對國際市場時的生存能力。
1.1.3集團化組織模式在其組織結(jié)構(gòu)上的不足。平級項目部之間缺乏必要的溝通，共分利益且互相推卸責(zé)任，只考慮自身承擔(dān)的項目部分的實際情況，而不考慮整個項目的最終成果。
1.2動態(tài)聯(lián)盟的概念
動態(tài)聯(lián)盟這一提法從產(chǎn)生到現(xiàn)在只有10多年的時間，許多學(xué)者對企業(yè)動態(tài)聯(lián)盟進行了研究，但對于動態(tài)聯(lián)盟的概念，至今還沒有形成一個完全的統(tǒng)一的定義。本文給出的定義為：動態(tài)聯(lián)盟是兩個或兩個以上的企業(yè)或者特定的事業(yè)部門或職能部門，為了實現(xiàn)共同的目標，通過公司協(xié)議或聯(lián)合組織等方式而結(jié)成的一種網(wǎng)絡(luò)式的聯(lián)合體；是那些欲結(jié)盟的企業(yè)在自愿互利的原則下，出于降低交易費用、減少不確定性、實現(xiàn)優(yōu)勢互補等目的，以契約的方式結(jié)合起來的共同提高企業(yè)市場競爭力的合作模式。
1.3工程項目組織動態(tài)聯(lián)盟的定義及其優(yōu)勢
工程項目組織動態(tài)聯(lián)盟就是立足于建筑行業(yè)的特點，以施工聯(lián)合體為基礎(chǔ)，吸收動態(tài)聯(lián)盟的思想，針對具體的大型施工項目，突破原有建筑企業(yè)的有形界限，充分利用外部資源，通過建筑企業(yè)之間的最佳資源組合，創(chuàng)造出超常的競爭優(yōu)勢而進行的臨時組合，依靠現(xiàn)代化的網(wǎng)絡(luò)通訊設(shè)施達到資源共享、優(yōu)勢互補，項目結(jié)束后，原來的資源組合方式予以解散。它相比于傳統(tǒng)的集團化組織模式在作用效果上有明顯的優(yōu)勢：
第一，聯(lián)盟借助現(xiàn)代信息和通訊技術(shù)的強大支持，采用無層級、扁平化的管理組織方式，提高決策效率。第二，扁平化的網(wǎng)絡(luò)組織使權(quán)力由垂直變?yōu)樗?，組織成因獲得極大的自由而形成和諧、相互信任的關(guān)系。第三，通過信息技術(shù)進行溝通和協(xié)調(diào)，使信息傳遞實時、動態(tài)化，同時能極大地降低組織成本。第四，針對工程項目的建筑產(chǎn)品單件性，建筑企業(yè)的動態(tài)聯(lián)盟強調(diào)合作的一次性，暫時性。動態(tài)聯(lián)盟強調(diào)時效性，具有高度的彈性和靈活性。
2 工程項目組織動態(tài)聯(lián)盟模式的構(gòu)建
2.1動態(tài)聯(lián)盟的組建原則
工程項目組織動態(tài)聯(lián)盟結(jié)構(gòu)的確定應(yīng)該充分考慮具體工程項目的特點、所需資源的分布情況、聯(lián)盟活動的環(huán)境基礎(chǔ)條件等因素，并在一定的原則下實施結(jié)構(gòu)組建。
2.1.1目標導(dǎo)向原則。動態(tài)聯(lián)盟構(gòu)建的目標是抓住市場機遇，提高組織在市場中的競爭力。據(jù)此，應(yīng)該根據(jù)工程項目的資源需要對各個盟員企業(yè)的資源進行整合，獲得生產(chǎn)的有效形式，實現(xiàn)建筑制造所追求的目標。
2.1.2學(xué)習(xí)性原則。通過動態(tài)聯(lián)盟，盟員企業(yè)要互相借鑒彼此的經(jīng)驗，專心培養(yǎng)自己的核心能力。
2.1.3共享理念原則。動態(tài)聯(lián)盟的思想是各個盟員企業(yè)資源能力的整合共享思想，強調(diào)企業(yè)的雙贏理念。依靠盟員企業(yè)的整合力量實現(xiàn)整體優(yōu)勢，從而創(chuàng)造出1+1＞2的利益。
2.1.4信譽原則。在動態(tài)聯(lián)盟中，特別注意加盟各方的信譽。若盟員的信譽等級高，則它將有更多的機會參與到聯(lián)盟中，贏得更多的利益機會。
2.2項目動態(tài)聯(lián)盟的組織模式
作為工程項目管理的建筑業(yè)企業(yè)群體的動態(tài)聯(lián)盟組織，它的運營方式一般是面向建筑產(chǎn)品的全過程。動態(tài)聯(lián)盟組織的描述可分為四個層次：動態(tài)聯(lián)盟組織、項目部、專業(yè)承包隊伍和勞務(wù)分包組織。但無論哪一個層次，其伙伴合作的形式具有多樣性和靈活性。概括起來主要有五種方式：
2.2.1供應(yīng)鏈式。供應(yīng)鏈式是對整個供應(yīng)鏈系統(tǒng)進行計劃、協(xié)調(diào)、操作、控制、和優(yōu)化的活動和過程，這種合作形式是以建筑產(chǎn)品為主線進行的，并建立在建筑產(chǎn)品的價格、質(zhì)量、進度等基礎(chǔ)上相當(dāng)穩(wěn)定的合作，合作企業(yè)之間是上下游的關(guān)系。在工程項目建設(shè)中，以在建工程項目所需人、材、機為主要的對象展開合作，由設(shè)備供應(yīng)商、原材料供應(yīng)商、項目建造商組建成聯(lián)盟。
2.2.2總承包式。對總承包發(fā)包的項目，可在招標前若干施工企業(yè)、設(shè)計單位和材料供應(yīng)商以動態(tài)聯(lián)盟方式組建施工聯(lián)合體進行總承包投標，中標后根據(jù)聯(lián)合協(xié)議以動態(tài)聯(lián)盟的方式進行工程建設(shè)。也可在中標后，由總承包企業(yè)組建設(shè)計單位、施工分包單位和材料設(shè)備供應(yīng)商的動態(tài)聯(lián)盟，以動態(tài)聯(lián)盟方式進行工程建設(shè)。
2.2.3轉(zhuǎn)包分包式。由于工程項目的工程量一般都很大，總承包商不可能獨立完成整個項目，而會將項目中的一部分工作量轉(zhuǎn)包給一個或多個分包商。業(yè)主只與總承包商進行溝通，不直接與分包商聯(lián)系。總承包商對工程項目提出質(zhì)量、價格、進度等的要求，各分包企業(yè)組織完成，總承包商負責(zé)管理協(xié)調(diào)各分包商。
2.2.4插入兼容式。租賃市場、勞務(wù)建設(shè)工程管理的企業(yè)聯(lián)盟的承包商可以通過項目管理過程的需要，通過設(shè)備市場、人才市場等建立二級市場，使之與企業(yè)的自身核心資源結(jié)合，這種合作是動態(tài)聯(lián)盟具有很強的可塑性和靈活性。
2.2.5網(wǎng)絡(luò)式。網(wǎng)絡(luò)式動態(tài)聯(lián)盟是建立在自愿合作和信息與活動交互基礎(chǔ)上的，動態(tài)聯(lián)盟體內(nèi)的各方未必有合同關(guān)系，各方之間根據(jù)聯(lián)盟協(xié)議進行合作，這使合作各方能夠在平等地位上真正實現(xiàn)資源共享和風(fēng)險共擔(dān)。項目參與各方之間通過聯(lián)盟體內(nèi)部的信息溝通，及時了解施工進度，協(xié)調(diào)解決施工過程中出現(xiàn)圖紙?zhí)峁┖筒牧显O(shè)備的供應(yīng)延誤、施工工期拖延、專業(yè)工程的交接與配合等問題。這是一種真正意義上的動態(tài)聯(lián)盟模式，是項目組織模式未來發(fā)展的趨勢。
3 建筑企業(yè)動態(tài)聯(lián)盟模式的運作
3.1聯(lián)盟的利潤分配機制
動態(tài)聯(lián)盟是一個以市場機遇為主要驅(qū)動力的、暫時的組織結(jié)合體，對參與動態(tài)聯(lián)盟的伙伴來說，其根本目的是為了取得一定的經(jīng)濟利益，而對于動態(tài)聯(lián)盟的每一個盟員企業(yè)來說，收益和風(fēng)險是不可分割的。因此，科學(xué)、合理的利益分配機制是決定動態(tài)聯(lián)盟成敗的關(guān)鍵因素。
對于基于大型工程項目而組建的建筑企業(yè)動態(tài)聯(lián)盟，我們不能僅僅從投資額的大小出發(fā)確定收益比例，而需要充分考慮動態(tài)聯(lián)盟企業(yè)中盟員企業(yè)投資所承擔(dān)的風(fēng)險大小，從而保證動態(tài)聯(lián)盟能夠真正實現(xiàn)“風(fēng)險分擔(dān)，收益共享”。
3.2聯(lián)盟利潤分配模式
3.2.1產(chǎn)出分享模式，參與合作的所有成員(包括盟主和盟員) 按一定的分配比例系數(shù)從合作最終的總利潤中分得自己應(yīng)得部分，是一種利益共享、風(fēng)險共擔(dān)的分配模式。
3.2.2固定支付模式，盟主企業(yè)根據(jù)其他成員承擔(dān)的任務(wù)按事先協(xié)商好的酬金給其從合作最終的總利潤中支付固定的報酬，而其享有合作的其余全部剩余，同時也承擔(dān)全部風(fēng)險。這種分配模式接近市場交易的模式。
3.2.3混合模式，動態(tài)聯(lián)盟成員既從聯(lián)盟取得固定的報酬，同時也從總利潤產(chǎn)出中按一定分配比例取得剩余。
模式的具體選用視實際的市場機遇的性質(zhì)、產(chǎn)品競爭力、發(fā)展戰(zhàn)略和風(fēng)險態(tài)度等因素而決定。
3.3聯(lián)盟協(xié)調(diào)溝通機制
建筑企業(yè)動態(tài)聯(lián)盟體聯(lián)盟各方既有合作的愿望，又有目標的差異，在項目的運行中，盟員們都力圖擴大自身的收益，同時一方利益的取得又依賴于各方的合作，因而動態(tài)聯(lián)盟體的協(xié)調(diào)可以看作具有聯(lián)盟性質(zhì)的合作式協(xié)調(diào)，協(xié)調(diào)的內(nèi)容廣泛并且存在于聯(lián)盟創(chuàng)立、運行、解散整個生命周期，協(xié)調(diào)的過程就是盟員在各種方案上反復(fù)移動的過程，直到在某一個方案達成妥協(xié)一致。
3.4聯(lián)盟的風(fēng)險控制機制
風(fēng)險與收益是共存的，有收益的項目就必然有風(fēng)險。如何建立風(fēng)險控制機制，從事前、事中、事后全方位的控制風(fēng)險，對項目的全過程進行有效的控制，是項目管理的關(guān)鍵。
3.4.1聯(lián)盟體內(nèi)部的風(fēng)險管理措施
（1）慎重選擇合作伙伴。在組建動態(tài)聯(lián)盟時，合作伙伴的選擇是首要的任務(wù)。因為工程建設(shè)是風(fēng)險事業(yè)，所選擇的伙伴應(yīng)該能夠“同舟共濟”，共同承擔(dān)風(fēng)險，這對是否完成工程、能否盈利至關(guān)重要。
（2）簽訂責(zé)權(quán)利明確的聯(lián)盟體協(xié)議。聯(lián)盟體協(xié)議是指為了投標獲取項目、實施項目進行協(xié)作，就各盟員企業(yè)的職責(zé)、權(quán)利和義務(wù)達成的協(xié)議。
3.4.2與工程有關(guān)的風(fēng)險管理措施
與業(yè)主簽訂公平的工程合同。工程合同是連接業(yè)主和動態(tài)聯(lián)盟體的法律紐帶，業(yè)主和聯(lián)盟體在合同風(fēng)險和利益分配中相互約束。工程合同必須公平，聯(lián)盟體應(yīng)該說服業(yè)主采納工程合同條件，如FIDIC合同條件。聯(lián)盟體應(yīng)該特別重視工程合同中的支付、報價、變更及索賠等條款，特別是在合同實施期間發(fā)生通貨膨脹、變更、不可抗力等事件而導(dǎo)致的費用以及工期損失的補償。
3.4.3與外部環(huán)境有關(guān)的風(fēng)險管理措施
動態(tài)聯(lián)盟在承攬某一個具體的工程項目時，應(yīng)該適應(yīng)當(dāng)?shù)氐沫h(huán)境，了解當(dāng)?shù)爻霈F(xiàn)的新的法律、規(guī)章制度、對手，同時與當(dāng)?shù)卣约跋嚓P(guān)部門建立良好的關(guān)系，在項目執(zhí)行過程中，聯(lián)盟體有必要建立各種渠道與項目各個參與方進行良好的溝通，并且維護好這些交流渠道。
4 結(jié)論
通過對我國工程項目的現(xiàn)行組織模式進行了深入的分析，揭示了其傳統(tǒng)組織模式轉(zhuǎn)變的原因。在充分借鑒制造業(yè)動態(tài)聯(lián)盟思想的基礎(chǔ)上，根據(jù)我國建筑企業(yè)的自身特征，提出了建筑企業(yè)動態(tài)聯(lián)盟組織模式。研究結(jié)論如下：
4.1通過對我國建筑業(yè)傳統(tǒng)組織模式的分析及入世之后我國建筑企業(yè)發(fā)展方向的研究得出:我國建筑企業(yè)目前最根本的任務(wù)是增強自身的核心競爭力，變傳統(tǒng)的單個競爭為聯(lián)合競爭，借助外部資源來發(fā)展自身優(yōu)勢，轉(zhuǎn)向動態(tài)聯(lián)盟組織模式。
4.2從建筑企業(yè)從事工程項目建設(shè)的過程和方式分析，建筑企業(yè)動態(tài)聯(lián)盟是可行的，符合我國建筑企業(yè)發(fā)展的需要。
4.3針對具體的工程項目，本文建立了動態(tài)聯(lián)盟的利潤分配機制、協(xié)調(diào)溝通機制、風(fēng)險控制機制。
參考文獻：
[1]賈平.企業(yè)動態(tài)聯(lián)盟[M].北京:經(jīng)濟管理出版社，2003.
[2]林鳴，馬士華.動態(tài)聯(lián)盟——項目管理新模式[M].北京，電子工業(yè)出版社，2003.
[3]宋金昭，動態(tài)聯(lián)盟在建筑企業(yè)中的應(yīng)用研究[A].管理科學(xué)與工程，2004.
[4]金維興，21世紀中國建筑企業(yè)管理模式的總體構(gòu)思[J].中國科學(xué)基金，NO.2， 2000.
[5]趙艷萍，王棟.動態(tài)聯(lián)盟管理協(xié)作風(fēng)險的分析[J].商場現(xiàn)代化，2006，(33).
[6]陳一鳴，高陽.動態(tài)聯(lián)盟企業(yè)的一種組織結(jié)構(gòu)[J].技術(shù)經(jīng)濟與管理研究，2001， (06).
