導讀：本文是從《What Happened to Software Engineering?》這篇文章翻譯而來。譯文來自外刊IT評論《軟件工程的變遷》。

　　文章內容如下：

　　在過去的幾年里，在世界范圍內，軟件開發方法發生了一些變化。還不是很久以前，最主要的軟件開發生命周期(SDLC)方法論是瀑布模型方法(Waterfall Method)，它使用非常明確的階段把開發過程分割成諸如設計、測試等工程步驟。軟件開發行業，目前還是一種新興的行業，人們正在努力尋找一種可以重復的、可預知的軟件開發過程方法。

　　對于軟件開發過程，最好的參考模型看起來應該是物理學工程，就像土木建造工程。諸如詳細需求說明書、設計說明書以及技術說明書的等材料應該早在任何程序代碼編寫前就開始動工編寫和完成，就跟修橋、蓋大樓、修路、修大壩等物理建筑修建過程一樣。

　　為了更好的向這種物理學工程靠攏，諸如“軟件工程師”和“軟件架構師”等工作職位也開始在軟件開發中被接受。

　　這種風格的工程管理在建筑工程中使用的非常成功。然而在軟件工程中卻出現了大量的失敗，還有更多的項目最終嚴重超出預算或工期延誤。導致這種現象的因素很多，但最主要的一個因素應該是軟件和硬件上變化的速度和業務需求上變化的速度。軟件行業里的這種變化—做個比喻—就像是每18個月一款新型的汽車的出產都需要你對道路進行全面的重新設計。

　　當一個土木工程師去修建一座跨河大橋來連接河兩邊的道路時，工程師會非常清楚的知道道路跨河的精確地理坐標位置。行駛的車輛在數年里也不會發生重大的改變。橋梁工程師只需要按照之前已經被上千次的驗證過的建筑工藝把河兩邊的路連接到一起。

　　對于軟件系統，因為技術或業務發生了變化，在建設過程中(在所有需求和設計文檔完全完成后)需求需要做重大修改的情況并不罕見。如果把這種情況放到修橋的事情上，相當于當橋的地基打好后，再把橋的搭建位置往河的下游移6公里。

　　為了面對出現的這些問題，軟件工程師開發出了很多新的技術和實踐方法來重新定義軟件建設開發過程步驟，以此來提高軟件的質量、代碼重用率和生產率。有一些新的的實踐方法對代碼規范、命名規則進行了定義(和強制要求)，鼓勵使用那些經過驗證過的軟件設計模式，鼓勵使用諸如單元測試框架等工具和驅動測試開發(TDD)等技術方法，鼓勵采納行為驅動開發(BDD)、持續集成、結對編程等實踐方法。這些技術有效的減少了問題的出現，改進了建設開發過程，成為了公認的軟件工程做好的實踐方法。

　　當對開發過程階段的實踐方法有了改進發展后，針對項目過程中其它階段—諸如需求定義、系統設計、質量管控、測試等—的研究改進也相繼出現。它們包括Scrum，極限編程，Kanban(Lean制造工藝的一種修訂)…

　　這種針對開發上的變遷現在被人們歸結為敏捷方法論(Agile Methodologies)。事實上，大部分用來改進軟件開發的實踐方法，例如TDD，持續集成等，都是沿著改進開發過程的思路發展起來的，它們后來都被統稱為敏捷方法。

　　如今，敏捷方法論正迅速的從邊緣角色發展向主流技術，甚至滲透到了很多大公司的軟件開發團隊里。敏捷革命給軟件行業帶來了巨大的變化，很多在使用老的瀑布模型軟件開發方法時程序員會面對的問題，現在都被凸顯出來。

　　各種的會議，開發論壇，課程都起來討論如何更好的使用敏捷方法，人們都關注于像“如何最好的管理backlog，重構，spring計劃，以及其他過程問題“的論題——這些都是極其重要的、需要被那些打算采用敏捷方法的開發團隊認真理解、正確使用的概念。

　　所有敏捷運動留下來的產物都是用于創造高質量軟件的工藝實踐方法。大多數敏捷方法論主要針對的是過程管理問題，不涉及到其中的開發技術(Kent Benk 和 極限編程是例外)。這是敏捷方法論假設的一個前提：你已經很好的掌握了編程技術！

　　不幸的是，在我做顧問和敏捷指導的職業生涯中，我經常發現他們技術工藝水平遠遠達不到敏捷方法論的要求。這導致了在敏捷方法上出現了很多錯誤的認識，抓不住敏捷方法的特征重點。或者，對他們來說，敏捷方法的意義只之在于把來自于瀑布模型開發方法下出現的“軟件工程“這個詞給搞臭了。

　　我們是學習了前人的基礎上才發展成一個產業的。即使在過程上的革新也是要參考我們已經知道的東西，吸收那些好的，摒棄那些不好的。像測試/行為驅動開發、持續集成、結對編程這樣的優秀軟件工程實踐方法，如果我們視如不見，那我們其實是忘了我們最終的目的：開發出高質量的軟件。

　　其它類型的過程管理方法跟敏捷方法一樣，它們對實現我們最終的目標有著同樣重要的意義，所以，不要倒洗澡水時把孩子也潑了出去。我現在有很多的頭銜，包括演講家，敏捷教練，作家。而本質上，我是一個軟件工程師。而我為此自豪。