注：本文轉載自外刊IT評論
在過去的幾年裡，在世界範圍內，軟體開發方法發生了一些變化。還不是很久以前，最主要的軟體開發生命週期(SDLC)方法論是瀑布模型方法(Waterfall Method)，它使用非常明確的階段把開發過程分割成諸如設計、測試等工程步驟。軟體開發行業，目前還是一種新興的行業，人們正在努力尋找一種可以重複的、可預知的軟體開發過程方法。
對於軟體開發過程，最好的參考模型看起來應該是物理學工程，就像土木建造工程。諸如詳細需求說明書、設計說明書以及技術說明書的等材料應該早在任何程式程式碼編寫前就開始動工編寫和完成，就跟修橋、蓋大樓、修路、修大壩等物理建築修建過程一樣。
為了更好的向這種物理學工程靠攏，諸如“軟體工程師”和“軟體架構師”等工作職位也開始在軟體開發中被接受。
這種風格的工程管理在建築工程中使用的非常成功。然而在軟體工程中卻出現了大量的失敗，還有更多的專案最終嚴重超出預算或工期延誤。導致這種現象的因素很多，但最主要的一個因素應該是軟體和硬體上變化的速度和業務需求上變化的速度。軟體行業裡的這種變化—做個比喻—就像是每18個月一款新型的汽車的出產都需要你對道路進行全面的重新設計。
當一個土木工程師去修建一座跨河大橋來連線河兩邊的道路時，工程師會非常清楚的知道道路跨河的精確地理座標位置。行駛的車輛在數年裡也不會發生重大的改變。橋樑工程師只需要按照之前已經被上千次的驗證過的建築工藝把河兩邊的路連線到一起。
對於軟體系統，因為技術或業務發生了變化，在建設過程中(在所有需求和設計文件完全完成後)需求需要做重大修改的情況並不罕見。如果把這種情況放到修橋的事情上，相當於當橋的地基打好後，再把橋的搭建位置往河的下游移6公里。
為了面對出現的這些問題，軟體工程師開發出了很多新的技術和實踐方法來重新定義軟體建設開發過程步驟，以此來提高軟體的質量、程式碼重用率和生產率。有一些新的的實踐方法對程式碼規範、命名規則進行了定義(和強制要求)，鼓勵使用那些經過驗證過的軟體設計模式，鼓勵使用諸如單元測試框架等工具和驅動測試開發(TDD)等技術方法，鼓勵採納行為驅動開發(BDD)、持續整合、結對程式設計等實踐方法。這些技術有效的減少了問題的出現，改進了建設開發過程，成為了公認的軟體工程做好的實踐方法。
當對開發過程階段的實踐方法有了改進發展後，針對專案過程中其它階段—諸如需求定義、系統設計、質量管控、測試等—的研究改進也相繼出現。它們包括Scrum，極限程式設計，Kanban(Lean製造工藝的一種修訂)…
這種針對開發上的變遷現在被人們歸結為敏捷方法論(Agile Methodologies)。事實上，大部分用來改進軟體開發的實踐方法，例如TDD，持續整合等，都是沿著改進開發過程的思路發展起來的，它們後來都被統稱為敏捷方法。
如今，敏捷方法論正迅速的從邊緣角色發展向主流技術，甚至滲透到了很多大公司的軟體開發團隊裡。敏捷革命給軟體行業帶來了巨大的變化，很多在使用老的瀑布模型軟體開發方法時程式設計師會面對的問題，現在都被凸顯出來。
各種的會議，開發論壇，課程都起來討論如何更好的使用敏捷方法，人們都關注於像“如何最好的管理backlog，重構，spring計劃，以及其他過程問題“的論題——這些都是極其重要的、需要被那些打算採用敏捷方法的開發團隊認真理解、正確使用的概念。
所有敏捷運動留下來的產物都是用於創造高質量軟體的工藝實踐方法。大多數敏捷方法論主要針對的是過程管理問題，不涉及到其中的開發技術(Kent Benk 和 極限程式設計是例外)。這是敏捷方法論假設的一個前提：你已經很好的掌握了程式設計技術！
不幸的是，在我做顧問和敏捷指導的職業生涯中，我經常發現他們技術工藝水平遠遠達不到敏捷方法論的要求。這導致了在敏捷方法上出現了很多錯誤的認識，抓不住敏捷方法的特徵重點。或者，對他們來說，敏捷方法的意義只之在於把來自於瀑布模型開發方法下出現的“軟體工程“這個詞給搞臭了。
我們是學習了前人的基礎上才發展成一個產業的。即使在過程上的革新也是要參考我們已經知道的東西，吸收那些好的，摒棄那些不好的。像測試/行為驅動開發、持續整合、結對程式設計這樣的優秀軟體工程實踐方法，如果我們視如不見，那我們其實是忘了我們最終的目的：開發出高質量的軟體。
其它型別的過程管理方法跟敏捷方法一樣，它們對實現我們最終的目標有著同樣重要的意義，所以，不要倒洗澡水時把孩子也潑了出去。我現在有很多的頭銜，包括演講家，敏捷教練，作家。而本質上，我是一個軟體工程師。而我為此自豪。