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

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

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

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

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

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

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

需求變更。每個軟件工程項目在某些時候都會面臨這個困難的問題。

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

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

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

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

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

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

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

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

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

任何項目，無論計劃得有多好，都會導致至少與最初預想的有所不同的結果。開發(fā)過程必須接受這一點，并準備好應對它。

因此，軟件永遠不會完成，只是被拋棄了。

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

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

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

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

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

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

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

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

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

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

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

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