上個世紀四五十年代，程序設計剛剛誕生之際，是沒有“軟件”的概念的。硬件是開發(fā)的主體，規(guī)模小、工具簡單，而且主要是用于科學計算。

　　隨著軟件概念興起，一些針對軟件開發(fā)的“小作坊”也隨之涌現。作坊做法往往隨意，以個別編程員的意愿為主，沒有形成明確標準，效率不高。此外，“作坊”式開發(fā)特別倚重個人能力，大多都雜亂無章，軟件質量也無從保障。

　　20 世紀 70 年代開始，“工程化”思維開始進入軟件開發(fā)流程。主要原因是，信息技術發(fā)展迅速，人們對軟件的需求變大，軟件生產必須提高產能，走向規(guī)模化。

　　然而，從工業(yè)借鑒而來的開發(fā)流程是否真的適合軟件開發(fā)呢?隨著社會不斷發(fā)展，數字技術打破了各行各業(yè)的生產范式，軟件開發(fā)自身也并沒有停止進化。這些年，軟件開發(fā)流程都經歷了些什么呢?

　　師從工業(yè)的瀑布式開發(fā)

　　1913年，福特開發(fā)出了世界上第一條流水線，打破了汽車制造業(yè)的手工作坊式生產方式，這一模式的出現改變了世界。標準化和規(guī)模生產將汽車帶入了尋常百姓家。

　　在軟件開發(fā)陷入生產效能無法滿足日漸擴大的需求的困境中時，福特的“流水線”概念或許多多少少啟發(fā)到了當時的軟件開發(fā)者們。

　　瀑布式開發(fā)(Waterfall)由此出現。大多數觀點認為，傳統(tǒng)瀑布式開發(fā)有不少于30年的歷史。

　　其根源可以追溯到 1970 年，那一年溫斯頓·羅伊斯(Winston Royce)在論文《管理大型軟件系統(tǒng)開發(fā)》(Managing the Development of Larger Software Systems)中提出，將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

　　瀑布模型將軟件生存周期的各項活動規(guī)定為按固定順序而連接的若干階段工作，形如瀑布流水，直到80年代早期，它一直是唯一被廣泛采用的軟件開發(fā)模型。

　　但是，這樣套用傳統(tǒng)工業(yè)生產的方法，多少會有不適應計算機軟件開發(fā)的弊病。因為過程是線性的，沒有充分照顧到客戶需求，難免會鬧出一些笑話：比如客戶希望你造一輛汽車，卻經費不夠，但瀑布式開發(fā)要在汽車完成生產和測試之后，一次性交付到客戶手中，需求溝通不足導致最后交付的卻是一輛自行車。

(描繪了軟件模式變化的漫畫 來源：Toggle)

　　瀑布式開發(fā)模式較好的例子是微軟。微軟 Office 、 Windows 等主打產品的更新周期一般 3 年左右，軟件延期發(fā)布也是家常便飯，因此其軟件產品遭受大家詬病也是無可厚非。隨后，微軟不得不放棄傳統(tǒng)的瀑布式開發(fā)模式，改變產品研發(fā)策略。

　　有觀點認為，瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對后期需求的變化難以調整，代價高昂。

　　因此，在需求不明并且在項目進行過程中可能發(fā)生變化的情況下，瀑布式基本是不可行的。

　　向客戶傾斜的敏捷開發(fā)

　　時間到了上個世紀90年代，一批輕量的軟件工程方法和框架相繼誕生，它們共同的特點是，相對傳統(tǒng)軟件工程，都遵循演進和迭代的模型，過程更加輕量靈活。

　　既是對傳統(tǒng)的反叛，也是對野蠻生長的規(guī)范，敏捷運動應運而生。

　　2001 年 2 月，17 位輕量級軟件工程方法的代表人物，齊聚美國猶他州的雪鳥滑雪勝地，其中也包括 Scrum 和極限編程的幾位發(fā)明人。在兩天的會議之后，敏捷宣言發(fā)布。

詳情請見： http://agilemanifesto.org/

　　敏捷概念的出現，可以說適逢其時，立即在當時發(fā)展成為了一場運動，被迅速地推廣和應用。在早期，敏捷專注研發(fā)交付，目標是幫助產品和研發(fā)團隊提升敏捷響應能力。

　　但是，之后敏捷開發(fā)開始向客戶靠攏，成為以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，客戶會參與到軟件開發(fā)的整個流程中。整個開發(fā)過程不再是一堵不透風的墻，透明是關鍵(TRANSPARENCY IS KEY)，但是，隨著越來越多的用戶參與進來，越來越多的問題也暴露出來了，越來越多不著調的需求也會被提出。

　　因此，在敏捷開發(fā)中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，可獨立運行的小項目，在此過程中軟件一直處于可使用狀態(tài)。

　　在微軟云計算 Azure 的理解中，敏捷的基礎是創(chuàng)建工作原型或在需求和要求不斷變化的現實中構建。彌合開發(fā)團隊和最終用戶之間的差距，適應性是敏捷的核心屬性，優(yōu)先考慮用戶和利益干系人的需求，而不是嚴格的計劃。

圖片來源：https://blog.csdn.net/xiajun2356033/article/details/81513957

　　DevOps帶來的改變是巨大的

　　顯然，敏捷并沒有將“運維”作為關注的重點。實際上，光有系統(tǒng)開發(fā)是不夠的，開發(fā)完的系統(tǒng)必須即時順利部署，并連續(xù)穩(wěn)定運行才能夠實現價值。而傳統(tǒng)上，這部分是由運維負責的。

　　《阿里巴巴 DevOps 實踐》認為，從價值的角度，開發(fā)加運維才構成相對完整的 IT 價值鏈。而DevOps 的誕生，正是為了解決IT 價值鏈的最突出問題——開發(fā)和運維之間的問題。

　　在傳統(tǒng)的 IT 組織下，開發(fā)團隊 (Dev) 和運維團隊 (Ops) 之間有一道無形的部門墻。開發(fā)團隊(尤其是敏捷團隊) 追求變化，運維團隊追求穩(wěn)定，二者存在利益沖突。

圖片來源于：https://www.cnblogs.com/liufei1983/p/7152013.html

　　2009 年，比利時獨立 IT 咨詢師 Patrick Debois 組織了第一屆 DevOpsDays， DevOps 正式登上舞臺。此后，DevOps 發(fā)展迅速，已經為企業(yè)數字化的核心能力之一，是對 IT 交付和運行的基本要求。其中，以容器化和自動編排調度為代表的云原生技術的出現極大加速了這一進程。

　　根據微軟云計算 Azure，DevOps 的獨特之處在于開發(fā)、IT 運營、質量工程和安全團隊協(xié)同工作，在發(fā)布新產品、版本或更新所涉及的所有任務中創(chuàng)造效率。其中，DevOps 的主要表現形式包括持續(xù)集成、持續(xù)交付和連續(xù)部署。

　　在 《鳳凰項目》和《DevOps 實踐指南》兩本書中，Gene Kim 等人總結了 DevOps 實施的三步工作法：

• 流動原則:聚焦 IT 系統(tǒng)的整體價值流，全局優(yōu)化，保證價值從左(上游)到右(下游)的快速流動。
• 反饋原則:創(chuàng)建從左到右的反饋循環(huán)，并縮短反饋周期和放大反饋效果。這樣，就可以更快的響應和理解內外部客戶，并即時獲取改進所需要的知識。
• 持續(xù)的實驗和學習原則:創(chuàng)建承擔風險、持續(xù)實驗并從錯誤中學習的文化，在不斷的嘗試中精進能力，并提高系統(tǒng)的韌性。

　　在現實操作中，DevOps 也不乏實現工具。比如我國國產的飛算 SoFlu 全自動軟件工程平臺，其出發(fā)點是想讓 DevOps 真正的落地，而實現“落地”，首先重點要解決的就是開發(fā)的問題， 包括開發(fā)的品質、安全和效率等，再逐步解決測試和運維問題。

　　除了飛算 SoFlu 全自動軟件工程平臺，幫助 DevOps 實現組織落地的工具不在少數，其中還包括開源的 CI/CD 服務器 Jenkins、容器平臺 Docker等等。

　　此外，值得關注的，在主流觀點中DevOps 成功與否的重點，或許不在現實層面，而在于文化。Puppet field CTO Nigel Kersten 就曾表示，“仍然存在組織對變革的抵制，這是一個真正的問題。而且人們真的沒有看到他們實際上試圖通過 DevOps 實現的實際價值。”

　　從瀑布式開發(fā)、到敏捷，再到目前最流行的DevOps，不難發(fā)現，軟件開發(fā)流程正在向自動化、便捷化和智能化的方向發(fā)展，而這樣的發(fā)展會大大加快開發(fā)效率、降低開發(fā)門檻，讓未來的開發(fā)流程呈現出全然不同的樣貌。

特別提醒：本網信息來自于互聯網，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創(chuàng)性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。