項管理實踐總結(jié):這可能是最為詳細、

并被驗證過的敏捷項管理實踐總結(jié)了

19年到21年，2年多的時間我和團隊一起搭建了一套BI平臺。我們完成了80

多個迭代，1300多個特性,85%以上的迭代未出現(xiàn)任何延期,2年半時間保持

穩(wěn)定輸出2周一個迭代。團隊在敏捷項目迭代中成為標(biāo)桿。

這其中，一套科學(xué)有效的敏捷項目管理方法發(fā)揮了至關(guān)重要的作用。

項目管理貫穿于產(chǎn)品的全流程管理，因此我把他分為了5個模塊，分別為需求管

理、需求評審、研發(fā)前準(zhǔn)備、研發(fā)中、上線后的回顧。接下來，我將從這5個模

塊分別描述我們是如何進行高效管理的。

一.需求管理

產(chǎn)品的需求總是源源不斷的，有的來自于用戶直接的需求反饋，有的則來自于公

司對產(chǎn)品的宏觀愿景。這些需求我們究竟要如何進行管理呢？

1.需求池管理

1）從目標(biāo)出發(fā)對需求池進行管理

需求池的需求總是超出我們的預(yù)期的，需求不是做的越多越好，需求的目標(biāo)也不

是為了把需求做完。需求的管理指的是在有限的團隊和有限的時間范圍下，找到

優(yōu)先級更高的需求，解決用戶最關(guān)心的問題，滿足用戶的最大價值和公司的最大

價值。

所以確定產(chǎn)品的愿景和目標(biāo)，從愿景、目標(biāo)出發(fā)對需求池進行管理而不是從功能

出發(fā)進行管理。

對于目標(biāo)的確定，首先，我們需要明確產(chǎn)品的愿景，再在產(chǎn)品整體愿景的基礎(chǔ)上

確定產(chǎn)品年度目標(biāo),產(chǎn)品的roadmap,再將目標(biāo)拆解為季度和月度目標(biāo)，進行

細化。一方面通過目標(biāo)確定當(dāng)年的需求方向，并因比能夠標(biāo)記出池需求的優(yōu)先級，

另一方面，拆解到月度范圍的目標(biāo)能讓我們有條不紊穩(wěn)步前進。

但同時，雖然我們以目標(biāo)為導(dǎo)向，大目標(biāo)一般是穩(wěn)定的，但小周期的目標(biāo)實際上

是允許靈活變動的，需要根據(jù)用戶以及當(dāng)前環(huán)境的變化做出靈活的應(yīng)對。

目標(biāo)管理是為了讓團隊和項目有清晰的指弓I和前進的動力，但目標(biāo)管理本身并不

是我們追求的目標(biāo)，所以千萬不要覺得目標(biāo)是不可改動的，就像敏捷宣言中所說：

響應(yīng)變化高于遵循計劃才是正確的處理方式。我們需要根據(jù)客戶的影響度適當(dāng)對

目標(biāo)進行調(diào)整，同時也對需求優(yōu)先級進行調(diào)整。

2）和用戶一起建立溝通和閉環(huán)機制

需求池的管理不僅僅能夠?qū)Ξa(chǎn)品本身的迭代進行管理，同時也能夠和用戶之間建

立關(guān)系橋梁。

一份清晰的需求清單表，應(yīng)該包括需求的描述、提出人、提出時間、產(chǎn)品評估結(jié)

果，當(dāng)前進度，優(yōu)先級等字段，這樣就能夠輔助產(chǎn)品對需求進行管理。

同時，如果需求和業(yè)務(wù)方密切合作，也應(yīng)該通過將需求清單共享給用戶查看，不

斷更新需求池狀態(tài)，讓用戶和項目組同學(xué)知道對于用戶需求的響應(yīng)狀況，建立積

極的用戶關(guān)系，和用戶一起建立起溝通和閉環(huán)機制。

2.迭代需求管理

當(dāng)我們從需求池撈出需求進入迭代完成原型后，并不是馬上進入需求評審階段。

如果需求較為復(fù)雜或產(chǎn)品無法判斷需求的數(shù)量以及方案的可行性，需要產(chǎn)品在需

求評審前拉起主要研發(fā)同學(xué)進行小范圍討論，目的是確定需求方案的可落地性和

迭代需求范圍。

為什么要確定迭代需求范圍呢？因為在敏捷開發(fā)中，迭代的周期是穩(wěn)定的，比如

2周一個迭代，通過穩(wěn)定而較短的開發(fā)周期，一方面保證了需求響應(yīng)的及時性，

也符合MVP快速市場驗證的理念。同時,通過穩(wěn)定的開發(fā)周期，能夠提高班發(fā)

同學(xué)對需求評估的精準(zhǔn)度（迭代周期穩(wěn)定,需求數(shù)量較為穩(wěn)定，通過越多的相似

規(guī)模的需求實際開發(fā)時間作為樣本，對開發(fā)工作量的評估就會越來越接近實際

值），以及積極的項目節(jié)奏氛圍。當(dāng)然，如果不是敏捷開發(fā)，可能就另當(dāng)別論了。

所以，我們進行迭代范圍的確定，也就是在正式需求評審前，將優(yōu)先級較低的需

求砍掉，以免浪費大家的時間。

2.需求的優(yōu)先級

除了講清楚需求的背景，在完成需求評審后，我們還需要對需求優(yōu)先級進行評估。

一方面保證研發(fā)順序按照優(yōu)先級進行，保證高優(yōu)先級需求的交付。另一方，低優(yōu)

先級但可能完不成的需求，作為迭代沖刺目標(biāo)，是可以根據(jù)完成情況移入下迭代，

而不影響迭代的。

這里，我們的方法是，除了高中低的優(yōu)先級排序，我們還會把這些需求標(biāo)上阿拉

伯?dāng)?shù)字，表明各需求整體的優(yōu)先級排序。

3.將確定的需求錄入到相應(yīng)的項目管理系統(tǒng)

需求的線上管理我們之前使用jira,市面上也有一些其他的項目管理工具，比如

騰訊的tapd以及很久前我用過一個叫trello的工具。如果沒有，用excel和便

利貼進行管理也是可以的。

需求的拆分，粒度是比較難的一件事兒。

從用戶的角度來說，大小規(guī)模合適的需求，是一個可以滿足某一需要達成某一業(yè)

務(wù)目標(biāo)的故事，比如刪除一條彳壬務(wù)，就是能夠獨立作為一個需求單的需求。而從

項目組研發(fā)的角度上來說，一個大小規(guī)模適當(dāng)?shù)男枨笫强梢栽趲滋鞎r間內(nèi)完成開

發(fā)和測試的故事，因此，同樣刪除也是滿足的。

通過拆分這樣的小模塊，對于開發(fā)、測試和最終的發(fā)布上線都是大有裨益的，因

為將需求劃分為這樣的小故事，團隊就可以并行開發(fā)各個模塊，而無需彼此等待。

也就不會出現(xiàn)需求開發(fā)堆積到后期的風(fēng)險。因此我們建議將需求拆分為可以在兩

三天時間內(nèi)完成開發(fā)和測試的模塊。

拆分完需求后，就需要把需求錄入線上系統(tǒng)。在需求錄入時，需求的標(biāo)題需要簡

單直接，我們一般會采用的描述如下：

?作為：who

?我希望：what

?以便：why

除此還需要標(biāo)注需求的優(yōu)先級，需求負責(zé)人、故事點、開始時間、結(jié)束時間等信

息。完整和簡潔的信息有助于后期進行故事墻管理。

三、研發(fā)前準(zhǔn)備

如果需求評審結(jié)束就立即進入研發(fā)，極大可能會出現(xiàn)事倍功半和混亂的局面，所

以，研發(fā)前的準(zhǔn)備工作是不可忽略的。那研發(fā)前有哪些準(zhǔn)備工作呢？

1.技術(shù)評審會

技術(shù)評審主要由研發(fā)側(cè)發(fā)起和負責(zé)，目的是前后端同學(xué)對各需求所需要的技術(shù)能

力以及風(fēng)險進行對齊，尤其是當(dāng)功能復(fù)雜，對應(yīng)技術(shù)復(fù)雜的時候，充分的技術(shù)評

審能夠規(guī)避迭代研發(fā)過程中可能出現(xiàn)的技術(shù)風(fēng)險，確保迭代進度和質(zhì)量。

一般這時候，研發(fā)負責(zé)人需要和大家一起確定每一個需求的前后端研發(fā)同學(xué)。前

后端對各自的需求進行闡述，后端主要是接口文檔的定義（格式和地址待定）。

當(dāng)項目需要引入新組件、新技術(shù)時還需要進行技術(shù)預(yù)演，去熟悉新的技術(shù)，評估

怎么整合到系統(tǒng)、有沒有風(fēng)險等。

2.拆分研發(fā)任務(wù)和確定需求開發(fā)節(jié)奏

完成技術(shù)評審會之后，研發(fā)同學(xué)對于每一個需求的完成需要做哪些工作以及怎么

做也就清楚了。這個時候就可以開始進行研發(fā)任務(wù)的拆分了。

研發(fā)任務(wù)的拆分是為了對于每一個需求的跟進提供切實可依的依據(jù)，并在后期的

項目故事板進行展示，輔助項目能夠有序穩(wěn)步前進，而不是讓項目管理進入無序

的黑盒子。因此，在任務(wù)拆分的時候需要遵循幾個點：

?研發(fā)任務(wù)需要分別拆分前端、后端研發(fā)任務(wù)，分別確定負責(zé)人進行跟進。

?研發(fā)任務(wù)的粒度盡量小于3天的開發(fā)周期，否則很難跟進和評估風(fēng)險。

?研發(fā)任務(wù)需要標(biāo)記。wner、研發(fā)開始時間、研發(fā)結(jié)束時間、故事點信息。

基于以上，我們又能對需求進行一些信息的補充，包括：

?根據(jù)單個需求下所屬的全部研發(fā)彳壬務(wù)的開始時間和結(jié)束時間確定需求的提測時間，

即需求的研發(fā)開始時間和結(jié)束時間。

?確定需求的研發(fā)owner，研發(fā)owner對需求的開發(fā)周期負責(zé)。包括確保需求按時進

入聯(lián)調(diào)，按時完成聯(lián)調(diào)，按時提測。

3.需求反講和計劃會

1）需求反講

我們經(jīng)常會聽到研發(fā)和產(chǎn)品經(jīng)理撕的事情，有些時候我們也會聽到因為前期需求

溝通不一致，導(dǎo)致研發(fā)結(jié)果和產(chǎn)品需求出現(xiàn)偏差的事情。為了規(guī)避這樣的問題，

我們加入了需求反講環(huán)節(jié)。

所謂的需求反講就是讓研發(fā)同學(xué)來講需求，產(chǎn)品同學(xué)聽需求。在這個過程中，需

求的前后端研發(fā)負責(zé)人會先講一講整體的功能流程，同時會闡述自己需要準(zhǔn)備什

么。如果信息不對稱能夠很快發(fā)現(xiàn)。當(dāng)然，如果需求很簡單，也可以忽略這一環(huán)

節(jié)。

2）計劃會

計劃會的目的主要是和大家一起確定迭代節(jié)奏。包括每一項需求的開始時間和開

發(fā)結(jié)束時間（包括聯(lián)調(diào)，也就是開發(fā)結(jié)束就應(yīng)該進入測試），并由此確定全面提

測時間，并由測試同學(xué)確定測試完成封版的時間以及發(fā)布的時間。

如果前面的任務(wù)拆分都做的很好，每一項任務(wù)前后端都評估了時間，同時大家對

需求理解沒有問題，在這樣的前提下，計劃會具實是很快的。

如果考慮會議太多，其實可以將計劃會和需求反講放到一起進行。

計劃會結(jié)束后，整體迭代中的需求節(jié)奏，迭代發(fā)布節(jié)奏基本也就確定了。這時候

作為項目經(jīng)理，可以整理郵件，將迭代目標(biāo)，計劃發(fā)送知會全員。

4.完成故事墻

故事墻顧名思義是一面墻或者白板，線上或線下都可以。而墻上則是迭代中的用

戶故事以及研發(fā)任務(wù)，項目管理中通過把這些故事和任務(wù)貼到故事墻上并根據(jù)進

度挪動，從而實現(xiàn)項目中的進度管理。

1）故事墻的結(jié)構(gòu)

規(guī)劃中需求

實現(xiàn)中聯(lián)調(diào)中試中待發(fā)布

用戶故事研發(fā)任務(wù)

正常狀態(tài)

迭代目標(biāo)

風(fēng)險項

頂部是項目進度的敘事主線，通過一個個的活動階段將故事和任務(wù)組織起來。并

通過對正常狀態(tài)和風(fēng)險項的細分，有效的反映出故事和人物的變化性，讓項目成

員對項目進度能夠有效把控。

迭代目標(biāo)的展示是為了讓項目組同學(xué)目標(biāo)一致前進，也能明白大家做的事情的意

義和價值。

我們把所有規(guī)劃到迭代中的需求以及對應(yīng)的研發(fā)任務(wù)放到規(guī)劃中，分兩列放置。

當(dāng)需求下的任務(wù)啟動開發(fā)后，就可以將任務(wù)拖動到實現(xiàn)中，當(dāng)任務(wù)狀態(tài)進入聯(lián)調(diào)

中時，我們就需要把需求和任務(wù)一起拖動到聯(lián)調(diào)中狀態(tài)。為了方便查看，進入聯(lián)

調(diào)后會建議大家把需求和對應(yīng)任務(wù)放到一起開始進行拖動，如果你的故事墻是便

簽紙制作，這個時候你可以把需求和任務(wù)疊到一起進行拖動。

接著需求進入到測試、待發(fā)布的流程，并最終隨版本全部發(fā)布上線。

在實際操作中我們發(fā)現(xiàn)在進程中部分需求可能出現(xiàn)風(fēng)險延遲，因此我們在縱向上

又將需求劃分為正常進度和風(fēng)險項，一旦需求或任務(wù)出現(xiàn)風(fēng)險就需要將需求和任

務(wù)拖入到風(fēng)險頂一行，解除后可回到正常一行。

當(dāng)然，根據(jù)需要你也可以增加更多的狀態(tài)欄來輔助管理，比如我們之前的故事墻

是這樣的。敏捷教練甚至?xí)陧敳看蛴〕龃蠹业念^像，來讓大家有更明確的團隊

歸屬感。

?

0

2）故事卡片

故事墻由一個個的需求和任務(wù)卡片組成，對于故事卡片來講，需要包括如下內(nèi)容：

故事標(biāo)題、故事描述、優(yōu)先級、負責(zé)人、開始時間、結(jié)束時間、狀態(tài)

而對于任務(wù)來說則需要包括：

任務(wù)標(biāo)題，依賴的需求、負責(zé)人、開始時間、結(jié)束時間、狀態(tài)、故事點信息。

通過這些信息，我們能夠清晰的看到每一天應(yīng)該做哪些需求，哪些需求應(yīng)該進入

測試，哪些需求出現(xiàn)延期，需求的負責(zé)人是誰。從而對需求的完成進度，項目的

節(jié)奏能夠有較強的把控力。

!1!■研發(fā)階段的項目推進

1.站立會

研發(fā)正式開始后，為了正常推進項目進度，我們會進行每日站立會。

站立會階段主要需要明確每一個成員的進度和計劃，以及同步風(fēng)險。即項目成員

昨天完成了什么，今日要做什么，當(dāng)前是否有風(fēng)險項或項目阻塞,每人不會超過

1分鐘。

站立會上若遇到需要解決的問題，我們會督促大家會議結(jié)束后立馬小范圍拉上相

關(guān)人員討論解決，而不會在站立會上直接解決，因為如果在站立會上解決，會讓

整個站立會的時間拉的特別長，耽誤其他同學(xué)的時間。

成員在同步的同時，需要同步拖動卡片的位置改變卡片狀態(tài)。這樣，站立會結(jié)束,

目前各個需求以及任務(wù)對應(yīng)的開發(fā)狀態(tài)和進度也就一目了然了。

2.需求的驗收

隨著需求不斷被交付，產(chǎn)品逐漸進入測試階段。在這個過程中，除了研發(fā)要做好

開發(fā)和自測，測試同學(xué)要做好功能測試，也需要產(chǎn)品經(jīng)理在各個環(huán)節(jié)深度參與，

把控質(zhì)量。

為了從源頭上阻斷功能開發(fā)和產(chǎn)品理解不一致，我們一般會在研發(fā)完成聯(lián)調(diào)后先

讓產(chǎn)品經(jīng)理先做功能測試，這個過程中主要看功能主流程是否跑通，是否和需求

開發(fā)一致。產(chǎn)品測試通過，則可轉(zhuǎn)測試狀態(tài)，并知會測試同學(xué)開始功能測試。

為了保證各流轉(zhuǎn)環(huán)節(jié)的無縫銜接。我們采用的方式是群知會，比如研發(fā)完成聯(lián)調(diào)

后群里@產(chǎn)品進行開發(fā)環(huán)境測試，產(chǎn)品測試通過后群里立馬@測試同學(xué)可開始測

試,以保證流程的順暢。雖然我們通過jira或者郎件都可以實現(xiàn)轉(zhuǎn)單以及通知，

但從溝通的實效性以及流程的完整性上，我們更建議通過群通知方式進行。

如果因為開發(fā)群消息太多會淹沒消息，甚至可以單獨開一個測試群，專門周知測

試流程周轉(zhuǎn)。

測試同學(xué)在收到測試單以后開始進行測試，并將發(fā)現(xiàn)的問題和對應(yīng)研發(fā)同學(xué)溝通

后提單bug。修改并測試完成后將需求改為待發(fā)布狀態(tài)。

進入全面提測階段后，還需要邀請UED同學(xué)進行交互、視覺還原度測試，并及

時將發(fā)現(xiàn)的問題反饋給項目組。

3.迭代發(fā)布

迭代發(fā)布代表著產(chǎn)品研發(fā)完成終于可以上線了，但一旦功能存在問題，上線就會

給用戶造成較為糟糕的體驗和印象，因此迭代正式發(fā)布前的驗收也至關(guān)重要。

一般情況下，測試同學(xué)按照封版時間完成測試后發(fā)出測試驗收郵件，產(chǎn)品在收到

郵件后開始進行全局產(chǎn)品驗收。驗收無誤則可知會大家產(chǎn)品驗收通過，進入發(fā)布

狀態(tài)。

此時，研發(fā)同學(xué)需要召集運維同學(xué)進行發(fā)布評審，各研發(fā)同學(xué)報備準(zhǔn)備無誤，各

項準(zhǔn)備就緒，運維同學(xué)確定發(fā)布的具體時間點，即可發(fā)布。

五.上線后的□顧會

在項目迭代中，并不是產(chǎn)品上線后就大功告成可以撒手不管了，產(chǎn)品上線后我們

需要去進行回顧和持續(xù)跟進，回顧的目的不是為了糾錯，還是為了從過程中不斷

的學(xué)習(xí)和進步。

1.關(guān)注上線后產(chǎn)品的質(zhì)量

首先，需要關(guān)注產(chǎn)品的質(zhì)量和用戶反饋，第一時間去觀察用戶的行為和反饋，并

將用戶反饋納入需求池進行管理。

同時，也需要通過指標(biāo)客觀進行觀測，看看用戶對新功能的使用情況。

2.回顧和關(guān)注工作計劃是否合理。

工作計劃的合理有序是保證項目推進有序的必要條件，如果不合理是哪里不合

理，就需要考慮如何在下一個迭代中進行調(diào)整。針對這一塊我們可以看的包括需

求燃盡圖、迭代需求完成率、需求變更率等報表。

需求燃盡圖反映了在迭代下需求完成的趨勢。正常情況下，需求完成數(shù)是勻速上

升的，如果出現(xiàn)前期上升緩慢，則表明需求極有可能堆積在后期交付，故事和任

務(wù)可能都拆的過大，項目存在極大風(fēng)險。若前期上升速度過快，則可能是需求評

估不準(zhǔn)，導(dǎo)致需求提前完成，或前期堆積的都是小需求。

需求燃燒圖

0000000000000

04-0804-1104-1204-1304-1404-1504-1804-19(M-2004-2104-2204-25(M-26

.未抬來.已結(jié)朱??準(zhǔn)鉉

迭代完成率指的是，迭代實際完成的需求數(shù)或故事點數(shù)占規(guī)劃需求數(shù)或故事點數(shù)

的比率。度量研發(fā)團隊在核定的時間內(nèi)穩(wěn)定交付需求的能力。

需求變更率則主要指由于前期考慮不周導(dǎo)致需求的大變更，或研發(fā)中臨時撤換需

求。在客戶需求變更或特殊情況下，我們允許一定情況的需求變更，擁抱變化,

但同時，頻繁的需求變更也會對研發(fā)團隊帶來交付和資源上的壓力，因此并不建

議這樣的操作。

同時，由于前期需求考慮不充分導(dǎo)致的頻繁需求變更，還會讓研發(fā)團隊對產(chǎn)品產(chǎn)

生不信任感，降低項目的凝聚力。

3.關(guān)注過程是否有序

比如開發(fā)的節(jié)奏是否根據(jù)大家估算的開始時間、結(jié)束時間進行推進，是否及時提

測，整體需求的延遲交付率是怎樣的等等。

產(chǎn)品從需求到上線，整體是多方協(xié)作共同的結(jié)果，如果一方在過程中無序，就會

形成多米諾連鎖反應(yīng)，造成項目的混亂。經(jīng)?？吹接行╉椖康默F(xiàn)象是，研發(fā)團隊

延遲提測，壓縮測試時間，導(dǎo)致測試不充分情況下上線，測試不充分又導(dǎo)致產(chǎn)品

問題沒有被發(fā)現(xiàn)而影響用戶體驗，最終，用戶體驗受損，產(chǎn)品品牌受損，造成不

可挽回的損失。

六.誰對項目管理負責(zé)

項目管理是一件繁瑣而專業(yè)的工作，一般稍微大型的公司和團隊都會配有專業(yè)的

項目經(jīng)理，如果是敏捷開發(fā)還會配置敏捷教練。但無論如何，項目管理一定不是

某一個人的事情，而是需要團隊一起努力的結(jié)果，

一方面，產(chǎn)品經(jīng)理和項目經(jīng)理需要進行配合管理，同時，研發(fā)端也需要有一個