(2022.06.08 Wed)
完整的軟件開發(fā)流程SDLC也被稱為瀑布式開發(fā)waterfall，該流程隨著場景的多樣化需求而不停進(jìn)化。本文介紹幾種常見的軟件開發(fā)流程方法論，以及各自擅長的場景奖蔓，包括

• 瀑布式開發(fā) waterfall
• 敏捷開發(fā) agile and scrum 和Devops
• 迭代遞增 iterative and incremental
• V型 V-shaped
• 螺旋型開發(fā) spiral
• 快速應(yīng)用開發(fā) Rapid Application Development, RAD

瀑布式開發(fā) waterfall

也稱線性順序開發(fā)模型linear sequential model或計(jì)劃驅(qū)動型開發(fā)，它是最常見和傳統(tǒng)的開發(fā)模式铁孵，嚴(yán)格遵循SDLC锭硼，逐步依次完成每一步進(jìn)程，

優(yōu)勢包括易于理解蜕劝，開發(fā)團(tuán)隊(duì)可以遵循清晰的開發(fā)流程檀头、便于管理。
劣勢包括

• 耗時(shí)過多：開發(fā)的各步驟按順序執(zhí)行岖沛，在前一步完成之前暑始，下一步無法開展
• 非自適應(yīng)：如果需求不明確則無法開展項(xiàng)目，客戶需要對需求有清晰的認(rèn)知和表述
• 不適合短期項(xiàng)目：不適合持續(xù)時(shí)間短的項(xiàng)目
• 缺乏靈活性：無法測試最小可用模型 MVP婴削，直到上線才可以

適用于目標(biāo)廊镜、需求、技術(shù)棧在開發(fā)周期中都相對穩(wěn)定唉俗、不會產(chǎn)生劇烈變化的情況嗤朴，適合于需要在開始前有清晰sign-offs、文檔和范圍餓大型項(xiàng)目虫溜。

敏捷開發(fā) agile and scrum 和DevOps

相較于有嚴(yán)格流程的waterfall雹姊，敏捷開發(fā)更加靈活和自適應(yīng)。它基于短促的開發(fā)流程(sprints)衡楞。與waterfall不同的是吱雏，開發(fā)團(tuán)隊(duì)不會花大量時(shí)間從頭開始建立一個(gè)完整的軟件產(chǎn)品，而是創(chuàng)建一個(gè)Minaimal Viable Product MVP最小可用產(chǎn)品瘾境，并逐步交付給客戶歧杏。

采用敏捷開發(fā)的項(xiàng)目會被分解為更小的增量builds。每個(gè)增量build對應(yīng)的周期被稱為sprints迷守。每個(gè)sprint持續(xù)時(shí)間大約2到4個(gè)星期犬绒。每個(gè)sprint之初，開發(fā)團(tuán)隊(duì)與客戶溝通明確該sprint的目標(biāo)兑凿，并進(jìn)行開發(fā)測試懂更。最終在sprint結(jié)束時(shí)交付于客戶眨业。

敏捷開發(fā)的常見變體包括scrum急膀，extreme編程和特征驅(qū)動開發(fā)沮协。

敏捷開發(fā)方式適合于需要持續(xù)更新的項(xiàng)目和產(chǎn)品，但管理成本和難度會相對提高卓嫂。

敏捷開發(fā)聚焦于：

• 增量改進(jìn)
• 用戶反饋
• 2到4周為周期的sprint
• 持續(xù)測試

敏捷開發(fā)的優(yōu)勢包括

• 自適應(yīng)：靈活慷暂，團(tuán)隊(duì)隨時(shí)根據(jù)需求調(diào)整工作
• 提高客戶滿意度：與客戶的溝通頻率提高，便于客戶在開發(fā)的每一步提供反饋
• 容易加新特性：每個(gè)開發(fā)周期為2到4周晨雳，加入新特性很方便

劣勢包括：

• 經(jīng)驗(yàn)要求高：需要團(tuán)隊(duì)成員或管理者有經(jīng)驗(yàn)
• 無文檔：關(guān)注軟件品質(zhì)勝過文檔
• 需要清晰：客戶需要清晰指出他們的預(yù)期行瑞，因?yàn)槊艚蓍_發(fā)沒有SDS文檔

敏捷開發(fā)適用于對產(chǎn)品做持續(xù)更新的動態(tài)團(tuán)隊(duì)。由于其以用戶為中心的屬性餐禁，敏捷開發(fā)被眾多初創(chuàng)公司青睞血久，技術(shù)公司測試新產(chǎn)品和對長期產(chǎn)品的持續(xù)更新也會應(yīng)用敏捷開發(fā)。由于使得快捷發(fā)布和收集用戶反饋?zhàn)兊萌菀装锓牵艚蓍_發(fā)允許公司快速推進(jìn)項(xiàng)目和測試氧吐，而免去了major release帶來的潛在風(fēng)險(xiǎn)。而且每次迭代后都要測試末盔，便于跟蹤bug和版本回滾筑舅。

敏捷開發(fā)不適用于預(yù)算和時(shí)間都緊張的團(tuán)隊(duì)。敏捷開發(fā)的靈活性意味著項(xiàng)目可能輕易超出最初的時(shí)間框架和預(yù)算陨舱，與現(xiàn)有架構(gòu)沖突翠拣，或由于管理失誤而進(jìn)展緩慢。此外采用敏捷開發(fā)需要對底層的過程有深入的了解游盲，需要團(tuán)隊(duì)有scrum大師以保證sprint和milestone都能夠達(dá)成误墓。

DevOps是敏捷開發(fā)的擴(kuò)展，它優(yōu)先了持續(xù)改進(jìn)與合作益缎。與其說DevOps是一種開發(fā)方法論不如說是一種組織文化谜慌，DevOps依賴于開發(fā)流程上不同團(tuán)隊(duì)之間的合作。

在傳統(tǒng)方法論中链峭，開發(fā)者傾向于使用單一工具完成一個(gè)任務(wù)并將其傳遞給流水線的下一人畦娄。而DevOps開發(fā)者常使用工具鏈-系列工具使得他們可以與項(xiàng)目的stakeholder持續(xù)溝通與合作。對于需要持續(xù)和盡快更新的項(xiàng)目弊仪，DevOps是一個(gè)好方法但是對于過程驅(qū)動型的公司和項(xiàng)目來說可能會有很多問題熙卡。

迭代遞增 iterative and incremental

針對waterfall開發(fā)的缺陷，迭代遞增方式應(yīng)運(yùn)而生励饵，該模型支持以循環(huán)迭代的方式進(jìn)行開發(fā)驳癌，介于waterfall和敏捷開發(fā)之間。在迭代遞增開發(fā)過程中役听，每次產(chǎn)品遞增都根據(jù)反饋對MVP也就是核心功能加入新的特性颓鲜。

迭代遞增開發(fā)模塊有不同的階段：

• 開端 Inception：這個(gè)階段明確需求和項(xiàng)目的范圍
• 思考 Elaboration：根據(jù)開端的需求設(shè)計(jì)產(chǎn)品架構(gòu)
• 建設(shè) Construction：開發(fā)團(tuán)隊(duì)根據(jù)產(chǎn)品架構(gòu)表窘，分析、設(shè)計(jì)甜滨、實(shí)現(xiàn)和測試代碼
• 轉(zhuǎn)譯 Transition：將產(chǎn)品推向生產(chǎn)環(huán)境

優(yōu)勢：

• 易于修改：軟件可以輕易適配新的需求
• 識別風(fēng)險(xiǎn)：開發(fā)在迭代中進(jìn)行乐严，風(fēng)險(xiǎn)也可以在早期識別和解決
• bug檢測：每次迭代中發(fā)現(xiàn)
• 易于管理：將項(xiàng)目分解為多個(gè)階段，使得創(chuàng)建衣摩、測試和管理軟件變得容易

劣勢：

• 完全理解：開發(fā)團(tuán)隊(duì)需要對產(chǎn)品有足夠了解并逐步建立產(chǎn)品

適用于有著清晰需求且不采用waterfall方法的團(tuán)隊(duì)昂验。

不適用于沒有長期未來技術(shù)規(guī)劃的團(tuán)隊(duì)。該方法需要詳細(xì)規(guī)劃和早期的架構(gòu)構(gòu)建艾扮，這意味著對于仍然測試user-case的小項(xiàng)目或正在尋找產(chǎn)品與市場結(jié)合點(diǎn)的團(tuán)隊(duì)并不理想既琴。

迭代遞增與敏捷開發(fā)的對比
遞增中的每次增量都構(gòu)建一個(gè)完整的feature。而迭代中每次構(gòu)建的是所有feature中的一小部分泡嘴。

敏捷開發(fā)結(jié)合了不同方法的不同方面甫恩。在敏捷開發(fā)的sprint中，構(gòu)建每個(gè)feature的一小部分酌予，每次只開發(fā)一個(gè)磺箕，并向其中逐步添加新功能和feature。

V型 V-shaped

V型對waterfall中QA部分做了擴(kuò)展霎终，強(qiáng)調(diào)測試并加強(qiáng)測試的比重滞磺。QA一步擴(kuò)展為unit testing，integration testing莱褒，system testing和acceptance testing击困。
適用于有嚴(yán)格范圍和明確、靜態(tài)需求的小項(xiàng)目广凸。

螺旋型開發(fā) Spiral

螺旋形開發(fā)結(jié)合了V型開發(fā)過程中的測試和迭代遞增方式中的風(fēng)險(xiǎn)評估阅茶。
一旦在某個(gè)迭代周期中計(jì)劃正常進(jìn)行，下一步就是做深度風(fēng)險(xiǎn)分析以識別出誤差和可能引起風(fēng)險(xiǎn)的領(lǐng)域谅海。比如脸哀，你想出了一個(gè)未經(jīng)客戶驗(yàn)證的feature特性想要加到產(chǎn)品中。比起將該feature直接加到milestone中扭吁，你可以先建立一個(gè)原型prototype交給用戶測試撞蜂，之后再將其移動到開發(fā)周期中。每個(gè)milestone完成之后侥袜，范圍像落選一樣進(jìn)一步擴(kuò)展蝌诡，根據(jù)計(jì)劃執(zhí)行開發(fā)并做下一次的風(fēng)險(xiǎn)評估。

適合于開發(fā)大型項(xiàng)目且厭倦風(fēng)險(xiǎn)的團(tuán)隊(duì)枫吧。該方法的核心是降低風(fēng)險(xiǎn)浦旱。如果從事大型或重要項(xiàng)目，在開發(fā)過程中對文檔和驗(yàn)證的要求較高九杂，采用該方法則合情合理颁湖。如果客戶對需求不能完全確認(rèn)宣蠕，并且期待在開發(fā)過程中有大幅修改，這個(gè)方法也適用甥捺。

不適合于大多數(shù)人抢蚀。盡管理論上聽上去新奇，螺旋形開發(fā)過程很少被付諸實(shí)踐涎永，因其高昂的時(shí)間成本思币。相反，該法更多應(yīng)用于對迭代法應(yīng)用于開發(fā)的批判性思考的舉例羡微。

快速應(yīng)用開發(fā) RAD

RAD的目標(biāo)是以最小代價(jià)得到產(chǎn)品最大化的品質(zhì)。RAD以用戶為中心惶我，并依賴于用戶在開發(fā)過程中提供的輸入妈倔。

RAD摒棄了嚴(yán)格的開發(fā)流程，以最快速度開發(fā)出功能性的產(chǎn)品原型绸贡，并不斷打磨直到可以部署到線上盯蝴。

RAD只適用于小型、時(shí)間敏感型項(xiàng)目和有經(jīng)驗(yàn)的團(tuán)隊(duì)听怕。