我相信大部分都知道“敏捷管理”，且都會(huì)喊一下它的口號(hào)“敏捷迭代，小步快跑”，那我們除了喊口號(hào)之外，還做了什么呢？或者說，對(duì)于我們的項(xiàng)目管理，又帶來了什么不同的點(diǎn)呢？

試想一個(gè)場(chǎng)景，公司目前要引入“敏捷管理“，開始用兩周一個(gè)迭代的周期進(jìn)行。

接著我們常規(guī)情況下可能會(huì)這樣做，簡(jiǎn)單排個(gè)需求優(yōu)先級(jí)，然后對(duì)于緊急又重要的出原型和需求，寫需求文檔進(jìn)行評(píng)審，最后開發(fā)抓緊去做，偶爾追問一下開發(fā)的進(jìn)度，接著開發(fā)完了進(jìn)行測(cè)試，然后吭哧吭哧到了第二周的周五晚上上線。

請(qǐng)問這是敏捷嗎？

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

到最后你發(fā)現(xiàn)，兩周一個(gè)版本，所有成員瘋狂加班，簡(jiǎn)直要人命，一上線發(fā)現(xiàn)又全都是問題，還能怎么辦？回滾吧…

那真正的敏捷型項(xiàng)目管理，到底是怎么做的，它有什么方法論嗎？

我會(huì)嘗試從“規(guī)劃”“需求”“拆解”“跟進(jìn)”“回顧”五個(gè)方面講解，我們要如何做敏捷管理。

敏捷管理的一些概念

項(xiàng)目管理有很多類型，如預(yù)測(cè)性、敏捷型等等，不能說哪個(gè)更好。具體根據(jù)自身的項(xiàng)目出發(fā)，找到最合適自己的那條路，才是最好的。

所以我們得理清楚，敏捷并不是神，它只是眾多項(xiàng)目管理的一種。

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

• 個(gè)體和互動(dòng)高于流程和工具
• 工作的軟件高于詳細(xì)的文檔
• 客戶合作高于合同談判
• 響應(yīng)變化高于遵循計(jì)劃

這4條宣言一定程度上涵蓋了我接下來要講的內(nèi)容，當(dāng)然這些宣言記不記住都沒啥關(guān)系，最重要的是從實(shí)踐找到方法，而不是在方法里面找到方法。

所以我們開始從傳統(tǒng)的瀑布型開發(fā)轉(zhuǎn)成敏捷型開發(fā)，首先要做的是——規(guī)劃。

規(guī)劃

項(xiàng)目假定采用2周1迭代的小步快跑形式，那么最核心最重要的其實(shí)是規(guī)劃。

規(guī)劃我認(rèn)為主要有兩個(gè)最重要的點(diǎn)，一則團(tuán)隊(duì)，二則關(guān)鍵時(shí)間點(diǎn)。

在團(tuán)隊(duì)的規(guī)劃中，每個(gè)團(tuán)隊(duì)的人數(shù)需控制在十個(gè)人以內(nèi)，因?yàn)槿藬?shù)一多，交流的信息會(huì)越復(fù)雜，這不適合敏捷的“個(gè)體和互動(dòng)”的宣言。

如果團(tuán)隊(duì)超過10人，則需要進(jìn)行團(tuán)隊(duì)拆分，每個(gè)團(tuán)隊(duì)需要設(shè)定一個(gè)“Scrum Master（團(tuán)隊(duì)負(fù)責(zé)人）”。

有了團(tuán)隊(duì)后，并且對(duì)團(tuán)隊(duì)進(jìn)行具體的分工后，則需要開始規(guī)劃關(guān)鍵時(shí)間點(diǎn)。

在具體的規(guī)劃中，我們需要在兩周的時(shí)間規(guī)劃出關(guān)鍵的時(shí)間節(jié)點(diǎn)；我們可以采用倒推的形式去思考到底有什么關(guān)鍵節(jié)點(diǎn)。

如上線前，我們需要具體的“上線時(shí)間”，再往前我們需要具體的“測(cè)試時(shí)間”，測(cè)試之前我們需要知道具體“開發(fā)完結(jié)時(shí)間”，再繼續(xù)往前我們需要知道具體“評(píng)審時(shí)間”。

這里的關(guān)鍵點(diǎn)在于“具體”，直接通過甘特圖的形式標(biāo)識(shí)出具體的關(guān)鍵時(shí)間，和每個(gè)職位在各自環(huán)節(jié)下的處理時(shí)間。

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

接著我們每次版本都根據(jù)規(guī)劃的時(shí)間節(jié)點(diǎn)，按部就班的進(jìn)行，有了指向標(biāo)，才能讓項(xiàng)目更清晰。

我們只有規(guī)劃好整個(gè)盤子，才能往里面加?xùn)|西，不會(huì)造成自己和團(tuán)隊(duì)的混亂。

需求

有了規(guī)劃后，我們需要知道這期做什么，而做什么則是“需求”決定的，即設(shè)定“Sprint Backlog（當(dāng)前沖刺需要解決的事情）”

本期需求迭代的內(nèi)容需要進(jìn)行詳盡的分析，根據(jù)產(chǎn)品對(duì)需求的優(yōu)先級(jí)來確定本期迭代的內(nèi)容，這里優(yōu)先級(jí)的排列可根據(jù)“緊急且重要”、“緊急但不重要”、“不緊急但重要”、“不緊急且不重要”四象限進(jìn)行分析。

如發(fā)現(xiàn)某個(gè)需求涉及的內(nèi)容非常廣大，則需要我們產(chǎn)品經(jīng)理對(duì)這個(gè)需求再進(jìn)一步的細(xì)化，從整體拆成局部進(jìn)行重新排列，以“天”為單位。

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

拆解

假設(shè)我們經(jīng)過了需求評(píng)審，在評(píng)審中，我們可以提前和開發(fā)負(fù)責(zé)人溝通這些需求對(duì)應(yīng)的開發(fā)人員，這樣他們?cè)谠u(píng)審的過程中參與度才是最高的，不過在評(píng)審后，按照平常的情況，可能我們直接讓他們進(jìn)行開發(fā)了。

但是先別著急，也請(qǐng)先別讓開發(fā)的小伙伴直接進(jìn)入開發(fā)，讓他們首先對(duì)自己的開發(fā)任務(wù)進(jìn)行“拆解”。

假設(shè)一個(gè)開發(fā)的任務(wù)是“篩選列表項(xiàng)”功能，按照一般的開發(fā)邏輯，可能從頁(yè)面的元素、JS、接口、數(shù)據(jù)庫(kù)索引、前后端聯(lián)調(diào)等步驟進(jìn)行開發(fā)。

這里面其實(shí)對(duì)于開發(fā)來說是可以詳細(xì)拆解的。

所以我們需要讓開發(fā)把具體的開發(fā)的功能項(xiàng)，按照“小時(shí)”進(jìn)行拆分，確定好每個(gè)開發(fā)的步驟和工時(shí)，我們才能做到實(shí)際的跟進(jìn)，從每個(gè)工作項(xiàng)著手跟進(jìn)具體的完成度，才能做到有的放矢。

這整個(gè)拆解的最后的內(nèi)容，稱之為“SBI（和WBS同理，只是會(huì)更加細(xì)化開發(fā)工作項(xiàng)的內(nèi)容）”。

有了“SBI”后，我們就可以實(shí)時(shí)跟進(jìn)開發(fā)進(jìn)度，當(dāng)某個(gè)事項(xiàng)沒有完成時(shí)，可以隨時(shí)通過任務(wù)項(xiàng)反映出這個(gè)功能是否有風(fēng)險(xiǎn)。

因?yàn)榍耙粋€(gè)工作項(xiàng)和后一個(gè)工作項(xiàng)，相互之間大概率是耦合的，缺少這一點(diǎn)，可能也會(huì)導(dǎo)致整個(gè)功能無法上線。

跟進(jìn)

有了具體的工作項(xiàng)后，則需要進(jìn)行跟進(jìn)了，當(dāng)然這一節(jié)雖然說的是跟進(jìn)，但是更注重“工具的使用”，這個(gè)工具是——看板。

看板主要呈現(xiàn)工作項(xiàng)的流轉(zhuǎn)和完結(jié)情況，通過小卡片的形式，實(shí)時(shí)跟進(jìn)每個(gè)開發(fā)工作項(xiàng)對(duì)應(yīng)泳道下的情況，如這個(gè)工作項(xiàng)在“開發(fā)中”，過了幾天工作項(xiàng)可以流轉(zhuǎn)到“測(cè)試中”，每個(gè)工作項(xiàng)都是流動(dòng)狀態(tài)的！

舉個(gè)例子：A開發(fā)者正在開發(fā)“A工作項(xiàng)”，此時(shí)對(duì)應(yīng)的狀態(tài)是“開發(fā)中”，開發(fā)完成后 ，則流轉(zhuǎn)到“已完成”，等到工作項(xiàng)上到測(cè)試環(huán)境，此時(shí)工作項(xiàng)流轉(zhuǎn)到“測(cè)試中”，最后上線，任務(wù)流轉(zhuǎn)到“已完成”。

這個(gè)看板可以是實(shí)際的黑板，用線條畫出來，也可通過網(wǎng)上的工具，如TAPD的網(wǎng)絡(luò)看板進(jìn)行管理，關(guān)鍵在于呈現(xiàn)任務(wù)項(xiàng)的流動(dòng)狀態(tài)，和當(dāng)前節(jié)點(diǎn)狀態(tài)。

看板完成后，還需要完成任務(wù)項(xiàng)卡片的制作，卡片主要描述具體的任務(wù)項(xiàng)，完成時(shí)間和工時(shí)，描述清楚即可。

此時(shí)有了看板和卡片，則這個(gè)管理項(xiàng)目的工具已經(jīng)完成了。

但是有了看板還不夠，我們還需要通過“每日站會(huì)”來面對(duì)面溝通任務(wù)情況，每日會(huì)議的時(shí)間不能超過10分鐘，每個(gè)成員時(shí)間控制在一分鐘內(nèi)。

每個(gè)團(tuán)隊(duì)成員都需要說三點(diǎn)：

1.我昨天做了什么

2.我今天做了什么

3.當(dāng)前有什么風(fēng)險(xiǎn)，需要誰(shuí)進(jìn)行協(xié)助

通過站會(huì)，我們才能做到真正跟進(jìn)開發(fā)任務(wù)項(xiàng)的完成情況，才知道這個(gè)任務(wù)項(xiàng)是否有風(fēng)險(xiǎn)；有風(fēng)險(xiǎn)的情況下，是加班解決，還是這個(gè)功能只能延期等等的解決方案。

我們通過看板和每日站會(huì)這兩個(gè)工具，實(shí)時(shí)跟進(jìn)了每個(gè)沖刺的具體情況，才能做到心中有數(shù)，把風(fēng)險(xiǎn)下降到最低。

需要項(xiàng)目管理資料合集的同學(xué)可先關(guān)注然后私信我哦

更多精彩內(nèi)容請(qǐng)點(diǎn)擊“了解更多”