敏捷開發(fā)之研發(fā)流程
本文轉(zhuǎn)載自微信公眾號「問其」，作者陳少文 。轉(zhuǎn)載本文請聯(lián)系問其公眾號。
1. 敏捷開發(fā)是什么
在傳統(tǒng)的軟件研發(fā)模型中，從提出需求到最后交付，時間周期較長。瀑布模型遵循需求分析、設計、編碼、集成、測試、維護六個步驟進行。一旦需求發(fā)生變化，不僅浪費前期投入，還不易于調(diào)整。
敏捷開發(fā)是一種應對快速變化的需求的軟件開發(fā)能力。特別是互聯(lián)網(wǎng)軟件，前期設計不可能十分完美，在研發(fā)的過程中，會不斷地調(diào)整、優(yōu)化。
敏捷開發(fā)是面向交付、面向協(xié)作的。相較于主張完善的設計、文檔、流程規(guī)范，敏捷開發(fā)強調(diào)的是持續(xù)交付，讓目標更早得到驗收，讓缺陷更早暴露。
在實踐過程中，我們需要保持 1-2 周的迭代周期。過長的迭代周期，排期評估通常是不準確的，容易導致延期。同時，較長的迭代周期，意味著復雜的功能。一次迭代將復雜功能引入主版本，不是一個好主意。通過拆分功能，能有效降低問題的復雜度，提高軟件質(zhì)量。
另一方面，需求方、設計方、開發(fā)方還需要時刻了解進度。1-2 周的迭代，提供的是一個短期的目標，無法具體到每天的工作內(nèi)容。建議，負責人每天能組織一次站立晨會，相關(guān)人員能花 2 分鐘匯報進度，反饋遇到的問題。會后，主要負責人，統(tǒng)一協(xié)商解決問題，以保持項目推進。
針對這種快速迭代、持續(xù)交付的特點，我們需要尋找合適的分支開發(fā)模型。如果是幾個人的項目團隊，我推薦的是主干集成、分支發(fā)布的開發(fā)模式。版本管理軟件推薦使用 Git，如果使用 SVN，建議轉(zhuǎn)向 Git。這里有一篇博客，可以參考：從 GitLab 推送代碼到 SVN 倉庫[1]。
2. 特征開發(fā)，主干集成，分支發(fā)布
- 特征開發(fā)，就是每個小的功能，都新建一個特征分支進行開發(fā)?；谔卣鏖_發(fā)，能夠保障各個特征的獨立性，允許并行開發(fā)特征。同時，未完成的特征，也不會影響主干分支。
- 主干集成，就是盡可能早地將代碼合并到主分支上，在主分支上進行持續(xù)集成。
假設每個迭代有 N 個功能，如果這些功能在同一天被合并到主干分支，交叉驗證這些功能是否符合預期，需要的工作量是 N ^ 2 級別。但是，如果這些功能，開發(fā)自測完畢后，立即發(fā)起 MR/PR 流程，合并到主干分支。N 個功能，合并成本會下降到 N 級別。
盡可能早地發(fā)起合并請求，能將自己的修改，盡快地告知其他開發(fā)者。在開發(fā)過程中，其他開發(fā)者，就能解決大部分的沖突。
- 分支發(fā)布，就是每次發(fā)布都新建一個分支，而不是發(fā)布主干分支。
假設現(xiàn)在需要發(fā)行 2.1 版本。首先，基于主干分支，創(chuàng)建發(fā)布分支 2.1，在 2.1 分支上進行測試，并將缺陷回歸到主干分支。驗收通過之后，在 2.1 分支上打上 Tag 2.1.0，對外進行發(fā)布。
發(fā)布之后，如果 Tag 2.1.0 版本有缺陷，需要在 2.1 分支上進行修復，然后回歸缺陷到主干分支，打上 Tag 2.1.1，繼續(xù)發(fā)行版本。
分支發(fā)布的好處，就是讓發(fā)布的版本可以追溯，允許開發(fā)者對發(fā)行版本進行修復，持續(xù)發(fā)布。另一方面，發(fā)布分支不會影響新特性的開發(fā)，也不會被主干集成干擾。
3. 測試決定了敏捷開發(fā)的速度
沒有質(zhì)量的交付是沒有價值的。
敏捷開發(fā)過程中，測試是持續(xù)集成中的重要環(huán)節(jié)。測試既是目標，驅(qū)動開發(fā)人員去達成，也是交付的憑證，是給項目質(zhì)量的背書。
測試應該整合到研發(fā)流程，貫穿整個項目過程。單元測試，API 測試，集成測試，功能測試，不同的測試階段可以發(fā)現(xiàn)著不同粒度的問題。
在實踐過程中，我們鼓勵將測試左移。參照測試金字塔，盡可能多地寫單元測試，能夠獲得較好的效果。在團隊中，測試/開發(fā)比通常很低。由開發(fā)人員寫單元測試，測試人員進行集成測試、功能測試比較合理。
在 MR/PR 流程中，添加 CI 流水線，自動執(zhí)行測試用例，輔助驗證功能，也是事半功倍的實踐。
參考資料
[1]從 GitLab 推送代碼到 SVN 倉庫: https://www.chenshaowen.com/blog/some-common-scripts-in-ci.html#3-從-GitLab-推送代碼到-SVN-倉庫
