談軟件開發項目管理之需求變動（轉）

在軟件開發過程當中需求的變動會給開發帶來不肯定性，但只要把需求變動做爲重點、難點當心加以控制，軟件開發的進度、成本和質量也就有了"安全"的基礎。變化並非人們最懼怕的，最怕的是跟不上變化的步伐。

一、需求變動管理的需求

需求變動是由於需求發生變化。根據軟件工程思想，需求說明書通常要通過論證，若是在需求說明書通過論證之後，須要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬於需求變動。需求變動的出現主要是由於在項目的需求肯定階段，用戶每每不能確切地定義本身須要什麼。用戶經常覺得本身清楚，但實際上他們提出的需求只是依據當前的工做所需，而採用的新設備、新技術一般會改變他們的工做方式;或者要開發的系統對用戶來講也是個未知數，他們之前沒有過相關的使用經驗。

隨着開發工做的不斷進展，系統開始展示功能的雛形，用戶對系統的瞭解也逐步深刻。因而，他們可能會想到各類新的功能和特點，或對之前提出的要求進行改動。他們瞭解得越多，新的要求也就越多，需求變動所以不可避免地一次又一次出現。這時，若是開發團隊缺乏明確的需求變動控制過程或採用的變動控制機制無效，抑或不按變動控制流程來管理需求變動，那麼極可能形成項目進度拖延、成本不足、人力緊缺，甚至致使整個項目失敗。固然，即便按照需求變動控制流程進行管理，因爲受進度、成本等因素的制約，軟件質量仍是會受到不一樣程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變動給軟件質量形成的負面影響，這也正是咱們進行需求變動管理的目的所在。

二、六大原則

實施需求變動管理須要遵循以下原則：

1）創建需求基線。需求基線是需求變動的依據。在開發過程當中，需求肯定並通過評審後(用戶參與評審)，能夠創建第一個需求基線。此後每次變動並通過評審後，都要從新肯定新的需求基線。

2）制訂簡單、有效的變動控制流程，並造成文檔。在創建了需求基線後提出的全部變動都必須遵循這個控制流程進行控制。同時，這個流程具備必定的廣泛性，對之後的項目開發和其餘項目都有借鑑做用。

3）成立項目變動控制委員會(CCB)或相關職能的相似組織，負責裁定接受哪些變動。CCB 由項目所涉及的多方人員共同組成，應該包括用戶方和開發方的決策人員在內。

4）需求變動必定要先申請而後再評估，最後通過與變動大小至關級別的評審確認。

5）需求變動後，受影響的軟件計劃、產品、活動都要進行相應的變動，以保持和更新的需求一致。

6）妥善保存變動產生的相關文檔。

三、應對之道

需求變動控制通常要通過變動申請、變動評估、決策、回覆這四大步驟。若是變動被接受，還要增長實施變動和驗證兩個步驟，有時還會有取消變動的步驟。

變動控制流程如圖所示。針對變動控制流程，筆者在實際工做中總結出了軟件開發人員在需求變動管理實踐中的幾點對策：

1）相互協做

很難想像遭到用戶抵制的項目可以成功。在討論需求時，開發人員與用戶應該儘可能採起相互理解、相互協做的態度，對能解決的問題儘可能解決。即便用戶提出了在開發人員看來"過度"的要求，也應該仔細分析緣由，積極提出可行的替代方案。

2）充分交流

需求變動管理的過程很大程度上就是用戶與開發人員的交流過程。軟件開發人員必須學會認真聽取用戶的要求、考慮和設想，並加以分析和整理。同時，軟件開發人員應該向用戶說明，進入設計階段之後，再提出需求變動會給整個開發工做帶來什麼樣的衝擊和不良後果。

3）安排專職人員負責需求變動管理

有時開發任務較重，開發人員容易陷入開發工做中而忽略了與用戶的隨時溝通，所以須要一名專職的需求變動管理人員負責與用戶及時交流。

4）合同約束

需求變動給軟件開發帶來的影響有目共睹，因此在與用戶簽定合同時，能夠增長一些相關條款，如限定用戶提出需求變動的時間，規定何種狀況的變動能夠接受、拒絕接受或部分接受，還能夠規定發生需求變動時必須執行變動控制流程。

5）區別對待

隨着開發進展，有些用戶會不斷提出一些在項目組看來確實沒法實現或工做量比較大、對項目進度有重大影響的需求。遇到這種狀況，開發人員能夠向用戶說明，項目的啓動是以最初的基本需求做爲開發前提的，若是大量增長新的需求(雖然用戶認爲是細化需求，但其實是增長了工做量的新需求)，會使項目不能按時完成。若是用戶堅持實施新需求，能夠建議用戶將新需求按重要和緊迫程度劃分檔次，做爲需求變動評估的一項依據。同時，還要注意控制新需求提出的頻率。

6）適當的開發模型

採用創建原型的開發模型比較適合需求不明確的開發項目。開發人員先根據用戶對需求的說明創建一個系統原型，再與用戶溝通。通常用戶看到一些實際的東西后，對需求會有更爲詳細的解釋，開發人員可根據用戶的說明進一步完善系統原型。這個過程重複幾回後，系統原型逐漸向最終的用戶需求靠攏，從根本上減小需求變動的出現。

目前業界較爲流行的疊代式開發方法對工期緊迫的項目的需求變動控制頗有成效。

7）參與需求評審

做爲需求的提出者，用戶理所固然是最具權威的發言人之一。實際上，在需求評審過程當中，用戶每每能提出許多有價值的意見。同時，這也是由用戶對需求進行最後確認的機會，能夠有效減小需求變動的發生。

 

補充：屢次迭代驗收。一方面能夠控制風險，另外一方面保證需求變動在一個可控範圍內。。