一、問題的提出
筆者近幾年一直從事資訊系統的開發，特別是有關國家機關和企業資訊系統的開發工作，取得了許多的經驗和教訓。其中乙個深切的體會是，需求的不斷變化，如果不能很好的應對，會導致整個專案的進度和質量都難以控制，最終使整個系統失敗。特別是在我國，使用者對於如何應用計算機軟體並沒有乙個成熟的經驗，在專案進行中使用者會頻繁的改變和增加各種要求。當最終完成系統的建設時，卻發現企業的業務需求已經發生了很大的改變，一方面是系統的設計已經無法很好地滿足新的需求，另一方面是專案週期大大超過預期，專案發生虧損。
據美國軟體工程實施現狀的調查，軟體研發的情況也是很難**，大約只有10%的專案能夠在預定的費用和進度下交付。在商用軟體產業中，這一現象尤為嚴重。
因此如何從軟體工程的角度，通過採用適當系統設計方法和加強專案管理來解決需求不斷變化的問題，是各個軟體開發商的乙個重要課題。通過實踐，感到採用敏捷方法的基本思想和原則來設計系統和處理需求變化問題，能夠產生較好的效果。
下面就從系統設計和專案管理等方面談一下這方面的體會。
二、需求變化帶來的問題
作為軟體開發商，當接到乙個專案後，一般的做法是首先由使用者提出需求，然後開發商根據使用者的需求作出乙個系統實現方案，而使用者通常並沒有實質地理解方案，隨即通過了方案，開始了軟體的開發工作。根據筆者所開發過的多個系統，開發前期，大多數單位並沒有明確的想法，也提不出確切的需求，因為業務人員不了解計算機技術是怎樣實現業務流程的。使用者總是希望開發單位根據當前的業務流程先做出乙個樣板來，然後再進行改造，而多數使用者認為軟體修改很容易。
儘管已經做好了系統規劃，簽訂了功能較明確的合同，然而隨著系統分析、系統設計和系統實施的進展，當客戶在專案部署後看到真正的軟體系統的介面及操作方式，客戶的需求就被激發起來，會根據自己的對軟體的理解和日常工作的習慣，對軟體的處理及操作方式提出修改，而這種修改往往比較隨意，因此導致開發方需要對流程、介面、以及相關文件經常的大量的修改，這些成為開發方的乙個很大的負擔，而這種負擔對使用者基本是看不見的。
三、用敏捷方法方法應對需求變化
1．敏捷建模（agile modeling）進行系統設計
軟體開發過程一般是要盡早完成需求分析，停止需求的變動，將這些需求作為設計的基礎，然後開始構築系統，這是瀑布方法----基於計畫的生命週期。這種方法是通過大量的前期工作來減少變化。一旦前期工作完成，當需求變化時，這樣的方法就會有很大的問題。
另外乙個重要原因是，許多單位的管理模式都處在探索階段，可能引起變動的因素很多，因此根據現行的管理模式設計出的資訊系統將面臨使用單位管理模式的變化的考驗，包括許多的工作流程的細節處理方式式否合乎工作人員的習慣等問題。
系統在設計時要充分考慮這些不確定因素，才能適應這些變化。特別是資料結構要以系統靈活性為主，其次才是考慮系統效能的提高。
在軟體開發出現工期或bug等問題時，開發人員常抱怨是由於需求的變化造成的，對於軟體的修改存在牴觸情緒。實際上在商業軟體開發領域，需求變化是很正常的，問題是我們該怎樣對待它。為了適應需求的變化，必須採取不同的設計態度。這裡介紹敏捷方法的幾點思想，對如何應對需求的變化很有教益。
主張簡單、遞增的變化、擁抱變化是敏捷建模方法的核心原則之中的三個。
敏捷建模主張當從事開發工作時，最簡單的解決方案就是最好的解決方案，盡可能的保持模型的簡單。
對無法在專案一開始就固化的需求進行演進型的設計。你現在不必要對這個系統進行過分的建模，只要基於現有的需求進行建模，隨著專案的進行，專案環境和需求發生變化時，再來完善和重構這個系統。
遞增的變化是指你不用在模型中包容所有的細節，你只要開發乙個小的模型或是概要模型，打下乙個基礎，然後慢慢的改進模型。
敏捷建模採取不同的設計態度來"擁抱變化"。它認為需求時刻在變，人們對於需求的理解也時刻在變。隨著專案的進行，專案環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。對於使用者的反饋，要勇於對自己的**進行修改，丟掉壞的**。
對於易變的需求，敏捷方法使用了一系列實踐。其核心則是迭代式開發，尋求快速的反饋，使用者經歷過一次或幾次的迭代之後，對軟體開發和業務需求如何實現已經有了形象的認識，使用者提出的需求基本上可以代表他們的真實需求。這時，就可以將需求進行凍結。後面如果還有修改，將是細節的調整，不會對軟體的架構產生重大的影響。
按照上述的敏捷方法的原則來設計系統，則能夠使我們正確的看待使用者需求的變動，從而較好的適應需求的變動。如果專案管理者和程式開發人員真正的理解並貫徹這種方法，用這種思想去管理專案，那麼就能有效的避免出現專案後期軟體架構混亂、補丁加補丁、系統效能大大減低的情況。
2．專案管理的作用
1）推動技術與需求"匹配"
上面提到要採用敏捷方法的迭代式開發，盡快的凍結需求，那麼通過專案管理的手段，可以控制和縮短需求凍結的時間。
專案管理是一種管理手段，目的是在指定時間和資源的條件下，保質、按時地完成預定的任務。作為乙個專案管理人員，必須注意有些需求的變化是由於業務與設計的"不匹配"造成的，即使用者一方可能對資訊系統的開發和實現方法，缺乏全面的了解，不懂得如何將傳統的業務模式轉換為資訊系統所要求的處理模式。
另一方面，也可能開發商對使用者方的需求、細節了解不充分等因素，使得使用者方與開發方對工程的理解從一開始就存在著差異。因為業務人員開始提不出實際的需求來，而只是把大致的工作流程介紹一遍。而這種認識上的差異與理解的不同往往在開發初期並沒有表現出來，當軟體基本成型，給使用者演示時，顯出較大的差異。
作為開發商，過去經常將開發的注意力集中在"技術"上，即計算機軟硬體、作業系統平台和資料庫等技術實現上。而對於資訊系統的開發，則必須首先考慮到使用者的理念、方針和及其對技術方法的領會等各方面因素。往往這些因素對系統成敗所起的作用，比技術實現的因素更重要。
首先，專案設計組人員要向需求方的領導及業務人員闡述資訊系統是如何實現的，什麼樣的業務模式適合於網路，怎樣處理和解決什麼問題，需要在傳業務模式上做哪些改進，建立基本的操作規範等等。必須明確，資訊系統改變了現行的工作管理模式，使工作人員失去了一定的靈活性和隨意性。如果不建立新的操作流程和規範，在傳統手工處理方式上，實現資訊系統是不可能的。
其次，詳細的了解全盤業務流程之後，用基本使用者介面原型向需求方演示和說明方案，使業務人員真正理解技術實現的思路，能夠及時發現與實際不吻合或存在的困難，這樣才可能從工作流程上或技術上來解決這些問題。
當出現問題時，專案管理人員應迅速分析問題，正確判斷哪些問題屬於不適應新的工作模式引起的，哪些問題屬於操作不當引起的，哪些問題屬於系統本身不完善引起的。對於那些由於不適應新的工作模式引起的問題，專案管理人員應引導使用人員迅速適應新的工作模式，必要時也要說服使用者方的決策層採用行政手段推動實施；專案管理人員時刻注意取得決策層的理解與支援，幫助工作人員盡快地適應新的工作方式。
專案管理者就像是乙個樞紐，由他來決定需求的分類、工作量、需求變化對現有軟體的影響程度等因素，從而安排需求變更的計畫――是在本次迭代中完成，還是在下一次迭代中完成。
2）開發文件的更新
軟體開發文件對與軟體專案來說是乙個很大的工作量。很多軟體專案的開發，在初期文件比較正規，隨著專案的深入，特別是需求發生多次變化之後，要保持軟體開發文件的一致性就感到非常困難了，因為需求改變的各種資訊沒有記錄下來，最後不得不蒙混過關，草草了之。
但如果我們按照敏捷方法的原則，在需求凍結之前，不要過分的把精力投入到文件的製作上，而是將有關的資訊記錄和保留下來，在需求基本凍結之後，化一定的時間來建立和對文件進行格式化。
3）合同的考慮
儘管按照敏捷方法的原則是擁抱變化，但還是應該在簽定開發合同時，一方面對專案的費用和時間估計時一定要考慮使用者需求的變化，另一方面把使用者需求的改動的條款寫清楚，如果使用者增加或改動了需求，那麼軟體的交付日期可以推遲，費用也應增加。這樣可以限制使用者的隨意改動。
三、結束語
每個專案的開發環境及實施環境各不相同，在系統設計和專案管理方面所面臨的問題不盡相同，但需求發生變化是所有專案都會遇到的問題。資訊系統的建設由於會改變原有的傳統工作模式，需求的內容因而會隨時變動，給開發工作帶來很大的難度。本文提出了應用敏捷方法的思想來應對軟體開發過程中需求變化的問題，希望能對系統開發人員和專案管理人員有所幫助。
作團隊感悟 13 如何應對需求變化
本文出處 http blog.csdn.net sodme 前記 過去，在傳統軟體行業裡，開發的流程一般是 先作需求分析，然後確定功能，最後實施開發。也就是說，需求分析之後，需求基本就很少變了，會在相當長一段時間內，維持乙個穩定的需求。但是，在進入網際網路軟體時代後，事情已經發生了變化，僅就需求而言...
作團隊感悟 13 如何應對需求變化
本文出處 前記 過去，在傳統軟體行業裡，開發的流程一般是 先作需求分析，然後確定功能，最後實施開發。也就是說，需求分析之後，需求基本就很少變了，會在相當長一段時間內，維持乙個穩定的需求。但是，在進入網際網路軟體時代後，事情已經發生了變化，僅就需求而言，朝令夕改 已經不是什麼新鮮事，作為系統的實現者，...
需求變化與IoC
2012年3月26日 todd 15,687 人閱讀 感謝 todd投遞本文 微博帳號 weidagang 需求又變了，怎麼辦？程式設計師xx遭遇車禍成植物人，醫生說活下來的希望只有萬分之一，喚醒更為渺茫。可他的lead和親人沒有放棄，他們根據xx工作如命的作風，每天都在他身邊念 xx，需求又改了，...