我們開發(fā)軟件的原因是為了滿足某些客戶、客戶、用戶或市場的需求。軟件工程的目標(biāo)是使開發(fā)具有可預(yù)測性和成本效益。

第一次關(guān)于軟件工程的IFIP會(huì)議至今已有50多年，在此期間，提出了許多不同的軟件工程方法、過程和模型，以幫助軟件開發(fā)人員實(shí)現(xiàn)可預(yù)測的、經(jīng)濟(jì)有效的過程。但50年后，我們似乎仍然看到我們經(jīng)常遇到的同樣類型的問題:延遲交付，不滿意的結(jié)果，以及整個(gè)項(xiàng)目的失敗。

以我多年前為之工作的一份政府合同為例。毫無疑問，這是我參與過的最成功的項(xiàng)目，至少從通常的項(xiàng)目管理度量的角度來看是這樣的:它提前完成了，在預(yù)算范圍內(nèi)完成了，并且在三天內(nèi)完成了一個(gè)計(jì)劃的長達(dá)一個(gè)月的驗(yàn)收測試。

這個(gè)項(xiàng)目是在一些不尋常的約束下運(yùn)作的:合同是以外幣計(jì)價(jià)和支付的，并且是絕對(duì)固定的固定價(jià)格，在合同中沒有任何變更管理過程。事實(shí)上，作為合同的一部分，驗(yàn)收測試被安排為一系列可觀察的、做這個(gè)和做這個(gè)的測試，這些測試可以被檢查，是或不是，幾乎沒有爭論的余地。根據(jù)合同條款，任何需求或外匯匯率變化的風(fēng)險(xiǎn)都由我公司承擔(dān)。

這個(gè)過程是絕對(duì)的，堅(jiān)定的，經(jīng)典的瀑布式的，并且我們滿懷信心地進(jìn)行這些步驟，直到最終的系統(tǒng)被完成，交付，驗(yàn)收測試被接受。

之后，我又花了18個(gè)月的時(shí)間修改這個(gè)系統(tǒng)，直到它真正滿足了客戶的需求。

在合同簽署和軟件交付之間的這一年，報(bào)告格式發(fā)生了變化，硬件平臺(tái)的一些組件被新的和更好的產(chǎn)品取代，系統(tǒng)必須對(duì)監(jiān)管方面的變化作出反應(yīng)。

需求變更。每個(gè)軟件工程項(xiàng)目在某些時(shí)候都會(huì)面臨這個(gè)困難的問題。

記住這一點(diǎn)，所有的軟件開發(fā)過程都可以看作是對(duì)這個(gè)基本事實(shí)的不同反應(yīng)。原始的(和幼稚的)瀑布過程簡單地假設(shè)您可以從要滿足的需求的堅(jiān)定聲明開始。

W.W. Royce被認(rèn)為是在他的論文“管理大型軟件系統(tǒng)的開發(fā)”中第一次觀察到這個(gè)瀑布，并且在數(shù)百篇軟件工程論文、教科書和文章中都可以看到他創(chuàng)建的圖表。但是在Royce的原始論文中經(jīng)常被忘記的是，他還說“(圖中的)實(shí)現(xiàn)是有風(fēng)險(xiǎn)的，會(huì)招致失敗?！?/span>

將流程與環(huán)境匹配

Royce的觀察是很好的——每個(gè)開發(fā)都要經(jīng)歷可識(shí)別的階段，從確定需求和提出的解決方案，到構(gòu)建軟件，然后測試它以確定它是否滿足這些需求。事實(shí)上，每個(gè)程序員都很熟悉這個(gè)，甚至在他們的第一次課堂作業(yè)中。但是，當(dāng)您的需求在項(xiàng)目持續(xù)期間發(fā)生變化時(shí)，您就可以保證，即使您完全滿足了最初的需求，您也無法滿足客戶。

對(duì)于這個(gè)問題，實(shí)際上只有一個(gè)答案:您需要找到一種方法，使需求-開發(fā)-交付周期與需求變化的速度相匹配。在我的政府項(xiàng)目中，我們是人為地這樣做的:沒有任何實(shí)質(zhì)性的變化，所以很容易按照規(guī)范和驗(yàn)收測試進(jìn)行構(gòu)建。

Royce的原始論文實(shí)際上認(rèn)識(shí)到了開發(fā)過程中的變化問題。他的論文描述了一個(gè)迭代模型，在這個(gè)模型中，意外的變化和無法實(shí)現(xiàn)的設(shè)計(jì)決策會(huì)在開發(fā)過程中得到反饋。

軟件開發(fā)的真實(shí)性

一旦我們接受了所有軟件開發(fā)中的核心不確定性，即需求永遠(yuǎn)不會(huì)隨著時(shí)間的推移保持不變，我們就可以開始以能夠應(yīng)對(duì)不可避免的變化的方式進(jìn)行開發(fā)。

首先要接受改變是不可避免的。

任何項(xiàng)目，無論計(jì)劃得有多好，都會(huì)導(dǎo)致至少與最初預(yù)想的有所不同的結(jié)果。開發(fā)過程必須接受這一點(diǎn)，并準(zhǔn)備好應(yīng)對(duì)它。

因此，軟件永遠(yuǎn)不會(huì)完成，只是被拋棄了。

我們喜歡創(chuàng)建一個(gè)特殊的、清晰定義的點(diǎn)，在此點(diǎn)上開發(fā)項(xiàng)目“完成”。然而，現(xiàn)實(shí)是，任何一個(gè)我們說“完成了”的固定時(shí)間只是人為的分界線。新特性、修訂的特性和錯(cuò)誤修復(fù)將在“完成”的產(chǎn)品交付時(shí)開始出現(xiàn)。(實(shí)際上，在軟件發(fā)布的那一刻，仍然會(huì)有需要的變更，代表技術(shù)債務(wù)和延期的需求。)只要軟件產(chǎn)品還在使用，這些變化就會(huì)繼續(xù)。

這意味著沒有一個(gè)軟件產(chǎn)品是完全令人滿意的。真正的軟件開發(fā)就像射擊一個(gè)移動(dòng)的目標(biāo)——所有的目標(biāo)、目標(biāo)的運(yùn)動(dòng)、風(fēng)和振動(dòng)的各種隨機(jī)變化都確保你可能接近準(zhǔn)確的靶心，但你永遠(yuǎn)不會(huì)達(dá)到完美。

使我們的流程適應(yīng)環(huán)境

從這個(gè)角度來看，軟件開發(fā)似乎是相當(dāng)令人沮喪的，甚至是令人沮喪的。聽起來好像我們在說，可預(yù)測的、成本效益高的發(fā)展的整個(gè)概念是在追逐一個(gè)不可能實(shí)現(xiàn)的夢想。

它不是。只要我們牢記現(xiàn)實(shí)，我們就可以成為非常有效的開發(fā)者。

第一個(gè)現(xiàn)實(shí)是，完美是不可能的，務(wù)實(shí)的成功是很可能的。精益創(chuàng)業(yè)運(yùn)動(dòng)使得MVP——“最小可行產(chǎn)品”——成為創(chuàng)業(yè)公司通常的目標(biāo)。我們需要將這個(gè)想法擴(kuò)展到所有的開發(fā)中，并認(rèn)識(shí)到每個(gè)產(chǎn)品都是真正的mvp——我們對(duì)當(dāng)前理解問題的最佳近似解決方案。

第二個(gè)現(xiàn)實(shí)是我們不能真正停止需求的變化，所以我們需要處理這些變化。這在實(shí)際的軟件開發(fā)中已經(jīng)理解了很長一段時(shí)間——parnas識(shí)別模塊的規(guī)則是構(gòu)建模塊來隱藏可能發(fā)生變化的需求。與此同時(shí)，人們一再嘗試描述期望提供連續(xù)近似的軟件開發(fā)過程——增量開發(fā)過程(我稱之為“一次性和未來方法學(xué)”)。

一旦我們接受了增量開發(fā)的必要性，一旦我們從完成完美解決方案的概念中解放出來，我們就可以坦然地接受變更。

第三個(gè)也是最后一個(gè)事實(shí)是，所有的時(shí)間表都是有時(shí)間限制的時(shí)間表。當(dāng)我們進(jìn)入一個(gè)開發(fā)項(xiàng)目時(shí)，我們無法確切地說出最終的產(chǎn)品是什么。因此，早期預(yù)測的完成時(shí)間是不準(zhǔn)確的，所有最終交付都將是部分交付。

敏捷開發(fā)可以解決這個(gè)問題

敏捷宣言就是基于對(duì)這些事實(shí)的認(rèn)識(shí)而產(chǎn)生的。定期交付可工作的軟件是這種認(rèn)識(shí)的一部分:一個(gè)真正敏捷的項(xiàng)目有定期工作的部分實(shí)現(xiàn)。與最終客戶的密切關(guān)系確保當(dāng)需求變化變得明顯時(shí)，它們可以適應(yīng)工作計(jì)劃。

在一個(gè)敏捷項(xiàng)目中，理想情況下，在項(xiàng)目的早期就有一個(gè)工作的部分實(shí)現(xiàn)，并且從一開始就朝著一個(gè)令人滿意的產(chǎn)品取得了可觀的進(jìn)展。再想想射擊的比喻——當(dāng)我們前進(jìn)時(shí)，我們越來越接近中心環(huán)，也就是靶心。我們可以確信，當(dāng)時(shí)間到了，產(chǎn)品至少會(huì)接近目標(biāo)。