混合敏捷研發（二） 敏捷開發中，Product Backlog 是否足以實現需求管理？

          敏捷開發中，Product Backlog 是否足以實現需求管理？

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

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

• 無法支持需求驅動下完整的可追溯性；

• 整個團隊完全致力于項目的開發是基本前提，一旦開發團隊的方向出現變化，會導致項目的崩潰，因為需求總在變化。

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

需求空間用來做什么？

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

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

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

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

問題一：需求還在設計中或整理完畢，但還未決定讓開發團隊去實現，這些需求是否需要存放在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中？

項目經理：那不就出現重復的需求條目了么？

     顯然這兩種想法都不是好辦法。針對這個問題，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概念的定義等系統化地需求管理，將有助于團隊決定產品功能的取舍，且能直接從軟件產品結果中進行追蹤，也提高了可執行產品的交付正確性。高效、靈活地保證了可執行產品的交付，也就能讓用戶更早提出修改意見，從而使得項目整體保持良好的進展健康度，管理層也無需擔憂由于團隊人員變動和流失，而讓企業找不回當初創造產品功能時所經歷過的團隊討論與決定過程。