敏捷方法指導團隊將產品需求置於Product Backlog中管理，並按照優先順序對每個產品需求進行必要的排列。在計劃會(Planning Meeting)之前，由Product Owner從Product Backlog中挑選迭代週期準備開發的意向表（Willing List）進行總體介紹，然後分配到Sprint研發過程中。以Scrum為代表的純敏捷方法，認為首先不需要對需求做分析，因為需求一直在變。所以提出了Story的概念，認為需求就該是對需求的一種類似講故事的方式來表達的，這樣便於讓原始客戶比較清晰的對需求進行表達，同樣開發和測試也會逐漸以客戶的需求思維來思考自己的工作。使得大家都能在需求的層面上，進行大腦思維。

但是敏捷方法的普遍使用中，又發現了純敏捷方法的侷限性

• 無法支援需求驅動下完整的可追溯性。
• 整個團隊完全致力於專案的開發是基本前提。一旦開發團隊的方向出現變化，會導致專案的崩潰；因為需求總在變化。

       實踐調查發現更多大型專案的成功，依賴於通過需求工作流、需求分析、和需求可追溯性的管理，在需求層面上進行整體的專案規劃和控制。敏捷過程中，僅用Product Backlog，不足以滿足需求的管理。通常，一個專案的研發過程，通過3個空間來進行表達：需求空間、研發空間和QA測試空間。3個空間相互間應當是完全整合的，使得整個團隊的不同職能工作能夠相互協作。今天我們首先探討需求空間！

需求空間用來做什麼？

       SpecDD模型中，使用者需求，在需求空間中被錄入登記。敏捷提倡客戶價值導向，應當從客戶價值角度描述，就是描述客戶如何使用，而不是描述技術層面如何實現。我們喜歡Story的使用者需求表達方式，但這不代表使用者需求的管理就是雜亂、隨意和無序的。產品負責人需要藉助需求工作流、需求分析、和需求可追溯性的管理，進行產品需求的提煉、條目化、優先順序排序等。通過需求空間，對使用者需求形成細化和量化的SPEC。

       需求和SPEC之間常常存在多對多的關係，即一個需求可能拆分出多個SPEC，一個SPEC可能來源於多個原始的使用者需求。而實際的開發任務和測試任務，又常常需要基於具體的SPEC來分解和分配。這樣的話，藉助於需求空間的系統化管理，專案負責人能更好的對需求相關聯的產品功能、使用者需求、開發任務、測試用例、產品缺陷等進行全程跟蹤，實現需求可追溯性管理。

有了需求空間後，Product Backlog 是否被取代？在實踐中應當如何使用？

可以明確的回答，有了需求空間後，我們仍然需要Product Backlog，並且Product Backlog仍將繼續扮演重要的角色。首先我們明確Product Backlog 存放的是給開發團隊用的需求，更多服務於開發團隊。如何來理解這點？你可能會說，這不是廢話麼，給開發團隊的需求當然應該放在Product Backlog裡了。但實際專案進展中，常常會遇到以下2個實際問題。

問題一：“需求還在設計中；或整理完畢，但還未決定讓開發團隊去實現；這些需求是否需要存放在Product Backlog來管理”？

回答：可以啊，就放Product Backlog來管理，通過特定欄位或者標題標識加以區分就好。

評論：這樣的處理辦法，您依然可以使用Excel來管理產品Backlog。但隨著使用者需求的增加，或者當專案很龐大的時候，您勢必會需要一臺47寸顯示器和一雙鷹般銳利的眼睛來管理Product Backlog 列表:-)

       SpecDD認為，只有當需求決定要開發的時候，才需要有分配；有了分配後，才需要放到Backlog中。否則當一個需求還在設計階段，或者還沒有決定是否需要開始實施的時候，甚至都可以對開發部門和測試部門進行隱藏。有了這樣的改進，能更好的控制、管理Product Backlog列表。需求一旦分配到開發團隊後，也就從Backlog中移除了。新的，設計完畢的，可供分派到開發團隊的待處理需求，又從需求空間進入到 Product Backlog中。這樣的改進，更能讓Product Backlog實現了Scrum最早的思想；幫助專案經理從茫茫海洋中快速定位急待開發的任務。

問題二：一個需求包含的開發工作較大，Sprint 1 開始的時候，需求從Product Backlog分配出去。但是在Sprint 2中，同一個需求需要繼續迭代開發，但該需求已經不存在於Product Backlog中了，該怎麼辦？

產品負責人：從Sprint 1將之前的需求move到Sprint 2中？

專案經理：那Sprint 1的歷史工作記錄不就失真和破壞了麼？

產品負責人：或者在ProductBacklog建立一個相同的需求，再分配到Sprint 2中？

專案經理：那不就出現了重複的需求條目了麼？

       顯然這2種想法都不是好辦法。針對這個問題，SpecDD做了現實解答。SpecDD認為，Product backlog和需求空間是相互整合的。只不過需求（Epic/Spec）並不直接從需求空間被分配到 Product Backlog或Sprint中。當產品負責人決定要實現的時候，需求以Story的形式分配到Product Backlog中。Story是需求的一次實現分配。

SpecDD模型認為Product Backlog中不要直接存放使用者需求，否則會使得Backlog中的任務佇列越來越多，反倒影響了對於任務優先順序的排列。 Backlog中的內容應該儘可能的少，因此避免直接把需求放到Backlog中。而是採用把Story和Task放到Backlog中更好。Story一旦被分配，也就從Product Backlog中移除了。一個需求，如果工作量較大，需要通過多次迭代開發，或多個團隊共同協作來完成的話，那麼就可以根據開發情況，生成多個Story來進行分配。您也可以把Story理解為一個指向需求的指標；通過Story，開發團隊能直接檢視到具體Epic/SPEC的描述資訊，獲得上下游需求。分配到開發團隊的Story，可包含一組已分類的開發任務。所有這些關聯派生的Story以及拆分的任務，在需求空間上，又全都能夠在Epic/SPEC條目上進行全程跟蹤和追溯管理；從而讓專案負責人和管理組從需求層面上，牢牢掌控、規劃專案的進度和質量。

       通過上面一系列的討論，我們就會發現單純的Product Backlog 不足以實現需求管理。通過引入需求空間，重新定位Product Backlog的作用，以及Story概念的定義等系統化地需求管理，將有助於團隊決定產品功能取捨的“智慧”有效地發揮作用，且能直接從軟體產品結果中進行追蹤，也提高了可執行產品的交付正確性。高效、靈活地保證了可執行產品的交付，也就能讓使用者更早提出修改意見，從而使得專案整體保持良好的進展健康度。管理層也無需擔憂由於團隊人員變動和流失，而讓企業找不回當初創造產品功能時所經歷過的團隊討論與決定過程。