產品Backlog 管理

傳統的瀑布工作模式使用詳細的需求說明書來表達需求，需求人員負責做需求調研，根據調研情況編制詳細的需求說明書，進行需求評審，評審之後簽字確認交給研發團隊設計開發。在這樣的環境下，需求文件是資訊傳遞的主體，也是一份契約。

然而詳細的需求說明書有以下5大弊端：

• 單向的資訊傳遞，容易出現理解偏差。
• 文件很正式，我們會誤以為它一定是對的，不去質疑它，讓我們停止作出判斷。
• 有了詳細的文件，我們不會反覆討論它，相互確認。
• 書面文件不利於團隊共享責任，它扮演了證據的角色。Scrum強調團隊共享責任，不論是需求人員、開發人員和還是測試員，大家的共同目標是通過討論、協作，正確理解需求之後把這些需求變成客戶真正需要的功能，而不是單向的任務傳遞。
• 編制詳細的、表達準確需求文件需要花費大量的時間，如果需求變化頻繁，維護成本更高。

 敏捷使用產品Backlog來管理需求，產品Backlog是一個需求的清單，按照需求的商業價值排序， 高優先順序的需求在Backlog的最上層。產品Backlog是一個漸進明細的清單，它有4個主要特點，稱之為DEEP：

• Detailed 合適的詳細程度，高優先順序需求更加明細，低優先順序的需求粒度更大
• Emergent 湧現式的，需求是慢慢湧現出來的，漸進明細的
• Estimated 經過估算的
• Prioritized/ Ordered 根據商業價值排好順序的

在產品Backlog中，需求的主要表現形式是使用者故事。使用者故事是從使用者的角度對需求的簡短描述。使用者故事是將團隊的焦點從描述、編寫功能需求轉移到討論需求的最佳方式。

使用者故事是從使用者的角度來描述使用者渴望得到的功能。一個好的使用者故事包括三個要素：

• 角色：誰要使用這個功能。
• 活動：需要完成什麼樣的功能。
• 商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。

使用者故事通常按照如下的格式來表達：

英文：
As a <Role>, I want to <Activity>, so that <Business Value>.

中文：
作為一個<角色>, 我想要<活動>, 以便於<商業價值>。
比如：作為一個網站的普通會員，我期望在我下訂單後，未發貨之前可以取消訂單，這樣對我來說更靈活。

 

我們目前是用的國內的一款敏捷工具Leangoo在做需求管理！

Leangoo是一個非常簡潔的看板協作工具，我們可以通過Leangoo建立產品Backlog看板來管理敏捷需求。通過leangoo看板對產品backlog條目進行視覺化管理，讓整個團隊非常直觀的瞭解需求的優先順序和規劃安排。

在Leangoo看板上，我們可以建立多個列表，然後在每個列表上新增故事卡片。

因為我們需要將近期高優先順序的需求放到Sprint中，所以在看板上可以建立這幾個列表：待整理原始需求，以後的迭代，下個迭代待梳理故事，下個迭代就緒故事，當前迭代，已交付。
我們可以根據需求的優先順序把需求分別放到這幾個列中。當前迭代的優先順序最高。

下圖就是一個產品Backlog看板的示例：

 

建立好了列之後，我們就可以往列表裡面增加卡片了，每個故事一張卡。

我們可以為每一張卡片新增工作量，以及故事的驗收測試要點。驗收測試要點以檢查項的方式體現。

除了工作量，檢查項，我們可以對這個故事進行一些討論，也就是評論，也可以@某位成員！

我們也可以為卡片設定標籤

標籤可以自己命名。標籤通常是用來給卡片分類，也可以用卡片標註優先順序！

（每張卡片的優先順序可以位置來決定的，每個list裡面的卡片根據位置對卡片進行強制排序，高優先順序的卡片放到最上面，低優先順序的需求卡片在下面）

卡片ID

我們也可以為每一張卡片設定ID,便於卡片定位溝通和跟蹤，在選單欄開啟就可以。

卡片多選

當我們開啟卡片多選的時候  可以批量移動卡片，為卡片批量新增標籤，為卡片批量新增成員等等 ，這也是我最愛的功能之一

燃盡圖

當一個迭代結束時，我們要對完成的故事進行評審會議，評審通過的故事可以挪到已交付的列表中。

Leangoo會根據故事卡的變化自動生成釋出燃盡圖，點選選單-看板統計，就可以檢視！不僅有燃盡圖 還有任務週期，任務分佈等

如下圖所示：

通過上述的方式，我們就可以很好的管理我們的產品Backlog了。

最後還有一點提醒，敏捷強調透明性，所以，視覺化管理產品backlog很重要，如果條件允許，我們可以考慮通過大的顯示螢幕將產品Backlog進行視覺化，有觸屏大電視會更好。

Leangoo官網：www.leangoo.com