研發流程在敏捷開發中的詳解

導讀	在傳統的軟體研發模型中，從提出需求到最後交付，時間週期較長。瀑布模型遵循需求分析、設計、編碼、整合、測試、維護六個步驟進行。一旦需求發生變化，不僅浪費前期投入，還不易於調整。

在傳統的軟體研發模型中，從提出需求到最後交付，時間週期較長。瀑布模型遵循需求分析、設計、編碼、整合、測試、維護六個步驟進行。一旦需求發生變化，不僅浪費前期投入，還不易於調整。

敏捷開發是一種應對快速變化的需求的軟體開發能力。特別是網際網路軟體，前期設計不可能十分完美，在研發的過程中，會不斷地調整、優化。

敏捷開發是面向交付、面向協作的。相較於主張完善的設計、文件、流程規範，敏捷開發強調的是持續交付，讓目標更早得到驗收，讓缺陷更早暴露。

在實踐過程中，我們需要保持 1-2 周的迭代週期。過長的迭代週期，排期評估通常是不準確的，容易導致延期。同時，較長的迭代週期，意味著複雜的功能。一次迭代將複雜功能引入主版本，不是一個好主意。通過拆分功能，能有效降低問題的複雜度，提高軟體質量。

另一方面，需求方、設計方、開發方還需要時刻了解進度。1-2 周的迭代，提供的是一個短期的目標，無法具體到每天的工作內容。建議，負責人每天能組織一次站立晨會，相關人員能花 2 分鐘彙報進度，反饋遇到的問題。會後，主要負責人，統一協商解決問題，以保持專案推進。

針對這種快速迭代、持續交付的特點，我們需要尋找合適的分支開發模型。如果是幾個人的專案團隊，我推薦的是主幹整合、分支釋出的開發模式。版本管理軟體推薦使用 Git，如果使用 SVN，建議轉向 Git。這裡有一篇部落格，可以參考：從 GitLab 推送程式碼到 SVN 倉庫[1]。

• 特徵開發，就是每個小的功能，都新建一個特徵分支進行開發。基於特徵開發，能夠保障各個特徵的獨立性，允許並行開發特徵。同時，未完成的特徵，也不會影響主幹分支。

• 主幹整合，就是儘可能早地將程式碼合併到主分支上，在主分支上進行持續整合。

假設每個迭代有 N 個功能，如果這些功能在同一天被合併到主幹分支，交叉驗證這些功能是否符合預期，需要的工作量是 N ^ 2 級別。但是，如果這些功能，開發自測完畢後，立即發起 MR/PR 流程，合併到主幹分支。N 個功能，合併成本會下降到 N 級別。

儘可能早地發起合併請求，能將自己的修改，儘快地告知其他開發者。在開發過程中，其他開發者，就能解決大部分的衝突。

• 分支釋出，就是每次釋出都新建一個分支，而不是釋出主幹分支。

假設現在需要發行 2.1 版本。首先，基於主幹分支，建立釋出分支 2.1，在 2.1 分支上進行測試，並將缺陷迴歸到主幹分支。驗收通過之後，在 2.1 分支上打上 Tag 2.1.0，對外進行釋出。

釋出之後，如果 Tag 2.1.0 版本有缺陷，需要在 2.1 分支上進行修復，然後迴歸缺陷到主幹分支，打上 Tag 2.1.1，繼續發行版本。

分支釋出的好處，就是讓釋出的版本可以追溯，允許開發者對發行版本進行修復，持續釋出。另一方面，釋出分支不會影響新特性的開發，也不會被主幹整合干擾。

沒有質量的交付是沒有價值的。

敏捷開發過程中，測試是持續整合中的重要環節。測試既是目標，驅動開發人員去達成，也是交付的憑證，是給專案質量的背書。

測試應該整合到研發流程，貫穿整個專案過程。單元測試，API 測試，整合測試，功能測試，不同的測試階段可以發現著不同粒度的問題。

在實踐過程中，我們鼓勵將測試左移。參照測試金字塔，儘可能多地寫單元測試，能夠獲得較好的效果。在團隊中，測試/開發比通常很低。由開發人員寫單元測試，測試人員進行整合測試、功能測試比較合理。

在 MR/PR 流程中，新增 CI 流水線，自動執行測試用例，輔助驗證功能，也是事半功倍的實踐。

[1]從 GitLab 推送程式碼到 SVN 倉庫: https://www.chenshaowen.com/blog/some-common-scripts-in-ci.html#3-從-GitLab-推送程式碼到-SVN-倉庫

原文來自： https://www.linuxprobe.com/process-agile-development.html