更重要的是，缺少正式的程式會增加不可預見的更改帶來影響的風險。如果缺少文檔，后續的開發人員不能很好地理解軟件的各個方面，以及如何運轉，將會增加犯錯誤的機會。而且缺少需求和用例，將來的測試人員會更容易漏測一些功能。
對于很多人來說，敏捷給人的感覺是把小心謹慎拋之“九霄云外”，一頭扎進混亂中去。畢竟，傳統的過程已經被認為是不必要的了 – 從課程上學到的。
擴大包括的范圍
盡管瀑布模型和類似的模型有存在的理由，但是其中的很多理由已經不再成立。早期使用計算機的目的是通過把手工過程加速來提高生產率，代碼被小心翼翼地通過圖表設計，并且從頭到尾手工構造出來。軟件開發可以 - 并且也確實是 – 花上幾年的時間來完成。
然而今天的軟件則專注于競爭 – 讓過程和產品不能被手工復制，通常通過快速地組裝各種組件和服務。不再是為了生產率，而是持續發展。整個市場形勢可能在一年中劇烈地改變，因此速度不僅僅是需要的，而是必要的。每人會關注一個在4月16號以后發布的稅務軟件，即使它是多么的優秀。
那么你如何彌補因為缺乏正式的程式和更短的周期規劃帶來的風險呢？把所有利益相關方包括進來。
與其使用文檔來與用戶、分析師、開發人員、測試人員和技術文檔編寫人員進行信息的交流 – 這些人中的每一位都負責進度表中自己的那一部分任務 – 敏捷方法要求即時的、直接的、面對面的交流。講和聽會比讀和寫花費更少的時間，通過討論要比通過編輯文檔更容易暴露不確定性。這樣，通過上下文來驅動進度，而不是通過其他方式。
但是這種方法的最顯著的影響莫過于不再是業務需要IT企業的發布日期，而是業務決定什么時候得到自己的需要。這種責任的轉移是關鍵的，因為IT企業不再負責“按期”發布，更需要防范變更。
這是管理層在考慮敏捷時經常遺漏的。經理們設想敏捷改變了IT操作方式，實際上，敏捷需要整個組織的改變。除非大家接受了這個新的模型中的角色和職責，敏捷開發只是一時的狂熱，承諾的比實際得到的少。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
