在進(jìn)行軟件開發(fā)項目之前最關(guān)鍵的決定是決定具體的管理方法。然而，由于關(guān)于當(dāng)今可用的兩種主要開發(fā)方法的激烈爭論：敏捷和瀑布，這并不是一個容易做出的決定。簡而言之，開發(fā)方法規(guī)定了如何為成功的項目規(guī)劃和開展軟件開發(fā)工作。

一方面，有傳統(tǒng)的軟件開發(fā)方法，瀑布式，從構(gòu)思到生產(chǎn)，項目是通過幾個事件線性處理的。另一方面，您擁有現(xiàn)代敏捷方法，涉及多功能、迭代、以團(tuán)隊為中心的開發(fā)。雖然這兩種開發(fā)方法都致力于幫助簡化管理軟件開發(fā)任務(wù)的過程，但它們的工作方式完全不同。在下面了解有關(guān)敏捷和瀑布的更多信息，包括每種方法的歷史和優(yōu)缺點。

歷史

自 70 年代引入以來，瀑布方法在最長的時間內(nèi)一直是主要或領(lǐng)先的軟件開發(fā)方法。當(dāng)時，項目經(jīng)理使用 Waterfall 作為一種為軟件開發(fā)帶來更有條理的結(jié)構(gòu)的方式。

與此同時，幾十年后的 2001 年，作為解決與瀑布相關(guān)的一些限制的一種方式，敏捷誕生了。這些限制主要是基于 Waterfall 過于強(qiáng)調(diào)文檔和計劃階段，而不是軟件交付這一事實。此外，在開發(fā)過程中回過頭來做出必要的改變也太難了。

隨著整個軟件行業(yè)的不斷發(fā)展，很明顯 Waterfall 不再能夠滿足所有企業(yè)的需要和要求。

讓我們更詳細(xì)地了解這兩種開發(fā)方法。

瀑布模型

瀑布模型被視為傳統(tǒng)的軟件開發(fā)策略，其中項目被劃分為必須按順序完成的獨特階段或事件。通過這種非迭代設(shè)計過程，軟件在線性通過所有階段后才能發(fā)布。

正如術(shù)語“瀑布”所暗示的那樣，開發(fā)人員必須一次在一個階段上工作，然后才能進(jìn)入下一階段。在 Waterfall 實現(xiàn)中，您被禁止返回上一步，因為您只能向下游移動。因此，回到早期階段的唯一方法是先完成整個開發(fā)周期。

瀑布模型的階段

每個組織通常都有一組獨特的瀑布模型階段，但通常，該方法可能如下所示：

? 概念：概念是開發(fā)人員決定想法和他們希望創(chuàng)建的內(nèi)容的初始階段。它將演變成成本/收益分析，并以對整個項目的估算結(jié)束。

? 啟動：此啟動階段旨在收集和記錄項目所需的內(nèi)容，包括軟件和系統(tǒng)要求。那是在您根據(jù)目的、可交付成果和目標(biāo)擴(kuò)展任務(wù)范圍時雇用團(tuán)隊成員的時候。

? 分析：下一階段涉及進(jìn)行可行性分析測試，以創(chuàng)建更詳細(xì)的需求規(guī)范文檔。

? 設(shè)計：在設(shè)計階段，設(shè)計師開發(fā)故事板、模型和線框以幫助他們獲得項目的可視化表示。他們審查和評估需求，設(shè)定團(tuán)隊目標(biāo)，制定行動計劃，結(jié)果是清晰的軟件架構(gòu)。

? 編碼或構(gòu)建：核心軟件構(gòu)建工作從這里開始。此階段涉及軟件每個單獨部分的編碼工作。開發(fā)人員開始按照他們在早期階段達(dá)成一致的設(shè)計和流程來創(chuàng)建應(yīng)用程序。

? 測試：構(gòu)建的軟件經(jīng)過廣泛的測試以消除任何錯誤。此階段通常涉及額外的編碼，以解決軟件源代碼中的任何問題。它還將包括 UAT 測試，最終用戶在發(fā)布前審查應(yīng)用程序。

? 實施：最終產(chǎn)品最終投放市場供消費者使用。

? 維護(hù)：沒有完美的應(yīng)用程序，用戶在使用新軟件時可能會遇到錯誤。開發(fā)人員必須創(chuàng)建一個適當(dāng)?shù)闹С纸Y(jié)構(gòu)，以解決任何出現(xiàn)的補(bǔ)丁和錯誤修復(fù)問題。這些補(bǔ)丁甚至可以用于添加新功能以保持競爭力。

現(xiàn)在，讓我們考慮使用這種軟件開發(fā)方法的一些優(yōu)點和缺點。

瀑布的好處

? 更有紀(jì)律的設(shè)計：由于每個階段都有明確的起點和終點審查，開發(fā)人員必須完成每個階段的所有任務(wù)，項目才能繼續(xù)進(jìn)行。

? 明確定義的截止日期：瀑布模型的靜態(tài)特性和可預(yù)測的工作流使得設(shè)置明確定義的截止日期、估算成本和創(chuàng)建時間表變得更加容易。

? 有據(jù)可查的方法：許多組織更喜歡使用 Waterfall，因為它需要為每個開發(fā)階段提供大量文檔。這使得評估過去項目背后的邏輯以及為未來的軟件開發(fā)項目奠定基礎(chǔ)變得容易。

? 清晰的溝通：充分記錄的性質(zhì)和可預(yù)測的開發(fā)階段允許開發(fā)人員向利益相關(guān)者、客戶或高層管理人員提供進(jìn)度報告。

? 更輕松的學(xué)習(xí)曲線：由于瀑布模型是大多數(shù)行業(yè)管理項目的傳統(tǒng)方法；大多數(shù)團(tuán)隊不需要預(yù)先培訓(xùn)或知識就可以使用此策略啟動項目。此外，由于客戶和開發(fā)商在早期就項目細(xì)節(jié)達(dá)成一致，因此設(shè)計和規(guī)劃更加直接。

瀑布的缺點

? 過早收集項目需求可能風(fēng)險很大：現(xiàn)實情況是，客戶和其他利益相關(guān)者通常在花時間研究原型之前不確定他們想要什么。由于瀑布方法涉及預(yù)先處理所有需求，因此存在獲取錯誤數(shù)據(jù)的相當(dāng)大的風(fēng)險，這將在開發(fā)階段的后續(xù)階段引起許多令人頭疼的問題。

? 進(jìn)行更改的成本非常高：瀑布方法的剛性的主要缺點是處理更改的能力受到嚴(yán)重阻礙。測試在軟件的生命周期中進(jìn)行得太晚了，這意味著如果用戶不喜歡您正在構(gòu)建的應(yīng)用程序，那么進(jìn)行更改和調(diào)整可能會很晚。

? 項目交付時間延長：開發(fā)人員在開始編碼之前必須完成幾個開發(fā)階段。這意味著客戶和利益相關(guān)者要到項目生命周期的后期才能看到原型或工作成果。

? 忽視測試的傾向：一旦項目快要完成就進(jìn)行所有廣泛的測試是相當(dāng)冒險的，因為誘惑或倉促通過它，尤其是在緊迫的期限內(nèi)工作時。現(xiàn)實情況是，測試不當(dāng)?shù)漠a(chǎn)品可能會導(dǎo)致災(zāi)難性的發(fā)布，開發(fā)人員也會失去他們本可以在項目早期階段使用的寶貴數(shù)據(jù)和反饋。

 敏捷模型

敏捷提供了一種更靈活、迭代更短、周期更短的方法，而不是使用一個漫長而連續(xù)的軟件開發(fā)過程。使用敏捷，重點是精益開發(fā)和在特定持續(xù)時間內(nèi)創(chuàng)建 MVP 或最小可行產(chǎn)品，同時在每次新軟件迭代中進(jìn)行改進(jìn)。

盡管您仍然會發(fā)現(xiàn)類似的軟件開發(fā)，如計劃、設(shè)計和編碼，但在這兩種方法中，這些步驟在敏捷中是逐步發(fā)生的，而不是在瀑布中一次執(zhí)行。團(tuán)隊合作、持續(xù)改進(jìn)、持續(xù)反饋以及適應(yīng)不斷變化的項目需求的能力在敏捷方法中都是至關(guān)重要的。值得注意的是，敏捷指的是所有遵循 2001 年創(chuàng)建的敏捷宣言中提出的意識形態(tài)的方法。

言鼎科技