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