每個企業都應根據自己的優先事項和發展項目決定組織公司內部的工作流程。我的目標是告訴您現有的方法類型以及您可以獲得的結果。我收集了不同案例和不同公司使用的最著名的軟件開發方法。他們都有自己的優點和缺點。但看板沒有列入這個名單，因為我已經寫了很多有關它之前。

以下是前6種方法的列表：

1. 敏捷

2. 瀑布

3. Scrum

4. 極限編程

5. 快速應用程序開發方法

6. 螺旋

敏捷

敏捷軟件開發是承擔軟件工程項目的概念框架。有許多像Scrum這樣的敏捷軟件開發方法論（我們將在本文中更多地介紹它），Crystal方法和動態系統開發模型。

敏捷方法的主要目標是通過在短時間內開發軟件來降低風險，稱為迭代，通常會持續一到四周。每個時間盒就像一個迷你軟件項目，包括發布新增功能的所有必要任務：

• 規劃，

• 需求分析，

• 設計，

• 編碼，

• 測試和

• 文檔。

迭代可能不會增加足夠的功能來保證發布產品，但是敏捷軟件項目打算在每次迭代結束時發布新軟件。在此迭代之后，團隊重新評估項目優先級。敏捷方法強調工作產品是進度的主要衡量標準。相對于其他方法，敏捷產生很少的書面文檔 – “實時”是更好的通信類型。大部分開發團隊成員（以及企業主）都位于附近，可以面對面溝通。

敏捷軟件開發方法學的主要原則：面對面會議，持續合作，早期和持續交付工作軟件，透明度。每當客戶端或內部發生意外或頻繁的變化時，該模型就成為經理和團隊領導者的最佳選擇。

優點

• 自適應方法對變化做出有利的回應

• 允許直接溝通以保持透明度

• 通過快速查找和修復缺陷并提前識別期望不匹配來提高質量

缺點

• 專注于使用軟件并缺乏文檔效率

• 結果不一致的機會不明確

瀑布

瀑布模型是一種循序漸進的開發方法，其中開發被視為通過幾個階段穩步向下（如瀑布），通常：

• 分析

• 軟件需求說明軟件設計

• 軟件設計

• 測試

• 整合（如果有多個子系統）

• 部署（或安裝）

• 維護

該方法的線性和剛性特性使其易于理解和管理。所以對于經驗不足的經理和團隊來說，這是理想之選 在這種方法中，完成了不同的目標。在進入下一個階段之前，每個階段必須完成100％，不要回頭修改項目或方向。從理論上講，這個過程導致項目按時交付，因為每個階段都有詳細的計劃。它可以用于目標明確，需求穩定的項目。

但在實踐中，瀑布式開發通常不能達到預期，因為它不包含大多數項目所必需的不可避免的變化和修訂。當一個應用程序正處于測試階段時，很難回頭去改變在概念階段沒有想到的東西。

重點是一次性規劃，時間安排，目標日期，預算和整個系統的實施。在開始下一階段之前，通過大量書面文件，正式評審以及用戶的批準/簽收和大多數階段結束時發生的信息技術管理，在項目的整個生命周期內保持嚴密的控制。書面文件是每個階段的明確可交付成果。

盡管缺乏靈活性和過時的想法，但這種方法旨在擺脫不必要的文書工作，耗時的定期會議和積壓。因此，對于預先了解開發的所有方面的小型項目而言，這是一個很好的選擇，對于復雜項目來說這是一個不好的解決方案，因為它非常不靈活。

在您有明確要求和解決方案的情況下，您不需要定義流程來開發最終產品。您只需在完成項目時設定截止日期，并以您自己的方式完成項目。

優點

• 易于理解和功能

• 簡單到足以處理模型是僵化的

• 節省大量的時間

• 允許簡單的測試和分析

• 它允許部門化和管理控制

缺點

• 只匹配精確的需求

• 不適用于維護項目

• 不允許在測試階段進行編輯

• 無法知道項目的可能結果

• 對于長期和正在進行的項目來說不是很好

Scrum

Scrum是一個用于管理產品開發的迭代式和增量式敏捷軟件開發框架。它定義了一個靈活的整體產品開發策略，開發團隊作為一個單元實現共同目標。這種方法使團隊能夠通過鼓勵所有團隊成員的實際共同定位或緊密的在線協作以及所有團隊成員和所涉及的學科之間的日常面對面交流來自我組織。

Scrum的一個關鍵原則是雙重認識，即客戶會改變他們想要或需要的東西（需求波動）并且會改變他們的想法。Scrum采用基于證據的經驗方法 – 接受事先不能充分理解或定義的問題，而是集中關注如何最大限度地提高團隊的快速交付能力，響應新興需求，并適應不斷發展的技術和變化在市場條件下。

Scrum的主要特點：

• 積極進行優先工作

• 完成一系列短迭代或沖刺中的固定積壓項目

• 一個簡短的每日會議（“scrum”）來解釋進展情況，描述即將開展的工作和可能的障礙

• 一個簡短的計劃會話，其中將定義sprint的積壓項目

• 當所有團隊成員反思過去的沖刺時，一個簡短的心跳回顧

Scrum由Scrum master提供，它的主要工作是消除阻礙團隊實現沖刺目標的能力。Scrum的主人并不是團隊的領導者（因為他們是自組織的），而是團隊與任何不穩定影響之間的生產力緩沖區。

該方法鼓勵所有團隊成員以及項目涉及的所有學科進行口頭交流。

與看板不同，Scrum更具時間框架和計劃性。整個項目被分成稱為Sprints的時間框，并且所有團隊坐在一起并為每個Sprint計劃需要完成的任務列表或用戶故事列表。一旦團隊同意并承諾在給定的時間框架內完成某些任務，開發團隊應該堅持承諾并完成Sprint中的所有任務。

如果延遲成本很高，最后期限應盡可能延遲，Scrum最適合。當最終產品不清楚或者需求沒有得到客戶的正確反饋時，經常會使用Scrum。在這里，客戶參與整個過程，確定并關注需要完成的某些sprint產品待辦事項（與團隊一起）。Scrum取代了靈活的方法論，適合長期發展，并且頻繁更改需求。換句話說，它適用于需要300多個小時的開發項目。

與瀑布不同的是，Scrum模型采用更靈活的規則，可以適應最后時刻的變化。團隊合作，檢查和透明度是Scrum方法的關鍵因素。

結構：

• 產品積壓（一組允許盡快建立MVP的最高優先級任務）

• 沖刺積壓（包含開發人員將在2-4周后處理的高優先級功能）

• 沖刺本身

這種增長方法用于快速開發軟件，其中包括一系列迭代以生成所需軟件。它使有意推進的項目步入正軌。

優點

• 決策權掌握在團隊的手中

• 業務需求文檔被認為是不重要的

• 輕輕控制的方法empathizing與不斷更新

缺點

• 處理方法因成本波動而受損

• 不適合大型項目

• 需要高度專業的團隊，這對新手來說沒有任何地方

極限編程

極限編程方法（XP）指的是敏捷軟件工程方法論。它是為了避免開發目前不需要的功能而創建的。它旨在創造一流的最終產品，而不考慮需求的頻繁變化。這種方法的另一個目的是降低軟件必需品的成本。為了實現這一點，應用持續測試和計劃。

與其他方法相比，XP需要更多時間和人力資源。至于XP主要用于在非常不平衡的環境中制作軟件，并在建模過程中提供更好的易用性，這對于復雜的項目來說是完美的。如果您的客戶有最后期限來交付產品，但沒有清楚地了解其工作方式，并且風險更高，那么這是最佳選擇。XP技術的設立是為了解決和緩解風險并提高成功的可能性。

與瀑布方法不同的是，系統的需求被確定并且通常被“凍結”，XP意味著在項目后期階段改變需求的成本可能非常高。

極限編程核心實踐：

精細的反饋

• TDD（測試驅動開發）

• 計劃游戲

• 整個團隊

• 配對編程

連續的過程而不是批次

• 持續集成

• 設計改進

• 小版本

共同理解

• 簡單的設計

• 系統隱喻

• 集體代碼所有權

• 編碼標準或編碼慣例

程序員福利

• 可持續的步伐（即每周四十小時）

XP團隊應該在現場設立一個客戶，為團隊指定工作的優先次序，以及誰可以在問題出現時立即回答問題。

簡單的代碼更有可能工作。因此，極端的程序員只能編寫代碼來滿足當前項目中的實際需求。為了回顧XP程序員編寫的代碼，共享一個屏幕和鍵盤（這也改善了通信），以便在編寫代碼時對所有代碼進行審閱。

在極限編程中，測試是在編寫代碼之前編寫的。代碼在通過測試時被認為是完整的（但是之后需要重構以消除復雜性）。盡管人們認為XP只能在少于12人的小團隊中工作，但它已被成功應用于超過一百名開發人員的團隊。

優點

• 它著重于客戶參與

• 制定合理的計劃和時間表

• 開發人員特別致力于該項目

• 配備高質量軟件的現代化方法

缺點

• 有效性取決于涉及的人員

• 需要頻繁召開會議以提高總成本

• 需要過度的發展變化

• 確切的可能性和未來的結果真的是未知的

螺旋

螺旋方法擴展了瀑布模型，增加了快速原型，以結合自上而下和自下而上的概念。它在重點領域重點考慮迭代風險分析。它適合于大型復雜系統。對于大型，昂貴和復雜的項目，螺旋通常選擇瀑布方法。

螺旋生命周期模型是一個復雜的生命周期模型，重點在于及早識別和減少項目風險。一個螺旋型項目從小規模開始，探索風險，制定一個處理風險的計劃，然后決定是否采取下一步的項目（做下一輪迭代）。它源于不斷降低項目風險水平帶來的快速發展收益。成功使用螺旋生命周期模型取決于認真，細心和知識淵博的管理。

您可以在螺旋模型中找到以下步驟：

• 新的系統要求詳細定義

• 初步設計創建

• 初步設計構建了新系統的第一個原型

• 第二個原型使用四個步驟演變： – 第一個原型的評估; – 確定第二個原型的要求; – 計劃和設計第二個原型; – 構建并測試第二個原型

• 如果風險很大，項目可能會中止。風險因素可能涉及開發成本超支

• 現有原型的評估方式與之前的原型相同，如果需要，還可以從中開發另一個原型

• 重復前面的步驟直到客戶滿意

• 最終系統的構建（基于精制原型）

• 最終的系統經過徹底的評估和測試

• 日常維護是持續進行的，以防止大規模故障并最大限度地減少停機時間

重點在于風險評估以及通過將項目分解成更小的部分并在開發過程中提供更多的易變性來降低項目風險。開發者打算制定一個迭代螺旋的計劃。每個周期都涉及產品各個部分的相同步驟以及每個層次的細化。任何螺旋生命周期模型的完成都基于對項目的一致，細致和熟悉的管理。

優點

• 風險因素大大減少

• 非常適合大型和復雜的項目

• 稍后允許其他功能

• 適用于各種業務需求的高風險項目

缺點

• 昂貴的軟件開發模式

• 風險分析階段失敗可能會損害整個項目

• 不適合低風險項目

• 可能會繼續，永遠不會完成