濟(jì)南軟件開發(fā)—軟件開發(fā)方法需要理論的支持
軟件方法學(xué)是一個(gè)特殊的領(lǐng)域。按原理它應(yīng)該是基于科學(xué)的工程學(xué)科，但目前的實(shí)踐中它卻時(shí)而像時(shí)裝業(yè)，時(shí)而又像搞政治。
時(shí)裝業(yè)每年都要有一種新潮流，在匆忙跟風(fēng)中，人們將好的和壞的一起拋棄。人們不是從自己的經(jīng)驗(yàn)中學(xué)習(xí)，而是跟著自認(rèn)為更好的走，因?yàn)槠渌硕颊f這樣更好。創(chuàng)新者們常常抱怨，大公司擁抱變化非常緩慢，但事實(shí)上并非如此，許多大公司非常渴望嘗試新事物。真正的問題在于，他們也會更快地放棄，還沒等認(rèn)真用起來呢，在過程和工具上的不菲投入就打水漂了。
在政治中，重點(diǎn)不是放在難題的切實(shí)解決，而是口號、宣傳和煽情。理念不是通過對利弊仔細(xì)的討論來提出，而是像品牌那樣進(jìn)行營銷，借助一些大師的一些金口玉言來傳播。每一種方法都試圖忽略自己的同類，如果不得不承認(rèn)它們的存在，通常也會惡意貶低，這弄得一線人員無所適從。
最終，很少有新思想能運(yùn)用在大規(guī)模的項(xiàng)目里，因此對大系統(tǒng)開發(fā)中的質(zhì)量、生產(chǎn)力和上市時(shí)間等等都沒有產(chǎn)生什么影響。過去四十年中軟件開發(fā)方法中出現(xiàn)的所有新概念里，只有少數(shù)大的創(chuàng)新——結(jié)構(gòu)化編程、對象技術(shù)、設(shè)計(jì)模式和UML等對行業(yè)產(chǎn)生了真正的影響。
這些都是不成熟的表現(xiàn)。我們的學(xué)科該長大了。
席卷業(yè)界的最新一波浪潮是“敏捷”。敏捷方法的確做出了許多貢獻(xiàn)，并使我們再次注意到人在軟件工程中的中心地位。一些敏捷的經(jīng)驗(yàn)很可能仍然會在未來的方法中繼續(xù)存在。與此同時(shí)，敏捷領(lǐng)域也為上面談到的現(xiàn)象提供了活例子。作為一個(gè)重視人甚于過程和工具的運(yùn)動，敏捷卻提出了許多被宣傳為“新的”過程和工具，而且沒有說清楚其中哪些是真正新的，哪些只是已有概念的重述。很多一線人員很自然地就被弄暈了。先不說這些“新”概念的價(jià)值如何，對它們的推廣方式就頗為引人注目：先是為這個(gè)方法精心編寫了一份基礎(chǔ)性文獻(xiàn)的—個(gè)宣言，更多的是第一人稱復(fù)數(shù)的情感訴求，而缺少事實(shí)依據(jù)。這種風(fēng)格對于吸引眼球可能有效，但隨著概念日益成熟，還是應(yīng)該采用更傳統(tǒng)闡釋形式。
在工程和科學(xué)中，一種新技術(shù)的提出者與任何人一樣都急于推廣自己的發(fā)明，但是也會很小心地確定應(yīng)用這項(xiàng)新技術(shù)在什么地方存在不足或者未經(jīng)證實(shí)。然而，很少有軟件方法學(xué)者會提供這樣的警示信息。太多人夸大了自己的方法與前人的差異。每一次變革（比如對象技術(shù)）中，有多少突破其實(shí)是已知概念的調(diào)整？逐漸改進(jìn)當(dāng)然沒有錯(cuò)，科學(xué)和工程中大量進(jìn)展都是如此實(shí)現(xiàn)的。但是，將每一次改進(jìn)都包裝成革命，就沒意思了。
我們目前軟件開發(fā)的方法，無論是商業(yè)還是公司內(nèi)部，新還是舊，需求已知還是不清，實(shí)際上都只是來自方法文獻(xiàn)中各種元素的組合，加上一些特定于領(lǐng)域或者業(yè)務(wù)的擴(kuò)展�；镜某煞质且粋�(gè)個(gè)實(shí)踐。
如果我們將這些基本成分從大雜燴中分離出來，大家就可以建立自己所需的方法。這種方法是以模塊的方式設(shè)計(jì)的，能夠在不斷總結(jié)經(jīng)驗(yàn)的基礎(chǔ)上快速演進(jìn)，響應(yīng)我們快速變化的行業(yè)的需求。
經(jīng)濟(jì)壓力是當(dāng)前的時(shí)代特征，與時(shí)裝業(yè)的跟風(fēng)和政治宣傳一樣都不會完全消失。但是，所有關(guān)注軟件工程價(jià)值的方法學(xué)者都理應(yīng)為學(xué)科找到存在的理由。
我們所缺乏的是作為一門科學(xué)和工程學(xué)的基礎(chǔ)：理論及其驗(yàn)證。我們應(yīng)該采取以下步驟，將軟件方法學(xué)轉(zhuǎn)變?yōu)橐环N嚴(yán)謹(jǐn)?shù)墓ぷ鳌?br /> 軟件開發(fā)是一種人的活動，但它也是由若干明確定義的步驟組成的，而且我們對這些步驟之間關(guān)系已經(jīng)有了充分認(rèn)識。至少，在有經(jīng)驗(yàn)的從業(yè)人員腦中，對這些概念的定義和理解都是不言自明的。但這還不夠，我們需要堅(jiān)實(shí)的軟件開發(fā)理論。形式化方法為我們提供了進(jìn)行建模的正確工具，含有約定構(gòu)造（contract）的面向?qū)ο笳Z言也可以實(shí)現(xiàn)同一目的。如果軟件開發(fā)的任務(wù)和限制沒有精確的、無歧義的模型，我們就無法顯著地進(jìn)行改善。模型應(yīng)該獨(dú)立于具體方法（只描述問題，而非解決方案）；模型應(yīng)該不僅包含定義和公理，而且還應(yīng)該包括描述所有系統(tǒng)和可行方法的定理——這恰恰是形式化模型經(jīng)常缺失的部分。
所有方法在被過度宣傳的差異之外，都有許多共同的屬性。而以理論作為基礎(chǔ)，我們將描述出任何有效的開發(fā)高質(zhì)量軟件的方法都應(yīng)該滿足的屬性。畢竟，它們都是用來開發(fā)軟件的，而且都承認(rèn)軟件開發(fā)中有一些東西總是需要。我們總是要寫代碼，用某種方式進(jìn)行測試，總是要考慮需求（無論要不要文檔），總是有backlog（無論顯式還是隱式），總是需要計(jì)劃。
我們需要找到軟件開發(fā)本質(zhì)的不能再簡化的內(nèi)核。例如，通過研究大約50種方法包括XP和Scrum，我們已經(jīng)找到了一個(gè)包含超過15個(gè)元素的內(nèi)核，其中的元素是我們總要做的事情或者總要生成的東西。
有了內(nèi)核之后，所有方法都可以進(jìn)行描述和比較。我們可以從所有廣泛使用和經(jīng)過驗(yàn)證的方法或者過程中采集隱含的實(shí)踐，比如架構(gòu)、組件、迭代等等。有些實(shí)踐是重疊的，比如用例驅(qū)動開發(fā)和特性驅(qū)動開發(fā)。有些是互相補(bǔ)充的，比如用例驅(qū)動開發(fā)和按約定設(shè)計(jì)。
內(nèi)核清除了方法之間表面存在的差異，比如不同方法中只是稱呼不同的相同事物。比如，RUP所說的迭代在Scrum中稱為sprint，但是它們基本上說的是一回事。通過這種清理，可以明顯地看出不同方法之間真正的差異。
因?yàn)閮?nèi)核對于任何具體的實(shí)踐都是中立的，我們可以簡單地分辨出不同實(shí)踐之間的實(shí)際區(qū)別，不是表面上的，而是深層次的。這將減少各種方法中包含的“宗教”成分。
