敏捷專案管理到底怎麼實施？

我們使用各種敏捷軟體寫feature，流轉、跟蹤任務，言必談敏捷，然而我們是否真的走對了敏捷？

顯而易見，敏捷是絕對的結果導向，去文件化，去流程化，高效溝通和合作是究極奧義。

去文件，敏捷管理者需要維護更為精細的需求池；去流程，口頭溝通成為常態，對團隊的耦合度要求更高。

Product Backlog:

backlog 即需求池。待辦事項列表。

Backlog裡面寫什麼：

1.待開發任務。

2.任務優先順序。

敏捷需要維護一份詳盡的需求列表。這份列表常常要求scrum持有人（一般是產品經理）對所有待開發事項有深入瞭解，並且能夠把待開發事項分解成更為細緻的任務。

story board:

一個sprint內，人/時是一個比較固定的值。在這個時間框架充分安排開發任務，每天進行時間結算，繪製時間燃盡圖。專案成員透過燃盡圖獲知時間進展，若專案燃盡所用時間與預期時間契合，則需求時間預估和安排合理，若不契合則需要在下一個sprint進行調整。

一個誤區：我們用了敏捷管理工具，就敏捷了

隨著敏捷在行業內的不斷融入，各種工具產品層出不窮。我們在敏捷管理工具上建迭代，建需求，研發、測試等著收到需求流轉的郵件之後開始幹活…任務在測試和研發之間流轉，bug提給研發，研發解決bug…..我們宣稱：我們敏捷化了！

我們習慣於敏捷軟體的便利，拉群解決一切，然而卻喪失了敏捷的初衷，scrum的本意。

假設我們沒有任何專案協同軟體，敏捷怎麼實施？

設定一個環境，現在沒有任何協同工具可用，但是所有人都坐在一起。有人站起來說，既然這樣，我們不如敏捷吧！

敏捷路徑裡必須有一個專案持有者，制定規劃並把握專案走向。這位PM汪我看你骨骼驚奇，你就擔負起這個責任吧。

另外還有一個關鍵人物SM。SM全稱scrum master，中文稱敏捷教練。一般說來，SM需要由對技術開發以及當前專案明晰的技術經理擔任。

雖然缺少線上工具，但至少要準備一些簡單材料：一卷雙面膠+白紙或一沓便利貼；筆，一面平坦的牆或一塊黑板。

如果還有電腦可用，excel或者word，甚至寫字板都可以，沒有電腦那就白紙好了，總之你得找個地方寫下你的需求池（backlog）

需求池示例(任務名稱、平臺、詳細描述、優先順序按照P0-PX逐漸遞減)

確定一個sprint週期的自然天。可以用月/旬/周等時間概念作為週期，我們選擇一週（五個工作日）作為一個sprint週期。

按照優先順序，從需求池中拉出你認為應該加入你們一窮二白的第一個sprint裡面去的需求，別太貪心，大概覺得差不多一週左右的開發量就夠了。拉上SM單獨開一次小會。當然不是讓你倆傻站著，你倆要開會。

你們一起通覽需求，SM根據經驗對需求先行分解一遍，比如某需求在開發層面需要分解為ABC三部分，這三部分就形成三個開發任務。

分解完成後，你得到了一個比較詳細的待開發列表。

正式開始一個sprint開始之前，產品、研發、測試需要一同開一次scrum會議，共同討論本次sprint的功能點。

會上討論什麼：

1.需求討論或技術討論；

2.成員預估需求所需開發時間；

3.需求是否match人力時間，需求排入sprint；

4.交流一下感情。

▲每個任務的預估時間在最後由敏捷教練綜合判定

scrum會後你的工作：

1.整理這個sprint內的需求列表；

2.整理每個需求的預期開發時間；

3.撰寫故事版上的小紙條；

4.把小紙條貼到故事版上；

5.製作一個燃盡圖。

一個改良版的小紙條，寫明開發者、任務描述、預估時間和每日燃盡時間

故事版佈局如下：

一個標準的故事版：最開始所有的小紙條都在“待開發”一欄

到此為止，你可以開始run起一個sprint。

以為這就完事了？天真。

接下來你必須來參加每日舉行的專案短會。為了縮減會議時間，我們一般站著開——所以也叫“站會”，早上上班後或晚上下班前，抽出十到十五分鐘時間，完成它。

▲每日站會

站會都有什麼人參加：

1.你（專案持有者）

2.SM

3.其他scrum成員

站會幹什麼：

1.昨天大家分別做了什麼事，遇到了什麼問題，如何解決或尋求解決方案；

2.昨天任務的完成狀態，剩餘多少時間，是否需要進行時間修正（增加時間或減少時間），把已完成的任務流轉到下一環節（把紙條從一個item內撕下，貼到下一個item裡去）；

▲任務進行中，小紙條的示例

3.功能測試後是否有返工；

4.交流一下感情。

站會之後你的工作：

繪製燃盡圖

▲sprint的任務時間隨著sprint的程式逐漸減少

週而復始，完成了一個sprint後，你們開了第二次scrum會。這時議題多了一項:覆盤上一個sprint。

任務未能燃盡；研發返工過多；測試需求淤積…..

針對問題討論解決方案，根據實際情況進行下一個sprint的任務安排。

自此，我們在沒有任何敏捷工具的幫助下，開始了敏捷的旅程。

敏捷了一段時間之後，產品進入正軌，專案拿到撥款，公司拿到投資，你們要擴大團隊規模，新入職的同事想了解下產品和技術細節，你告訴TA：

你要不翻下backlog看看？這個實現你要不看一下程式碼？這個欄位我也不記得有沒有了….你抓包看下？

新同事一臉懵逼，難道我們們沒有文件嗎？你自豪地指出：

“我們是敏捷團隊。”

十幾個人八九條槍的階段之後，產品趨於穩定，團隊逐步擴大。無論從內部協調還是外部溝通上對產品流程的正規化和文件化要求與日俱增。

從短期收益上看，文件對於敏捷開發是非必須品，並且很有可能會拖慢進度。在一個sprint中，口頭溝通顯然效率更高，每個人都有精確到工時的任務，沒人有等待文件更新的時間。強調文件就等於放棄靈活性。

從長期和宏觀上看，文件對於敏捷團隊和敏捷的實施利大於弊——節省在一些常規問題上的溝通成本，同時降低錯誤的發生機率。對於一個將要長期實施敏捷的團隊來講，文件讓後續的工作效率更高。

那麼——誰來維護文件，怎麼維護？

我們挑選其中一個重要的文件：產品文件

產品文件：PM雖然維護backlog、跟SM分解需求、開scrum會、寫小紙條、開站會、畫燃盡圖、還有什麼外部溝通啊……但你要認真把這個文件維護好。

▲對又是你

產品文件包括：

1.需求；

2.加入日期；

3.開發版本；

4.呈現和詳細方案。

長久來看，文件是提高效率的一大利器

文件的時效性和靈活性遠低於口頭溝通，但卻有它實在的好處。

1.空間上，文件傳播範圍更廣。規範化和常規化的內容形成文件可以大大減少溝通成本。尤其在多個系統協作的情況下，跨scrum、跨團隊甚至跨部門的溝通時有發生，文件的重要性和便捷性不言而喻。

2.時間上，文件流傳性更好。團隊不是一成不變的，有人離開有人加入。更新換代中，新人快速瞭解系統，老兵傳承研發理念；在更大的時間跨度上，文件的存在就是對產品歷程的完整追溯，你將不用他人幫助就可以瞭解到產品的大部分面貌甚至全貌。

看起來敏捷方法特別適合產品常規迭代。有一種可能性是，你的產品需要插入一個巨無霸模組，與其說是模組倒不如說它幾乎可以成為一個產品了。你想了想，這麼大個專案怎麼說產品、設計、研發、測試全情投入也得個一兩個月。

還能走敏捷嗎？

注意你的專案時間。有deadline的scrum是帶著鐐銬跳迪斯科，時間節點關乎sprint的大小。

大專案敏捷之前，先得不敏捷幾步。

可能會發生一到多次需求討論會。

團隊必須不厭其煩地理解需求或修正產品經理“天真的幻想”，產品經理使用不斷完善的原型同團隊進行溝通。在最後這次評審邀請專案成員和所有協同團隊，除了敲定的產品功能，技術上需要得到一些初步結論（比如“能不能做”）。

大專案敏捷中：

1.將deadline之前的時間分解為多個sprint。（deadline之前必須留出一定“出血時間”用以解決時間預估不足的任務、返工任務以及bug)

2.將所有需求分解成任務，開一次全域性scrum會。預估時間之後，分散任務到各個sprint中。在時間較緊的情況下，sprint的容量就要相應增加。

▲一個需要加班的sprint

3.進入敏捷流程，常規scrum會、站會，燃盡圖，故事版。未完成任務在scrum會上重新預估時間，滾入新sprint內，以此類推（按時完成sprint內的任務是目標。實在不行我們還有“出血時間”呢）

4.別忘了文件。

雖然被推崇備至，但敏捷並不是完美的開發方法。敏捷的最大的優勢是靈活，而造成敏捷問題的根源也正是靈活。

1.敏捷是一種流程、方法、理念，甚至信仰。

2 用了敏捷管理軟體不一定就是敏捷。敏捷的初衷是團隊成員能夠更加緊密地配合完成工作，線上的的流轉如果削弱了這種配合性，反倒背離了敏捷的本意。實際上只要有白板紙張和筆，你的團隊就能開始敏捷。

4.我們敏捷了，不是不要文件了。在外部交流多、世代跨度長的情況下，文件的必要性顯而易見。長期的面對面溝通最終會導致低效，這也是敏捷缺陷的根源。

5.大專案開發中可以走敏捷，具體問題具體分析，需要根據專案特點制定敏捷計劃。