敏捷開發與傳統方法的核心區別在于讓變更變得更友好。這不意味著你需要笑著迎接變更；它意味著期待變更，并且讓變更帶來的影響最小化。換句話說，你通過減少摩擦來贏得速度。這可解釋為更少的程式和相關的管理。
在瀑布模型你從業務需求分析開始，然后開發功能需求。隨后是功能需求被用于描述用例，用例由測試用例驗證和為最終用戶文檔化。軟件圍繞著高層設計來組織，然后由低層設計來細化和解析并轉換成代碼。這種階梯式的行進方式實際上是在避免變更：我們設想通過系統的、全面的方法可以完全防止變更發生的必要性。
敏捷方法在腦海中始終保持這種邏輯思維：斷言變更就是標準。軟件反映的就是用戶的需求，而用戶是在一個動態改變的組織中，處于一個充滿競爭的市場。因此，你永遠也不可能真正預知什么是需要的 – 你只能適應它。為了避免對相同功能的多個表達方式的變更，需求被歸納成為索引卡；功能需求和用例被分解成測試用例；而代碼則表達了設計的思想。
因此，通過減少大量的輸出，我們可以減少變更所需要的工作量。
提高速率
敏捷模型的另外一個響應變更的方法是通過更小的迭代。不僅僅是更短，而是更小。與其收集所有可能的需求然后分配到一系列的迭代周期中，我們專注于目前的迭代。規劃的周期越長，你就會越傾向于抵制變更：細化一個迭代周期只會帶來下一個迭代周期的代價，讓你脫離進度。
這個思想的背后是：用戶在直到看到真正的產品之前是不可能真正知道他們自己需要的是什么。需求文檔就像散文一樣可以用不同的方式解釋，但是代碼操作只有一種方式。我們往往發現：當軟件產品最終暴露在用戶面前時，才發現需求文檔充滿了錯漏和誤解。
因此，用戶能越快見到軟件，與軟件交互，你就越快知道軟件是否滿足他們的需求，即使不滿足需求，你需要改動的東西也會比較少。
擴大不確定性
對敏捷方法抵制，不管是公開的抨擊還是悄悄的害怕，都是由于敏捷論引入了不確定性。你不能預見下一個迭代，更不用說真正的發布，因為每一個迭代周期都可能包括新的功能或者對已有特性的調整。而如果你不能預見迭代的話，如何能計劃發布呢？
更重要的是，缺少正式的程式會增加不可預見的更改帶來影響的風險。如果缺少文檔，后續的開發人員不能很好地理解軟件的各個方面，以及如何運轉，將會增加犯錯誤的機會。而且缺少需求和用例，將來的測試人員會更容易漏測一些功能。
對于很多人來說，敏捷給人的感覺是把小心謹慎拋之“九霄云外”，一頭扎進混亂中去。畢竟，傳統的過程已經被認為是不必要的了 – 從課程上學到的。
擴大包括的范圍
盡管瀑布模型和類似的模型有存在的理由，但是其中的很多理由已經不再成立。早期使用計算機的目的是通過把手工過程加速來提高生產率，代碼被小心翼翼地通過圖表設計，并且從頭到尾手工構造出來。軟件開發可以 - 并且也確實是 – 花上幾年的時間來完成。
然而今天的軟件則專注于競爭 – 讓過程和產品不能被手工復制，通常通過快速地組裝各種組件和服務。不再是為了生產率，而是持續發展。整個市場形勢可能在一年中劇烈地改變，因此速度不僅僅是需要的，而是必要的。每人會關注一個在4月16號以后發布的稅務軟件，即使它是多么的優秀。
那么你如何彌補因為缺乏正式的程式和更短的周期規劃帶來的風險呢？把所有利益相關方包括進來。
與其使用文檔來與用戶、分析師、開發人員、測試人員和技術文檔編寫人員進行信息的交流 – 這些人中的每一位都負責進度表中自己的那一部分任務 – 敏捷方法要求即時的、直接的、面對面的交流。講和聽會比讀和寫花費更少的時間，通過討論要比通過編輯文檔更容易暴露不確定性。這樣，通過上下文來驅動進度，而不是通過其他方式。
但是這種方法的最顯著的影響莫過于不再是業務需要IT企業的發布日期，而是業務決定什么時候得到自己的需要。這種責任的轉移是關鍵的，因為IT企業不再負責“按期”發布，更需要防范變更。
這是管理層在考慮敏捷時經常遺漏的。經理們設想敏捷改變了IT操作方式，實際上，敏捷需要整個組織的改變。除非大家接受了這個新的模型中的角色和職責，敏捷開發只是一時的狂熱，承諾的比實際得到的少。
延伸閱讀
文章來源于領測軟件測試網 http://www.k11sc111.com/