本文根據 CODING Compass 產品總監程勝聰在騰訊云 CIF 工程效能峰會上所做的分享，進行了整理與更新，文末可前往峰會官網，觀看回放并下載 PPT，
DevOps 從工具化階段邁入流程化階段
軟體工程從上世紀 60 年代發展到現在，毫無疑問正處于 DevOps 的時代，這幾年業內如火如荼的 DevOps 轉型也印證了這一點，到現在這個階段，企業在轉型落地上也持續投入了這么多年，開始迫切希望看到成果，大家普遍在思考一個問題，那就是 DevOps 是否真的對業務發展和數字化轉型帶來幫助，還是只是研發團隊自嗨而已？
在最近一年協助客戶進行 DevOps 產品落地的程序中，我們愈發意識到：研發管理真的不能只靠搭建工具鏈，還需要把這些工具應用到企業實際的業務流程當中， 我們應該切實的為開發減負，而不是反而給業務的開發增加負擔，只有這樣才能夠切實提升研發效能，更好地滿足業務發展的需要，
如果說，DevOps 在之前還屬于工具化階段，各式各樣的工具層出不窮，那么在數字業務發展迅猛的背景下，DevOps 正在進入一個新的階段：流程化階段，
企業使用 DevOps 工具仍然存在挑戰
先從一個典型的用戶反饋出發，來看看當前用戶所處的困境：
上面這個客戶深入使用 CODING 一年多，他們對產品是否好用有足夠的話語權，通過對反饋結果的整理，可以看出工具化階段的產品還是存在不足，一方面，客戶充分肯定了當初選擇 CODING DevOps 的決定，團隊中每個角色都能夠在一站式平臺上作業，很好地實作了研發一體化的目標；另一方面，盡管我們的一站式平臺提供了團隊所需的能力模塊，但是不同模塊之間的協作性還不能很好體現，
-
對產品來說，其關注的需求活動并不能很好關聯到開發實際在做的事情，從而對進展和風險不能完全掌控，
-
對于開發來說，更新任務狀態是很重要，但是由于這個事情并不會阻塞自己，是否及時更新就完全取決于自覺性高低，于是很多時候，忙于協作編程的開發往往會忘記去做這個事情，
-
同時，作為相對后置的測驗，一旦提測，各種事項檢查更是茫茫多，各種資訊核對和更新就要花費大量的時間，加上留給測驗的時間本來就不多，情況就顯得特別窘迫，
-
而再后面的運維同事更不用說了，只能反復叮囑發版之前要做好充分準備，各種驗證檢查都不能打折扣，然后就只能祈禱別總是在敏感的發布視窗，出現各種莫名其妙的問題，
總的來說，雖然在一個平臺上的不同工具大家都用得很順暢，但從全流程來看總覺得缺少點什么，在工具之間的來回切換仍然需要花費大量精力，而且還不能確保資訊的正確性，種種這些，都是工具型產品的不足之處，
企業日漸關注研發管理的整體效率
這個案例并非個案，而是 DevOps 轉型來到了新的流程化階段的標志：企業日漸關注研發管理的整體效率，從強調某個工具的區域優化，轉變為強調協同流程的全域優化，
工具并不能等同于整體效率，組織效能管理的經典理論 PPT 中就指出：一個組織的 3 個要素中，People、人是基礎，Tools、工具對人進行賦能，讓作業更有效率，而 Process、流程則是讓人的行為與目標保持一致的載體，完美地完成一件本來就不應該去做的事情是毫無意義的，甚至還會對整體造成損害，從全域上考慮，一個好的流程不可或缺，
DevOps 產品應該打造成為進一步解放生產力的新型生產關系
在數字化的背景下，業務迅猛發展帶來了軟體系統的高復雜度，個體需要處理的事情變得更多，導致單人效率下降，為了提升團隊中每個角色的作業效率，企業追求 DevOps 轉型，希望利用新興技術和工具來迅速提高團隊生產力，但是隨著在技術和工具上投入越多，以及團隊規模不斷擴大，同時也帶來了整體協作上的復雜度，而這些復雜的依賴關系如同金字塔般層層傳導至團隊成員身上，形成了對原有作業習慣乃至理解認知的巨大沖擊，哪怕是一次簡單的交付，都需要經過許多操作以及不同角色的協同，整個交付程序也因此顯得脆弱和低效：比如作業上下游的契約和規范缺失，研發程序的透明度不夠，需要在不同工具平臺之間來回切換等等，
如何才能讓不同的工具，有機地共存于一個完整的流程當中呢？如何為團隊打造高效的流程，讓人能夠順暢地完成高質量的軟體開發，并發布到生產環境中？在這個程序中，團隊成員不需要去處理不必要的復雜問題，陷入細枝末節之中，又或者是長時間的等待延誤，我們應該解放團隊成員的生產力，讓開發能把精力集中在能真正產生業務價值的作業上，這是當前很值得思考的事情：就像生產力決定生產關系一樣，我們需要更先進的研發管理產品來賦能研發團隊，來滿足現今數字化業務發展的需求，
CODING Compass：DevOps 流程化階段的研發流程管理產品
通過對 DevOps 實踐落地中凸顯出來的問題的梳理，我們得出了以下 2 個方面的認識：
1. 組織層面的 DevOps 轉型需要領域專家
7 月份信通院發布的《中國 DevOps 現狀調查報告（2021）》中就指出：接近 30% 的企業因為缺少 DevOps 專家導致推進落地緩慢，而在我們服務客戶的時候，也往往需要提供咨詢，通過專家診斷、制定流程，然后根據實際情況、設定要提升的目標以及具體的實作路徑，DevOps 產品要做的是：提煉出業內行之有效的研發管理經驗、并內嵌到產品當中，引導客戶團隊把優秀的習慣固化下來、持續優化，從而實作高效的研發管理，
2. 協作中團隊成員的最大痛點是“什么都要懂”
在現有已提供的工具的基礎下，團隊憑著對 DevOps 的樸素理解，是可以初步協同起來的，但是，用戶所面臨的協作問題確實存在：比如缺乏跨職能活動的能力拉通，活動之間的協作規范缺失，難以識別研發程序中的風險，個體在作業中需要理解的背景關系過多，還有跨職能的許多操作只能手工處理等等，這些看上去瑣碎，但是這些問題累積起來遲遲得不到解決，便會造成團隊成員極大的“心力損耗”，甚至導致了優秀員工對打造高效組織產生懷疑，
DevOps 深化發展到了現今階段，代表著行業對研發管理產品的新的期望：從敏捷到 DevOps、再結合 LEAN 精益思想的理念，朝著增強可視化和可追溯性、追求規范和效率的方向發展，基于察覺到的這些痛點，CODING 結合自身實踐和行業成果經驗，努力作出了產品的升級，來幫助客戶更好地提升研發管理能力，
Compass = 作業流 + 規范 + 自動化
CODING 打造了全新的研發流程管理產品 Compass，包括 3 個主要能力：分別是（串聯各種活動形成的協同）作業流，還有（提升研發活動一致性的標準）規范，以及（觸發后置活動的）自動化，代表著 CODING DevOps 在原有 DevOps 工具鏈的基礎之上，融入了 Know-how 的部分，讓客戶能夠充分借鑒業內行之有效的實踐經驗，做到高效的研發管理，
Compass 如何提升研發管理能力
簡單的說，Compass 的產品邏輯就是定義流程、規范程序、高效流轉、識別瓶頸并指導改進，
1. 首先，研發程序當中存在著各種各樣的活動，
比如說產品經理會創建需求到 backlog 里面，團隊開展規劃會納入到迭代當中，并進行任務分解、任務認領或者分配，開發會創建分支、寫代碼、提交合并等等，而測驗則是設計用例、執行測驗，然后團隊提測、通過質量門禁之后并創建發布單等等，
我們知道，這里列舉的有些是同一種角色內部發生的，有些卻是需要不同角色去協同完成的，實際上它們的進行存在著先后順序，
2. 其次，識別出關鍵的協同活動并串聯成為完整的作業流，
按照不同角色歸類好這些活動之后，會發現同一角色的某些活動客觀上就是另外一些活動的前提，比如需求被創建出來之后、才有可能被納入迭代，分支存在之后、才能有對應的代碼提交和 MR，用例設計完了、才能在它的基礎上關聯對應的需求等等，這些內在的關系導致了它們的活動流轉必然是自發完成的，
對于剩下的關鍵節點，我們從整體研發的視角，根據實際作業情況，人為定義好它們的依賴順序，并把它們串聯起來，比如任務拆解完畢才能創建對應的特性分支，有了 MR、并且需求關聯了測驗用例之后才能提測，然后執行測驗、給出測驗報告、最后提交發布單，這樣就形成了完整的作業流，
3. 再次，通過規范來保障活動的健壯流動，以及自動化驅動活動進行高效的流轉，
為了保障活動流轉的健壯性，我們可以對其中的某些活動設定準入準出規范，不符合規范的則給出警告并阻止繼續流轉，比如納入迭代中的需求要給出驗收標準、作為用例設計的依據，測驗報告中的通過率要滿足一定數值才能創建發布單等等，另外，對于某些可以標準化創建或者觸發的活動，可以設定自動化規則，當前提條件獲得滿足時則自動流轉，也不需要團隊成員切換到另外工具中去更新狀態、或者手工創建下一個步驟的任務，這樣一來就形成了一個井然有序的團隊協作作業流，
4. 最后，把研發具體步驟跟業務定義好的價值流階段映射到一起，提供洞察分析，
規范和自動化能夠產生精確的活動記錄，從而為效率度量提供真實可靠的資料，進行有效的洞察診斷和指導改進，比如前置時間和處理時間的差異、任務完成率/準確率等等，這是價值流管理（Value Stream Management）的基礎，
以上就是 Compass 的產品設計理念，我們希望能夠通過流程驅動協作中的開發行為，讓流程中的每個人都可以專注于自身的價值，同時沉淀下來的程序資料能夠準確的透視研發程序，并且基于資料的洞察分析來指導研發程序的持續改進，
總結
CODING Compass 是一款基于 CODING 原有 DevOps 工具鏈的研發流程管理產品，包含流程編排、流程驅動、規則約束及價值流轉，希望能夠幫助企業拉通管理者的目標預期和研發團隊的具體執行，用最小的協同成本實作最高的回應能力，從而最大化研發效率，
當前 Compass 正在內測中，預計年底開放公測，敬請期待！
前往觀看 CIF 峰會回放
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/373998.html
標籤：其他
上一篇：激勵方法論1、馬斯洛需求模型