本文根據 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 正在內測中，預計年底開放公測，敬請期待！