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

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

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

1. 敏捷開發是什麼

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

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

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

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

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

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

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

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

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

假設每個迭代有 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-倉庫

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2786915/,如需轉載,請註明出處,否則將追究法律責任。

相關文章