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

　　文章內(nèi)容如下：

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

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

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

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

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

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

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

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

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

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

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

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

　　不幸的是，在我做顧問和敏捷指導(dǎo)的職業(yè)生涯中，我經(jīng)常發(fā)現(xiàn)他們技術(shù)工藝水平遠(yuǎn)遠(yuǎn)達(dá)不到敏捷方法論的要求。這導(dǎo)致了在敏捷方法上出現(xiàn)了很多錯誤的認(rèn)識，抓不住敏捷方法的特征重點?；蛘?，對他們來說，敏捷方法的意義只之在于把來自于瀑布模型開發(fā)方法下出現(xiàn)的“軟件工程“這個詞給搞臭了。

　　我們是學(xué)習(xí)了前人的基礎(chǔ)上才發(fā)展成一個產(chǎn)業(yè)的。即使在過程上的革新也是要參考我們已經(jīng)知道的東西，吸收那些好的，摒棄那些不好的。像測試/行為驅(qū)動開發(fā)、持續(xù)集成、結(jié)對編程這樣的優(yōu)秀軟件工程實踐方法，如果我們視如不見，那我們其實是忘了我們最終的目的：開發(fā)出高質(zhì)量的軟件。

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