敏捷項目管理與傳統(tǒng)項目管理有什么區(qū)別？

敏捷項目管理VS傳統(tǒng)項目管理

軟件項目管理的兩大主流管理模式分別是傳統(tǒng)項目管理和敏捷項目管理。傳統(tǒng)項目管理童超采用的是瀑布式、部分迭代開發(fā)模式，要求在項目建設期，需求足夠明確、文檔足夠規(guī)范，迭代過程中需求變更越多，越晚，對項目影響越大，會影響到項目的交付質量。

敏捷項目管理作為新興的項目管理模式，簡化了傳統(tǒng)項目管理的繁瑣流程和文檔。以Scrum為代表，歡迎需求變更，在客戶需求不明確的時候，以在較短的周期內開發(fā)出可用的軟件為目標來幫助客戶描述自己的需求。迭代過程中的需求變更會加入到項目繼續(xù)迭代需求池，豐富項目的產品功能。

一、管理流程

完整的項目管理流程可以總結氛圍五個過程組：啟動、規(guī)劃、執(zhí)行、監(jiān)控、收尾，敏捷項目管理框架是：構想、推測、探索、適應、結束，和PMBOK知識體系項目管理五大過程組一一對齊。

1、傳統(tǒng)項目管理

傳統(tǒng)的項目管理要對項目的所有過程進行管理和風險把控，并要求在不同環(huán)節(jié)有文檔輸入和輸出。比如PMBOK對項目整合管理的過程組做了文檔輸入和輸出的整理，但是，項目管理主要是對范圍，進度、成本，質量、人力資源、溝通、風險、采購和干系人進行管理，每個環(huán)節(jié)都存在啟動、規(guī)劃、執(zhí)行、監(jiān)控和收尾的過程。

如果采用傳統(tǒng)項目管理模式，每個環(huán)節(jié)都必須要進行嚴格的規(guī)劃，一旦出現(xiàn)規(guī)劃以外的變更，都需要經過批準后才能執(zhí)行改變。

2、敏捷項目管理

敏捷項目管理簡化了繁瑣的流程和文檔管理，主張團隊內部面對面的溝通和交流，以Scrum為代表的的、簡單、持續(xù)集成、不斷交付、價值優(yōu)先、擁抱變化的原則在面對時刻變化的市場經濟和不斷發(fā)展的技術時變得十分友好。敏捷項目中，項目管理計劃分不同等級，可以用一個洋蔥圖來表示，也就是洋蔥計劃圖，如下圖：

戰(zhàn)略和投資規(guī)劃在敏捷項目管理的

最外層，由更廣泛的組織管理系統(tǒng)來處理。由外往內，不斷切分項目計劃，最后實現(xiàn)最小周期的可行性版本迭代。對復雜或不明確的客戶需求進行合理的分割，最終實現(xiàn)總體上的統(tǒng)一。

傳統(tǒng)鐵三角：范圍、成本、進度

敏捷鐵三角：進度、范圍、成本

敏捷三角：價值、質量、制約因素（成本、進度、范圍）

敏捷三角形的演變過程：

傳統(tǒng)項目鐵三角：范圍不可變

敏捷鐵三角：進度不可變

敏捷三角形：

1.價值目標：提供可交付的產品

2.質量目標：提供可靠的、適應性強的可交付產品

3、約束目標：在可接受約束內，實現(xiàn)價值量目標

項目管理的鐵三角，從原來的時間，范圍，成本質量幾個要素，逐漸過渡到了敏捷所追求的價值，質量以及時間，范圍，成本構成的約束，形成了敏捷的三角形。

有了這個理念，我們就可以把敏捷和項目管理做融合，項目管理多一些授權，多一些擁抱變化，就可以向敏捷靠近，敏捷多一些體系化，就可以向項目管理延伸，二者是一個融合的過程，這將是一個趨勢。

二、風險控制環(huán)節(jié)

項目風險在任何項目中都存在不確定性，一旦發(fā)生，會對項目造成積極或消極的影響，如范圍、進度、成本和質量。

傳統(tǒng)的項目管理：

傳統(tǒng)項目管理要求項目在規(guī)劃過程中規(guī)劃風險管理，識別風險，并且對風險進行定性/定量分析，給出風險應對方案。雖然已知的風險可以再被識別和分析后采取應對措施，但正是因為風險的不確定性，要求項目風險管理必須給未知風險或者已知又無法主動管理的風險分配一定的資源儲備。

所以，傳統(tǒng)項目管理會要求提供風險登記表，并且記錄風險應對措施在處理已識別風險及其根源方面的有效性，完成風險在評估和風險審計，直到風險被降到最低。

敏捷項目管理：

敏捷項目管理不同于傳統(tǒng)項目管理，開發(fā)評估是以工作量為導向而非時間導向。所以，在進行開發(fā)任務評估時采用的是相對估算而不是絕對估算，為風險留足了應對空間，同時Scrum集合了一線人員的參與，經驗分享，集思廣益，將小型團隊轉化成獨立的管理者，更有利于問題的解決。

敏捷項目管理在項目沒有正式結束前，交付的可用軟件是允許風險存在的，并且是根據風險的優(yōu)先級來進行排期修復。

三、第三方業(yè)務風險控制服務企業(yè)項目管理分析

項目管理模式：外瀑布內敏捷（有人稱為“信封法”）

第三方業(yè)務風險控制服務行業(yè)目前還沒有發(fā)展出固定的行業(yè)標桿，大家都在競爭中追求最大范圍的滿足行業(yè)需求。再這樣的背景前提下，大部分項目都沒有明確和長久穩(wěn)定的需求，Scrum管理模式很好的滿足了這個行業(yè)的項目管理現(xiàn)狀。

但是，作為行業(yè)客戶，在大部分的商務場景下客戶都會希望通過固定成本合同來實現(xiàn)自己的利益最大化，問題是現(xiàn)在合同雙方都很難在項目開始時明確約定需求和最終實現(xiàn)方式。所以，在客戶不能接受Scrum時，通常會選擇外瀑布內敏捷的項目管理模式，滿足雙方利益。

舉例：

如果把拍攝婚紗照作為一個項目，攝影師和新人作為項目主要成員，項目基本流程滿足：

1.選婚紗照的套餐（固定成本，確定基本需求）

2.拍攝（項目啟動）

3.挑照片（提交測試，開始驗收）

4.根據底片修圖（修復）

5.拿到照片（項目結束）

以上就是順序執(zhí)行，瀑布式的結果。

然而，拍攝的過程中，信任通常都會要求：

較短時間內提出新增造型、內景換外景的要求（切換pose的任務）

配合攝影師完成拍攝環(huán)節(jié)的工作（通過迭代，完成項目）

以上就是內部快速迭代，敏捷式的結果。

很顯然，新人在拍婚紗照前并不知道自己最終拿到的照片穿的回事哪套衣服，擺的會是哪個pose，但是很清楚的是哪天拍照、哪天挑照片、哪天可以拿到照片，這套流程同時滿足了內部和外部的需求。

只是，為了項目順利結束，可能在內部和外部需求時，并沒有要求完全以相同的速度前進，就像你不能以你配合完成攝影的速度去要求攝影樓馬上提供婚紗照。

四、傳統(tǒng)VS敏捷？適者生存

敏捷項目管理只是一個靈活的實踐框架，提供的是一套清晰游戲規(guī)則，根據不同的環(huán)境可以提供一系列不同的途徑。

傳統(tǒng)項目管理卻是一套中央集權制管理法，要求按計劃行事，任何環(huán)節(jié)發(fā)生變更都必須獲準后才能進行改變。

我們的項目經理或管理者們，很多都是從傳統(tǒng)項目管理或實踐中開始了解敏捷或在進行轉型的，但敏捷和傳統(tǒng)項目管理卻有著很大的不一樣，浙西不同，不是表面上的框架和方法論，也不僅僅是工具和技術的應用，更為關鍵的是思維方式的不同。

在市場經濟不斷發(fā)展、時刻變化的現(xiàn)代互聯(lián)網環(huán)境下，適應變化、擁抱變化的第三方業(yè)務風控服務企業(yè)的項目管理，才是友好的、可行的管理模式。

不管是傳統(tǒng)的瀑布式開發(fā)管理還是敏捷迭代式管理，沒有那個好與不好，只有在不同的項目環(huán)境中哪個更適合。敏捷已逐漸滲透到傳統(tǒng)的項目管理中，彼此相互相生的狀態(tài)。

五、閱讀參考

某博主po的一個很有趣的敏捷和瀑布對比例子，給大家做閱讀參考：

1.敏捷開發(fā)

客人到餐館來點菜（新項目）

不確定客戶想吃什么的時候，通常選好餐廳后會先看看餐廳的菜單（客戶往往提不出具體的需求）

根據圖文菜單，客人點了十個菜（根據原型和設計稿，基本確定了需求）

后廚開始準備（項目啟動）

配菜，炒菜、先上了兩盤，讓客人嘗嘗味道（先提供可用實例給客戶用）

客人說還不錯，后廚繼續(xù)準備后面的菜，陸續(xù)上菜（不斷迭代，不斷測試）

上菜過程中，客人突然發(fā)現(xiàn)有個菜的味道太淡了，讓后廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）

又上了兩盤，不夠辣，又拿到后廚加了辣（敏捷的壞處，需求沒有提前明確，反復迭代，增加了工作量）

到最后兩盤時，客人要求換兩個菜，還好沒有炒（迭代的好處，隨時接受需求變更）

客人吃完，很滿意（基本滿足了全部需求）。

2.瀑布模型開發(fā)

客人到餐館來點菜（新項目）

不確定客戶想吃什么的時候，通常選好餐廳后會先看看餐廳的菜單（客戶往往提不出具體的需求）

根據圖文菜單，客人點了十個菜（根據原型和設計稿，基本確定了需求）

后廚開始準備（項目啟動）

根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）

半個小時了，菜還沒上桌，客人餓極了（項目啟動后很長一段時間客戶什么都看不到）

再過20分鐘，十個菜一起上來了（項目最終一次交付）

客人說有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重復了想換掉（我是買單的，我要變需求）

這時候大堂經理來了，說:“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）

于是，后廚只給客戶加了鹽，加了辣。

客人吃完不是很滿意，下次不來了（沒有滿足需求）。