【敏捷開發】企業如何經過落地DevOps實現敏捷開發模式？

最近一段時間在客戶處遇到了不少一樣的問題，首先DevOps的落地建設是一個長鏈條的實踐，它不一樣於單純的工具引入，而是一個完總體系的落地，而做爲整個閉環體系的入口，如何從需求維度就能提升效率就成爲了不少企業的關注點，而做爲傳統企業往數字化轉型階段，不少企業仍是以傳統開發模式爲主，那如何開展敏捷開發及後續支撐規模化敏捷，此文但願能給你們帶來點思考。

前後說了十多年，爲何有敏捷

敏捷，最初做爲舶來品，在漂洋過海以前，就已經被互聯網背景的企業玩「花」了，最初，它體現的只是一種價值觀及簡單的規則，並無對工做的切實指導以及面向具體行業業務的解決方案。

那麼按照敏捷的價值觀體系，咱們傳統企業在引入工具和流程以前，另外一個須要考慮的就是咱們如今的「人」是怎麼樣的？在工做中他們有哪些互動，這些互動的結果是怎麼輸出的？哪些地方是企業或行業中規定的必須遵守的標準流程？

這些清楚事後，再結合一套工具的話，纔可以有效提高工做效率，因此說流程、工具都是爲了支撐人員的工做，而不是單純的引入一套流程、工具，人員圍繞工具轉。

有了上述的基礎，咱們就能夠開始看實際的問題，例如咱們可能常常沒法定期定期交付業務側提出的需求、沒法定期交付項目中的軟件，致使這些狀況發生的因素有不少，而咱們首要思考的是將問題統一提出，劃分主次，定義時間交付節點，全部的出發點都是解決問題而不是找出問題後丟給其餘人一個個解決。

因此聰明的你已經發現了，這裏面很天然的就體現出一個團隊的概念，全部的事情都是圍繞一個團隊來作，團隊中能夠有各類角色，可是事情是你們共同的事，不是我的的。

小結一下，「敏捷」並非一個完整、全面的流程，而是一種方式，用於引導出新流程，改進傳統流程的思考方式，它並非在全部狀況下都具有優點，而是要結合用戶的實際狀況來比較。

咱們怎麼樣作才叫敏捷

1.敏捷開發模型

目前敏捷愈加被傳統企業所接受，在軟件開發領域，不少狀況下你們將敏捷做爲一個優先考慮的事情，目前根據最初的敏捷方式，劃分的團隊基本在十人之內，此數量級的項目組溝通起來最爲方便而且人員分工也較爲完整，在此基礎上，常規的結構方式以下：

總體交付週期包括以上四個部分：

• 第一部分需求池，全部的需求最初能夠統一提到這裏，需求會有優先級的概念。
  

• 第二部分軟需，需求池中拆分後的技術任務，能夠是屢次拆分，例如需求分析、UI、研發、測試等，包括軟件開發週期中的全部工做任務。
  

• 第三部分兩個圈，大圈爲咱們常說的迭代週期，理論上建議是2-4周，小圈稱爲站立會，主要是天天統計總體的進度狀況及困難點等。
  

• 第四部分即最終的交付產物，如軟件、APP、甚至只是一個明確板塊功能均可以。
  

用戶角色：

• PO：產品經理或需求分析崗，主要接受各干係人提出的需求，將用戶描述轉化爲具體的業務需求。

• 敏捷教練：一個敏捷團隊的負責人，工做相似於一個總體項目的項目經理，須要理解業務需求，保證項目的總體按時交付。
  

• 團隊：包括完成一個特定功能或迭代的全部成員，設計、開發、測試、運維等。
  

2.落地經驗

結合藍鯨DevOps平臺——敏捷協同板塊能力來看，如何支撐實現業務敏捷，首先咱們能夠將項目劃分兩種體量來看，大型項目和普通項目。

大型項目

大型項目常見能夠定義爲兩種，第一種企業戰略級項目，一個戰略級項目需求每每會牽涉到多個子項目，第二種產品線複雜，一個完整的產品或業務每每由多個子業務線組成，而且他們互相之間可能存在必定的依賴關係。

藍鯨平臺中對於大型項目主要經過項目集能力進行管理，從項目集維度接收來自各個維度的業務需求，需求在項目集維度能夠繼續細分，若是產品組或戰略自己具有多層級，項目集自己也支持與子項目集進行層級關聯。這裏關係的劃分更多線下先對業務需求和產品層級進行討論，完畢後落入到項目集中。

項目集的主要做用是業需側的統一記錄並對齊多項目的里程碑及發佈時間，所以項目集中拆分後的最小顆粒度需求，能夠直接同步到敏捷管理中的協同管理板塊，做爲板塊的輸出記錄下來。

普通項目

項目維度的管理支持傳統、敏捷或混合方式，本次主要討論敏捷方式的支撐。

敏捷協同部分的輸入能夠有兩個來源，一種是直接經過項目集同步過來，進入平臺後就做爲最大的一個層級（EPIC俗稱故事集），另外一種方式是直接經過新建的方式記錄需求，做爲知足用戶開箱即用的需求，平臺中預設了經常使用的工做項。

用戶需求的記錄按照顆粒度能夠直接記錄於Epic或故事中，在經常使用的敏捷開發流程中，故事依然屬於業務維度的需求，須要由產品或需求拆分人員進一步拆分爲技術需求記錄於任務環節，任務進一步拆分爲具體工做項中的子任務，由具體人員進行執行。

用戶需求的記錄按照顆粒度能夠直接記錄於Epic或故事中，在經常使用的敏捷開發流程中，故事依然屬於業務維度的需求，須要由產品或需求拆分人員進一步拆分爲技術需求記錄於任務環節，任務進一步拆分爲具體工做項中的子任務，由具體人員進行執行。

3.需求與CI、CD的聯動

經過流程加平臺能力的方式支撐敏捷開發中的需求管理後，在整個DevOps中又能夠扮演哪些角色呢，這裏能夠提供一些思路參考。

首先咱們有一點是能夠明確的，需求及任務主要是看總體的進度，而落實到具體工做中，往期都是相對不透明的，那麼咱們怎樣才能從業務角度看到研發流程的完整流轉狀況和問題呢，藍鯨給出了兩種解決方式：

第一種：需求支持與代碼、流水線、測試用例作關聯，這樣咱們能夠作到經過需求查看哪一個分支是匹配這一塊能力的，也能夠看到相應需求下流水線執行狀況及測試用例準備及執行的狀況。

第二種：提供需求部分的研發商店，因爲藍鯨平臺自然的底層數據貫通，咱們能夠便捷的開發響應的插件能力，將需求側的數據與後續想要關聯的部分進行打通，造成企業特有的一種管理模式。

總結

在DevOps中如何輔助企業用好敏捷乃至規模化敏捷，毫不是純粹依靠拿來主義。真正想要達到完總體系的落地必定是須要量體裁衣，可經過輕量的諮詢服務結合企業組織現狀、人員能力等方面，逐步造成特點化的敏捷模式。

而如何匹配特點化的敏捷模式，這對於工具平臺開放性及擴展能力就要有很高的要求，應立即具有開箱即用的最小化板塊，亦能很便捷的擴展能力。

以上要求與PaaS化思想不謀而合，經過「能力」與「服務」的解耦不只可以知足特點化企業級平臺的落地要求，更多的是支撐企業對將來使用場景無限遐想。