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

原文請點選 敏捷開發 。

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

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

1. 有明確的交接點：不論是制定計劃還是需求分析，甚至是軟體測試，都有明確的起始點及開發流程——也就是在上一流程結束後再開始下一個流程；
2. 責任明確：開發人員都各司其職，協作流程合理清晰；
3. 發生問題能準確溯源：在開發過程中，如果發現有環節遺漏，負責人能夠準確定位問題根源，並找出最優解決方案；
4. 流程劃分清晰：由於開發流程是環環相接，因此不會出現多個環節同時作業的情況；
5. 及時反饋：在每個流程結束前都要對該流程完成的內容進行稽核，以便及早發現軟體開發過程中的錯誤，及時糾錯。

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

1. 反饋結果單一：由於瀑布模型的反饋形式只針對於目前完成的階段，無法對整個流程進行宏觀反饋，因此各交接點處的反饋結果從整體來講並不準確；
2. 客戶不參與開發過程：首先，客戶在最初提出需求後，便不再被允許參與到開發流程之中，除非提出新的需求。其次，客戶只能在開發過程的後期看到成果；
3. 新需求的增加會打亂整個釋出節奏：前文也說到瀑布模型有著嚴格的先後次序之分，只有前一個階段完成後，才能進入下一階段。因此在整個流程中，新需求的增加會導致當前任務停工，並返回需求分析、軟體設計等階段，且後面的流程都需要重新進行；
4. 造成人力資源浪費：瀑布模型要求流程是環環相接的，因此軟體開發還停留在前一階段時，後面流程的人都處於無可事事的狀態。又因為瀑布式開發中要求人員各司其職，因此當某一階段缺人手時，只能延長時間，導致有些人工作量過於飽和，有些人又過於清閒；
5. 週期長，不適合急需交付的專案：這一軟體開發模式各階段呈現按部就班的狀態，因此不適合急需交付的專案；
6. 標準化模式導  致流程僵化、死板：管理人員透過規定各階段完成時間以及交接點來控制過程狀態，這種標準化模式不加一點變通，最終導致流程的僵化、死板。

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

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

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

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

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

1. 強調“響應變化”：在做出開發計劃後，計劃並不是需要唯一遵循的指南。開發過程會因客戶需求的改變而出現改變，這時就需要產品經理不斷更新產品需求，開發團隊中的成員主動配合，使迭代過程可以根據需求變化靈活調整；
2. 使資源利用最大化：瀑布式開發要求每個人各司其職，但敏捷開發要求大家能夠互相信任、互相幫助，合作開發。在某一位置出現空缺時，其他人可以暫時代工，這一現象有效地使資源利用效率最大化；
3. 反饋及時：與瀑布式開發在整個生命週期後期才能得到反饋的狀態相比，敏捷開發在每個迭代後都能交付可獨立執行的成果。不論是團隊對迭代成果進行測試，還是從客戶那裡，都能得到及時的反饋；
4. 短週期：每一個迭代就是一個週期，因此交付成果的效率得到顯著提高；
5. 客戶參與：在每個迭代結束後都能將迭代的成果交付到客戶手中，客戶可以及時跟蹤到最新的產品狀態，且參與到產品開發中去。

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

1. 忽視文件的重要性：敏捷開發認為工作的軟體高於詳盡的文件，在注重成員之間溝通的同時，過於忽視文件的重要性，這會在團隊中增添新人時產生一些不必要的、繁瑣的溝通環節；
2. 開發成本：由於敏捷開發是迭代式開發，在每個迭代中都有一個小型的、完整的開發流程，因此開發成本高；
3. 需求分析失誤：在需求分析階段，一旦需求分析出現問題，會導致接下來的工作及開發流程都會出現方向上的偏差。

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

1. 促進跨職能部門的高效協作：在整個軟體開發的生命週期中進行持續開發、持續測試、持續整合、持續部署以及持續監控，解決了開發、運維、測試之間的協作效率不高問題；
2. 範圍更廣：不只侷限於開發流程，而是集開發、運維、測試於一體，範圍擴大到軟體的完整生命週期；
3. 流程自動化：將工作流程自動化，例如：可以透過自動化測試系統來識別程式碼中的錯誤或漏洞，確保功能不會出現缺陷或漏洞；
4. 更具安全性：透過自動化測試來持續地檢測交付產品的質量以及可交付標準，或者透過持續監控使產品更具安全性；
5. 週期短：DevOps可以在較短的週期內開發出高質量軟體。

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