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

敏捷開發社群發表於2020-09-07

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

 

我們可以發現,瀑布模型有很多優點:

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

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

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

  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都是困難重重,一不小心就會遇到很多的反模式,這就要求公司內部各團隊不能只是形式主義,而是大膽地邁開步子,走好第一步。

 

相關文章