需求變更，敏捷專案應如何做？

前兩天我們在做專案覆盤的時候，發現其實在整個過程中還是遇到了不少需求變更的問題，不過還好我們算是比較圓滿地解決了這些突如其來的問題。相信也會有很多朋友和我們團隊一樣，經常遇到客戶這邊的需求變更，確實這是一個非常棘手的問題。不過在敏捷專案管理過程中，我們還是有一些方法可以解決需求變更這個問題的。

儘管我們對需求變更“深惡痛絕”，但畢竟，該面對的還是要面對的。

在敏捷專案管理中，我們要如何應對需求變更的問題呢？

一、設定Product Backlog與Sprint Backlog

Scrum框架針對需求變更，設定了Product Backlog（產品待辦列表）和Sprint Backlog（迭代待辦列表）。在每個迭代開始時，產品負責人需要在Product Backlog中，透過優先順序排序來篩選、整理出這一迭代的Sprint Backlog，也就是這一迭代需要完成的產品需求。也就是說，Product Backlog是不斷變化的，而Sprint Backlog是當前迭代中已經確定的產品需求，是不變的。這樣就會保證需求的變更不會影響到當前迭代的產出。

二、做好需求排序

設定Sprint Backlog就意味著我們要做好需求排序，那需求的優先順序由哪些維度來決定呢？  一個維度是需求的重要緊急程度 ，比較重要且緊急的需求要往前排，相對不重要不緊急的需求往後排。如果我們要交付一個電商平臺的MVP版本，那下單支付的需求會比收藏某一商品的需求重要的多，所以我們自然需要優先解決下單支付的功能。

那  另一個維度其實是需求的明確性 ，因為在專案的前期階段，客戶需求其實也不是那麼清晰明確。所以我們要考慮一下優先做已經明確了的需求，同時和客戶不斷地溝通確認，將那些相對模糊、可能會產生變化的需求確定下來，然後再排進相應的Sprint Backlog中。

客戶在描述需求的時候，我們可以用極限程式設計中的使用者故事實踐，將需求以“作為一個<使用者角色>，我想要<完成活動>，以便於<實現價值>”的形式進行表達，這樣更有利於雙方溝通、澄清需求。

三、對需求變更進行限制

確認好Sprint Backlog後，原則上不允許再變更需求。所以這就要求產品負責人需要對Sprint Backlog進行負責，提前與客戶進行需求的溝通、確認。

• 如果遇到必須變更、優先順序比較高且對迭代影響較小的需求，我們可以將這個需求放入迭代中，然後將原本迭代中優先順序較低的需求替換出來；
• 如果遇到必須變更、優先順序比較高且對迭代影響較大的需求，則需要和客戶同步並確認後，將當前進行中的迭代暫停，產品負責人重新規劃新一期的Sprint Backlog。

在這種情況下，專案團隊和產品負責人要做好足夠的應急預案，例如產品負責人要提前規劃出接下來的幾期Sprint Backlog，以便出現需求變更時，更快速地響應。

“  欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化 。”敏捷 專案管理的過程是一個動態過程，在這一過程中，涉及客戶、專案團隊、利益相關者等多方因素，而且這些因素的變動會影響其他因素的活動。所以在變動不可預知的情況下，我們就需要化被動為主動，積極應對專案過程中的各種需求變化。以提高客戶的競爭優勢為目的，在變化中尋找解決的方法，尋求雙方統一意見的達成，將需求變更的成本降至最低，實現提高效率與保證質量的統一。