需求變更管理：
需求變更：
需求變更之所以會產(chǎn)生，可能是用戶不能清晰描述需求或?qū)π枨笠膊皇翘貏e明確，也可能是開發(fā)人員對需求理解與用戶不一致，或者是用戶需求確實有更改，或者是遇到其他外部環(huán)境的影響（如國家政策）。
需求的變更總會對項目產(chǎn)生一定的影響，比如項目范圍、項目進度、項目質(zhì)量、項目成本、開發(fā)人員的心里、用戶滿意度、代碼與文檔的吻合度等等。所以對需求的變更一定要有一定的管理策略。
變更管理：
變更管理應該有一定的規(guī)范，主要應該包含以下幾個步驟：
第一步，應該識別變更，只有識別那些是變更才能對其做出合適的處理。
第二步，應該對變更進行詳細的分析，分析變更的合理性和緊迫程度，以及對項目產(chǎn)生的影響，比如是否會影響項目進度，是否會加大項目投入等等。
第三步，提出正式的書面變更申請。
第四步，審批，來確定變更是否通過。
第五步，如果審批通過，那么應當詳細記錄變更。
需求可追溯性：
項目變更的可追溯性也非常重要，可以監(jiān)控變更執(zhí)行情況、防止與用戶之間的糾紛、問題的處理分析等等。要做到可追溯性，那么項目變更的記錄就需要非常詳細，應當記錄變更緣由，變更日期，變更前后的需求內(nèi)容等，這樣才能追溯到每一次的需求變更，讓項目更可控。但是并不是需求追溯的粒度越細越好，否則的話，一方面會使需求追溯耗費的時間成本巨大，另一方面也會讓需求追溯數(shù)據(jù)量變大而難以維護。
除此之外，項目需求文檔的格式以及力度也對項目變更的管理和記錄有一定影響，雖然可追溯性不是決定需求文檔編制的主要因素，但是結(jié)構(gòu)好的需求文檔更容易只是需求變更的可追溯性。
需求空間：
敏捷過程中，僅用Product Backlog，不足以滿足需求的管理。通常，一個項目的研發(fā)過程，通過3個空間來進行表達：需求空間、研發(fā)空間和QA測試空間。3個空間相互間應當是完全整合的，使得整個團隊的不同職能工作能夠相互協(xié)作。
需求空間用來做什么？
用戶需求，在需求空間中被錄入登記。
敏捷提倡客戶價值導向，應當從客戶價值角度描述，就是描述客戶如何使用，而不是描述技術(shù)層面如何實現(xiàn)。
我們喜歡Story的用戶需求表達方式，但這不代表用戶需求的管理就是雜亂、隨意和無序的。產(chǎn)品負責人需要借助需求工作流、需求分析、和需求可追溯性的管理，進行產(chǎn)品需求的提煉、條目化、優(yōu)先級排序等。通過需求空間，對用戶需求形成細化和量化.
借助于需求空間的系統(tǒng)化管理，項目負責人能更好的對需求相關(guān)聯(lián)的產(chǎn)品功能、用戶需求、開發(fā)任務、測試用例、產(chǎn)品缺陷等進行全程跟蹤，實現(xiàn)需求可追溯性管理。
有了需求空間后，我們?nèi)匀恍枰狿roduct Backlog，并且Product Backlog仍將繼續(xù)扮演重要的角色。首先我們明確Product Backlog存放的是給開發(fā)團隊用的需求，更多服務于開發(fā)團隊。
如何管理Product Backlog？
只有當需求決定要開發(fā)的時候，才需要有分配；有了分配后，才需要放到Backlog中。有了這樣的改進，能更好的控制、管理Product Backlog列表。需求一旦分配到開發(fā)團隊后，也就從Backlog中移除了。設計完畢的，可供分派到開發(fā)團隊的待處理需求，又從需求空間進入到 Product Backlog中。這樣的改進，更能讓Product Backlog實現(xiàn)了Scrum最早的思想；幫助項目經(jīng)理從茫茫海洋中快速定位急待開發(fā)的任務。
一個需求包含的開發(fā)工作較大，Sprint 1 開始的時候，需求從Product Backlog分配出去。但是在Sprint 2中，同一個需求需要繼續(xù)迭代開發(fā)，但該需求已經(jīng)不存在于Product Backlog中了，該怎么辦？
Product backlog和需求空間是相互整合的。只不過需求（Epic/Spec）并不直接從需求空間被分配到 Product Backlog或Sprint中。當產(chǎn)品負責人決定要實現(xiàn)的時候，需求以Story的形式分配到Product Backlog中。Story是需求的一次實現(xiàn)分配。
Product Backlog中不要直接存放用戶需求，否則會使得Backlog中的任務隊列越來越多，反倒影響了對于任務優(yōu)先級的排列。 Backlog中的內(nèi)容應該盡可能的少，因此避免直接把需求放到Backlog中。而是采用把Story和Task放到Backlog中更好。Story一旦被分配，也就從Product Backlog中移除了。一個需求，如果工作量較大，需要通過多次迭代開發(fā)，或多個團隊共同協(xié)作來完成的話，那么就可以根據(jù)開發(fā)情況，生成多個Story來進行分配。您也可以把Story理解為一個指向需求的指針；通過Story，開發(fā)團隊能直接查看到具體Epic/SPEC的描述信息，獲得上下游需求。分配到開發(fā)團隊的Story，可包含一組已分類的開發(fā)任務。所有這些關(guān)聯(lián)派生的Story以及拆分的任務，在需求空間上，又全都能夠在Epic/SPEC條目上進行全程跟蹤和追溯管理；從而讓項目負責人和管理組從需求層面上，牢牢掌控、規(guī)劃項目的進度和質(zhì)量。
通過上面一系列的討論，我們就會發(fā)現(xiàn)單純的Product Backlog 不足以實現(xiàn)需求管理。通過引入需求空間，重新定位Product Backlog的作用，以及Story概念的定義等系統(tǒng)化地需求管理，將有助于團隊決定產(chǎn)品功能取舍的“智慧”有效地發(fā)揮作用，且能直接從軟件產(chǎn)品結(jié)果中進行追蹤，也提高了可執(zhí)行產(chǎn)品的交付正確性。高效、靈活地保證了可執(zhí)行產(chǎn)品的交付，也就能讓用戶更早提出修改意見，從而使得項目整體保持良好的進展健康度。管理層也無需擔憂由于團隊人員變動和流失，而讓企業(yè)找不回當初創(chuàng)造產(chǎn)品功能時所經(jīng)歷過的團隊討論與決定過程。
