前一篇文章我們講到，DevOps 是一種重視 “軟件開發(fā)人員（Dev）” 和 “運(yùn)維技術(shù)人員（Ops）” 之間溝通合作的文化，是軟件開發(fā)領(lǐng)域最近十年來興起且當(dāng)下普遍成熟運(yùn)用的方法論。它和傳統(tǒng)的瀑布模型、螺旋模型等理念不同，其核心是 “敏捷”，結(jié)果是自動化。
越來越多的企業(yè)期望通過引入DevOps 模式，實(shí)現(xiàn)更高效的交付效率，從而提升客戶滿意度、創(chuàng)造更多商業(yè)價(jià)值。但具體到實(shí)施層面，如何成功實(shí)踐 DevOps 依然是一個(gè)難題。長亮科技自主研發(fā)的研發(fā)協(xié)同管理平臺（MOne），打通了從需求、設(shè)計(jì)、開發(fā)、構(gòu)建、測試、發(fā)布到部署的全流程，通過平臺沉淀標(biāo)準(zhǔn)流程、敏捷實(shí)踐的方法論，形成企業(yè)內(nèi)部的研發(fā)工藝，在DevOps的各個(gè)階段形成有效賦能。
本篇文章將重點(diǎn)分享，長亮科技研發(fā)協(xié)同管理平臺在DevOps的“敏捷迭代”階段，如何助力研發(fā)團(tuán)隊(duì)數(shù)字化協(xié)同水平上一個(gè)大臺階。
敏捷迭代全流程
敏捷迭代的實(shí)施流程，包含：產(chǎn)品團(tuán)隊(duì)對目標(biāo)進(jìn)行規(guī)劃→ 開發(fā)進(jìn)行需求拆解、排期開發(fā)→ 測試、測試人員進(jìn)行迭代排期、開發(fā)、測試→ 敏捷教練對迭代進(jìn)行跟蹤和反饋，在這個(gè)過程中不同團(tuán)隊(duì)的科學(xué)分工和優(yōu)秀協(xié)同，是能否真正實(shí)現(xiàn)“敏捷”的關(guān)鍵。
產(chǎn)品團(tuán)隊(duì)
作為用戶需求的分析和研發(fā)需求的導(dǎo)入橋梁，需要根據(jù)用戶場景分析來定義產(chǎn)品的關(guān)鍵特性，使得做出的產(chǎn)品更加貼近用戶；
開發(fā)團(tuán)隊(duì)
作為產(chǎn)品的開發(fā)來說，需要根據(jù)產(chǎn)品特性來分析、拆解開發(fā)團(tuán)隊(duì)的研發(fā)需求，聚焦于做解決用戶痛點(diǎn)問題的需求；
測試團(tuán)隊(duì)
測試團(tuán)隊(duì)主要作為產(chǎn)品研發(fā)過程中質(zhì)量的保證，通過用例管理、自動化測試等手段，保證交付給用戶的產(chǎn)品是經(jīng)得住考驗(yàn)的；
敏捷教練
敏捷教練主要在研發(fā)以Scrum敏捷迭代過程中，監(jiān)控迭代的進(jìn)度，識別迭代中可能的風(fēng)險(xiǎn)以及問題，并能夠幫助研發(fā)團(tuán)隊(duì)持續(xù)的改善研發(fā)效能。
不同場景下敏捷迭代實(shí)踐
場景一
從用戶場景出發(fā)識別用戶需求
用戶場景分析，主要是提供給產(chǎn)品團(tuán)隊(duì)，面向用戶的使用場景進(jìn)行的推演分析過程，在分析過程中，主要有兩個(gè)關(guān)鍵信息。
用戶活動： 按照用戶操作、使用流程，一步步推演出用戶的操作過程，我們稱這個(gè)流程為用戶活動的分析，此過程主要是為了識別用戶側(cè)關(guān)鍵的場景行為；
產(chǎn)品能力：用戶活動需要產(chǎn)品(組件)的特性來進(jìn)行支撐，比如用戶活動中的“點(diǎn)擊流水線發(fā)布”活動，就需要MOne Pipeline組件的“動態(tài)編排流水線”、“流水線調(diào)度執(zhí)行”等2個(gè)產(chǎn)品能力支撐。
通過用戶場景分析設(shè)計(jì)器來承載用戶的場景分析過程，最終識別出我們的產(chǎn)品(組件)需要具備什么樣的能力。
場景二
聚焦產(chǎn)品的關(guān)鍵特性
“能力地圖”是面向用戶視角，對產(chǎn)品(組件)對外提供的關(guān)鍵特性的一種表現(xiàn)形式，產(chǎn)品的能力輸入來源可由以下兩部分組成：
通過“用戶場景”推演用戶活動后，進(jìn)而識別產(chǎn)品組件的能力
事先規(guī)劃系統(tǒng)具備哪些產(chǎn)品組件，以及對應(yīng)組件的關(guān)鍵能力
當(dāng)所有產(chǎn)品能力聚合在一起，就可以形成產(chǎn)品的“能力地圖”。
通過“能力地圖”，我們可以更好的管理和跟蹤產(chǎn)品能力。
產(chǎn)品能力到研發(fā)需求的管理：產(chǎn)品的能力代表的是產(chǎn)品的特性輸出，能力是需要通過研發(fā)任務(wù)進(jìn)行分解完成后才能釋放的。我們通過分解能力，向下形成研發(fā)關(guān)注的“待辦事項(xiàng)列表”，實(shí)現(xiàn)產(chǎn)品能力與研發(fā)需求的打通。研發(fā)的待辦事項(xiàng)就可以通過敏捷迭代的方式，納入到一輪一輪的沖刺進(jìn)行完成。在沖刺過程中，研發(fā)需求的季度將自動反饋到產(chǎn)品能力的進(jìn)度上，實(shí)現(xiàn)能力進(jìn)度的同步更新，最終當(dāng)能力下所有的研發(fā)需求關(guān)閉后，就代表上層的能力開發(fā)完成；
產(chǎn)品能力進(jìn)度的跟蹤：可以通過產(chǎn)品的進(jìn)度跟蹤趨勢圖，來了解各個(gè)產(chǎn)品組件能力的進(jìn)度。產(chǎn)品能力的進(jìn)度匯報(bào)會以每周進(jìn)行匯總，方便管理層了解產(chǎn)品的開發(fā)情況。
場景三
面向多人開發(fā)的協(xié)作模式
場景一的“用戶場景”主要通過用戶活動識別產(chǎn)品能力，場景二的“產(chǎn)品能力地圖”是為了更好的管理和跟蹤產(chǎn)品能力，以上2個(gè)場景都主要是面向產(chǎn)品人員。通過能力向下分解成研發(fā)任務(wù)時(shí)，就會形成研發(fā)關(guān)注的“待辦事項(xiàng)”。
待辦事項(xiàng)池：通過規(guī)劃每2~3周為一周期的迭代，把待辦事項(xiàng)納入到迭代中進(jìn)行開發(fā)；
可視化的迭代看板：通過可視化看板，方便團(tuán)隊(duì)對于迭代任務(wù)進(jìn)度對齊和風(fēng)險(xiǎn)預(yù)知。
迭代看板可以根據(jù)流程劃分不同的“泳道”，開發(fā)人員在對任務(wù)進(jìn)行處理時(shí)，將會挪動看板上的任務(wù)卡片，實(shí)現(xiàn)狀態(tài)流轉(zhuǎn)過程。當(dāng)所有的卡片都在“關(guān)閉”泳道時(shí)，就代表本輪迭代任務(wù)都完成即可關(guān)閉迭代。
此外，在看板卡片上，通過“標(biāo)簽方式”可對重要、關(guān)鍵的任務(wù)進(jìn)行標(biāo)注識別，同時(shí)增加“延期的標(biāo)識”以提醒成員及時(shí)處理，避免延期。
場景四
特性分支的驅(qū)動開發(fā)模式
特性分支的驅(qū)動開發(fā)模式，主要是為了加快軟件的代碼開發(fā)到測試可交付的流程的一種模式，我們通過檢出研發(fā)需求對應(yīng)的代碼分支，進(jìn)行線下的代碼Coding工作，當(dāng)代碼開發(fā)完成后想快速進(jìn)行功能驗(yàn)證，可以發(fā)起合并申請流程，將自動觸發(fā)分支的發(fā)布流程：
CI構(gòu)建流水線，進(jìn)行源代碼的構(gòu)建、打包、質(zhì)量掃描等流程，上傳制品到對應(yīng)的制品庫；
CD發(fā)布流水線，將自動觸發(fā)從制品庫中拉取部署的制品包，實(shí)現(xiàn)在不同環(huán)境中的部署。
在不同環(huán)境中部署時(shí)，可以通過開發(fā)自測、測試人員測試，再到產(chǎn)品的預(yù)發(fā)布環(huán)境進(jìn)行審查。整個(gè)環(huán)境研發(fā)完成后，將分支代碼自動合并到代碼主干中。
特性分支開發(fā)的模式，串聯(lián)了開發(fā)、測試、產(chǎn)品等多種角色，可以更加快速的打通部門協(xié)作壁壘，加快了軟件的快速交付過程。
結(jié) 語
通過以上4個(gè)場景，我們描繪了長亮科技在DevOps的“敏捷迭代”階段的理念與方法的實(shí)踐。
在接下來的文章中，我們將聚焦“持續(xù)測試”階段的實(shí)踐，請您繼續(xù)關(guān)注。
