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