瀑布式開發(fā)與敏捷式對比

敏捷式vs.瀑布式：都需要經(jīng)常，細(xì)致的交互

團(tuán)隊和利益相關(guān)者之間需要經(jīng)常并且細(xì)致的交互。建立互信，人們之間維持開放并且忠誠的關(guān)系非常重要。這樣的氛圍使得溝通更為有效，幫助大家構(gòu)建對于正確需求的一致理解。

對于我來說，價值比費用更重要。如果你知道哪一個需求最為重要，那么開發(fā)它所需的成本反而不那么要緊。對價值的理解也會激勵大家，幫助大家關(guān)注于持續(xù)選擇并開發(fā)正確的需求。

使用敏捷項目框架，比如scrum、XP、SAFe或者LeSS并不會自動保證項目的成功。需要以適合項目需求的方式使用這些框架。選擇合適的方式，在工作方法上達(dá)成一致。不用太擔(dān)心項目一開始時達(dá)不到完美，反思之類的活動會幫助大家持續(xù)學(xué)習(xí)并在過程中不斷改進(jìn)。 2100433B

需求階段通常定義系統(tǒng)的需求，明白系統(tǒng)的目標(biāo)。

設(shè)計階段通常確定系統(tǒng)使用什么數(shù)據(jù)庫，系統(tǒng)模塊的劃分，各個模塊的功能。

編碼階段用編程語言對設(shè)計階段的實現(xiàn)。

測試階段分黑盒測試，白盒測試。測試系統(tǒng)的功能是否實現(xiàn)，是否準(zhǔn)確。

維護(hù)階段是根據(jù)用戶新的需要重新修改系統(tǒng)，使系統(tǒng)更加穩(wěn)定，更符合用戶的要求。

需求階段的工作是否到位是整個系統(tǒng)開發(fā)的關(guān)鍵，在需求階段有很多方式可以幫助自己完成工作，例如與客戶暢所欲言，跟隨客戶參與業(yè)務(wù)過程等等。不管任何一種方法，任何一種方式，在需求階段首先確定系統(tǒng)邊界，確定組織邊界，然后摸清企業(yè)為消費者創(chuàng)造的價值，看清企業(yè)的價值鏈，摸清價值鏈上的實體。最后要平衡價值鏈上各個實體之間的利益，爭取系統(tǒng)做到大家都滿意這個理想的狀態(tài)。

瀑布模型式是最典型的預(yù)見性的方法，嚴(yán)格遵循預(yù)先計劃的需求、分析、設(shè)計、編碼、測試的步驟順序進(jìn)行。步驟成果作為衡量進(jìn)度的方法，例如需求規(guī)格，設(shè)計文檔，測試計劃和代碼審閱等等。

瀑布式的主要的問題是它的嚴(yán)格分級導(dǎo)致的自由度降低，項目早期即作出承諾導(dǎo)致對后期需求的變化難以調(diào)整，代價高昂。瀑布式方法在需求不明并且在項目進(jìn)行過程中可能變化的情況下基本是不可行的。

有論文統(tǒng)計他是造成70%軟件開發(fā)失敗的原因。

大體分為這幾個階段：需求分析、設(shè)計、編碼、測試、維護(hù)。

瀑布開發(fā)也有一些缺點，但是，在你初履新職，剛剛接手管理一個新的團(tuán)隊，同時獲得了一種支持瀑布開發(fā)模式的解決方案的情況下，這種開發(fā)模式可以令你很快進(jìn)入角色把工作開展起來，從而為將來采用更高級的開發(fā)方式做好了準(zhǔn)備。

瀑布開發(fā)過程在政府項目中特別受到歡迎，在這樣的軟件開發(fā)項目中，其規(guī)劃階段超出了大多數(shù)企業(yè)部署階段的時間和力度。采用這種方式的其他用戶包括那些理解比較全面和深入的軟件項目，相關(guān)的解決方案對團(tuán)隊而言非常熟悉，或者只需要小小的改動。

瀑布開發(fā)方式的缺點也是明顯的。如果期間的每一階段沒有得到堅決貫徹和實現(xiàn)，那么隱藏的問題最終會影響項目的成功。雖然瀑布管理方式對項目經(jīng)理而言非常方便，但是對開發(fā)人員而言就可能顯得太嚴(yán)酷了。因為測試過程在開發(fā)階段之后實施，子系統(tǒng)測試所暴露的問題可能需要立即修改代碼，這樣就顯著增加了計劃架構(gòu)的成本。

調(diào)試過程可能非常復(fù)雜，原因在于，開發(fā)人員在同一階段通常還可以從事其他項目的開發(fā)工作，而所需要的軟件修改可能會降低開發(fā)人員的生產(chǎn)率和工作質(zhì)量。有時工作區(qū)還必須集中到一個地方來，從而威脅到解決方案的完整性。

另一可能的危險是你只有到解決方案啟動的時候才能知道當(dāng)初所預(yù)計的是否成功，所以余下用來改正問題的時間和空間都非常有限。而設(shè)計工作上的疏漏和缺陷可能會嚴(yán)重地影響解決方案的啟動日期。

這種模式的另一問題在于，除了到階段終止之時，其他時候幾乎沒有獲取反饋的時間，還有，一旦開發(fā)工作開始啟動那么修改的空間也就沒有了。最后，假如系統(tǒng)測試表面功能或者性能沒有達(dá)到要求也許到這個時候已經(jīng)沒有糾正問題的可能了。

在部署瀑布開發(fā)模式之前你必須仔細(xì)評估自己所處的環(huán)境和條件。如果客戶希望在開發(fā)工作開始之后加入進(jìn)來或者你要處理很多未知的問題，那么你或許最好采用一種更具重復(fù)性的開發(fā)過程。2100433B

瀑布開發(fā)也被稱作系統(tǒng)開發(fā)生命期模式，簡稱SDLC（Systems Development Lifecycle Model），這是一種軟件開發(fā)途徑，它把項目分解為有限的階段。每一個階段都有序執(zhí)行，并且依賴于先前已完成的階段。在采用瀑布開發(fā)方法的情況下，開發(fā)工作的各個部分必須分別評估，而且通常由不同的開發(fā)隊伍來實施。具體開發(fā)階段的劃分存在一定的爭議，但各個階段基本上取決于任務(wù)相對繁重的預(yù)先規(guī)劃。以下就是瀑布開發(fā)過程的常見階段劃分：

問題評估—也就是概念形成階段。明確現(xiàn)有解決方案所存在的問題同時收集相關(guān)信息。

計劃解決方案—提出解決方案的詳細(xì)說明，包括軟件的優(yōu)點和缺點以及試圖解決的問題。確定開發(fā)時序，工作結(jié)構(gòu)分解以及其他支持文檔。最重要的是明確和分析軟件需求。

設(shè)計系統(tǒng)架構(gòu)—提案獲得接受之后即可創(chuàng)建解決方案模式，包括工作流和數(shù)據(jù)流圖、模塊和功能層次已經(jīng)其他由解決方案所需要的說明。在這一階段通?？偸前殡S一個有力度的檢查過程。

開發(fā)代碼—用以上階段創(chuàng)建的藍(lán)圖編寫、調(diào)試和單元測試軟件代碼。接著，集成系統(tǒng)的代碼和測試部分。最后測試整個系統(tǒng)。該階段要到測試完全通過才能結(jié)束。

部署和使用系統(tǒng)—部署最終功能，同時向用戶提供所需的培訓(xùn)和文檔。

維護(hù)解決方案—在必要的時候指出和升級軟件并且修補軟件錯誤。

有時測試會成為單獨的一個階段，其中包括軟件調(diào)試而不是在開發(fā)階段進(jìn)行代碼調(diào)試。此外，獲取軟件需求也可能成為獨立的階段。無論采取怎么樣的開發(fā)路線，以上過程都是一次實施的，同時還要整合到整個解決方案中來。