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

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

1. 敏捷

2. 瀑布

3. Scrum

4. 極限編程

5. 快速應用程序開發(fā)方法

6. 螺旋

敏捷

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

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

• 規(guī)劃，

• 需求分析，

• 設(shè)計，

• 編碼，

• 測試和

• 文檔。

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

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

優(yōu)點

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

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

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

缺點

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

• 結(jié)果不一致的機會不明確

瀑布

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

• 分析

• 軟件需求說明軟件設(shè)計

• 軟件設(shè)計

• 測試

• 整合（如果有多個子系統(tǒng)）

• 部署（或安裝）

• 維護

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

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

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

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

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

優(yōu)點

• 易于理解和功能

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

• 節(jié)省大量的時間

• 允許簡單的測試和分析

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

缺點

• 只匹配精確的需求

• 不適用于維護項目

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

• 無法知道項目的可能結(jié)果

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

Scrum

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

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

Scrum的主要特點：

• 積極進行優(yōu)先工作

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

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

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

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

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

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

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

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

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

結(jié)構(gòu)：

• 產(chǎn)品積壓（一組允許盡快建立MVP的最高優(yōu)先級任務）

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

• 沖刺本身

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

優(yōu)點

• 決策權(quán)掌握在團隊的手中

• 業(yè)務需求文檔被認為是不重要的

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

缺點

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

• 不適合大型項目

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

極限編程

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

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

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

極限編程核心實踐：

精細的反饋

• TDD（測試驅(qū)動開發(fā)）

• 計劃游戲

• 整個團隊

• 配對編程

連續(xù)的過程而不是批次

• 持續(xù)集成

• 設(shè)計改進

• 小版本

共同理解

• 簡單的設(shè)計

• 系統(tǒng)隱喻

• 集體代碼所有權(quán)

• 編碼標準或編碼慣例

程序員福利

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

XP團隊應該在現(xiàn)場設(shè)立一個客戶，為團隊指定工作的優(yōu)先次序，以及誰可以在問題出現(xiàn)時立即回答問題。

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

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

優(yōu)點

• 它著重于客戶參與

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

• 開發(fā)人員特別致力于該項目

• 配備高質(zhì)量軟件的現(xiàn)代化方法

缺點

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

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

• 需要過度的發(fā)展變化

• 確切的可能性和未來的結(jié)果真的是未知的

螺旋

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

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

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

• 新的系統(tǒng)要求詳細定義

• 初步設(shè)計創(chuàng)建

• 初步設(shè)計構(gòu)建了新系統(tǒng)的第一個原型

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

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

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

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

• 最終系統(tǒng)的構(gòu)建（基于精制原型）

• 最終的系統(tǒng)經(jīng)過徹底的評估和測試

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

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

優(yōu)點

• 風險因素大大減少

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

• 稍后允許其他功能

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

缺點

• 昂貴的軟件開發(fā)模式

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

• 不適合低風險項目

• 可能會繼續(xù)，永遠不會完成