網站開發中如何從容應對需求變更？

　　說起最讓程序員痛心疾首的事，非需求變更莫屬了。一度到了談“需求變更”色變的程度，網上更流傳著各種段子進行調侃，可見需求變更是工作中最令程序員頭疼的事情了。原有的需求代碼已經寫了大半，或已經準備上線，此時再提出變更需求，就相當于造的房子，已經到了封頂階段，這個時候要求從原來一層改成兩層，這不僅僅是說再加蓋一層那么簡單，為了保證牢固性，從地基以及房屋結構等等方面都需要發生改變。

既然需求變更如此令人生厭，那可不可以不允許需求變更呢？如果可以，相信研發兄弟們早就這么干了，又何必為此頭疼呢？閉門造出來的輪子可能還沒上路跑就已經被市場淘汰了。

如何處理需求變更進行解析：擁抱變化的正確解讀

　　在網站開發過程中有一條真理：需求的變化是永恒的，需求不可能是完備的。軟件開發過程實際上就是一個不斷應對變化的過程。小編認為：擁抱變化就是可以隨意變更需求。其實不然，在開發中有兩個工件：Product Backlog（產品待辦列表）和Sprint Backlog（迭代待辦列表），這里說的變化是指Product Backlog是一個不斷變化的需求池，由PO負責管理完善，在整個開發過程中，PO都可以對Product Backlog中的需求進行修改和完善，根據情況調整優先級，增添必要需求，刪除無價值需求。而Sprint Backlog是迭代計劃會議上的產物，是當前迭代需要完成的產品需求，是從Product Backlog中通過優先級、重要性等篩選出來的子集。在迭代計劃會議上PO需要向開發團隊承諾在迭代進行中到結束都不會更改Sprint Backlog中的需求。

開發需求管理遵循的原則

1. 精確的需求優先開發，模糊的需求延后開發

軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，在項目初期客戶可能只知道大概想要一個什么樣的軟件，大部分的需求都不是清晰的，這個時候讓客戶把所有需求細節都表述明白，也著實是難為人了。那么此時應該做的是將已經明確的需求落入到前期的迭代中，而隨著項目開發的進行，客戶想要一個什么樣的軟件的想法也會越來越清晰，再把需求細節進行補充，根據需求的精確程度調整優先級，把之前只是一個想法，后來發現并沒有什么價值的需求剔除。這樣就一定程度上避免了開發中的需求發生變更。

2. 開發中的需求，原則上不允許變更

上面說過，在迭代計劃會議上PO需要向開發團隊承諾：在迭代進行中到結束都不會更改Sprint Backlog中的需求。迭代計劃會需要全員參與，就本次迭代完成的增量達成共識，迭代開始后，為不影響開發節奏和進度，原則上是不允許修改Sprint Backlog中的需求。迭代進行時PO可以修改未進入過迭代中的需求。

3. 必須變更的需求需經過評估確認

當然，理論是比較理想的狀態，進入現實，完全拒絕需求變更是不現實的，還是會有出現需要修改迭代中需求的情況，那該怎么處理呢？

在開發中遇到需求變更，不是直接的接受或者拒絕，需要遵循“NO CHANGE”原則，先對需求進行分析，在根據分析結果做相應的處理：

無價值需求

通過與PO溝通分析后，對于無價值需求果斷拒絕。

優先級高，影響小的需求

對于優先級比較高的，對迭代影響小的需求變更，可以接納，但要工作量評估，做等價交換，就是把未做的優先級低的需求從迭代替換出來，移動到Product Backlog中。

 優先級高，影響很大的需求

對于高優先級的，對迭代影響很大的需求變更，需要停止當前迭代，重新規劃新的迭代。“影響很大”是指當前迭代中的需求繼續做下去也沒有價值，這時應該停止當前迭代。這種情況影響較大需要全體成員（包括客戶方）共同商定，并接受由此帶來的影響和成本提升。為避免或減少這種情況的出現，日常工作中PO應該至少整理好接下來1-3個迭代需要做的Product Backlog，然后按優先級，挑選出最近一個迭代需要開發的需求，形成Sprint Backlog。

該不該進行項目細節展示

開發的三個支柱：透明、檢視和適應，其中透明指的是：“涌現的過程和工作必須對執行工作的人員和接受工作的人員都是可見的”，對于這一點有的人會存在這樣的疑慮：給客戶（接受工作的人）展示項目的細節越多，客戶的問題和需求就會越多，到底應該不應該給客戶展示項目的全貌呢？ 

不給客戶展示項目細節只是一種逃避的做法，要知道展示或不展示，需求就在那里，只是早與晚的區別。早在1980年代，Barry Boehm發布的一些統計數據（ 軟件工程經濟學，1981年 ）就表明，隨著時間的推移，進行軟件更改或修復的成本會顯著增加。所以最好的辦法就是要求客戶共同參與，及時發現問題，及時修正，他們也能了解你的初衷和困難，更容易達成共識，才能保證交付的產品滿足客戶的要求。

總結

軟件開發的終極目標是交付客戶滿意的產品，不要一味懼怕和逃避需求變化，采用適合的需求管理原則，邀請客戶共同參與到開發活動中，盡量多的向客戶展示開發細節，才能及時發現問題，及時調整應對，將需求變更成本降到最低。