軟件開發流變史：從瀑布開發到敏捷開發再到DevOps

本文摘自敏捷開發。

作為在20世紀70年代、80年代盛極一時的軟件開發模型，瀑布模型通過制定計劃、需求分析、軟件設計、程序編寫、軟件測試、運行維護等6個流程將整個軟件生命周期銜接起來。這6個流程有著嚴格的先后次序之分，只有當前面的流程結束之后，下一個流程才能開始運轉。這種自上而下的流程像極了瀑布的下落，因此得名瀑布模型。

我們可以發現，瀑布模型有很多優點：

有明確的交接點：不論是制定計劃還是需求分析，甚至是軟件測試，都有明確的起始點及開發流程——也就是在上一流程結束后再開始下一個流程；

責任明確：開發人員都各司其職，協作流程合理清晰；

發生問題能準確溯源：在開發過程中，如果發現有環節遺漏，負責人能夠準確定位問題根源，并找出最優解決方案；

流程劃分清晰：由于開發流程是環環相接，因此不會出現多個環節同時作業的情況；

及時反饋：在每個流程結束前都要對該流程完成的內容進行審核，以便及早發現軟件開發過程中的錯誤，及時糾錯。

但隨著軟件行業的快速發展，瀑布模型也逐漸暴露出許多缺點：

反饋結果單一：由于瀑布模型的反饋形式只針對于目前完成的階段，無法對整個流程進行宏觀反饋，因此各交接點處的反饋結果從整體來講并不準確；

客戶不參與開發過程：首先，客戶在最初提出需求后，便不再被允許參與到開發流程之中，除非提出新的需求。其次，客戶只能在開發過程的后期看到成果；

新需求的增加會打亂整個發布節奏：前文也說到瀑布模型有著嚴格的先后次序之分，只有前一個階段完成后，才能進入下一階段。因此在整個流程中，新需求的增加會導致當前任務停工，并返回需求分析、軟件設計等階段，且后面的流程都需要重新進行；

造成人力資源浪費：瀑布模型要求流程是環環相接的，因此軟件開發還停留在前一階段時，后面流程的人都處于無可事事的狀態。又因為瀑布式開發中要求人員各司其職，因此當某一階段缺人手時，只能延長時間，導致有些人工作量過于飽和，有些人又過于清閑；

周期長，不適合急需交付的項目：這一軟件開發模式各階段呈現按部就班的狀態，因此不適合急需交付的項目；

標準化模式導?致流程僵化、死板：管理人員通過規定各階段完成時間以及交接點來控制過程狀態，這種標準化模式不加一點變通，最終導致流程的僵化、死板。

網絡的逐漸普及要求軟件開發更能貼近人們的日常使用，也在這時，瀑布式開發受到逐漸興起的“敏捷開發”的沖擊。

2001年，十七位關于敏捷方法的發起者和實踐者聚集到一起，發表了“敏捷軟件開發宣言”。他們強調敏捷開發能夠以一種更加簡潔、可持續、短周期、高效率的方式進行軟件開發，同時希望以敏捷聯盟為形式的合作可以幫助到行業中的其他人，幫助他們以更加敏捷的新方式來思考軟件開發、方法論以及組織架構。

敏捷開發強調：

個體和互動高于流程和工具

工作的軟件高于詳盡的文檔

客戶合作高于合同談判

響應變化高于遵循計劃

簡單來講，敏捷開發采用“迭代開發”，將軟件項目需求分成多個迭代，且每個迭代成果在完成開發、測試、反饋等環節后都可以進行交付。也就是說，在將軟件交付到客戶手中之前，開發過程中的任何經過測試的子項目都能夠獨立運行。

敏捷開發成功地彌補了瀑布式開發的不足，有很大的優勢：

強調“響應變化”：在做出開發計劃后，計劃并不是需要唯一遵循的指南。開發過程會因客戶需求的改變而出現改變，這時就需要產品經理不斷更新產品需求，開發團隊中的成員主動配合，使迭代過程可以根據需求變化靈活調整；

使資源利用最大化：瀑布式開發要求每個人各司其職，但敏捷開發要求大家能夠互相信任、互相幫助，合作開發。在某一位置出現空缺時，其他人可以暫時代工，這一現象有效地使資源利用效率最大化；

反饋及時：與瀑布式開發在整個生命周期后期才能得到反饋的狀態相比，敏捷開發在每個迭代后都能交付可獨立運行的成果。不論是團隊對迭代成果進行測試，還是從客戶那里，都能得到及時的反饋；

短周期：每一個迭代就是一個周期，因此交付成果的效率得到顯著提高；

客戶參與：在每個迭代結束后都能將迭代的成果交付到客戶手中，客戶可以及時跟蹤到最新的產品狀態，且參與到產品開發中去。

與此同時，也有一些相應的缺點表現了出來：

忽視文檔的重要性：敏捷開發認為工作的軟件高于詳盡的文檔，在注重成員之間溝通的同時，過于忽視文檔的重要性，這會在團隊中增添新人時產生一些不必要的、繁瑣的溝通環節；

開發成本：由于敏捷開發是迭代式開發，在每個迭代中都有一個小型的、完整的開發流程，因此開發成本高；

需求分析失誤：在需求分析階段，一旦需求分析出現問題，會導致接下來的工作及開發流程都會出現方向上的偏差。

敏捷開發極大地提高了軟件開發的速度，但它注重的是軟件的開發階段，并未兼顧到運維階段。在開發人員與運維人員進行交接的時候，并沒有體現出敏捷的價值、原則，因此開發與運維之間仍缺乏一些必要的協作效率。這時DevOps就應運而生，DevOps促進開發、運維、測試之間的高效協同，從而做到用持續軟件交付來修復并能夠更快地解決問題：

促進跨職能部門的高效協作：在整個軟件開發的生命周期中進行持續開發、持續測試、持續集成、持續部署以及持續監控，解決了開發、運維、測試之間的協作效率不高問題；

范圍更廣：不只局限于開發流程，而是集開發、運維、測試于一體，范圍擴大到軟件的完整生命周期；

流程自動化：將工作流程自動化，例如：可以通過自動化測試系統來識別代碼中的錯誤或漏洞，確保功能不會出現缺陷或漏洞；

更具安全性：通過自動化測試來持續地檢測交付產品的質量以及可交付標準，或者通過持續監控使產品更具安全性；

周期短：DevOps可以在較短的周期內開發出高質量軟件。

在軟件生命周期中，不論是瀑布模型還是現如今各大公司都在積極轉型的敏捷開發和DevOps，都是在軟件行業不斷發展中產生的，迎合了行業發展的需求。而在轉型的過程中，不論是敏捷還是DevOps都是困難重重，一不小心就會遇到很多的反模式，這就要求公司內部各團隊不能只是形式主義，而是大膽地邁開步子，走好第一步。

軟件開發 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。