兩者之間的區(qū)別在于開發(fā)完畢之后發(fā)生的事情。

早期，軟件開發(fā)并沒有特定的管理流程。隨后出現(xiàn)了瀑布開發(fā)流程Waterfall，它提出軟件開發(fā)活動(dòng)可以用開發(fā)和構(gòu)建應(yīng)用所耗費(fèi)的時(shí)間來定義。

那時(shí)候，由于在開發(fā)流程中沒有審查環(huán)節(jié)和權(quán)衡考慮，常常需要花費(fèi)很長的時(shí)間來開發(fā)、測試和部署軟件。交付的軟件也是帶有缺陷和 Bug 的質(zhì)量較差的軟件，而且交付時(shí)間也不滿足要求。那時(shí)候軟件項(xiàng)目管理的重點(diǎn)是長期而拖沓的計(jì)劃。

瀑布流程與三重約束模型triple constraint model相關(guān)，三重約束模型也稱為項(xiàng)目管理三角形project management triangle。三角形的每一個(gè)邊代表項(xiàng)目管理三要素的一個(gè)要素: 范圍、時(shí)間和成本。正如 Angelo Baretta 寫到，三重約束模型“認(rèn)為成本是時(shí)間和范圍的函數(shù)，這三個(gè)約束以一種確定的、可預(yù)測的方式相互作用。……如果我們想縮短時(shí)間表(時(shí)間)，就必須增加成本。如果我們想增加范圍，就必須增加成本或時(shí)間。”

從瀑布流程過渡到敏捷開發(fā)

瀑布流程來源于生產(chǎn)和工程領(lǐng)域，這些領(lǐng)域適合線性化的流程：正如房屋封頂之前需要先蓋好支撐墻。相似地，軟件開發(fā)問題被認(rèn)為可以通過提前做好計(jì)劃來解決。從頭到尾，開發(fā)流程均由路線圖清晰地定義，沿著路線圖就可以得到最終交付的產(chǎn)品。

最終，瀑布模型被認(rèn)為對(duì)軟件開發(fā)是不利的而且違反人的直覺，因?yàn)橥ǔＶ钡介_發(fā)流程的最后才能體現(xiàn)出項(xiàng)目的價(jià)值，這導(dǎo)致許多項(xiàng)目最終都以失敗告終。而且，在項(xiàng)目結(jié)束前客戶看不到任何可以工作的軟件。

敏捷Agile采用了一種不同的方法，它拋棄了規(guī)劃整個(gè)項(xiàng)目，承諾估計(jì)的時(shí)間點(diǎn)，簡單的遵循計(jì)劃。與瀑布流程相反，它假設(shè)和擁抱不確定性。它的理念是以響應(yīng)變化代替討論過去，它認(rèn)為變更是客戶需求的一部分。

敏捷價(jià)值觀

敏捷由敏捷宣言Agile Manifesto代言，敏捷宣言定義了 12 條原則(LCTT 譯注：此處沒有采用本文原本的簡略句式，而是摘錄了來自敏捷軟件開發(fā)宣言官方的中文譯本)：

1. 我們最重要的目標(biāo)，是通過持續(xù)不斷地及早交付有價(jià)值的軟件使客戶滿意。
2. 欣然面對(duì)需求變化，即使在開發(fā)后期也一樣。
3. 經(jīng)常交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。
4. 業(yè)務(wù)人員和開發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。
5. 激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。
6. 面對(duì)面溝通是傳遞信息的最佳的也是效率最高的方法。
7. 可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。
8. 敏捷流程倡導(dǎo)可持續(xù)的開發(fā)，責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。
9. 堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。
10. 以簡潔為本，它是極力減少不必要工作量的藝術(shù)。
11. 最好的架構(gòu)，需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)
12. 團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整自身的舉止表現(xiàn)。

敏捷的四個(gè)核心價(jià)值觀是(LCTT 譯注：此處譯文同樣來自敏捷軟件開發(fā)宣言官方)：

• 個(gè)體和互動(dòng) 高于流程和工具
• 工作的軟件 高于詳盡的文檔
• 客戶合作 高于合同談判
• 響應(yīng)變化 高于遵循計(jì)劃

這與瀑布流程死板的計(jì)劃風(fēng)格相反。在敏捷流程中，客戶是開發(fā)團(tuán)隊(duì)的一員，而不僅僅是在項(xiàng)目開始時(shí)參與項(xiàng)目需求的定義，在項(xiàng)目結(jié)束時(shí)驗(yàn)收最終的產(chǎn)品。客戶幫忙團(tuán)隊(duì)完成驗(yàn)收標(biāo)準(zhǔn)，并在整個(gè)過程中保持投入。另外，敏捷需要整個(gè)組織的變化和持續(xù)的改進(jìn)。開發(fā)團(tuán)隊(duì)和其他團(tuán)隊(duì)一起合作，包括項(xiàng)目管理團(tuán)隊(duì)和測試團(tuán)隊(duì)。做什么和計(jì)劃什么時(shí)候做由指定的角色領(lǐng)導(dǎo)，并由整個(gè)團(tuán)隊(duì)同意。

敏捷軟件開發(fā)

敏捷軟件開發(fā)需要自適應(yīng)的規(guī)劃、演進(jìn)式的開發(fā)和交付。許多軟件開發(fā)方法、框架和實(shí)踐遵從敏捷的理念，包括：

• Scrum
• 看板Kanban(可視化工作流)
• 極限編程Xtreme Programming(XP)
• 精益方法Lean
• DevOps
• 特性驅(qū)動(dòng)開發(fā)Feature-Driven Development(FDD)
• 測試驅(qū)動(dòng)開發(fā)Test-Driven Development(TDD)
• 水晶方法Crystal
• 動(dòng)態(tài)系統(tǒng)開發(fā)方法Dynamic Systems Development Method(DSDM)
• 自適應(yīng)軟件開發(fā)Adaptive Software Development(ASD)

所有這些已經(jīng)被單獨(dú)用于或一起用于開發(fā)和部署軟件。最常用的是 Scrum、看板(或 Scrumban)和 DevOps。

Scrum 是一個(gè)框架，采用該框架的團(tuán)隊(duì)通常由一個(gè) Scrum 教練、產(chǎn)品經(jīng)理和開發(fā)人員組成，該團(tuán)隊(duì)以跨職能、自主的工作方式運(yùn)作，能夠加快軟件交付速度從而給客戶帶來巨大的商業(yè)價(jià)值。其關(guān)注點(diǎn)是較小增量的快速迭代。

看板 是一個(gè)敏捷框架，有時(shí)也叫工作流管理系統(tǒng)，它能幫助團(tuán)隊(duì)可視化他們的工作從而最大化效率(因而變得敏捷)。看板通常由數(shù)字或物理展示板來呈現(xiàn)。團(tuán)隊(duì)的工作在展示板上隨著進(jìn)度而移動(dòng)，例如從未啟動(dòng)到進(jìn)行中，一直到測試中、已完成。看板使得每個(gè)團(tuán)隊(duì)成員可以隨時(shí)查看到所有工作的狀態(tài)。

DevOps 價(jià)值觀

DevOps 是一種文化，是一種思維狀態(tài)，是一種軟件開發(fā)的方式或者基礎(chǔ)設(shè)施的方式，也是一種構(gòu)建和部署軟件和應(yīng)用的方式。它假設(shè)開發(fā)和運(yùn)維之間沒有隔閡，他們一起合作，沒有矛盾。

DevOps 基于其它兩個(gè)領(lǐng)域的實(shí)踐: 精益和敏捷。DevOps 不是一個(gè)公司內(nèi)的崗位或角色;它是一個(gè)組織或團(tuán)隊(duì)對(duì)持續(xù)交付、持續(xù)部署和持續(xù)集成的堅(jiān)持不懈的追求。Gene Kim(Phoenix 項(xiàng)目和 Unicorn 項(xiàng)目的作者)認(rèn)為，有三種方式定義 DevOps 的理念：

• 第一種: 流程原則
• 第二種: 反饋原則
• 第三種: 持續(xù)學(xué)習(xí)原則

DevOps 軟件開發(fā)

DevOps 不會(huì)憑空產(chǎn)生;它是一種靈活的實(shí)踐，它的本質(zhì)是一種關(guān)于軟件開發(fā)和 IT 或基礎(chǔ)設(shè)施實(shí)施的共享文化和思維方式。

當(dāng)你想到自動(dòng)化、云、微服務(wù)時(shí)，你會(huì)想到 DevOps。在一次訪談中，《加速構(gòu)建和擴(kuò)張高性能技術(shù)組織》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 這樣解釋到：

• 軟件交付能力很重要，它極大地影響到組織的成果，例如利潤、市場份額、質(zhì)量、客戶滿意度以及組織戰(zhàn)略目標(biāo)的達(dá)成。
• 優(yōu)秀的團(tuán)隊(duì)能達(dá)到很高的交付量、穩(wěn)定性和質(zhì)量;他們并沒有為了獲得這些屬性而進(jìn)行取舍。
• 你可以通過實(shí)施精益、敏捷和 DevOps 中的實(shí)踐來提升能力。
• 實(shí)施這些實(shí)踐和能力也會(huì)影響你的組織文化，并且會(huì)進(jìn)一步對(duì)你的軟件交付能力和組織能力產(chǎn)生有益的提升。
• 懂得怎樣改進(jìn)能力需要做很多工作。

DevOps 和敏捷的對(duì)比

DevOps 和敏捷有相似性，但是它們不完全相同，一些人認(rèn)為 DevOps 比敏捷更好。為了避免造成混淆，深入地了解它們是很重要的。

相似之處

• 毫無疑問，兩者都是軟件開發(fā)技術(shù)。
• 敏捷已經(jīng)存在了 20 多年，DevOps 是最近才出現(xiàn)的。
• 兩者都追求軟件的快速開發(fā)，它們的理念都基于怎樣在不傷害客戶或運(yùn)維利益的情況下快速開發(fā)出軟件。

不同之處

兩者的差異在于軟件開發(fā)完成后發(fā)生的事情。

• 在 DevOps 和敏捷中，都有軟件開發(fā)、測試和部署的階段。然而，敏捷流程在這三個(gè)階段之后會(huì)終止。相反，DevOps 包括后續(xù)持續(xù)的運(yùn)維。因此，DevOps 會(huì)持續(xù)的監(jiān)控軟件運(yùn)行情況和進(jìn)行持續(xù)的開發(fā)。

敏捷中，不同的人負(fù)責(zé)軟件的開發(fā)、測試和部署。而 DevOps 工程角色負(fù)責(zé)所有活動(dòng)，開發(fā)即運(yùn)維，運(yùn)維即開發(fā)。

DevOps 更關(guān)注于削減成本，而敏捷則是精益和減少浪費(fèi)的代名詞，側(cè)重于像敏捷項(xiàng)目會(huì)計(jì)和最小可行產(chǎn)品的概念。

敏捷專注于并體現(xiàn)了經(jīng)驗(yàn)主義(適應(yīng)、透明和檢查)，而不是預(yù)測性措施。

總結(jié)

敏捷和 DevOps 是截然不同的，盡管它們的相似之處使人們認(rèn)為它們是相同的。這對(duì)敏捷和 DevOps 都是一種傷害。

根據(jù)我作為一名敏捷專家的經(jīng)驗(yàn)，我發(fā)現(xiàn)對(duì)于組織和團(tuán)隊(duì)從高層次上了解敏捷和 DevOps 是什么，以及它們?nèi)绾螏椭鷪F(tuán)隊(duì)更高效地工作，更快地交付高質(zhì)量產(chǎn)品從而提高客戶滿意度非常有價(jià)值。

敏捷和 DevOps 絕不是對(duì)抗性的(或至少?zèng)]有這個(gè)意圖)。在敏捷革命中，它們更像是盟友而不是敵人。敏捷和 DevOps 可以相互協(xié)作一致對(duì)外，因此可以在相同的場合共存。