摘要：說起最讓程式設計師痛心疾首的事，非需求變更莫屬了，一度到了談“需求變更”色變的程度。
本文分享自華為雲社群《敏捷開發中如何從容應對需求變更？》，作者：敏捷小智 。
說起最讓程式設計師痛心疾首的事，非需求變更莫屬了。一度到了談“需求變更”色變的程度，網上更流傳著各種段子進行調侃，可見需求變更是工作中最令程式設計師頭疼的事情了。原有的需求程式碼已經寫了大半，或已經準備上線，此時再提出變更需求，就相當於造的房子，已經到了封頂階段，這個時候要求從原來一層改成兩層，這不僅僅是說再加蓋一層那麼簡單，為了保證牢固性，從地基以及房屋結構等等方面都需要發生改變。
既然需求變更如此令人生厭，那可不可以不允許需求變更呢？如果可以，相信研發兄弟們早就這麼幹了，又何必為此頭疼呢？閉門造出來的輪子可能還沒上路跑就已經被市場淘汰了。
大家都知道敏捷開發提倡擁抱變化，那是不是就可以隨意更改需求了？不是的，應對需求變更敏捷開發有一套自己的辦法，下面就對敏捷開發中如何處理需求變更進行解析。
擁抱變化的正確解讀
在軟體開發過程中有一條真理：需求的變化是永恆的，需求不可能是完備的。軟體開發過程實際上就是一個不斷應對變化的過程。敏捷開發提倡擁抱變化，但是有些對敏捷開發有誤解的人會認為：擁抱變化就是可以隨意變更需求。其實不然，在敏捷開發中有兩個工件：Product Backlog（產品代辦列表）和Sprint Backlog（迭代代辦列表），這裡說的變化是指Product Backlog是一個不斷變化的需求池，由PO負責管理完善，在整個開發過程中，PO都可以對Product Backlog中的需求進行修改和完善，根據情況調整優先順序，增添必要需求，刪除無價值需求。而Sprint Backlog是迭代計劃會議上的產物，是當前迭代需要完成的產品需求，是從Product Backlog中通過優先順序、重要性等篩選出來的子集。在迭代計劃會議上PO需要向開發團隊承諾在迭代進行中到結束都不會更改Sprint Backlog中的需求。
敏捷開發需求管理遵循的原則
1. 精確的需求優先開發，模糊的需求延後開發
軟體的需求具有模糊性、不確定性、變化性和主觀性的特點，在專案初期客戶可能只知道大概想要一個什麼樣的軟體，大部分的需求都不是清晰的，這個時候讓客戶把所有需求細節都表述明白，也著實是難為人了。那麼此時應該做的是將已經明確的需求落入到前期的迭代中，而隨著專案開發的進行，客戶想要一個什麼樣的軟體的想法也會越來越清晰，再把需求細節進行補充，根據需求的精確程度調整優先順序，把之前只是一個想法，後來發現並沒有什麼價值的需求剔除。這樣就一定程度上避免了開發中的需求發生變更。
2. 開發中的需求，原則上不允許變更
上面說過，在迭代計劃會議上PO需要向開發團隊承諾，在迭代計劃會議上PO需要向開發團隊承諾：在迭代進行中到結束都不會更改Sprint Backlog中的需求。迭代計劃會需要全員參與，就本次迭代完成的增量達成共識，迭代開始後，為不影響開發節奏和進度，原則上是不允許修改Sprint Backlog中的需求。迭代進行時PO可以修改未進入過迭代中的需求。
3. 必須變更的需求需經過評估確認
當然，理論是比較理想的狀態，進入現實，完全拒絕需求變更是不現實的，還是會有出現需要修改迭代中需求的情況，那該怎麼處理呢？
在敏捷開發中遇到需求變更，不是直接的接受或者拒絕，需要遵循“NO CHANGE”原則，先對需求進行分析，在根據分析結果做相應的處理：
- 無價值需求
通過與PO溝通分析後，對於無價值需求果斷拒絕。
- 優先順序高，影響小的需求
對於優先順序比較高的，對迭代影響小的需求變更，可以接納，但要工作量評估，做等價交換，就是把未做的優先順序低的需求從迭代替換出來，移動到Product Backlog中。
- 優先順序高，影響很大的需求
對於高優先順序的，對迭代影響很大的需求變更，需要停止當前迭代，重新規劃新的迭代。“影響很大”是指當前迭代中的需求繼續做下去也沒有價值，這時應該停止當前迭代。這種情況影響較大需要全體成員（包括客戶方）共同商定，並接受由此帶來的影響和成本提升。為避免或減少這種情況的出現，日常工作中PO應該至少整理好接下來1-3個迭代需要做的Product Backlog，然後按優先順序，挑選出最近一個迭代需要開發的需求，形成Sprint Backlog。
該不該進行專案細節展示？
敏捷開發的三個支柱：透明、檢視和適應，其中透明指的是：“湧現的過程和工作必須對執行工作的人員和接受工作的人員都是可見的”，對於這一點有的人會存在這樣的疑慮：給客戶（接受工作的人）展示專案的細節越多，客戶的問題和需求就會越多，到底應該不應該給客戶展示專案的全貌呢？
不給客戶展示專案細節只是一種逃避的做法，要知道展示或不展示，需求就在那裡，只是早與晚的區別。早在1980年代，Barry Boehm釋出的一些統計資料（ 軟體工程經濟學，1981年 ）就表明，隨著時間的推移，進行軟體更改或修復的成本會顯著增加。所以最好的辦法就是要求客戶共同參與，及時發現問題，及時修正，他們也能瞭解你的初衷和困難，更容易達成共識，才能保證交付的產品滿足客戶的要求。
總結
軟體開發的終極目標是交付客戶滿意的產品，不要一味懼怕和逃避需求變化，採用適合的需求管理原則，邀請客戶共同參與到開發活動中，儘量多的向客戶展示開發細節，才能及時發現問題，及時調整應對，將需求變更成本降到最低。