【敏捷轉型，效能提升】萬字長文敏捷轉型實踐系列分享

作者：王先科、田野、王鎖、劉雙、馬越、劉思琪

摘要：本文總結了近 4 年以來部門實施敏捷轉型的實踐及經驗教訓，從 5 個方面進行了闡述：

1. 文化建設下好先手棋

2. 持續敏捷實踐祭出連環招

3. 沉澱實踐指引把牢定盤星

4. 效能度量定準風向標

5. 洞察分析點亮啟明燈

一.概述

“敏捷就是快速應對變化，解決不確定性問題和維護複雜產品”，沒錯，這是敏捷最核心的價值體現。在多部門協作、多業務型別等複雜場景下，如何落地敏捷理念、思維、框架、方法、工具和實踐，實現組織敏捷、技術敏捷、專案敏捷，進而實現業務敏捷，一直是我們追求的目標。近 4 年來，市場與平臺運營中心 - 平臺研發部基於 Scrum 框架進行了很多的嘗試和實踐，有成功的經驗，也有失敗的教訓。本文分別從敏捷文化建設、持續敏捷最佳化、實踐指引、效能度量及洞察分析五個方面，分別介紹我們敏捷轉型的一些實踐：

（1）敏捷文化建設：欲修其身,先正其心，欲正其心,先誠其意。透過培訓、分享、建立敏捷社群、內外部交流、內部考試認證等方式，營造敏捷文化氛圍，糾正誤區，提升認識，增強信心。

（2）持續最佳化敏捷實踐：道阻且長，行則將至，行而不輟，未來可期。敏捷模式落地，離不開持續的實踐及過程中的不斷最佳化，需遵循由簡入繁，由易到難的節奏，先僵化再固化最後最佳化。先從最基礎的敏捷實踐以及需求流轉協作工具開始，在實踐的過程中逐步理解敏捷的思維和方法，並結合部門特點，不斷最佳化，引入更高階的實踐以及更高效的工具，並與 DevOps 的流程和機制結合起來，形成敏捷 DevOps 流程機制。

（3）實踐指引：行之愈篤，則知之愈明，知之愈明，則行之愈篤。實踐與認知相輔相成，敏捷轉型過程中需要不斷總結實踐過程中好的經驗，標準的、通用的可以沉澱為流程規範，無法作為標準規範的，可以以最佳實踐的方式指導後續的實踐活動。

（4）效能度量：懸衡而知平,設規而知圓。有效的度量可以及時發現問題，並輔助管理。透過對全鏈路效能資料的解讀和洞察分析，指導和驅動效能改進。

（5）洞察分析：見出以知入，觀往以知來。敏捷轉型過程中，不能被表面現象所矇蔽，若要透過現象直達本質，需要對過程、現象以及結果進行深刻的洞察分析，以指導改進和提升。

1.1 對敏捷認知的誤區

平臺研發部既直接承接業務需求，服務於金融產品層和運營團隊，又有很多中臺、平臺型別的系統，如營銷權益、活動平臺、mPaaS 等，並且也同時是京東金融 APP 的研發團隊，負責 APP 的原生、H5 研發及發版管理，業務系統多，型別複雜，模式多樣，研發團隊達到幾百人，在如此複雜環境下，如何有效協同各方，持續提升研發敏捷性及效能，是 PMO 團隊首要考慮的問題。落地敏捷研發模式是其中一種非常重要的手段和方式。從 2018 年成立中臺，到現在的平臺研發部，雖歷經多次組織架構變動，但我們一直在踐行敏捷研發和敏捷專案管理。在最初的階段，大家對敏捷的認知存在諸多誤區。

誤區一：敏捷就是小瀑布

把敏捷迭代當成小的瀑布流，仍然執行著瀑布專案模式。當時很多團隊的做法是，每一個迭代做的計劃只是一個使用者故事的一部分，並不能完全交付使用，產品無法拆解最小 MVP 版本，產研測認為這個迭代做一個介面，下一個迭代再做頁面，那麼兩個迭代就合成一個功能去做測試，雖然分成迭代去做，但並沒有在一個迭代裡交付一個完整閉環的可用功能。

誤區二：迭代就是敏捷

團隊經常認為，固定了週期即是迭代，即是敏捷，經常把產品的實現過程流程化，這個迭代做研發，下個迭代做測試，這並不是敏捷，這只是把瀑布式開發階段化的表現了一下。

誤區三：敏捷無需計劃性

認為敏捷就是想到哪裡做到那裡，不需要計劃性。計劃性有多重含義，第一，它可以明確短時間內的目標、所要做的任務及方案、達成可交付的產品。第二，可以做驗收的標準依據 ，也就是計劃內容可以用作目標追尋，方向一致。第三，計劃性可以不斷檢驗歷史積累的經驗是否可用，特別是在評估工作量投入方面、任務統籌方面，不斷的檢驗可以更精準的評估產研的投入。其實敏捷與計劃性不衝突，計劃對任何敏捷開發專案都是不可缺少的組成部分。

誤區四：回顧會無價值

經常排斥回顧會和覆盤會，認為這類會議是無效時間投入，有這樣的時間還不如多寫程式碼。敏捷開發非常重要的點就是，不斷提升團隊的作戰能力，不總結回顧如何提升產能，產生這樣的誤區，有兩方面原因，第一，回顧會的方式方法不得當，方式方法裡面也包含回顧會中是否真正的發現可提升的點。第二，回顧會的改進結論沒有真正的落地執行。

誤區五：敏捷不需要文件

敏捷宣言的第二條 “可工作的軟體勝於詳盡的文件”，很多人理解為敏捷開發不重視文件，甚至以此為藉口逃避寫文件。但敏捷強調 “價值”、“快速交付價值”、“為客戶提供價值” 的理念，研發團隊要把精力放在能夠為客戶帶來價值的地方，避免在不產生價值或者 ROI 低的任務上浪費時間。規範化和常規化的內容形成文件可以大大減少溝通成本。尤其在多團隊協作環境下，文件的重要性和必要性不言而喻。

誤區六：敏捷就是單純追求速度

敏捷的快並非研發的快，敏捷更應該被團隊記住的是靈活，透過敏捷框架，我們可以應對瞬息變化的環境，而不是我們用了一個框架，原來寫 2000 行程式碼的程式設計師就能成為寫 10000 行程式碼的軟體工程師了。另外，透過敏捷，開發效率確實可以提升，但這是建立在各種工具、流程、體系、基本功訓練上的。

1.2 PMO 與敏捷模式推廣

PMO 是一個很特殊的部門，不同行業、不同公司對 PMO 的定位、期望和實際承擔的職責不盡相同，PMO 需根據部門特點和領導期望制定適合當前環境的部門定位。我們對自己的定位是聚焦三大方向，利用敏捷的理念和方法，協同各角色持續、順暢、高質量交付有效價值。

•價值交付方向：透過專業的、全鏈路專案管理，按時保質交付業務價值，提升業務滿意度，透過專案實現組織戰略。

•組織效能方向：透過敏捷研發模式落地及多種提效舉措，提升研發效率、質量、能力和效果。

•洞察分析方向：透過對效能資料、資源投入、專案收益、敏捷成熟度以及團隊協同過程的洞察分析，為部門提供決策依據。

為了支撐以上定位和目標，我們把 PMO 劃分成四大職能，分別為敏捷專案管理中心、效能中心、卓越中心及治理中心。敏捷專案管理中心，透過全生命週期的專案管理，提升戰略落地的確定性及效率，交付有效價值；效能中心，透過從組織、技術、工具、專案層面推動效能提升，提升交付的效率、質量、能力、效果以及安全；卓越中心，透過技術文化氛圍和技術能力建設，提升組織的可持續發展能力；治理中心沉澱知識、經驗、教訓、能力、流程規範、最佳實踐等組織過程資產，提升團隊能力。其中，這四項職責中最核心的支撐力量就是要實現組織敏捷、技術敏捷和專案敏捷，進而實現業務敏捷。

圖 1-1 平臺研發部專案管理全景圖

在專案管理全景大圖中，敏捷有著至關重要的作用和地位，沒有專案和需求的敏捷交付，就談不上組織戰略和業務價值的實現，組織效能也不會持續提升。敏捷研發的流程、機制以及敏捷 DevOps 工具鏈建設，需要持續建設和完善，並透過精細化管理和持續改善行動驅動團隊敏捷成熟度提升，多管齊下，多措並舉，持之以恆方能見到成效。下面將分章節介紹平臺研發部如何逐步實現敏捷實踐落地和敏捷轉型的。

二.文化建設下好先手棋

敏捷轉型，文化先行。如何從根本解決這些問題，轉變團隊觀念，讓更多人接受敏捷並感受到敏捷帶來的好處，是我們面臨的第一個課題。我們透過以下幾個步驟，逐步建設敏捷文化：

•鋪墊：最初階段，PMO 團隊分析當前專案交付過程中面臨的困境，結合內外部實際案例，證明迫切需要引入敏捷研發模式以滿足業務快速發展的需要，並獲得領導支援。

•洗腦：匯入階段，進行大量的洗腦式培訓和宣講，加強對敏捷知識、原理和基礎實踐的灌輸，讓大家接受敏捷，啟動敏捷的實踐。

•培訓：發展階段，團隊 Scrum Master 一般由專案經理兼任，結合實踐過程中反饋的問題，引入外部的敏捷教練和專案管理專家進行分享交流，學習外部優秀的實踐，提升專案經理作為 Scrum Master 角色的能力。

•賦能：全面應用階段，PMO 人力有限，無論是作為專案經理還是作為 ScrumMaster，都無法覆蓋到所有的專案和需求，以往我們的做法是 PMO 帶一個專案團隊，待團隊逐步掌握敏捷方法，再去帶另外一個，或者同時帶領多個團隊進行敏捷管理和實踐。這樣做法存在的問題就是，頭疼醫頭腳疼醫腳，無法從根本提升敏捷能力。現在我們的做法是，進行敏捷賦能，由 PMO 團隊規劃敏捷培訓系列課程，團隊中敏捷積極分子參加培訓課程，名為” 共振計劃 “，就是將更多的成員培養成 Scrum Master，同時加強對敏捷知識、原理和基礎實踐的灌輸，讓敏捷變成所有人的工作價值觀，提升專案團隊自組織、自敏捷能力，這也是作為敏捷文化建設的重要環節。

2.1 內部培訓賦能

PMO 團隊內部進行頭腦風暴，梳理作為 Scrum Master 和敏捷團隊成員的痛點和建議的解決方案；其次，我們在專案團隊內部尋找多名研發和測試的敏捷積極分子及團隊 leader，進行了深度訪談，瞭解他們的困惑、對敏捷的認知以及面臨的痛點；然後，我們根據訪談結果，制定調研問卷，在大部門內部進行更廣泛的調研。

透過以上三個方面的工作，收集到大量敏捷實施與落地方面的反饋，為我們有針對性提升和最佳化提供了基礎。舉個例子，經過多番討論和調研，發現產研測同學對敏捷只是瞭解概念，並沒有真正的掌握核心價值及執行過程的要點，甚至很多動作跑偏，違背了敏捷的初衷。因此，我們決定大力提升團隊成員敏捷專案管理知識，提升敏捷文化，我們舉辦了名為 “共振計劃” 培訓課程，針對非專案經理角色進行敏捷研發和敏捷專案管理系列課程，在專案經理和非專案經理之間產生” 同頻共振 “，使非 PMO 的專案成員具備 PM 及 SM 能力，從而提升整個團隊的自敏捷、自組織能力。

” 共振計劃 “是一項專案管理&敏捷管理賦能計劃，計劃透過針對非專案經理角色（產品、開發、測試）進行專案管理 + 敏捷管理賦能認證。課程體系設計別從基礎能力到專項能力進行分享，每個章節的課程都運用實踐作為理論支援，而且每個實踐場景都是我們的實際專案經歷，這讓大家對整個知識體系的掌握更加清晰。下面給大家分享一下兩期課程的設定及上課情況，第一期注重加強專案管理能力提升和敏捷基礎理念和基本技能輔導，整體分為培訓課程 + 導師制陪伴式專案實踐 + 考試認證三部分，第二期重點加強敏捷高階能力提升和 Scrum Master 培養，致力於提升整個組織的自組織、自敏捷能力，整體分為培訓課程 + 各角色分享 + 線下實踐 + 知識競賽四部分。

圖 2-1 共振計劃一期課程體系



圖 2-2 共振計劃二期課程體系

圖 2-3 共振計劃課堂

目前已經舉辦兩期的活動，兩期學員均在 100 人以上，經反饋滿意度達 90% 以上，目前很多團隊已經可以實現自運轉能力，這樣的活動我們也將持續開展，後續計劃走出平臺研發部，引入集團內外部優秀敏捷實踐以及更高階的敏捷技能、方法和工具。

2.2 外部分享交流

敏捷轉型不能閉門造車，別人的實踐經驗對我們來說是非常好的借鑑。在敏捷轉型過程中，透過組織與 PMI 的分享、與行業大廠的經驗交流、引入外部優秀敏捷為組織賦能、走出去參加行業大會、加入敏捷社群等方式，時刻與時代要求與行業先進水平保持同頻。另外，透過 “共振計劃” 敏捷賦能培訓，我們也選拔並培養了一大批既對敏捷感興趣，又具有一線實踐經驗的研發、測試及產品同學，目前我們正在計劃透過持續的運營，打造內部的敏捷社群，打造更廣泛的影響力。

圖 2-4 與業界交流敏捷落地經驗

三.持續敏捷實踐祭出連環招

持之以恆方能行穩致遠。談到敏捷，大多數人認為就是兩週迭代、站會、回顧會等。但是在實際上遠遠不止這些內容。還記得之前在轉型的初期，對於相關的實踐很難理解，哪怕是在參加了 ACP、CSM 等培訓，或者是經過教練傳幫帶後也只學其形，未達其意，甚至可能對敏捷的理念產生了質疑，同樣對於團隊來說，初期非常痛苦，大家根本不知道要做什麼，為什麼要這麼做。但是在經過不斷的嘗試和實踐之後，敏捷為團隊帶來了翻天覆地的變化，研發效率提升、專案風險管控、應對業務頻繁變化等都能夠使用最小成本帶來更大收益。因此對於敏捷或者 Scrum 框架來說，我們不僅要學習它的方式和理念，更重要的是進行實踐並不斷改進，尋找最適合當前環境的落地方式，走出敏捷轉型的困境。

回想幾年之前，業務處於高速發展期，部門內部系統眾多，各小組無統一規範和管理模式，各角色協同配合難度大，需求交付速度慢，變更成本高。以 APP 發版為例，最初是 3 週一個開發測試班車，2 周後再上線，專案組無法應對產品源源不斷的需求，版本上線內容可預測性差，封版整合耗時長，手工指令碼打包錯誤率高。

在此背景下，我們決定進行更加徹底的敏捷轉型，採用 Scrum 框架進行敏捷試點，並引入敏捷 DevOps 理念，將工具鏈層打通，選定的是場景適合、團隊意願強烈的移動平臺研發部 APP 發版專案團隊，經過近兩年的實踐及不斷最佳化，京東金融 APP 發版週期從原來的至少 4 周變為現在的 2 周，迭代週期由原來的至少 5 周變為現在的 3 周，整體縮短 40%，需求按計劃交付率提升約 10%，版本變更下降 10% ，業務滿意度不斷提升。下面將以京東金融 APP 如何逐步實現敏捷轉型並帶動部門整體敏捷落地為例，介紹敏捷是如何在我們部門落地生根的。

3.1 匯入階段 - 敏捷交付 1.0

首先確立敏捷轉型的目標，即實現更快速、更可靠發版，發版節奏和版本容量對齊業界主流 APP。確定轉型目標後，我們開始著手進行相應的變革動作，首先是要把小瀑布制研發模式轉變為基於 Scrum 框架的模式，同時，確定了敏捷轉型小組及職責：

• 組長：二級部門管理者。

• 工具負責人：負責打通行雲、PMP、JCI 等工具。

• 業務專案經理/產品經理介面人：負責提供產品路線圖。

• APP 敏捷專案經理：負責敏捷方法落地，推進組織敏捷改革，解決部門間、各角色間協同問題。

• 敏捷教練：負責指導團隊敏捷轉型，解決流程卡點。

• 開發團隊組長：負責承擔團隊 Scrum Master，帶領團隊落地敏捷各類活動。

專案組制定轉型規劃，1.0 階段目標是實現 4 周發版（2 周開發測試，2 周打包、迴歸、灰度和釋出），主要分為 5 步：

•準備： 敏捷教練及專案經理充分調研，收集問題和痛點，制定解決方案和詳細計劃，並向 leader 彙報，獲得充分認可與支援。

•啟動： 組織啟動會，邀請產研 leader、各關鍵角色參加 APP 的敏捷轉型啟動會，拉齊認知，共識目標，統一節奏。

•培訓： 對涉及到 APP 原生的所有一線產品經理、開發以及測試人員進行全員培訓。

•組織： 由專案經理或 Scrum Master 將圍繞各業務線的 APP 原生相關的產品經理、開發、測試，組建成 7 個敏捷小團隊，團隊內進行敏捷協作，並由敏捷教練作為顧問。

•工具： 推進工具建設和使用，包括程式碼釋出、分支管理、需求管理、質量管理、迭代管理等。

•落地： 首先保持 3 周開發測試周期，強化版本目標、計劃以及承諾，所有需求錄入行雲。3 個迭代之後，正式過渡到 2 周開發加測試的迭代週期。

（1）落地過程中，傳遞新的理念，賦予各個角色新的職責。

圖 3-1 角色職責變化

（2）制定多種看板，例如在 1.0 階段，5 周的發版週期【3 周開發週期（開發 + 測試）+11 天（整合 + 打包 + 迴歸 + 灰度 + 上線）】，另外依據發版週期指導敏捷各類活動，如站會、計劃會、迭代演示會等。



圖 3-2 1.0 階段的釋出計劃



（3）根據發版日曆，按固定節奏開發測試，在上線視窗期上線業務所需內容。



圖 3-3 按節奏開發，按需釋出

（4）制定規模化敏捷物理看板（引用 SAFe 框架理念，紅色線條代表故事間的依賴關係）。



圖 3-4 1.0 階段物理看板

（5）引入敏捷 DevOps 概念，建設 DevOps 工具。

圖 3-5 DevOps 流程和工具

透過以上實踐以及工具的引入，京東金融 APP 迭代節奏明顯加快，從 5 周班車制變為 4 周釋出火車制：

圖 3-6 1.0 階段京東金融 APP 釋出火車

3.2 發展階段 - 敏捷交付 2.0

經過 1 年的磨合和適應，團隊開始逐漸摸索出敏捷的精髓，不但大大提高了信心，同時又能更好的擁抱業務變化，以更小成本應對需求變更。在此基礎上，迎來了 2.0 階段的發展，此時大家開始考慮如何在原有的敏捷框架下，探索出適合組織的新方法和新實踐。敏捷交付的內涵不僅僅是交付速度快，而且要有持續性，同時還需要有穩定的交付質量。敏捷交付 2.0 的目標設為 4 項：

•業務目標一：協同一致

•業務目標二：構建質量

•業務目標三：加速業務需求上市時間

•業務目標四：交付業務價值

做法依舊持續執行 4 周釋出火車制度，但持續完善細節並最佳化流程機制，提高研發效率和質量：

•架構解耦，元件化；

•2 周迭代內持續整合；

•細化 DoR &DoD；

•強化敏捷 PRD ，使用者故事&AC；

•強化迭代內變更管理；

•fmPaaS 移動研發平臺；

•自動化單元測試；

•IDE 程式碼評審外掛；

•質量門戶建設；

•研發效能度量資料；

根據團隊交付形態，變更了版本節奏，升級了迭代日曆。



圖 3-7 2.0 階段的版本節奏



圖 3-8 2.0 階段的版本日曆



看板也進行了簡化。

圖 3-9 2.0 階段的物理看板

敏捷機制更加精細化，強調需求拆細、條目化，並按節奏開發，按需釋出，同時不斷反饋和改進。

圖 3-10 條目化需求，按節奏開發，按需釋出



3.3 全面應用階段 - 敏捷交付 3.0

經過 APP 團隊不斷的迭代嘗試，部門將目光放到所有團隊，開始擴大戰果。在這個過程中，不是簡單的完全照搬金融 APP 的實踐，而是在敏捷的思維和 Scrum 的框架下，結合各團隊自己的特點，在實踐的基礎上，不斷修正和最佳化，同時對敏捷團隊的管理和要求也更加精細化。在金融 APP 敏捷轉型成功的鼓舞下，各團隊都開始進行敏捷轉型，大部分都是基於 Scrum 框架，並根據各自專案和部門特點持續最佳化和完善，形成適合自己特點的敏捷實踐，在迭代節奏上，絕大部分團隊都遵循雙週迭代的節奏。



圖 3-11 基於 Scrum 的框架的實踐

3.3.1 最佳化版本日曆

各個團隊均強調版本日曆的重要性，團隊嚴格遵守迭代日曆的約定，形成固定節奏。

（1）透過版本日曆可以清楚的知道業務何時進行需求溝通，需求優先順序何時進行確認，產品 PO 何時進行 PRD 設計，團隊何時進行需求評審，以及團隊承諾何時交付等。

（2）透過版本日曆的約束，糾正了各業務隨時隨地，雜亂無章的需求溝通，同時結合著《需求准入規範》，設定以價值為導向的原則，讓團隊做有意義的事情。

（3）部分團隊為應對需求插入採用需求置換原則，團隊每個迭代的總工時固定的，因此約定業務需求插入執行需求置換，並且只能置換掉並未啟動開發的需求，以求降低影響。

（4）團隊內部的迭代原則：

•固定評審時間：如每個迭代第二週星期三進行需求評審，產品輸出優先順序。

•固定排期時間：如研發在週五輸出研發排期，測試在次週週一下班前輸出排期。

•例外情況處理：對於存有待辦的需求可適當延期給排期，但要與業務方同步；研發排期如果開始時間超過了迭代第二週的週三，則無需排期。



圖 3-12 3.0 階段的平臺系統版本日曆示例

3.3.2 重視回顧會

回顧會議 (retrospective meeting) 作為 Scrum 最有價值的會議之一，在敏捷迭代實踐中佔據非常重要的位置。平臺研發部重視回顧會的作用，關於回顧會，我們遵循以下 5 個原則：

•對事不對人： 回顧會議不是批評和自我批評，而是識別團隊的改進措施；不是追究責任，而是要考慮如何做的更好，如何讓我們持續進步。考慮如何充分利用團隊的力量來預防錯誤、及時發現潛在問題。

•人人平等，全員參與： 回顧會議不能一言堂，不能被少數人左右，團隊成員是平等的。每個人都應該充分分享自己的觀點，在回顧會議上希望是給所有人分享盡可能全面的、不同視角的資訊。

•視覺化團隊績效： 在回顧會議上可以採用燃盡圖、燃起圖、折線圖等形式展示團隊的績效，例如本次迭代與上次迭代相比，交付速度是否提升了？截止到本次迭代，我們累計實現了哪些改進措施？另外，回顧我們已經落地的措施，可以建立起團隊成員對回顧會議價值的認可。

•改進措施要落地： 回顧會議一定要輸出下個迭代要落地的改進措施是什麼？這樣才能不斷提升。不要試圖解決在回顧會議上識別出的所有的題，要聚焦短板，重點突破，一次識別出 1-3 項改進措施即可。

•發現優點，建立信心： 在回顧會議上不但要發現改進點，也要發現優點，發現進步和受大家歡迎的成員和做法，讓大家建立起對團隊、對產品的信心。

透過正確地組織回顧會，讓團隊認識到問題所在，清楚的知道自己的優劣勢，從而進行持續改善。

3.3.3 加強覆盤

回顧會作為 Scrum 模式固定的實踐，在每個迭代固定執行，除此之外，我們在近兩年，也同時加強了專案覆盤，覆盤會也成為專項專案和迭代類專案不可或缺的環節。與回顧會不同的是，覆盤會一般按月度或季度組織（事故覆盤隨時進行），除去敏捷團隊成員之外，還會有更多的業務、運營及部分 leader 參加，且比回顧會更有宏觀性和整體性。各角色以回顧目標 - 確認解決 - 分析影響因素 - 總結經驗教訓這樣的步驟，針對業務目標、專案收益、資源投入、經驗教訓、下階段改進目標等內容進行討論和反思，拉齊認知，對齊目標。組織好覆盤，最重要的不是覆盤會議，而是會議之前的準備工作，如下圖所示：



圖 3-13 覆盤會議要點

透過覆盤會的形式，大家停下來回頭看，目的是更快的向前走。目前，平臺研發部各專案團隊及敏捷團隊均建立了定期的覆盤機制。

3.3.4 流程及工具輔助實踐

經過 2 年的不斷嘗試，團隊不僅加深了敏捷理論，同時也落地了更加精細化的管理方法：

•DevOps 敏捷成熟度評估：定期進行團隊敏捷成熟度評估，主要是從 3 個角色，5 大能力的維度進行評估，並總結經驗持續改進（詳見 4.2）。

•團隊責任心培養：從分配任務升級為自認領，敏捷所提倡的也是團隊能夠自認領，每一個人都是任務的 Owner。

•需求拆解指引：規範大需求拆解，使需求具備業務最小 MVP 版本交付的狀態（詳見 4.4）。

•任務拆解原則：充分使用行雲，在任務拆解時，遵守以每條任務 8H 最佳，16H 其次，最大不超過 24H 的原則。

京東金融 APP 落地敏捷研發模式的過程中，移動平臺研發部研發和測試團隊給與了專案組堅定的支援和充分的試錯空間，在確保 APP 安全合規發版的前提下，實現了快速、穩定以及順暢的需求交付，體現了敏捷帶來的價值。透過金融 APP 專案團隊的成功的實踐，提升了大家的信心，進而帶動整個部門敏捷研發模式順利落地，並透過精細化管理和持續改善行動驅動團隊敏捷成熟度的不斷提升，成為快速實現業務價值及支援業務低成本快速試錯的基礎和保障。

四.沉澱實踐指引把牢定盤星

在敏捷轉型過程中，不能完全照搬理論，需要結合當前客觀環境，並不斷總結最適合自身的實踐，很多實踐未必是標準的流程規範，但有時可能比流程規範更能指導實踐。流程規範一般規定了必須要做的事情，或者不能做的事情，帶有強制性，而實踐指引卻是告訴你以何種方式做大機率是最優的，帶有建議的性質，流程規範 + 實踐指引共同構成了敏捷落地的基礎保障。平臺研發部在敏捷實踐過程中，總結了一些有用的實踐指引，給到專案經理和各研發團隊 Scrum Master，以更好的落地敏捷研發模式。

4.1 敏捷管理裁剪指引

PMO 團隊不斷積累和總結經驗，形成專案管理、敏捷管理的 SOP 流程，並制定了標準化文件以及對應的裁剪指引，作為專案管理的統一的、最基本的標準。專案管理 SOP 流程中我們把專案分為兩類，第一類是：業務專項，即有明確的目標、時間節奏、資源投入及預期產出，一個或幾個階段就可以輸出全部交付物，這類專案既可以按瀑布方式執行，也可以敏捷方式執行或部分模組用敏捷方式執行；第二類是產品迭代專案，此類專案一般在持續運營階段，或者是探索型迭代產品，這類專案幾乎都是在以敏捷迭代方式執行。對於這兩種專案我們規定了標準動作及在實踐過程中的裁剪指引，專案經理及 Scrum Master 在敏捷實踐中依據團隊的實際情況進行裁剪，以下是迭代類專案裁剪指引：



圖 4-1 產品迭代 - 敏捷實踐工作裁剪指引



4.2 敏捷 DevOps 實踐指引

DevOps 是文化理念、實踐和工具的組合，用於促進軟體開發過程中各角色之間的溝通、協作與整合，以提高組織持續交付高質量軟體的能力。敏捷與 DevOps 之間的區別在於，敏捷專注於最佳化開發生命週期，而 DevOps 將開發和運維統一在 CI/CD 環境中，圍繞非敏捷關注的實踐而構建。敏捷和 DevOps 都旨在及時交付高質量的軟體，當一起使用時，構成敏捷 DevOps，結合敏捷思維、敏捷實踐以及 DevOps 相關流程和工具，達到持續在最短週期內交付客戶價值的目的，並且將研發流程與 DevOps 工具鏈整合，全鏈路提升交付效能。

平臺研發部結合業界 DevOps 實踐及部門特點，沉澱了敏捷 DevOps 在研發全生命週期各個階段的活動，包括每個活動的主要內容、負責人、參與人、輸入、輸出、工具以及過程指導，用以指導各個角色在落地敏捷 DevOps 理念及流程時作為實踐的參考。



圖 4-2 敏捷 DevOps 主體流程



4.3 敏捷成熟度評估實踐指引

從高效能團隊維度，敏捷團隊理解自己當前能力，自我確定提升目標、舉措、計劃，以此持續改善，我們制定了敏捷成熟度評估的實踐指引，Scrum Master、PO、專案經理、敏捷教練及三級管理者針對敏捷成熟度從五個維度進行評價，分別為業務敏捷、產品管理、敏捷團隊、迭代運作以及工程實踐，每個維度又分為若干子項。敏捷團隊定期自評，也可以定期或不定期邀請敏捷教練、管理者進行專家評估，確定當前處在成熟度的哪一個級別，成熟度級別共分五級：

•一級：有意識的（坐）

•二級：有實踐的（爬）

•三級：熟練的（走）

•四級：量化可靠的（跑）

•五級：最佳化創新的（飛）

每次評估之後，根據各個子項的評價分數，以雷達圖的形式進行呈現，並由團隊進行洞察分析（詳見 6.2），由 Scrum Master 帶領團隊制定改進措施和計劃，專案經理進行跟蹤和推進，敏捷教練按需提供支援。

4.4 收益管理實踐指引

在精細化經營的大背景下，業務和產研都更加重視專案和需求的投入與產出比，需要進行體系化的收益管理，逐步實現業務需求收益的可評估、可量化、可衡量。透過統一專案收益管理的範圍與機制，提升專案收益管理規範性，讓產研資源聚焦於高產出業務。為此，我們制定了收益管理的實踐指引。收益管理涉及的兩類角色：

（1）需求方

需求負責人負責設定收益指標，即負責參照收益指標庫制定合理的、可量化的、可驗證的專案/需求收益指標並在交付專案後按要求反饋專案收益實現情況，在行雲提交驗證結果，並提供支撐材料。

（2）執行方（產研測）

•產品負責人：評估收益指標技術角度合理性，專項類的收益指標需經過 C-3/C-2 複核（參考立項流程，立項郵件涵蓋收益指標）。

•專案經理：

專項專案 - 負責發起立項，組織立項材料編寫；跟蹤專案收益達成情況，提醒驗收人及時完成業務驗證，推動專案收益目標達成，組織評估收益合理性與可驗證性。

迭代類專案 - 負責組織需求評審會，迭代開始前收益收集，跟蹤收益達成情況，提醒驗收人及時完成業務驗證，推動需求收益目標達成，組織評估收益合理性與可驗證性。

•團隊成員：如實評估與填報工時。

專項專案按照整個專案的維度進行收益管理，迭代類專案按照單個需求的維度進行收益管理，我們對銷售類指標（如直接效益類指標、使用者類指標、頁面類指標）要求是必須填寫收益，效率提升類的高度建議有收益指標，對體驗提升&系統技術類不做明確要求，如有可提供收益指標。迭代類專案收益管理流程如下：



圖 4-3 迭代類專案收益管理流程

專項類專案收益管理流程如下：

圖 4-4 專項專案收益管理流程

利用行雲，實現全流程的線上化收益管理。



圖 4-5 行雲收益管理線上化流程



4.5 需求拆解實踐指引

為進一步踐行敏捷理念與研發模式，需要細化需求顆粒度，需求顆粒度足夠細緻，質量才能足夠高，小批次、快速、頻繁、高質量交付業務可用的需求是我們追求的目標，為此，我們結合實踐總結形成了需求拆解實踐指引。具體的做法是，首先透過識別 + 引導的方式，瞭解業務目標和運營計劃，站在需求提出方的角度識別業務訴求，引導需求提出方說出業務訴求背後的目的/目標/意義，即識別出說的，引匯出沒說的，形成最原始的業務訴求，透過產品分析，形成產品需求，再進一步分解成可交付評審的功能點，最後才是我們常說的 Story。需求拆解需滿足以下幾個原則：

•獨立性：功能是獨立實現的，低耦合的。

•可交付：功能是可以交付使用的或驗證的，不是幻想的功能。

•可商討：功能是有細節的，可以討論更具體的內容。

•有價值：強調價值。

•可估計：主要強調每個 Story 可以估算工作量。

此外，需求拆解還有一個重要的原則，就是大小合適，從我們實踐的經驗來看，比較理想的情況是把需求拆分成多個使用者故事（Story），可以在 1~2 周完成開發 + 測試 + 上線的顆粒度。但有些需求確實很大，從業務交付的角度來說，很難拆分，如果產品或研發人為把需求拆分為多個小需求，但這些小需求不是閉環的小功能，不能獨立交付業務或者使用者使用，這樣的拆分有沒有意義，有沒有必要？我們的回答是：要分不同情況分別看。單獨上線不能獨立使用的功能，對業務來說好像沒什麼意義，並且可能會增加測試迴歸、研發上線的工作量，但也會帶來其它收益：

•保持迭代的節奏，每兩週內都有交付物（雖然該交付物未必真正可用），提升產研同學的信心。

•提高協同性。這種階段性輸出，方便需求提出方掌握研發進度和彙報進度，提升信任感。

•減少了變更的成本。若在此過程中業務需求有變更，這種階段性輸出物（或功能模組）由於已經被測試驗證過，是可以繼續複用的；另外一方面，需求提出方在試用階段性輸出物時，可以體驗到部分功能或流程（雖然不完整，或者流程沒有閉環），若發現有問題，可以提前變更，減少變更成本。

總結以上，這種需求的強制拆分在一定程度上也是有意義的。需求拆解實踐指引提供了一種參考和視角，至於在真正的實踐中需不需要強制拆分，產研可以根據實際情況進行評估和判斷。

五.效能度量定準風向標

管理大師彼得.德魯克說過：“沒有度量就無法管理”。兩年來，我們搭建並持續完善了適合團隊特點的效能度量體系，經歷了由簡入繁、再基於實踐過程進行化繁為簡的過程，由關注資料到關注問題，由效能度量到效能提升的過程，並逐步實現了全民關注效能提升的技術文化氛圍。

5.1 為什麼需要度量

•從 PMO 組織專案管理工作層面來看，效能度量是一種全域性監控的工具，透過度量為起點，透過度量資料反饋的問題和待改進點，提升組織效率、質量和能力。

•從單個敏捷團隊來看，度量的資料結果可以提供相對直接和客觀的團隊進步成果，增加團隊自我認同感和持續提升的動力。

•從 Scrum 框架來看，度量可以對團隊的迭代回顧提供客觀的資料幫助，並對調整提供有針對性的指向、以及對調整後結果進行有效性的評估。

5.2 需要哪些度量指標

對於剛開始啟動效能度量的團隊來說，管理角色看到指標總是很興奮，全都想要、哪個都不想放棄。對於有這樣的想法其實很正常，因為這畢竟是先進公司的優秀實踐，但是如何選用合理的指標呢？可以試試從這個角度去評估：

•既行的敏捷管理和 DevOps 流程

•既有的線上化管理系統

•團隊有共識的存在的問題

•當前組織內管理層的期望

下面，將從以上幾個角度，舉例說明具體的思路。

•既行的敏捷管理和 DevOps 流程：這一項既是一個評估考慮點，更是一個組織做度量的前提。組織/團隊先要有一套執行相對成熟的流程機制，大家遵守同一套遊戲規則，才有去度量的意義。說回來，怎麼去結合當前執行的流程去選用度量指標，舉個實際的例子，如果當下 Scrum 框架落地範圍已經切實覆蓋了產品經理角色（由於組織架構的原因，很多團隊 Scrum 的落地都僅在研發測試團隊），在交付效率方面，可以選用 “產研交付週期” 指標。相反如果產品經理角色表面上認可實行 Scrum 框架，但實際上內心和行為並不十分配合，這個階段就不建議開始 “產研交付週期”“需求分析週期” 的度量，因為這些指標對於眼前的團隊改進大機率起不到實際作用。

•既有的線上化管理系統：萬事開頭難，度量也一樣。選好了適用的指標，發現當下用的管理工具/線上化系統並不完全支援，獲取資料花費大量的人工成本。這種情況下，建議結合指標的必要性和獲取資料的難易性再進行綜合評估。對於團隊自己努努力、動動手、費些時間的指標，建議堅持獲取（也可以成為線上管理系統迭代最佳化的輸入），對於強依賴外部團隊而獲取的指標，建議期初先放一放。

•團隊有共識的存在的問題：這個很好理解，例如測試角色認為研發提測質量不好，那用資料說話，就去看一看程式碼 bug 相關的統計、例如千行程式碼 bug 率、reopen 率等等。

•當前組織內管理層的期望：這個也很好理解，領導層的期望無非是 “多、快、好、省”，但需要結合當下的問題和痛點，確定管理層最急切的期望。對於大多數網際網路 IT 團隊來說，第一期望通常是對業務側的感受來說；快！那就篤定的選擇：產研交付週期。

5.3 如何循序漸進的實施度量工作

簡單來說可以分為 3 個步驟：確定度量週期 → 分析解讀度量報告 → 最佳化工作方法及基礎設施

•選擇適用的度量週期。度量週期的選擇也需要結合迭代週期，一般選用 2 周迭代的團隊，度量週期可以定為月度（注意，而不是 2 周）。度量週期和迭代節奏本身並沒有強繫結的關係，度量週期太短，會導致資料區域性性表現和影響的凸顯，也無法有效反饋團隊的成果（因為人並不是機器，不是簡單的換個檔就能立馬加速）。任何改進都需要有一定的耐心、給與團隊和決策的信任。

•進行度量報告的透明、與團隊成員一起進行分析解讀。注意這裡的關鍵詞是 “一起”。分析並不是報告輸出者一個人的事情，解讀也不是脫離團隊的空想。分析者應當給出團隊直接的資料資訊、環比的變化、帶來負向變化的直接原因（例如某幾個需求週期超長導致團隊平均週期延長），將這些資訊共享給團隊，與當事人一起分析原因和後續改進計劃或減緩措施。

•基於識別的改進點，通常逃不出這兩個方向：流程/工作方法的改進、基礎設施的改善。並不是所有的最佳化點都要真的一一去落地實現，需要考慮投入收益，長期計劃和短期行動，尤其是基礎設施方面，如果花很大力氣去解決個例問題是不經濟的。總而言之，凡事不走極端，需要綜合全面的考慮。

5.4 平臺研發部度量實踐

基於以上的思路，平臺研發部在效能度量方面持續實踐，總結為 “525 研發效能度量實踐”，概括來講：

•五大度量指標群：交付效率、交付質量、交付能力、交付安全、交付效果。每一個度量指標群下包括多個具體的度量指標，選取最核心的指標，按照一定的權重和演算法，組成整體的效能健康度模型。

•兩級度量體系：C2 級別的月度及年度效能度量報告、C3/C4 級別的雙週洞察分析會議。

•五個效能提升實踐：單位化核心指標、進行洞察分析、設立提效官、提供分析思路框架、組織團隊分享。

5.4.1 五大度量指標群

（1）核心度量指標

基於行業的實踐以及與集團內 BGBU 兄弟部門的溝通交流，我們選取了以下幾個核心的度量指標，分別從效率、質量、能力、效果以及安全五個方面，對產研效能進行量化評估。

•交付效率：指標包括產研交付週期、雙週交付率、人均周/月吞吐量、需求吞吐量/率。從衡量交付效率的多個指標中，選取以上幾個，分別從需求提出者視角 (產研交付週期、雙週交付率)、需求實現者視角 (人均吞吐量)，以及部門整體視角 (需求吞吐率/量) 衡量交付的效率情況。

•交付質量：指標包括線上缺陷率、千行程式碼 bug 率、缺陷關閉率、平均缺陷關閉時長。從衡量交付質量的多個指標中選取以上以上幾個，分別從線上缺陷密度（線上缺陷率）、提測質量（千行程式碼 bug 率），以及缺陷解決程度（缺陷關閉率）、缺陷解決和驗證的效率（缺陷關閉時長）衡量交付的質量情況。

•交付能力：指標包括髮布次數、釋出頻率。釋出頻率是衡量部門交付能力的核心指標，它反映了價值的流動速度。更快和更可靠的釋出，意味著更強的持續交付能力，產研可以更頻繁地將更小批次的需求投入生產，業務方可以更快速體驗到產品新功能。

•交付效果：主要指標是 ROI 達成率，反饋收益的達成比例。

•交付安全：合規及安全漏洞及修復數量。該指標用以度量近期在安全、合規方面的量化資料及趨勢。

（2）效能健康度

效能度量的指標眾多，但每一個指標僅代表某一個方面，無法代表部門整體的效能情況。為此，我們把多個核心指標整合到一起，按照一定的演算法和權重，組成效能健康度指標，用以直觀呈現部門整體的效能（主要是效率和質量）概況及趨勢。現在該指標作為一個實驗性指標，正在徵集反饋並不斷最佳化中。如下圖所示：



圖 5-1 效能健康度



5.4.2 兩級度量分析體系

在剛開始進行效能度量時，由於人力和指標/資料自動化、以及指標複雜度的問題，我們僅進行 C-2 大部門維度的度量，後來隨著指標的精簡和資料線上化，我們開始賦能每個產品線團隊的專案經理角色效能資料度量和分析的方法，用了大概 3 個月左右的時間，各個 C-3 維度的產品線團隊開始定期進行月度開展度量工作。一方面，基於各自團隊的特性新增了一些附屬指標並進行差異化評估，另一方面，各團隊又進一步下鑽到專案角度、C-4 角度等進行詳細分析。後來，各 C-3 設立提效官（介面人），負責本部門雙週維度的度量資料計算及洞察分析（詳見下文效能提效官），C-3 部門的效能度量分析工作逐步由專案經理轉變為部門提效官。

5.4.3 五大效能提升實踐

（1）單位化核心指標

所謂的單位化核心指標，就是讓指標平均到專案、平均到個人，再縮短改指標的單位時間。舉個很好理解的例子，各個團隊都知道需求吞吐量是個衡量團隊交付能力的重要指標，但由於每個團隊的人員規模不同，導致團隊橫向比較時沒有任何可比性；又因為每個月份可能工作日數量不同（例如遇上十一假期等情況），也會導致團隊自身時間維度上展現的趨勢沒有持續可比較性。基於以上，我們制定出了 【人均周吞吐量】 指標，不管是橫向、還是時間縱向，都可以相對穩定的具有比較和分析意義。

（2）洞察分析

•C-2 級別洞察分析

根據交付效率、交付質量及交付能力的資料，首先進行資料解讀，然後進行關聯分析、趨勢分析和因果分析，提出待改進點。如下圖所示：



圖 5-2 C-2 級別資料解讀



圖 5-3 C-2 級別洞察分析

•C-3/4 級別洞察分析

基於 C-3/4 與 C-2 資料的對比，進一步進行下鑽分析，找出具體的問題所在。舉一個例子，在 C-2 級別的度量報告裡，對【產品處理階段】時長進行了度量，並且細分到待處理時長和處理時長，用以評估平臺類產品經理對業務需求的支援效率和資源等待情況。下方是 2021 年某個團隊做的下鑽分析，一方面從專案角度入手，識別出拉長週期（或者說在平均週期以上）的專案，對這些專案在該度量週期內的事情進行分析，另一方面，從週期較長的 Top5 為切入點、再下鑽到這些需求的各個階段時長，進行詳細分析。各 C-3/4 部門根據自身部門特點，在 C-2 北極星指標基礎上，可以定製自己的度量指標以及度量報告模板。

（3）設立效能提效官

基於專案經理角色開展各團隊的效能洞察分析的動作和成果，各個部門/團隊都逐漸重視和正視效能度量的意義和價值，為了去輻射和傳達提升效能的實踐經驗和動作導向，我們又在每個團隊中發起了 “效能提效官” 的報名，由此每個團隊都提報了 1~2 位提效官，用以自驅主動、更加貼切詳細的分析其團隊內部的效能資料，讓效能提升不再是 “專案經理” 的目標，而是實實在在團隊的目標。因此，不管是團隊做得好的、還是待改進的問題，第一負責人都是團隊自己，而各個專案經理的工作重點逐漸轉變為：

•定義標準，總結通用問題和解決方案，沉澱最佳實踐。

•以顧問角色，指導各團隊提效官。

•檢查度量資料的真實性和客觀性，對於不合理的動作進行糾偏。

（4）提供分析思路框架

效能提效官有了、度量資料包告也有了、提升目標也設立了，但糾結怎麼結構化的去識別瓶頸和指定解決方案，開始成為各個團隊的通用問題。大家在不遺餘力的找出 “問題需求” 之後，往往陷入瞭如何去制定有效改進措施的自我困惑中，一方面要實際有效、另一方面也要避免 “矯枉過正” 的做法出現。以 “產研交付週期” 舉例，我們以優秀實踐經驗而明確的導向出發，為各團隊效能提效官提供了以下分析思路框架，旨在引導團隊：1）拆小需求 2）做好計劃。



圖 5-5 分析思路示例

（5）組織優秀團隊分享

“最具說服力的不是報告上數字的提升，而且兄弟團隊的接地氣的分享”。基於效能度量報告，定期優秀團隊和個人進行分享，在共性問題上聽到其他團隊的解決小妙招時，往往能讓大家更有感觸，原來同樣的問題，還能這麼解決，同樣的困難、同樣的阻力，再堅持一下就真的可以擊破！

六. 洞察分析點亮啟明燈

6.1 效能度量資料洞察分析

效能度量不是最終目的，效能提升才是。我們需要透過效能度量實現問題分析、最佳化改進及效果檢驗的閉環。在上面的效能度量章節，我們介紹了 “兩級效能度量分析體系”，C-2 級別的洞察分析屬於宏觀分析和趨勢分析，側重整體趨勢和通用問題，C-3/4 級別的洞察分析屬於中觀和微觀分析，側重分析實際的案例和具體的問題，以此作為提升的方向。詳細內容可參見 5.4.3。

6.2 敏捷成熟度洞察分析

在上面的章節，我們介紹了敏捷成熟度評估實踐指引，團隊定期進行敏捷成熟度的評估，並把各項打分結果以雷達圖的形式展現，同時可以進行資料的環比分析。如下圖所示：



圖 6-1 評價結果雷達圖



每次評估之後，根據各個子項的評價分數及團隊的反饋，由 Scrum Master 帶領團隊制定改進提升措施和計劃，團隊實施，專案經理進行跟蹤和推進，敏捷教練按需提供支援。對於通用問題，可以考慮是否透過流程規範、工具或者管理的手段解決。

6.3 收益分析

PMO 會定期針對收益驗證的情況進行資料統計和洞察分析（收益驗證詳情參見 4.4），出具分析報告，並推動各部門針對收益管理各個環節反饋的問題進行改進，提升收益達成率，助力業務實現更高價值。

6.4 回顧與覆盤

回顧和覆盤在上面已經詳細介紹（詳情見 3.3.2 和 3.3.3），它們既是敏捷活動和專案活動的重要一環，也是洞察分析的重要源頭和輸入，透過建立並固化定期的回顧和覆盤機制，洞察問題，分析解決方案，並推動持續改進。

以上是我們的一些實踐，可能未必標準，或者未必與理論完全一致，甚至可能是錯誤的，但只有不斷實踐才能不斷改進，我們仍然需要在敏捷轉型的路上披荊斬棘，透過更加精細化的管理、更深入的敏捷實踐以及持續改善的行動驅動團隊敏捷成熟度不斷提升，不求立竿見影，但需潛移默化，潤物無聲。