我相信大部分都知道“敏捷管理”，且都會喊一下它的口號“敏捷迭代，小步快跑”，那我們除了喊口號之外，還做了什么呢？或者說，對于我們的項目管理，又帶來了什么不同的點呢？
試想一個場景，公司目前要引入“敏捷管理“，開始用兩周一個迭代的周期進行。
接著我們常規情況下可能會這樣做，簡單排個需求優先級，然后對于緊急又重要的出原型和需求，寫需求文檔進行評審，最后開發抓緊去做，偶爾追問一下開發的進度，接著開發完了進行測試，然后吭哧吭哧到了第二周的周五晚上上線。
請問這是敏捷嗎？
這樣只是用傳統的“瀑布型“去套“敏捷型”，僅此而已。
到最后你發現，兩周一個版本，所有成員瘋狂加班，簡直要人命，一上線發現又全都是問題，還能怎么辦？回滾吧…
那真正的敏捷型項目管理，到底是怎么做的，它有什么方法論嗎？
我會嘗試從“規劃”“需求”“拆解”“跟進”“回顧”五個方面講解，我們要如何做敏捷管理。
敏捷管理的一些概念
項目管理有很多類型，如預測性、敏捷型等等，不能說哪個更好。具體根據自身的項目出發，找到最合適自己的那條路，才是最好的。
所以我們得理清楚，敏捷并不是神，它只是眾多項目管理的一種。
敏捷本身也有很多方法論，其中我要講的是“Scrum”，主要有4條宣言：
- 個體和互動高于流程和工具
- 工作的軟件高于詳細的文檔
- 客戶合作高于合同談判
- 響應變化高于遵循計劃
這4條宣言一定程度上涵蓋了我接下來要講的內容，當然這些宣言記不記住都沒啥關系，最重要的是從實踐找到方法，而不是在方法里面找到方法。
所以我們開始從傳統的瀑布型開發轉成敏捷型開發，首先要做的是——規劃。
規劃
項目假定采用2周1迭代的小步快跑形式，那么最核心最重要的其實是規劃。
規劃我認為主要有兩個最重要的點，一則團隊，二則關鍵時間點。
在團隊的規劃中，每個團隊的人數需控制在十個人以內，因為人數一多，交流的信息會越復雜，這不適合敏捷的“個體和互動”的宣言。
如果團隊超過10人，則需要進行團隊拆分，每個團隊需要設定一個“Scrum Master（團隊負責人）”。
有了團隊后，并且對團隊進行具體的分工后，則需要開始規劃關鍵時間點。
在具體的規劃中，我們需要在兩周的時間規劃出關鍵的時間節點；我們可以采用倒推的形式去思考到底有什么關鍵節點。
如上線前，我們需要具體的“上線時間”，再往前我們需要具體的“測試時間”，測試之前我們需要知道具體“開發完結時間”，再繼續往前我們需要知道具體“評審時間”。
這里的關鍵點在于“具體”，直接通過甘特圖的形式標識出具體的關鍵時間，和每個職位在各自環節下的處理時間。
圖片只是示例，并不代表具體情況
接著我們每次版本都根據規劃的時間節點，按部就班的進行，有了指向標，才能讓項目更清晰。
我們只有規劃好整個盤子，才能往里面加東西，不會造成自己和團隊的混亂。
需求
有了規劃后，我們需要知道這期做什么，而做什么則是“需求”決定的，即設定“Sprint Backlog（當前沖刺需要解決的事情）”
本期需求迭代的內容需要進行詳盡的分析，根據產品對需求的優先級來確定本期迭代的內容，這里優先級的排列可根據“緊急且重要”、“緊急但不重要”、“不緊急但重要”、“不緊急且不重要”四象限進行分析。
如發現某個需求涉及的內容非常廣大，則需要我們產品經理對這個需求再進一步的細化，從整體拆成局部進行重新排列，以“天”為單位。
最后，我們確定好本期的“Sprint Backlog”后，則開始策劃需求吧！
拆解
假設我們經過了需求評審，在評審中，我們可以提前和開發負責人溝通這些需求對應的開發人員，這樣他們在評審的過程中參與度才是最高的，不過在評審后，按照平常的情況，可能我們直接讓他們進行開發了。
但是先別著急，也請先別讓開發的小伙伴直接進入開發，讓他們首先對自己的開發任務進行“拆解”。
假設一個開發的任務是“篩選列表項”功能，按照一般的開發邏輯，可能從頁面的元素、JS、接口、數據庫索引、前后端聯調等步驟進行開發。
這里面其實對于開發來說是可以詳細拆解的。
所以我們需要讓開發把具體的開發的功能項，按照“小時”進行拆分，確定好每個開發的步驟和工時，我們才能做到實際的跟進，從每個工作項著手跟進具體的完成度，才能做到有的放矢。
這整個拆解的最后的內容，稱之為“SBI（和WBS同理，只是會更加細化開發工作項的內容）”。
有了“SBI”后，我們就可以實時跟進開發進度，當某個事項沒有完成時，可以隨時通過任務項反映出這個功能是否有風險。
因為前一個工作項和后一個工作項，相互之間大概率是耦合的，缺少這一點，可能也會導致整個功能無法上線。
跟進
有了具體的工作項后，則需要進行跟進了，當然這一節雖然說的是跟進，但是更注重“工具的使用”，這個工具是——看板。
看板主要呈現工作項的流轉和完結情況，通過小卡片的形式，實時跟進每個開發工作項對應泳道下的情況，如這個工作項在“開發中”，過了幾天工作項可以流轉到“測試中”，每個工作項都是流動狀態的！
舉個例子：A開發者正在開發“A工作項”，此時對應的狀態是“開發中”，開發完成后 ，則流轉到“已完成”，等到工作項上到測試環境，此時工作項流轉到“測試中”，最后上線，任務流轉到“已完成”。
這個看板可以是實際的黑板，用線條畫出來，也可通過網上的工具，如TAPD的網絡看板進行管理，關鍵在于呈現任務項的流動狀態，和當前節點狀態。
看板完成后，還需要完成任務項卡片的制作，卡片主要描述具體的任務項，完成時間和工時，描述清楚即可。
此時有了看板和卡片，則這個管理項目的工具已經完成了。
但是有了看板還不夠，我們還需要通過“每日站會”來面對面溝通任務情況，每日會議的時間不能超過10分鐘，每個成員時間控制在一分鐘內。
每個團隊成員都需要說三點：
1.我昨天做了什么
2.我今天做了什么
3.當前有什么風險，需要誰進行協助
通過站會，我們才能做到真正跟進開發任務項的完成情況，才知道這個任務項是否有風險；有風險的情況下，是加班解決，還是這個功能只能延期等等的解決方案。
我們通過看板和每日站會這兩個工具，實時跟進了每個沖刺的具體情況，才能做到心中有數，把風險下降到最低。
需要項目管理資料合集的同學可先關注然后私信我哦
更多精彩內容請點擊“了解更多”
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。