*用戶價值驅動
在傳統軟件工程方法中，我們已經注意到一個事實，客戶對于需求的認識往往是含混不清的，不能夠簡單地認為用戶在需求說明中所描述的軟件就是他們真正想要的軟件。
因此傳統軟件工程的方法強調了對于需求的管理，從而形成了以需求驅動整個軟件開發的方法學。但是，傳統軟件工程方法同時忽略的一個問題是，用戶對于需求價值的評估隨時間的變化也有一些不同。
傳統方法往往無法作做到令人滿意需求價值跟蹤管理。雖然優先級重排等方法在一定程度上代表了傳統方法對于需求價值的重視，但是由于傳統方法中軟件的構造和軟件的實施有較長的周期間隔，用戶的反饋往往嚴重滯后于軟件開發過程，從而造成高昂的成本。同時用戶缺乏一個可以實際上線的軟件，大多數價值變化來自于簡單的臆想，因此估算價值和實際價值變化存在較大的出入。
敏捷軟件開發強調縮短第一版本上線周期，持續為用戶提供有價值的軟件。用戶對于需求價值的評估都來自于實際的使用評價，而不是無根據的猜想，因此敏捷方法中的價值估計具有更高的可靠性。同時敏捷開發方法中，上線與軟件開發并不是工程的截然不同的兩個階段。在大多數的時間里，上線的軟件和圍繞這個軟件的開發是同步進行的。用戶的反饋以及變化的需求可以較容易的得到實現。
敏捷軟件方法中需求的評估全部是動態的:在每一個小版本上線之后，用戶可以根據當前業務環境的需求，修正需求的價值評估;在每一個版本開發過程中，用戶可以在每一迭代開始的時候選，對當前開發版本的需求的價值進行重估，也可以重新組織當前版本的需求范圍。
工程價值與客戶滿意度
無論是短期交付還是價值驅動，敏捷軟件方法都強調為客戶提供有價值的軟件。軟件的實際價值以及軟件的實際價值為用戶帶來的收益，才是敏捷方法的最關注的重點。因此，在敏捷軟件工程和傳統工程在工程價值的體現上有本質的差異。
傳統軟件工程的價值體現在按時按質按量的完成用戶規定的需求范圍。而敏捷軟件工程的價值直接體現為用戶提供一個最符合當前業務環境的信息系統，敏捷軟件工程并不能承諾完成用戶全部需求，也不能承諾用更低的成本來完成更多的需求。
敏捷軟件只能保證交付一個在一定成本范圍內最有價值的軟件。
*敏捷方法和SOA
敏捷軟件開發過程和SOA分別達成了不同但又相關的目標:敏捷方法增加了軟件交付的效率而SOA則增加了軟件的彈性和重用性。
正因為SOA和敏捷方法的目標的相關性，采用SOA架構的企業在開發方法上往往選擇了敏捷方法。如圖5Forrester的研究數據所示:所有參加統計的企業中，采用敏捷方法的占14%;在企業范圍內采用SOA架構的公司中，采用敏捷方法的為28%;選擇應用SOA而沒有明確策略的公司中，采用敏捷方法的為21%;而不準備采用SOA的公司，僅有6%采用敏捷方法。
可以看出，采用SOA而同時應用敏捷方法的公司占所有應用SOA公司的比率是采用敏捷的公司占所有參與統計公司比率的1.5～2倍，而不準備采用SOA的公司中采用敏捷方法的比率，僅僅是采用敏捷的公司占所有參與統計公司比率的1/2。
敏捷方法與SOA都強調了商業價值導向的，靈活并且可以持續交付的軟件。這兩者也在不同的方面使這樣一種軟件成為可能。同時采用敏捷方法和SOA可以在如下方面獲益，敏捷方法天然地就適合應用在多變的環境中，通過不同的實踐可以有效地適應商業和技術需求的變化。SOA藉由基于服務的體系結構（Service-Based）將不同的業務分割為不同的服務，敏捷團隊可以依照這樣的業務劃分綜合其技術需求交付軟件。由于二者完美匹配的增量特性，適合企業可以迅速地改變業務和技術需求。
更好地控制實現過程中的風險
一種比較穩妥地實施SOA的策略是具有一個整體的愿景的同時小步伐漸進的交付，逐步將現有IT信息系統轉移到面向服務的架構。通過每一個小步驟的反饋，修正和調整愿景以更好地適應變化的商業環境，降低SOA實施的風險。而敏捷方法可以與這樣的SOA實施策略完美配合，通過迭代開發等最佳實踐，更好的控制SOA實現過程中的各種風險。
SOA通過服務將整個應用程序分解成可重用的系統單元，一個獨立的企業服務（Business Service）可能會服務于不同的應用，這也就意味著如果企業服務中存在錯誤，那么所有的應用中都可能存在潛在的質量缺陷。而敏捷方法恰恰是以能夠交付高質量的軟件而聞名，因此同時應用敏捷方法和SOA架構可以顯著地提高整個應用的質量。
應用SOA的公司往往能夠在敏捷方法中找到共同價值取向，敏捷方法也為成功實施SOA架構提供了更有利的保證。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
