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

早期，軟件開發(fā)并沒有特定的管理流程。隨后出現了瀑布開發(fā)流程Waterfall，它提出軟件開發(fā)活動可以用開發(fā)和構建應用所耗費的時間來定義。

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

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

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

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

最終，瀑布模型被認為對軟件開發(fā)是不利的而且違反人的直覺，因為通常直到開發(fā)流程的最后才能體現出項目的價值，這導致許多項目最終都以失敗告終。而且，在項目結束前客戶看不到任何可以工作的軟件。

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

敏捷價值觀

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

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

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

• 個體和互動 高于流程和工具
• 工作的軟件 高于詳盡的文檔
• 客戶合作 高于合同談判
• 響應變化 高于遵循計劃

這與瀑布流程死板的計劃風格相反。在敏捷流程中，客戶是開發(fā)團隊的一員，而不僅僅是在項目開始時參與項目需求的定義，在項目結束時驗收最終的產品?？蛻魩兔F隊完成驗收標準，并在整個過程中保持投入。另外，敏捷需要整個組織的變化和持續(xù)的改進。開發(fā)團隊和其他團隊一起合作，包括項目管理團隊和測試團隊。做什么和計劃什么時候做由指定的角色領導，并由整個團隊同意。

敏捷軟件開發(fā)

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

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

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

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

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

DevOps 價值觀

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

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

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

DevOps 軟件開發(fā)

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

當你想到自動化、云、微服務時，你會想到 DevOps。在一次訪談中，《加速構建和擴張高性能技術組織》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 這樣解釋到：

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

DevOps 和敏捷的對比

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

相似之處

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

不同之處

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

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

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

DevOps 更關注于削減成本，而敏捷則是精益和減少浪費的代名詞，側重于像敏捷項目會計和最小可行產品的概念。

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

總結

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

根據我作為一名敏捷專家的經驗，我發(fā)現對于組織和團隊從高層次上了解敏捷和 DevOps 是什么，以及它們如何幫助團隊更高效地工作，更快地交付高質量產品從而提高客戶滿意度非常有價值。

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