我相信大部分都知道“敏捷管理”，且都會喊一下它的口號“敏捷迭代，小步快跑”，那我們除了喊口號之外，還做了什麼呢？或者說，對於我們的專案管理，又帶來了什麼不同的點呢？

試想一個場景，公司目前要引入“敏捷管理“，開始用兩週一個迭代的週期進行。

接著我們常規情況下可能會這樣做，簡單排個需求優先順序，然後對於緊急又重要的出原型和需求，寫需求文件進行評審，最後開發抓緊去做，偶爾追問一下開發的進度，接著開發完了進行測試，然後吭哧吭哧到了第二週的週五晚上上線。

請問這是敏捷嗎？

這樣只是用傳統的“瀑布型“去套“敏捷型”，僅此而已。

到最後你發現，兩週一個版本，所有成員瘋狂加班，簡直要人命，一上線發現又全都是問題，還能怎麼辦？回滾吧。。。

那真正的敏捷型專案管理，到底是怎麼做的，它有什麼方法論嗎？

我會嘗試從“規劃”“需求”“拆解”“跟進”“回顧”五個方面講解，我們要如何做敏捷管理。

敏捷管理的一些概念

專案管理有很多型別，如預測性、敏捷型等等，不能說哪個更好。具體根據自身的專案出發，找到最合適自己的那條路，才是最好的。

所以我們得理清楚，敏捷並不是神，它只是眾多專案管理的一種。

敏捷本身也有很多方法論，其中我要講的是“Scrum”，主要有4條宣言：

個體和互動高於流程和工具

工作的軟體高於詳細的文件

客戶合作高於合同談判

響應變化高於遵循計劃

這4條宣言一定程度上涵蓋了我接下來要講的內容，當然這些宣言記不記住都沒啥關係，最重要的是從實踐找到方法，而不是在方法裡面找到方法。

所以我們開始從傳統的瀑布型開發轉成敏捷型開發，首先要做的是——規劃。

規劃

專案假定採用2周1迭代的小步快跑形式，那麼最核心最重要的其實是規劃。

規劃我認為主要有兩個最重要的點，一則團隊，二則關鍵時間點。

在團隊的規劃中，每個團隊的人數需控制在十個人以內，因為人數一多，交流的資訊會越複雜，這不適合敏捷的“個體和互動”的宣言。

如果團隊超過10人，則需要進行團隊拆分，每個團隊需要設定一個“Scrum Master（團隊負責人）”。

有了團隊後，並且對團隊進行具體的分工後，則需要開始規劃關鍵時間點。

在具體的規劃中，我們需要在兩週的時間規劃出關鍵的時間節點；我們可以採用倒推的形式去思考到底有什麼關鍵節點。

如上線前，我們需要

具體

的“上線時間”，再往前我們需要

具體

的“測試時間”，測試之前我們需要知道

具體

“開發完結時間”，再繼續往前我們需要知道

具體

“評審時間”。

這裡的關鍵點在於“具體”，直接透過

甘特圖

的形式標識出具體的關鍵時間，和每個職位在各自環節下的處理時間。

圖片只是示例，並不代表具體情況

接著我們每次版本都根據規劃的時間節點，按部就班的進行，有了指向標，才能讓專案更清晰。

我們只有規劃好整個盤子，才能往裡面加東西，不會造成自己和團隊的混亂。

需求

有了規劃後，我們需要知道這期做什麼，而做什麼則是“需求”決定的，即設定“Sprint Backlog（當前衝刺需要解決的事情）”

本期需求迭代的內容需要進行詳盡的分析，根據產品對需求的優先順序來確定本期迭代的內容，這裡優先順序的排列可根據“緊急且重要”、“緊急但不重要”、“不緊急但重要”、“不緊急且不重要”四象限進行分析。

如發現某個需求涉及的內容非常廣大，則需要我們產品經理對這個需求再進一步的細化，從整體拆成區域性進行重新排列，以“天”為單位。

最後，我們確定好本期的“Sprint Backlog”後，則開始策劃需求吧！

拆解

假設我們經過了需求評審，在評審中，我們可以提前和開發負責人溝通這些需求對應的開發人員，這樣他們在評審的過程中參與度才是最高的，不過在評審後，按照平常的情況，可能我們直接讓他們進行開發了。

但是先彆著急，也請先別讓開發的小夥伴直接進入開發，讓他們首先對自己的開發任務進行“拆解”。

假設一個開發的任務是“篩選列表項”功能，按照一般的開發邏輯，可能從頁面的元素、JS、介面、資料庫索引、前後端聯調等步驟進行開發。

這裡面其實對於開發來說是可以詳細拆解的。

所以我們需要讓開發把具體的開發的功能項，按照“小時”進行拆分，確定好每個開發的步驟和工時，我們才能做到實際的跟進，從每個工作項著手跟進具體的完成度，才能做到有的放矢。

這整個拆解的最後的內容，稱之為“SBI（和WBS同理，只是會更加細化開發工作項的內容）”。

有了“SBI”後，我們就可以實時跟進開發進度，當某個事項沒有完成時，可以隨時透過任務項反映出這個功能是否有風險。

因為前一個工作項和後一個工作項，相互之間大機率是耦合的，缺少這一點，可能也會導致整個功能無法上線。

跟進

有了具體的工作項後，則需要進行跟進了，當然這一節雖然說的是跟進，但是更注重“工具的使用”，這個工具是——看板。

看板主要呈現工作項的流轉和完結情況，透過小卡片的形式，實時跟進每個開發工作項對應泳道下的情況，如這個工作項在“開發中”，過了幾天工作項可以流轉到“測試中”，每個工作項都是流動狀態的！

舉個例子：A開發者正在開發“A工作項”，此時對應的狀態是“開發中”，開發完成後 ，則流轉到“已完成”，等到工作項上到測試環境，此時工作項流轉到“測試中”，最後上線，任務流轉到“已完成”。

這個看板可以是實際的黑板，用線條畫出來，也可透過網上的工具，如TAPD的網路看板進行管理，關鍵在於呈現任務項的流動狀態，和當前節點狀態。

看板完成後，還需要完成任務項卡片的製作，卡片主要描述具體的任務項，完成時間和工時，描述清楚即可。

此時有了看板和卡片，則這個管理專案的工具已經完成了。

但是有了看板還不夠，我們還需要透過“每日站會”來面對面溝通任務情況，每日會議的時間不能超過10分鐘，每個成員時間控制在一分鐘內。

每個團隊成員都需要說三點：

1。我昨天做了什麼

2。我今天做了什麼

3。當前有什麼風險，需要誰進行協助

透過站會，我們才能做到真正跟進開發任務項的完成情況，才知道這個任務項是否有風險；有風險的情況下，是加班解決，還是這個功能只能延期等等的解決方案。

我們透過看板和每日站會這兩個工具，實時跟進了每個衝刺的具體情況，才能做到心中有數，把風險下降到最低。

需要專案管理資料合集的同學可先關注然後私信我哦

更多精彩內容請點選“瞭解更多”