敏捷，scrum，看闆，精益，xp，瀑布、PRINCE2和PMBOK，這麼多不斷演變的項目管理方法可能會讓人困惑。在你看了這個完整的項目管理方法指南中，這一切都變得非常簡單易懂。

有許多不同的項目管理方法可以應用于不同的項目，但了解它們之間的差異，以及選擇适合使用哪種方法卻是非常棘手的。

閱讀本指南，讓您自己了解最常用的項目管理方法，并考慮它們如何才能在信息團隊交付項目的過程中發揮最佳作用。

常見9種項目管理方法概述：

• 敏捷 -- 協作叠代交付任何作品
• Scrum -- 使一個小型，跨職能，自我管理的團隊能夠快速交付
• 看闆 -- 通過提高工作進展的可視性，提高交付速度和質量，并限制多任務處理
• Scrumban -- 像看闆一樣每天都像Scrum一樣限制工作進展
• 精益 -- 簡化和消除浪費，以更少的投入獲得更多
• XP -- 極限編程方法 - 堅定地進行開發以确保質量
• 瀑布 -- 完全規劃項目，然後通過階段執行
• PRINCE2 -- 受控的項目管理，沒有任何機會
• PMI的PMBOK -- 将通用标準應用于瀑布項目管理

看完下面關于每種方法的介紹之後，請關注本頭條，還将繼續介紹《如何選擇項目管理方法》《對于外包團隊最佳的項目管理方法》

介紹項目管理方法

讓我們試着了解項目管理方法是什麼。PMI對項目管理方法論的廣泛定義是有幫助的 - “方法論是一個在一門學科中工作的人使用的實踐，技術，程序和規則的系統” - 但方法學必須植根于更基本的東西，這就決定了我們為什麼要選擇以某種方式做事，所以我建議它也應該包括主題。

作為項目經理，交付項目有很多不同的方式。一般來說，這些方式是我們的方法論 - 應用不同的原則，主題，框架，流程和标準來幫助為我們交付項目提供結構。

項目管理方法

某些項目管理方法隻是簡單地定義了基本原則，比如Agile敏捷。而有的則定義了包括主題，原則和流程的“全套”方法框架，如Prince2。有些是與一些過程有關的标準的廣泛列表，如PMI的PMBOK或XP，其中一些非常輕便，并且簡單地定義過程，如Scrum。

也許會有争議，但是與其無休止地争論争論哪些屬于方法論哪些不是，我甯可認為使用對項目管理方法的較為寬泛（也許不準确）的理解，簡單地指我們綜合運用各種方法一起把項目完成的最佳實踐框架。我不認為一種方法必須是一個完整的全棧實現“系統”才能被視為一種方法。

這是一個很好且有用的定義，因為事實上，作為項目經理，我們會使用為客戶和項目量身定制的各種原則，主題和流程的大雜燴。

在我們開始之前，讓我們先弄清楚一件事情，方法論有很多，但沒有絕對“正确的”方法。沒有一種萬能的方法是每個項目都應該始終使用的方法。

最終，最好的方法是合理的且最适合項目、團隊和客戶的。我們先來看看一些比較流行的項目管理方法，并了解一些在信息世界中交付項目的寶貴經驗。

通用項目管理方法

敏捷方法論 - 協作叠代交付任何作品

讓我們從每個人最喜歡的流行詞開始，敏捷。事實上，敏捷并不是一種方法論，而是一套開發軟件的原則。敏捷宣言概述了四條基本原則 - 個人與過程與工具之間的相互作用 ; 通過全面的文檔工作軟件 ; 客戶協作合同談判; 回應計劃的變化 - 敏捷更多的是理念和一套遵循的價值觀和原則，而不是适用于項目的過程。

當人們談論敏捷項目管理方法論時，他們通常所描述的是一個靈活的叠代設計和構建過程。敏捷項目的特點是根據具體情況需要構思，執行和調整的一系列任務，而不是預先規劃的過程。敏捷可以幫助團隊通過增量叠代工作流程來應對不可預測性。

就像一個好廚師在烹饪過程中品嘗食物時一樣，在添加缺少的成分時，一個敏捷的項目管理過程要求項目團隊循環執行規劃，執行和評估過程。

敏捷與其他項目管理方法不同，後者通常認為影響項目的因素是可預測的，因此它強調對變化情況的适應性，項目團隊之間以及他們與客戶之間充分和持續的溝通。敏捷方法非常适用于動态環境，這些動态環境可能會發生變化或不斷變化的需求，例如軟件和遊戲開發。

作為一套原則，敏捷是一個大的概念，并且傾向于被用作包括Scrum，極限編程（XP），看闆和Scrumban在内的敏捷風格的總稱。簡而言之，敏捷并不是一種可以直接使用的方法或流程，這讓事情變得混亂 - 如果您掌握了這些原則，您仍然需要定義交付項目的流程。

Scrum方法論 - 使一個小型，跨職能，自我管理的團隊能夠快速交付

Scrum是一種項目管理方法，提出了改進交付的原則和流程。在軟件開發中，Scrum是将敏捷原理應用于實踐的最流行和最簡單的框架之一。

Scrum的目标是改善溝通，團隊合作和發展速度。如果你聽到人們在談論沖刺，混亂，積壓和burndowns，他們可能在談論Scrum或其衍生物。

Scrum并不是一個真正的項目管理方法論，而是一個持續開發和維護複雜産品的框架。Scrum是一種輕量級的方法，它定義了一組簡單的角色，會議和工具，以高效，叠代和遞增方式提供有價值的可交付功能。

從根本上講，Scrum的重點是讓自我管理團隊提供和定義角色和責任，以便在盡可能快地提供正确的方式和正确的方式之間創造健康的緊張關系。

Scrum倡導使用一個由多達9人組成的小型跨職能團隊來處理待處理項目 - 一組用戶故事（需求） - 由産品負責人定義并确定優先級。

工作被分為一個個“sprints”，一個通常為2-4周的開發周期，在此期間，每天的“scrum”發生在團隊報告進展和障礙的地方。在每個sprint結束時，工作将在Sprint評審會議上進行審核，以便與産品負責人一起确定是否通過完成定義（DoD）。

Scrum由Scrum Master提供支持和服務，Scrum Master支持并領導Scrum，Sprint演示和評論，領導開發團隊完成他們的最佳工作，并在每個sprint之後領先進行“sprint回顧”，以确保團隊持續優化和改進。

Scrum最初是為軟件開發而設計的，盡管Scrum可以提供靈活的構件，但Scrum并不适合整合到通常更具戰略性和創造性的外包開發領域。即使在一個網站的開發項目上，固定的預算，時間表和範圍也會讓一個Scrum自我管理團隊缺乏靈活性，而這個項目的開始和結束都是定義好的。

這并不是說它不适用于開發項目 - 外包開發項目經理可以扮演scrum的主人，而客戶則可以作為一個大型快樂混合團隊的産品所有者。但它通常比這更複雜，固定的預算和範圍提供了嚴重的限制。這就是為什麼許多機構采用scrum的一些概念 - 小型，自組織，跨職能團隊，日常站立，進度演示和回顧，并以某種混合方式使用它們。

看闆方法論 - 通過提高工作進展的可視性并限制多任務，提高交付速度和質量

看闆是一種專注于精益原則和提高效率的嚴格流程的項目管理方法論。它在很多方面與Scrum類似 - 它們都是盡早發布，并經常與合作和自我管理團隊合作。但與Scrum相比，看闆是一種更具進化性的變化，因為它不太具有說服力，所以它更輕松地登陸敏捷世界。

看闆流程簡單，靈活，沒有規定的角色，隻是試圖通過增加團隊對真正重要的事情的關注來提高吞吐量。核心實踐是對工作流進行可視化，限制正在進行的工作，衡量交付周期，明确制定工藝策略并不斷評估改進機會。

看闆的重點是不斷發布的工作，速度更快，質量更好。對于優先級經常變化的運行或維護環境而言，這非常棒。看闆的重點是測量提前期 - 在收到簡報後需要多長時間才能交付。

通過看闆，項目經理通常在Kanban白闆或Trello等在線工具上使用便箋來表示團隊的工作流程，其分類很簡單，如“待辦事項”，“正在做”和“已完成”。

這可以顯示您想要執行的操作并限制正在進行的工作（WIP），以便在您測量和優化完成項目的平均時間時改進工作流程。

它還使團隊可以直觀地看到接下來會發生什麼，這可以輕松重新排列優先順序，發現過程問題并防止任務停滞。這也有助于他們了解新任務如何影響正在進行的工作。

看闆非常适合需要穩定生産的工作，如生産或支持和維護。在機構的世界裡，它也可以成為一個有用的工具，因為它更适應變化，客戶也喜歡不斷地改變主意。如果Scrum看起來太僵化了，但你想做'敏捷'，看闆是一個更簡單的選擇。

Scrumban方法論 - 像看闆一樣每天都像Scrum一樣限制工作進展

Scrumban是一種相對較新的混合項目管理方法，将混合Scrum和看闆方法結合到項目管理中。它需要看闆的靈活性，并增加了一些Scrum結構來創建管理項目的新方法。

Scrumban并沒有在潛在的限制性時間框沖刺中工作，而是使用按需計劃原則來填補積壓工作，而任務由團隊負責分配任務，因為他們可以适應這些任務，就像看闆一樣。這意味着進行中的工作是有限的，開發團隊仍然專注于手頭的任務，而不是擔心沖刺審查會議和團隊承諾在沖刺中提供什麼。

然而，并非所有的看闆 - Scrumban保留每日Scrum與審查和回顧，以改善隻在需要時使用的過程。此外，沒有沖刺的限制，計劃是在需要的基礎上進行，而不是在沖刺周圍進行 - 這可能會節省時間。

Scrumban真的隻是通過消除沖刺和允許自适應方法來為Scrum添加一些靈活性。或者，您可以将其看作是為Kanban添加一些急需的結構，通過會議來協助和優化流程。

對于産品開發而言，Scrumban可能非常有用，因為前景不清晰，需求不斷發展或沒有明确的路線圖，以及流程是否需要在流程中包含支持和維護工作。

精益方法 - 精簡和消除浪費，以更少的資源交付更多

精益是一種專注于效率主題的項目管理方法論。可以說敏捷教父 - 精益就是用更少的錢做更多的事情。它通過識别價值開始，然後通過持續改善，通過優化價值流動和消除浪費來最大化價值。

這是一個有原則的主題，而不是一個方法論的決定過程和事情。它表明，通過解決導緻浪費的三種功能障礙，您可以少花錢多辦事; Muda，Mura和Muri，也被稱為3Ms。

• Muda正在消除廢物處理過程或任何最終不會增加客戶價值的事情。在數字世界中，這可能會消除幾輪修訂。
• Mura正在消除變化 - 消除标準流程造成的差異。對我們來說，這可能意味着标準化簡報和審批流程。
• 穆裡關于消除超載 - 最佳容量在60-70％; 除此之外，任何事情都會變慢。我們可以将此應用于最小化我們試圖通過代理機構運行的項目數量。

精益專注于改變我們的經營方式，以激光為中心實現價值。它将關注點從優化獨立技術，資産和垂直部門轉向優化通過整個價值流的流量項目，這些價值流橫跨技術，資産和部門橫向流向客戶。

在審查項目交付過程時，精益可以成為一種有益的思維方式 - 思考如何将項目過程剝離回僅僅提供價值的切合實際的要素，并且删除那些隻是松散的事情，或者你總是完成的方式它 - 你會想到精益。

XP - 極限編程方法 - 堅定地進行開發以确保質量

極限編程（XP）是一種軟件開發項目管理方法，它定義值和流程以提高軟件質量并确保對不斷變化的客戶需求的響應。的值，或原理非常類似于Scrum的，圍繞簡單起見，通信，反饋，尊重和勇氣。

它真正背離Scrum的地方在于定義規則或規範流程。其中一些類似于Scrum，但是圍繞設計編碼和測試的技術實踐有規則，這些規則使得它成為開發項目的特定對象。這些規則包括強制性的; 包括用戶故事，測試驅動開發（TDD），結對編程以及其他許多方面的持續集成。

瀑布方法 - 充分規劃項目，然後分階段執行

通常被稱為SDLC（軟件開發生命周期）的瀑布是一個項目管理方法學主題，它具有非常簡單的方法，它重視可靠的規劃，一次做好并且做得對，而不是增量和叠代交付的敏捷方法。這很容易理解，因為你隻需制定一個好的計劃，然後執行就可以了。

項目經理往往比較龐大而且負責，而且工作是事先進行廣泛的規劃，然後按照嚴格的順序執行，遵守要求，以一個單一且通常很長的周期交付項目。

任何工作開始前，需求都會在瀑布頂部的開始處全部定義。然後工作級聯，如通過項目階段的瀑布瀑布。在瀑布模型中，每個階段必須在下一個階段開始之前完成，并且階段中沒有重疊。通常，在瀑布方法中，一個階段的結果将作為下一個階段的輸入順序。

在計劃獲得批準後，除非絕對必要，否則幾乎沒有必要調整計劃，而且所需的更改通常需要更改請求。然後該項目從需求流程開始，直到設計，實施，測試和維護。

由于采用單循環方法，因此在瀑布項目中，一旦完成某項工作，就沒有多少空間可以反思，修改和适應。一旦你進入測試階段，很難回頭去改變在概念階段沒有很好設計的東西。當你走的時候，也沒有什麼可以顯示并告訴客戶的。你大肆宣傳完成該項目，并祈禱客戶喜歡它。這可能是非常危險的。

一般認為，瀑布在一些機構中被視為一種效率低下且過時的傳統項目管理方法。但是，如果需求是固定的，有據可查的和清晰的，技術被理解和成熟，項目很短，并且沒有從“敏捷”中獲得額外價值，瀑布可以成為一種有用且可預測的方法。瀑布方法實際上可以為預算，時間表和範圍提供更可預測的最終結果。

PRINCE2方法論控制的項目管理，沒有任何機會

PRINCE2是一個'完整的'瀑布式項目管理方法論，包含原則，主題和流程。它是由英國政府于1996年為IT項目創建的。'PRINCE'表示PR ojects IN Ç ontrolled ê nvironments。它是一種非常面向過程的方法，将項目分為多個階段，每個階段都有自己的計劃和流程。該方法為項目的每個階段定義投入和産出，以便不會有任何機會。

該系統強調企業采取的課程理由，因此第一步就是确定項目的明确需求，目标客戶是誰，是否有現實利益以及徹底的成本評估。項目委員會擁有該項目并對其成功負責。該董事會為團隊定義了結構，而項目經理負責監督較低級别的日常活動。該方法基于八個高層流程，為團隊提供更多的資源控制和有效降低風險的能力。

作為一種方法論，它非常全面 - 它是如何運行大型可預測的企業項目的一個很好的框架。它闡明了将會交付什麼，确保關注項目的可行性，明确界定角色和責任，通過例外（可以說是敏捷原則）支持管理，與PMBOK類似，提供了一個我們可以應用于其他方法的通用詞彙。另一方面，雖然原則和主題很好，但這個過程可能會使小項目變得繁重和繁瑣。

PRINCE2專為大型IT項目而設計，因此絕不會在某個機構中用作項目管理方法。但是，當我們考慮為客戶管理項目時，強調利用KPI和價值創造良好的商業案例，明确角色和職責，管理變更和風險很有幫助。

PMI的PMBOK方法 - 将通用标準應用于瀑布項目管理

PMI（項目管理協會）項目管理方法論并不是一種真正的方法學，而是一套參照項目管理的五個流程步驟的标準，它們概述了項目管理知識體系（PMBOK）。這些是啟動，計劃，執行，控制和關閉。

這不僅僅是一種方法論，而是一種在項目管理行業内被接受為标準的标準，慣例，流程，最佳實踐，術語和指導方針的框架。它包含許多項目管理過程和技術，通過它們來評估或完成項目運行方式或使用的方法。

因此，這是一個更理論化的參考指南，您可以通過認證，雖然它在IT方面很受歡迎，但并不真正在機構世界中飛翔。您實際上無法運行PMI或PMBOK項目，但您可以利用這些标準在項目周圍創建通用語言和最佳做法。與PRINCE2相比，你可以想象PMI的PMBOK和PRINCE2是互補的，而不是兩種不同或獨立的瀑布方法。

如何選擇正确的項目管理方法

選擇正确的項目管理方法很重要，因為它定義了我們的工作方式。項目管理方法論提供了可以指導我們實現項目成敗的結構。

因此，在決定在項目中使用哪種項目管理方法時，我們需要考慮項目的簡單性或複雜性，客戶，可用資源和項目限制（包括對變更和風險的偏好），時間表，工具和人。

在涉及項目管理方法時，沒有适用于所有業務類型，規模或行業的萬能解決方案。無論您是在一個充滿變化和變化的動态環境中工作，而是采用靈活的方法。或者，如果您在非常固定，嚴格的要求，時間表和預算内工作，并采用瀑布式方法，那麼每種項目管理方法都有其自身的優勢和弱點。

最終，所選擇的方法應該基于其為客戶提供最大價值的能力進行分析，對交付方案的影響最小，滿足組織目标和價值的程度如何，項目團隊必須處理的限制，利益相關者的需求，涉及的風險，項目規模，成本以及項目的複雜性。

外包開發團隊最好的方法是什麼？

簡而言之，沒有對錯 - 這取決于你的客戶，你的團隊和項目。

也就是說，在一個團隊中，幾乎普遍地建議瀑布對于一個項目來說可能是一個好方法，這無異于為自己畫一個大目标。瀑布是沒有客戶或團隊想要聽到的東西 - 我們都希望被視為最前沿，而瀑布絕對不是很酷。

這不僅不是很酷，但瀑布是具有挑戰性的，因為它在任何創造價值的工作完成之前需要大量的前期規劃。有時需要規劃，因為客戶需要批準成本，時間表和範圍。但是客戶通常不願意為計劃付費，即使他們這樣做，如果您的計劃不符合要求，會發生什麼？

事實上，在IT世界中，我們經常會遇到要做出準确的預估。我們通常在不是太明确的項目中使用新技術。因此，除非您一次又一次地做同樣類型的項目，否則一旦開始項目，您的計劃可能就會過時。因此，雖然客戶喜歡可交付成果，預算和時間表的可預測性，但瀑布式方法本質上不靈活。

那麼敏捷的味道呢？

在代理和客戶之間，對敏捷的理解往往非常流暢。敏捷在很大程度上被稱為'不是瀑布'，而且被廣泛誤解為意味着以更少，更快，更便宜的方式做更多的事情。你為什麼不想要那個？

客戶傾向于喜歡敏捷的想法，因為它明顯具有靈活性來支持項目，并為他們提供更多的機會來提供反饋或在整個項目中持續改變他們的想法。

他們經常認為這意味着他們會以更少的工作量完成更多的工作，或者他們實際上不需要對任何事情做出最終決定，因為他們可以改變自己的想法，甚至到最後一刻。

這是真的，但不是真的整個故事。

故事的其他部分是這種靈活性是昂貴的 - 是的，你可以樞軸轉動，改變主意，但它耗費時間，而且時間花錢。

另一個挑戰是，為了成功并且真正敏捷，客戶必須使自己能夠獲得并被授權作出決策（這在分級和董事會導向的組織中是罕見的），并且提供持續的反饋和優先級以便保留項目移動。這通常非常棘手。

在很多方面，這歸結為信任。客戶是否真的相信該機構能夠提供價值，他們是否願意為成功之路付出失敗的代價？從根本上說，機構想要為他們所從事的工作獲得報酬，并且客戶希望機構能夠第一時間完成他們的最佳工作。需要有一些快樂的媒介。

少花錢多辦事，消除浪費是一種很好的精益原則，但這種方法面臨的挑戰往往是客戶 - 外包方關系; 大量的浪費是由客戶引起的，沒有真正的嵌入式客戶端，具有真正的決策權力和大量的相互信任，沒有任何一種敏捷項目方法能夠解決這個問題。

但是，如果有相互信任，并且願意嘗試，它可以創造出魔術發生的正确條件。事實是，敏捷可能會更好，但敏捷并不便宜或容易。

所以敏捷可能意味着應用從Scrum到XP的各種不同方法 - 最好的方法是挑選最适合您和您的團隊的産品，以實現最大的價值。

它要求我們的客戶成熟起來，明白我們不能确切地定義他們會得到什麼，或者什麼時候，但有了一些健康的信任，我們将一起努力，盡我們所能。

結論是

選擇最合适的項目管理方法可能會很棘手。這取決于很多變數，其中許多變數是我們無法控制的。

但這是真正重要的 - 超越了這個領域方法論的“搶地盤遊戲”。項目管理方法隻是幫助我們交付項目的工具。對于方法論的最終細節來說，真的不值得争論 - 相反，我們應該把重點放在更大的局面上。無論是看闆，瀑布還是其他方法，它都無關緊要。

重要的是要做好質量工作，滿足用戶需求，為我們的客戶創造價值。

最好的方法是持續有機地改進，适應并通過強大的協作增加産出的價值，因此總和遠大于部分。

這是一種讓客戶感到驚喜和愉悅的方法，通過持續不斷交付有價值和正确的産品。要做到這一點，你需要務實，而不是機械教條地使用你的方法。

來源：轉載

關注公衆号：PMP項目管理之家、才聚項目管理PMP暨NPDP考試中心

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!