本文為 CODING 協同產品總監張路宇 在騰訊雲 CIF 工程效能峰會上所做的分享。文末可前往峰會官網，觀看回放並下載 PPT。
歡迎各位朋友，來到騰訊雲 CIF 工程效能峰會的分論壇，我是 CODING 的產品經理路宇，很高興能以這種方式與大家見面。在接下來的主題環節中，會由我先為大家帶來 CODING DevOps 研發平臺的產品理念和全景解讀，我們還邀請了幾位今年下半年的新產品負責人給大家帶來關於專案協同、WePack、以及全新產品持續部署 Oribt 和研發流程管理 Compass 的分享（講稿已在陸續發出）。
我加入 CODING 已經三年了，此前有近十年的研發管理經歷，我同時是一個不折不扣的效率工具愛好者。過去幾年裡我看到了本土研發團隊、業界，以及 CODING 產品對研發工具理念理解的三個階段性變化：從工具、到工具箱、再到軟體工廠。
工具、工具箱到軟體工廠
西方經典管理理論認為，組織效率可以歸為勞動效率、組織效率和人的效率。美國管理學家泰勒所著的《科學管理原理》被德魯克譽為“20世紀最偉大的發明”，勞動效率說認為分工提升生產效率，福特的流水線就是分工和工業化的典型代表。經濟學家亞當斯密在《國富論》描述了螺絲製造的十八道工序，分別由十八個專門的工人負責完成。以馬克思·韋伯為代表的組織理論家認為，有效的劃分崗位，形成官僚組織結構能夠釋放效率，合理、合法的權利是促進組織達到自身目標的必要條件。組織效率最大化的手段是專業化水平與等級制度的結合。用我們今天的話說，就是讓不同專業能力的人匹配適合的崗位。瑪麗·芙麗特則提出了「以人為本」的人力資源管理理論，更加關注人的心理，管理中需要平衡員工需求與組織發展的目標。
現代數字化、平臺化企業強調創新和協同，在經典管理理論的基礎上又提出了新的挑戰，僅僅分工已經不能滿足市場的需要，我們發現：
1.強個體的價值崛起，最有價值的創新是由企業內少部分人完成的；
2.影響組織績效的因素由內部轉向外部，所有員工都需要關注交付內容的價值和客戶需要。效能 = 價值 X 效率。如果價值為 0，再高的效率也於事無補；
3.由於需求多樣化和快速變化，駕馭不確定性成為組織的核心挑戰。不確定性是一把雙刃劍，能夠把握不確定性便是專注了企業發展的機會。
以上，是我們認為的數字化協同的理論根基，管理邏輯正在從分工走向協同，好的工具需要遵循經典的分工理論，但更加需要注重數字經濟時代的協同需求。
我們提出這樣一個問題 —— 軟體研發還是數字化協同的領軍行業嗎？我找了這樣一張 DevOps 2021 年的生態地圖，如下圖所示，像這樣的圖片想必大家近年來看到了許多。圍繞程式碼的構建、測試、部署、執行環境、監控、專案管理以及資訊流等等的工具層出不窮，這反映了我們所處的技術環境正在快速變化，軟體從業人員的確越來越善於使用工具。
你的團隊可能在用 Jira 進行專案管理，用 Gitlab 管理程式碼，用 Jenkins 實現持續整合，用 JFrog 管理製品……但是，一個研發團隊需要使用如此多的工具，作為技術決策者在選擇時面臨不少的壓力。從學習、部署再到應用，成本經不起計算。一位新同事入職，需要開上七八個賬號，數字資產的管理面臨潛在風險。
更重要的是，我們認為在這種工具集形態下，沒有給開發者和管理者提供一個真正有效、柔性邊界協同的環境。
顯然，相比一些高整合度的數字化行業，甚至傳統行業，我們不能自信的說我們正保持領先。技術決策者們剛剛走出工具時代，正停留在工具箱時代，迫切的需要一個新形態的協同環境迎接挑戰。因此，CODING 提出了數字化軟體工廠的概念。這也恰好符合 CODING 產品的演進路線。
2014 年，CODING 率先推出基於 Git 的程式碼託管服務工具，成為國內領先的程式碼託管服務平臺，也是在此時提出了「雲端開發，讓開發更簡單」的理念。2018 年，我們推出專案協同、持續整合、Cloud Studio 等產品，形成了一系列的必備研發工具，這些工具經過時間的打磨已經達到了國內較領先水平。去年，CODING 首批獲得了信通院 DevOps “卓越級”認證，這也是國內最高階別的 DevOps 工具體系認證。今年，我們提出戰略升級，結合現代軟體工程實踐和先進理念，推出研發度量、研發流程管理 Compass 等產品，打造有開放生態能力的數字化軟體研發工作流。
“要充分發揮勤勉認真的技術人員的技能，建立一個自由豁達、輕鬆愉快的理想工廠。”——這是索尼公司已故創始人，井深大先生在公司成立之初寫在《成立宣言》中的一句話。我個人非常喜歡這句話，並以它為團隊管理和產品設計的信念願景。
作為軟體企業，需要站在現代軟體工程理論之上和技術前沿之上，沒有工程師可以脫離技術談效率。同時，管理效率不僅僅來自於分工，更來自於協同。我們對先進研發管理工具有三點基本理念：
1.注重協同效應，1+1 > 2，每個人都能獲得交付價值所需的資訊上下文環境，讓團隊中強個體能夠更強；
2.超越流程，基於卓越工程實踐。既要打造優秀的單點工具，也要緊緊圍繞雲原生、DevOps 等技術理念，讓每一個研發團隊以更短的路徑運用卓越團隊的工程理念；
3.一致性、沉浸式的融合體驗。緊密的整合使用者介面和資料，為每個開發者創造能保持專注的線上工作環境。
一站式 DevOps 平臺解讀
接下來我將為大家介紹 CODING DevOps 一站式全景。下圖體現了 CODING 的主要能力分佈，從能力維度上，我們可以將其劃分為專案協同、流水線、測試管理、製品管理、持續部署、知識管理、研發流程管理、PMO Office 及團隊管理幾大模組。
為了便於理解，我們可以將其中幾大模組對應一些朋友熟悉的 Jira、Jenkins 等，基本覆蓋了成熟軟體工程實踐中的全部所需。我們可以從專案管理、工程管理和團隊管理三個視角對它進行解讀。在 CODING 中，「專案」是基本的協作容器單位。它可以泛指一個有生命週期的工程，也可以代表一個固定工作方式的專案團隊。當需求進入需求池後，研發團隊可以使用以 Scrum 為代表的敏捷模型，也可以使用偏向計劃驅動的經典瀑布模型。史詩代表可以橫跨迭代的大粒度需求，需求、任務、缺陷等是基本事項分解單位。CODING 包括了一個成熟的程式碼倉庫服務，需求和程式碼提交、分支之間能夠進行關聯。
運用全新的研發流程管理產品 Compass，研發負責人可以對專案的工作流進行約束和自動化配置。例如需求變更狀態時，檢查對應的程式碼分支是否通過了自動化測試，開發者提交程式碼時需要遵循程式碼分支的命名規則等。
從工程管理視角看。CODING 涵蓋了一套健壯的視覺化流水線能力，包含持續整合、製品管理、持續部署等。持續整合的目的是實現更快的釋出頻次，運用「測試左移」的理念，結合程式碼掃描和自動化測試的能力，研發團隊可以實現每天幾十次的可靠整合與釋出。整合所產生的編譯結果將被納入到製品管理之中，便於版本索引和加速測試和釋出過程。製品掃描功能可以在不訪問原始碼的情況下，通過掃描二進位制元件及其後設資料，找尋元件中存在的漏洞。
持續部署能以自動化方式，頻繁而且持續性的將軟體部署到生產環境，使軟體產品能夠快速的交付使用。持續部署模組中，涵蓋了測試、生產環境的釋出目標環境資訊。根據釋出計劃，可以應用藍綠髮布、金絲雀釋出等多種釋出策略推送製品至線上環境。到這裡，工程實現了從需求到釋出的 DevOps 完整閉環，全環節的價值流、程式碼流、製品流上下文在 CODING 平臺中清晰、透明。
缺乏對人力資源的管理是過去散裝研發管理工具的弊端。為了適應不同規模研發團隊的管理需要，結合本土研發團隊的管理特點。CODING 在跨團隊、跨專案的橫向側提供了一系列團隊管理工具，深度發揮了一站式產品高資料整合度的優勢。
同時 CODING 包含了一個全新的「知識管理」模組，知識空間可以掛載在專案之下或單獨使用。可以使用 Markdown 或富文字的形式編寫和組織產品文件，基於塊集元素的文件結構可以讓團隊成員在文件中自由嵌入例如需求卡片、思維導圖、表格等多種內容結構。
通過「團隊目標」功能，可以在組織層運用 OKR 管理方法，CODING 中可設定公司級、部門級與個人級的目標檢視，關鍵結果可與需求進行關聯實現執行分解和跟蹤。如果團隊成員都能夠通過目標管理機制，從「要我做」轉變為「我要做」，毫無疑問這將會是一個充滿機動性與高效能的團隊。
團隊視角的管理是今天更多成熟組織關心的產品能力，CODING 在平臺層已經涵蓋了組織架構管理、集中許可權管理等等，我們期待能夠吸納和傳遞更多卓越團隊的管理實踐。在稍後的環節裡，我也將為大家介紹今天釋出的兩款新的團隊級管理工具：研發度量和工作負載。
平臺為人服務
話說回來，我們相信工具和平臺是以人為本，為人服務的。工程師的極客精神和慣性信念是「自己動手，豐衣足食」，技術決策者也面臨自建工具，和公有云平臺之間的選擇。那麼為什麼 SaaS 平臺好於自建工具呢？我在這裡打一個比方。自建工具與雲上平臺的關係，好比寵物與牲畜的關係。寵物，例如貓、狗，是嬌貴的，需要持續付出成本與精力細心養護，人為寵物提供關愛與服務，以換取情緒價值；牲畜，例如牛、馬，則是人類經過演化篩選的生產工具，天生是為人類提供生產價值的。
仍然有相當多研發團隊為自建工具無意識的、不計成本的投入，少則投入幾人，多則投入幾十人成立工程團隊，進行學習、搭建、維保和開發工作。這種寵物思維忽略了工具的生產為主的天性，也忽略了雲技術的演進和社會分工能帶來的巨大效率優勢。值得一提的是，CODING 擁有了可能是國內 DevOps 領域最大規模的高水平研發團隊，團隊成員有著豐富的技術、工程和使用者體驗積累。我們建議，技術決策者可以從運維成本、配置成本、易用性、許可權管理、度量與規範等各個角度去做一次理性選擇：是自建工具更好，還是一站式平臺更好。
此外 CODING 還擁有以下優勢：
- 可適應從瀑布式到敏捷的漸進式工作流過渡，支援從已有多種系統中進行資料遷移；
- ChatOps 生態與微信小程式、企業微信、釘釘等 IM 能夠互通，平臺開放了豐富的 API 供二次開發使用；
- 標準版免費，高階版本按人數規模訂閱；
- 充分利用了騰訊雲資源以及 CDN 加速能力，提供速度和可用性上的優勢；
- 免費與付費使用者均提供可用性保障和服務支援。
……
研發度量 & 工作負載新品解讀
希望以上我的介紹，能讓大家對一站式研發管理平臺的理念和優勢，有一個概覽性的認識。現在為大家帶來我們一系列的新產品，首先是研發度量。
德魯克曾寫道：“你如果無法度量它，就無法管理它。”這句話充分體現了度量在管理中的份量。對於注重研發效能的團隊來說，我們渴望去測量和提升創造價值的速度，我們渴望通過度量去及時發現和改進質量問題，渴望能夠比較組織內團隊之間，甚至與行業內其它團隊之間的工程效能，我們渴望有這樣一把好用的尺子。然而，度量確實在許多研發團隊的實踐中是一個複雜的問題。我們見過許多團隊從使用 Excel 去歸集各處的報表，到搭建基於 SQL 查詢或更復雜的資料倉儲的基礎設施。度量涉及到資料來源的規整和清洗，涉及到指標的選取和基線的設定，涉及到對指標的有效解讀和改進措施的判斷。
CODING 利用一站式平臺的資料整合優勢，給注重效能改進的研發團隊帶來了可對全平臺產生的資料進行多維度分析的研發度量工具。它的特徵是開箱即用、高度視覺化、自帶效能指標體系模型，促進 DevOps 工程透明化。
研發度量覆蓋從需求、程式碼、製品到釋出的全鏈路資料來源，可以自由組織個人檢視和團隊檢視，度量檢視帶有健全的許可權管理機制。使用度量查詢器，團隊負責人、PMO 可以定製複雜的視覺化報表，資料可以下鑽，可以匯出，也可以共享投屏。研發團隊其實沒有必要去進行過度的指標設計，通過少數指標（一般不超過 20 個）基本能覆蓋團隊和專案主要維度的統計，更重要的是抓住關鍵指標的有效改進措施。
基於 DevOps 成熟度模型，這裡我們選取了一些參考性指標和基線。例如需求交付週期、缺陷修復時長、自動化測試率等等。以往可能覆蓋這些關鍵指標有相當多的工序要配置，尤其是對於中大型組織，覆蓋較多團隊、較多專案，甚至交叉團隊、交叉專案的情景。
CODING 研發度量將預設基於成熟度模型的效能檢視和質量檢視，檢視內有預定義好的指標設計，通過一鍵開啟這項功能可以便捷的應用到你的團隊當中，無需進行復雜的配置即可直接使用。隨著使用深度增加，研發團隊可以自定義適合自己的公式化指標。
最後我為大家帶來的是工作負載，這是 CODING 提供的一項全新的人力資源管理工具。這款工具定義了一個工作飽和度的指標，能以直觀、視覺化的方式度量一組研發人員工作並行的的情況。尤其適用於計劃驅動型團隊的需求排版，識別閒置開發資源和過度飽和的開發資源。這款工具現在已經上線，可以在 CODING 線上版本中直接體驗和使用。
以上就是我今天為大家帶來的內容。如下圖所示，感謝過去一年這些團隊與我們共創產品。CODING 希望通過打造一站式研發平臺，讓人們相信數字化軟體工廠是可以實現的。我邀請您加入，和其他團隊一道，邁入高效能研發的數字化工作體驗。
點選觀看 CIF 峰會回放