本文爲 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 希望通過打造一站式研發平臺，讓人們相信數字化軟件工廠是可以實現的。我邀請您加入，和其他團隊一道，邁入高效能研發的數字化工作體驗。
