前言

敏捷開發已經有著超過20年的歷史，國內也熱起來有五年了，理論和方法學的文章網上數不勝數，但真正深入解決問題的卻少之又少，全靠團隊自己琢磨，比如下面我們要討論的如何解決敏捷化開發和需求跟蹤和記錄的問題。這篇文章我們主要討論需求管理是如何在敏捷團隊中落地，也就是如何才能不損害團隊敏捷流程的前提下更好的完成需求的跟蹤和記錄。
PS:本文作者，zhaoenweiex，擁有近5年的敏捷團隊管理實踐經驗,希望能夠將我們的實現敏捷落地遇到的坑坑坎坎分享給大家。

需求管理的實質

在軟體開發領域，每當我們談起需求管理我們到底在談什麼，相信大部分一線的技術人員談起需求管理的想起的第一件事就是多少個通宵編寫需求規格說明書以及上交完之後再也沒看過的不堪回首的經歷。每次我們寫完了之後問這東西到底有什麼用。
需求規格說明書，為了使使用者和軟體開發者雙方對該軟體的初始規定有一個共同的理解， 使之成為整個開發工作的基礎。包含硬體、功能、效能、輸入輸出、介面需求、警示資訊、保密安全、資料與資料庫、文件和法規的要求等等。

當然不少非一線管理者都會認為這個文件還是有用的，甚至不乏有人認為拿著這個文件隨便拉個團隊就能把這個系統再開發出來。
但實際上需求管理與需求規格說明絕不是相等的關係，需求管理的實質是跟蹤並記錄使用者的需求，並將相關的資訊傳遞給開發團隊並保證最終產品與使用者需求一致。一個合格的需求規格說明書應該能完整和動態的反映使用者的真是需求，但由於需求規格說明書這個載體過於沉重，維護代價極高，除非是產品的需求是靜態的否則依賴需求規格說明來完成需求管理的模式是註定要失敗的。

現實要求

大部分公司並不會容許開發人員自由的開發產品，也不贊成產品經理拍拍腦袋就讓開發人員實現，希望一切都有記錄與可追蹤，因此一般都希望將需求記錄下來。這麼做還有一個原因，一個不熟悉產品的人可以通過檢視這些記錄迅速的瞭解產品的脈絡和掌握情況。

傳統模式的需求管理

在傳統軟體開發模式下，需求是一次性獲取並幾乎不再更新的，因此傳統模式下廣大開發者不得不編寫需求規格說明書來假裝記錄固化的需求。但大多數情況下使用者的需求是無法固化的，他們會一次次的提出需求變更，開發團隊也就一次次的改寫需求規格上，最終開發團隊放棄需求規格，使之成為廢料甚至是有害的垃圾。這樣的悲劇在諸多傳統開發模式的團隊中已經上演了無數次。

敏捷模式的需求管理

敏捷團隊的需求管理在哪裡

下面這幅圖描述了Scrum(一種應用最廣的敏捷開發模式)的大體流程。

需求管理實際上嵌入到敏捷開發的每一處，從產品負責人給出產品功能列表（product backlog，PB）到開發人員列出本週期開發計劃(sprint backlog,SB)都是需求管理的重要組成部分。

回顧一下敏捷宣言

上面這幅圖就是著名的敏捷宣言，其中應用到需求管理就應該是這樣，其實不需要硬性的需求說明或規格說明書，需求是用來指導我們生產滿足使用者需要的軟體，是一箇中間產品。

令人失望的折衷

因此絕大多數的敏捷團隊都是繞過沉重的需求規格說明書的編寫，採用輕量級的需求管理方法，比如功能列表，直接開發產品，再專案進入尾聲後，若使用者或公司要求則一次性的集中力量編寫需求規格說明書。
這種模式下需求規格說明書基本描述了實際軟體，能夠為後來人提供參考依據，但實際上由於已經專案尾聲大部分團隊就是裝裝樣子，改改模板交了了事。這時我們的需求管理就沒有結果，也無法未後來人提供任何依據。
下面我們來討論一下如何在敏捷團隊進行更好的需求管理。

需求管理的敏捷優化

最終目標

團隊在開發過程中自然而然的完成了需求的記錄，而且在設計或需求變化的時候能夠即使的反映，在不需要付出任何額外代價的前提下就能生成需求說明文件。
特徵：
1.符合開發過程，自然記錄
2.自動生成文件
3.當產品變化時自動更新

如何落地

要想實現符合敏捷開發思維的需求管理並不是一件容易的事，需要根據團隊的開發模式和習慣結合具體環境和公司規範來確定，下面就介紹一下我們的落地形式。我們是主要藉助於Teambition軟體和物理看板來平衡團隊和公司要求的。
Teambition這款軟體我還是很推崇的，很接地氣關鍵還免費，細節我就不介紹了，有興趣的去官網看看吧。
下面是具體措施：
1.採用Teambition用於團隊的整體需求管理，劃分為待處理，本週期，歷史。

2.每條記錄都採用使用者故事的形式記錄

3.採用物理看板進行本週期詳細需求和任務管理，團隊在看板上完成使用者故事到任務的拆分，每日站會則再物理看板上更新任務進度。

ps：要是有管理者要求檢視團隊細緻的進展有兩個選擇
1）每天把看板進度發給他
2）將週期內的任務也更新到teambition上同時把管理者也拉進去。
4.再最後需要存檔或入庫時，直接從teambition中匯出即可，如下圖。

匯出的文件如下圖所示

這樣我們就有了一份跟最終軟體一致的需求說明，甚至還能反映出需求的變化。

總結

1.敏捷開發是一種軟體開發方法，而敏捷則是一種思維，這種思維促使我們不斷的改進著也推動著周邊環境的變遷，所以當你不想著如何改進時那麼那就不再敏捷了。
2.本文實際上給出了一種藉助免費軟體在開發中自然的記錄需求並能在最終時刻自動生成需求說明的方法。