兩者之間的區別在于開發完畢之后發生的事情。

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

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

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

從瀑布流程過渡到敏捷開發

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

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

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

敏捷價值觀

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

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

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

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

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

敏捷軟件開發

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

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

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

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

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

DevOps 價值觀

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

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

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

DevOps 軟件開發

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

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

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

DevOps 和敏捷的對比

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

相似之處

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

不同之處

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

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

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

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

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

總結

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

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

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