[[414483]]

本文轉載自微信公眾號「問其」，作者陳少文 。轉載本文請聯系問其公眾號。

1. 敏捷開發是什么

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

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

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

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

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

針對這種快速迭代、持續交付的特點，我們需要尋找合適的分支開發模型。如果是幾個人的項目團隊，我推薦的是主干集成、分支發布的開發模式。版本管理軟件推薦使用 Git，如果使用 SVN，建議轉向 Git。這里有一篇博客，可以參考：從 GitLab 推送代碼到 SVN 倉庫[1]。

2. 特征開發，主干集成，分支發布

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

[[414485]]

• 主干集成，就是盡可能早地將代碼合并到主分支上，在主分支上進行持續集成。

假設每個迭代有 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，繼續發行版本。

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

3. 測試決定了敏捷開發的速度

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

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

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

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

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

參考資料

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