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

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

1. 敏捷

2. 瀑布

3. Scrum

4. 極限編程

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

6. 螺旋

敏捷

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

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

• 規(guī)劃，

• 需求分析，

• 設(shè)計(jì)，

• 編碼，

• 測(cè)試和

• 文檔。

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

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

優(yōu)點(diǎn)

• 自適應(yīng)方法對(duì)變化做出有利的回應(yīng)

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

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

缺點(diǎn)

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

• 結(jié)果不一致的機(jī)會(huì)不明確

瀑布

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

• 分析

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

• 軟件設(shè)計(jì)

• 測(cè)試

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

• 部署（或安裝）

• 維護(hù)

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

但在實(shí)踐中，瀑布式開發(fā)通常不能達(dá)到預(yù)期，因?yàn)樗话蠖鄶?shù)項(xiàng)目所必需的不可避免的變化和修訂。當(dāng)一個(gè)應(yīng)用程序正處于測(cè)試階段時(shí)，很難回頭去改變?cè)诟拍铍A段沒有想到的東西。

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

盡管缺乏靈活性和過時(shí)的想法，但這種方法旨在擺脫不必要的文書工作，耗時(shí)的定期會(huì)議和積壓。因此，對(duì)于預(yù)先了解開發(fā)的所有方面的小型項(xiàng)目而言，這是一個(gè)很好的選擇，對(duì)于復(fù)雜項(xiàng)目來說這是一個(gè)不好的解決方案，因?yàn)樗浅２混`活。

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

優(yōu)點(diǎn)

• 易于理解和功能

• 簡(jiǎn)單到足以處理模型是僵化的

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

• 允許簡(jiǎn)單的測(cè)試和分析

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

缺點(diǎn)

• 只匹配精確的需求

• 不適用于維護(hù)項(xiàng)目

• 不允許在測(cè)試階段進(jìn)行編輯

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

• 對(duì)于長(zhǎng)期和正在進(jìn)行的項(xiàng)目來說不是很好

Scrum

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

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

Scrum的主要特點(diǎn)：

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

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

• 一個(gè)簡(jiǎn)短的每日會(huì)議（“scrum”）來解釋進(jìn)展情況，描述即將開展的工作和可能的障礙

• 一個(gè)簡(jiǎn)短的計(jì)劃會(huì)話，其中將定義sprint的積壓項(xiàng)目

• 當(dāng)所有團(tuán)隊(duì)成員反思過去的沖刺時(shí)，一個(gè)簡(jiǎn)短的心跳回顧

Scrum由Scrum master提供，它的主要工作是消除阻礙團(tuán)隊(duì)實(shí)現(xiàn)沖刺目標(biāo)的能力。Scrum的主人并不是團(tuán)隊(duì)的領(lǐng)導(dǎo)者（因?yàn)樗麄兪亲越M織的），而是團(tuán)隊(duì)與任何不穩(wěn)定影響之間的生產(chǎn)力緩沖區(qū)。

該方法鼓勵(lì)所有團(tuán)隊(duì)成員以及項(xiàng)目涉及的所有學(xué)科進(jìn)行口頭交流。

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

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

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

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

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

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

• 沖刺本身

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

優(yōu)點(diǎn)

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

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

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

缺點(diǎn)

• 處理方法因成本波動(dòng)而受損

• 不適合大型項(xiàng)目

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

極限編程

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

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

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

極限編程核心實(shí)踐：

精細(xì)的反饋

• TDD（測(cè)試驅(qū)動(dòng)開發(fā)）

• 計(jì)劃游戲

• 整個(gè)團(tuán)隊(duì)

• 配對(duì)編程

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

• 持續(xù)集成

• 設(shè)計(jì)改進(jìn)

• 小版本

共同理解

• 簡(jiǎn)單的設(shè)計(jì)

• 系統(tǒng)隱喻

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

• 編碼標(biāo)準(zhǔn)或編碼慣例

程序員福利

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

XP團(tuán)隊(duì)?wèi)?yīng)該在現(xiàn)場(chǎng)設(shè)立一個(gè)客戶，為團(tuán)隊(duì)指定工作的優(yōu)先次序，以及誰可以在問題出現(xiàn)時(shí)立即回答問題。

簡(jiǎn)單的代碼更有可能工作。因此，極端的程序員只能編寫代碼來滿足當(dāng)前項(xiàng)目中的實(shí)際需求。為了回顧XP程序員編寫的代碼，共享一個(gè)屏幕和鍵盤（這也改善了通信），以便在編寫代碼時(shí)對(duì)所有代碼進(jìn)行審閱。

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

優(yōu)點(diǎn)

• 它著重于客戶參與

• 制定合理的計(jì)劃和時(shí)間表

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

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

缺點(diǎn)

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

• 需要頻繁召開會(huì)議以提高總成本

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

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

螺旋

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

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

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

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

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

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

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

• 如果風(fēng)險(xiǎn)很大，項(xiàng)目可能會(huì)中止。風(fēng)險(xiǎn)因素可能涉及開發(fā)成本超支

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

• 重復(fù)前面的步驟直到客戶滿意

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

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

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

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

優(yōu)點(diǎn)

• 風(fēng)險(xiǎn)因素大大減少

• 非常適合大型和復(fù)雜的項(xiàng)目

• 稍后允許其他功能

• 適用于各種業(yè)務(wù)需求的高風(fēng)險(xiǎn)項(xiàng)目

缺點(diǎn)

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

• 風(fēng)險(xiǎn)分析階段失敗可能會(huì)損害整個(gè)項(xiàng)目

• 不適合低風(fēng)險(xiǎn)項(xiàng)目

• 可能會(huì)繼續(xù)，永遠(yuǎn)不會(huì)完成