需求真的在一直變化嗎？
 
　　不一定是這樣，例如對傳統行業(yè)的信息化，由于有相對穩(wěn)定的工作流程，需求變化不會很大。并不是所有的軟件項目的需求都是變幻莫測的。如果在項目初期沒有對需求進行全面的捕獲和確認，那項目進行過程中出現反復修改，以至于返工，都是很可能的事。
這就對需求捕獲人員提出了很高的要求，需求不但要全面，準確，還要考慮到實施中的每一個細節(jié)，如果某個細節(jié)出現不符合客戶實際的要求，到項目實施完成之后，可能要進行一個工作量很大的修改，還會牽扯到其他的功能，在修改的過程中又會引入新的問題，這就象所說的牽一發(fā)而動全身一樣。
 
　　不同的軟件開發(fā)過程對于需求變化的解決辦法是不同的。
 
　　統一軟件開發(fā)過程（UP、RUP）的解決辦法是預防和控制需求的變化。
 
　　敏捷的方法如XP，則倡導擁抱變化。

　　一、統一的方法
　　統一軟件開發(fā)過程是通過在項目的前期盡可能準確，全面地捕獲需求，然后對需求的變化加以控制和管理，來避免范圍的蔓延，并通過迭代和遞增的開發(fā)方式，來應對變化。
 
　　從軟件工程發(fā)展的歷史，我們說在項目前期全面地捕獲需求一直是一個做好軟件的不二法則。
 
　　對業(yè)務邏輯相對穩(wěn)定的項目，在項目實施之前做好需求的捕獲絕對是受益匪淺的，因為軟件的問題在生命周期的后期發(fā)現需要的成本要比在初期發(fā)現高得多。
 
　　迭代和遞增式開發(fā)也降低了項目的風險，他允許在項目進行過程中對需求進行校正，它通過遞增的版本發(fā)布使得客戶能在軟件開發(fā)生命周期過程中就對軟件有了更全面的認識，因此也能及時的提出改進意見。
 
　　從團隊的角度看，迭代的開發(fā)更符合人類學習的曲線－一個漸進的過程。在項目開發(fā)的初期，開發(fā)人員對業(yè)務邏輯和技術的掌握可能并不全面，隨著項目的進展，認識會不斷加深，這對于后期的迭代周期的成功是很好的保障。
 
　　然而，某些項目確實存在很多不確定因素，還有某些大型項目，歷時時間很長，在那么長的時間里需求會變化是很自然得事情。
對這些項目迭代和遞增的開發(fā)方法會比在項目早期就盡可能地捕獲需求更有意義。

　　一、敏捷方法（XP）
　　以XP為例，他提出以擁抱變化來應對需求的變化，他并沒有強調在項目的初期確定能確定的需求的重要意義。這與傳統的軟件工程觀點和統一軟件開發(fā)過程有差異，他不主張預防需求變化，因此也就沒有強調盡可能在早期確定需求。
擁抱變化與其說是一種方法，不如說是一種心態(tài)的調整，XP方法希望開發(fā)人員能有良好的面對變化的心態(tài)，不討厭變化，積極面對變化。
 
　　心理因素對于軟件行業(yè)是非常重要的，軟件的本質決定了軟件的成敗更多的依靠人的因素。軟件的可見性差，生產率的衡量也是需要考慮相當多的因素，需要相當高的學問的，一般的管理人員懂管理未必懂軟件，懂軟件呢又未必精通管理，因此XP的發(fā)明者覺得與其費力去度量和評估，不如發(fā)揮人的積極主動精神。如果一個軟件開發(fā)組織的人員能擁有積極向上的心態(tài)，那會比實施任何一種軟件開發(fā)過程，采用任何業(yè)績評估方法都更有效。
 
　　擁抱變化的確是一種非常優(yōu)良的品質，這不僅僅對于軟件需求如此，對于日新月異的軟件行業(yè)不也如此嗎，不跟上技術潮流就會被淘汰，作技術的人員都是深有體會的。同樣，面對飛速發(fā)展的社會，如果沒有積極的心態(tài)來應對各種變化，改變固有的觀念，也一樣會被時代所拋棄。
 
　　但是，我們如果既能擁抱變化，又能未雨綢繆，不是對事情的進展有更好的把握嗎？這不等于又多了一層保障嗎？就像很多人說瘋狂英語是失敗的，因為很少有人能一直保持著瘋狂的學習態(tài)度，的確是這樣，即便我們有擁抱變化的準備，和積極的心態(tài)，如果連續(xù)為變化而加班數月的話，相信一樣會有挫敗感，如果那時你還能以積極的心態(tài)來應對變化的話，我相信你將來一定能成就一番大事業(yè)。
當然XP的擁護者會說，XP不提倡加班，我們每周只工作４０小時，這當然是一個好的主意，如果能夠實施，又能滿足交付期限的話，那我們應該為你祝賀。
 
　　XP同樣采用迭代的開發(fā)方法，小版本交付，來使得客戶對軟件盡早有更多的認識和了解，這和統一軟件過程是相同的。

　　二、結論
　　縱觀統一軟件開發(fā)過程和敏捷方法對于需求變化的解決方法，我們可以得出結論：

　　預防變化，做到在軟件開發(fā)的初期就盡可能確定可以確定的需求；

　　控制需求變更，避免范圍蔓延；

　　以積極的心態(tài)來擁抱變化；

　　采用迭代和遞增的開發(fā)方法，

　　是解決需求變化的最佳方法。

轉帖于：軟件水平考試_考試吧