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

自首屆IFIP軟件工程大會以來，已有50多年的歷史，當(dāng)時提出了許多不同的軟件工程方法，流程和模型來幫助軟件開發(fā)人員實現(xiàn)可預(yù)測且具有成本效益的流程。但是50年后，我們似乎仍然遇到同樣的問題：交貨延遲，結(jié)果不令人滿意以及項目完全失敗。

拿我?guī)啄昵肮ぷ鞯恼贤?。至少從通常的項目管理指?biāo)的角度來看，它無疑是我迄今為止最成功的項目：它提早完成，在預(yù)算內(nèi)完成，并且在三天內(nèi)完成了計劃的為期一個月的驗收測試。

該項目在一些非同尋常的約束下運行：合同以外幣計價和支付，并且絕對是固定的固定價格，而合同中根本沒有變更管理流程。實際上，作為合同的一部分，驗收測試是按照一系列可觀察的，該做此和此后進(jìn)行的測試進(jìn)行布置的，可以進(jìn)行檢查，是或否，幾乎沒有爭議。由于合同的規(guī)定，要求或匯率變化的所有風(fēng)險均由我公司承擔(dān)。

這個過程絕對是經(jīng)典瀑布，我們充滿信心地完成了所有步驟，直到最終系統(tǒng)完成，交付并通過了驗收測試。

之后，我又花了18個月的時間對系統(tǒng)進(jìn)行修改，直到它真正滿足客戶需求為止。 

在簽訂合同和交付軟件之間的中間一年中，報告格式發(fā)生了變化，硬件平臺的某些組件被新的更好的產(chǎn)品所取代，并對系統(tǒng)必須做出的法規(guī)更改進(jìn)行了更改。 

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

考慮到這一點，所有軟件開發(fā)過程都可以看作是對此基本事實的不同回應(yīng)。最初的（并且是幼稚的）瀑布式過程只是假設(shè)您可以首先確定要滿足的條件。

羅伊斯（WW Royce）在他的論文“管理大型軟件系統(tǒng)的開發(fā)”中首先觀察到瀑布，而數(shù)百個軟件工程論文，教科書和文章中的插圖都是他創(chuàng)建的圖表，這一點得到了公認(rèn)。但是，在Royce的原始論文中經(jīng)常忘記的是，他還說：“（在圖中）實現(xiàn)是有風(fēng)險的，并且會導(dǎo)致失敗?！?nbsp;

使您的過程與您的環(huán)境相匹配

羅伊斯（Royce）的觀察是一個很好的發(fā)現(xiàn)-從確定需求和提議的解決方案到構(gòu)建軟件，然后對其進(jìn)行測試以查看其是否滿足這些需求，這些開發(fā)都經(jīng)歷了可識別的階段。實際上，即使是在第一次課堂作業(yè)中，每個程序員都對此很熟悉。但是，當(dāng)您的需求在項目進(jìn)行過程中發(fā)生變化時，即使您完全滿足原始需求，也可以保證您無法滿足客戶的需求。

對此，實際上只有一個答案：您需要找到一種方法來使需求開發(fā)交付周期與需求變化的速率相匹配。在我的政府項目中，我們是人為地這樣做的：任何物質(zhì)都沒有變化，因此可以很容易地進(jìn)行規(guī)格和驗收測試。

羅伊斯（Royce）的原始論文實際上認(rèn)識到了開發(fā)過程中的變化問題。他的論文描述了一種迭代模型，其中在開發(fā)過程中反饋了無法解決的意外更改和設(shè)計決策。

軟件開發(fā)中的現(xiàn)實主義

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

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

任何項目，無論計劃多么周密，都會產(chǎn)生與最初設(shè)想的至少有些不同的結(jié)果。開發(fā)過程必須接受這一點，并準(zhǔn)備好應(yīng)對它。 

結(jié)果，軟件永遠(yuǎn)不會完成，只會被放棄。

我們喜歡在開發(fā)項目“完成”時提出明確的定義。但是現(xiàn)實是，我們所說的“完成”的任何固定時間僅僅是人為的分界線。新功能，修訂功能和錯誤修復(fù)將在“成品”交付時開始出現(xiàn)。（實際上，在軟件發(fā)布的那一刻，仍然需要進(jìn)行一些更改，包括技術(shù)債務(wù)和延期的要求。）只要使用軟件產(chǎn)品，這些更改就會繼續(xù)。

這意味著沒有軟件產(chǎn)品能夠完全令人滿意。真正的軟件開發(fā)就像在移動的目標(biāo)上射擊一樣—目標(biāo)，目標(biāo)的運動，風(fēng)和振動的各種隨機(jī)變化可確保即使您靠近精確的靶心，也永遠(yuǎn)無法達(dá)到完美。 

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

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

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

第一個現(xiàn)實是，盡管不可能做到完美，但務(wù)實的成功卻是可能的。精益創(chuàng)業(yè)運動使MVP（“最小可行產(chǎn)品”）成為了創(chuàng)業(yè)公司的通常目標(biāo)。我們需要將此思想擴(kuò)展到所有開發(fā)中，并認(rèn)識到每個產(chǎn)品實際上都是MVP，這是當(dāng)前對問題的理解的最佳解決方案。

第二個現(xiàn)實是，我們無法真正停止需求的變更，因此我們需要應(yīng)對變更。在實際的軟件開發(fā)中，人們已經(jīng)很早就了解了這一點-Parnas識別模塊的規(guī)則是構(gòu)建模塊以隱藏可更改的需求。同時，人們反復(fù)嘗試描述期望提供逐次逼近的軟件開發(fā)過程-增量開發(fā)過程（我稱之為“曾經(jīng)與未來的方法論”）。

一旦我們接受了增量開發(fā)的必要性，一旦將自己從完成完美解決方案的想法中解放出來，我們就可以從容地接受變化。

第三個也是最后一個現(xiàn)實是，所有日程表實際上都是帶時間限制的日程表。我們進(jìn)入一個開發(fā)項目，無法確切說明最終產(chǎn)品是什么。因此，無法對完成時間進(jìn)行早期預(yù)測，因此所有最終交付都將是部分交付。

敏捷發(fā)展來拯救

敏捷宣言源于對這些事實的認(rèn)識。定期交付工作軟件是這種認(rèn)可的一部分：一個真正敏捷的項目會定期進(jìn)行部分工作實施。與最終客戶的密切關(guān)系確保了隨著需求變化的顯現(xiàn)，它們可以適應(yīng)工作計劃。

理想情況下，在敏捷項目中，從項目的早期開始就有部分可行的實施方案，并且從一開始就朝著令人滿意的產(chǎn)品邁進(jìn)。再次考慮目標(biāo)射擊的隱喻-隨著我們的前進(jìn)，我們越來越靠近中心環(huán)，靶心。我們可以確信，隨著時間的推移，產(chǎn)品將至少接近目標(biāo)。