敏捷 需求管理工具

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

然而詳細的需求說明書有如下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條目進行可視化管理，讓整個團隊很是直觀的瞭解需求的優先級和規劃安排。

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

在Leangoo看板上，咱們能夠建立多個列表，而後在每一個列表上添加故事卡片。

由於咱們須要將近期高優先級的需求放到Sprint中，因此在看板上能夠建立這幾個列表：待整理原始需求，之後的迭代，下個迭代待梳理故事，下個迭代就緒故事，當前迭代，已交付。
咱們能夠根據需求的優先級把需求分別放到這幾個列中。當前迭代的優先級最高。

創建好了列以後，咱們就能夠往列表裏面增長卡片了，每一個故事一張卡。

咱們能夠爲每一張卡片添加工做量，以及故事的驗收測試要點。驗收測試要點以檢查項的方式體現。

除了工做量，檢查項，咱們能夠對這個故事進行一些討論，也就是評論，也能夠@某位成員！

咱們也能夠爲卡片設置標籤

標籤一般是用來給卡片分類，也能夠用卡片標註優先級！

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

卡片ID

咱們也能夠爲每一張卡片設置ID,便於卡片定位溝通和跟蹤，在菜單欄開啓就能夠。

卡片多選

當咱們開啓卡片多選的時候  能夠批量移動卡片，爲卡片批量添加標籤，爲卡片批量添加成員等等 ，這也是我最愛的功能之一

燃盡圖

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

Leangoo會根據故事卡的變化自動生成發佈燃盡圖，點擊菜單-看板統計，就能夠查看！不只有燃盡圖 還有任務週期，任務分佈等

以下圖所示：

經過上述的方式，咱們就能夠很好的管理咱們的產品Backlog了。

最後還有一點提醒，敏捷強調透明性，因此，可視化管理產品backlog很重要，若是條件容許，咱們能夠考慮經過大的顯示屏幕將產品Backlog進行可視化，有觸屏大電視會更好。