多年前，當我們使用瀑布開發模式時，我們的開發流程如下：分析-設計-開發-測試-交付-運維。最終的交付只有一次，或者是有限的次數。瀑布開發模式的週期長，對於軟體產品的更新迭代困難度較高。因此在軟體工程中，結合精益軟體的思想，專家們提出了敏捷方法（scrum）。敏捷方法不再嚴苛要求環節，而是更注重開發人員與業務人員的溝通交流，不斷地完善產品。在敏捷方法中，軟體的交付是頻繁的、沒有上限的。交付不再是軟體工程生命週期的結束，而是持續不斷的完善過程中的一個必要環節。

        敏捷方法不是非常新的理論，Mike Beedle等人於2001年提出了敏捷軟體開發宣言，標誌著敏捷開發思想的面世。由於敏捷方法將交付環節變成一個頻繁的環節，模糊了交付與運維之間的關係。即運維-更新-交付之間的無限迴圈，運維不再是交付之後的步驟，沒有了明顯的順序關係。因此，隨著敏捷方法的提出，一個重要軟體工程概念形成了，那就是DevOps（Development和Operations的組合）。DevOps要解決的是傳統開發模式裡開發與運維的對立，或者說是各自的獨立性。因為在過去，開發人員與運維人員的互動是有限的，他們工作在不同的世界中。

       敏捷方法是DevOps的理論基礎，DevOps是敏捷方法的具體化和實踐原則。敏捷方法理論的兩個核心是：持續整合與持續交付。持續整合是指不同元件、不同團隊、不同平臺的之間的對接和整合。而持續交付則是上文所說的將交付變為頻繁、常態化的環節，在持續交付中實現對軟體產品的不斷完善和擴充套件。讓我們回想瀑布開發中軟體的交付前後所涉及到的幾個時間節點：測試-部署-交付，在敏捷方法中，頻繁的交付和部署要求將這幾個環節實現自動化。而不再是運維人員將其通過人工的方式，使用命令列將軟體部署到生產環境。自動化的部署要求，使得springboot框架應聲而出，讓我們回想springboot的目的，正是一種快發開發領域的解決方案。在資料庫方面，敏捷方法也推動了MongoDB等NoSql資料庫的發展，由於NoSql資料庫的半結構化特點，迴避了Sql資料庫在改動庫表結構方面的複雜性，使其在快速迭代和增量開發中十分好用。在專案構建方面，Grandle和Maven等工具減輕了專案的構建難度，使其成為敏捷開發中的重要實現手段。此外，由於持續交付對於軟體版本化的要求，Git因其在分支處理的優勢非常，從而也成為敏捷開發的重要工具。

       但是因為在敏捷方法剛被提出時，軟體的部署環境和網路制約了自動化的應用。不論是單機軟體，或者是基於C/S或者B/S結構的網路軟體，由於固定的軟體執行環境，例如單機程式，頻繁的交付很難實現；而對於企業級應用，私有的物理伺服器和封閉的執行環境讓持續整合和持續交付成為困難。而云的出現成為敏捷方法普及的助推力。

       雲提供了一種完全不同的思路。藉助網路的高速發展，雲讓軟體擺脫了私有物理伺服器，雲的彈性服務、資源池化、按需服務等特定讓DevOps變得更為輕鬆。例如，通過雲，只需要網路即可實現軟體的部署。而云軟體服務（SaaS）則讓使用者共享軟體的更新，讓每一次軟體迭代輕鬆傳達到所有使用者。

        藉助雲的優勢，持續整合的各個元件可以跨語言、跨平臺開發與部署，這就推動了微服務概念的提出。微服務的發展讓檢視和服務分離，從而推動了AngularJS和VueJs等前端資料繫結框架的出現。而將元件更細粒度化，則推動了Serverless或稱為”函式計算“概念的提出。在持續交付方面，要求在開發過程中儘量模擬生產環境，因為開發過程是並行在生產過程的。而容器的輕量級封裝特點，能溝保持執行環境的穩定，使其成為一種優秀的雲上軟體交付工具。

       雲、scrum互相推動，彼此促進發展，是軟體工程的發展史的重要組成部分。在軟體工程管理上，始終難以解決的難題是工程規模的量化分析。無論是瀑布開發還是增量開發，直到今天的敏捷開發，都是在不斷的探索和實驗，以求在無法精確計算工程規模的背景下儘量節省成本，提高產品質量。儘管同是設計到交付，土木工程由於其依賴技術和支撐技術的穩定性，以及使用者需求的大同小異，使得工程管理及其造價有可靠經驗可循。但在軟體工程上，技術的快速更新迭代，使得我們難以依靠已有的經驗推算未來的工作量，對軟體工程的探索依舊在進行。