導讀：平安作為網際網路金融的領跑者，目前有超過40個APP，傳統業務全面網際網路化。能夠成功轉型與敏捷密不可分，平安科技更是整個集團敏捷轉型的領頭羊。
2011年，敏捷開發試點專案大獲成功之後，平安科技駛入敏捷推廣的加速車道。
2012年試點範圍擴大到10個團隊，引入Scrum、看板(Kanban)、持續整合等流行的敏捷方法。
2013年“開啟敏捷2.0”，在組織架構上成立“敏捷中心”，整合業界優秀實踐，形成平安科技自己的敏捷開發方法體系和敏捷成熟度評價體系。
2014年，敏捷開發覆蓋到公司大約80%的開發團隊，並開始探索網際網路產品的敏捷開發模式。
2015年“邁向持續交付”，從研發過程的敏捷，向上下游擴充套件，引入精益創業(Lean
Startup)、DevOps等新的方法，打造端到端的反饋閉環。
2016年啟動持續交付支撐工具鏈的建設，致力於打造“精、輕、快”的持續交付一體化平臺與解決方案。
從2013年到2015年，公司整體的30天需求實現率從24%
提升到80%；產品研發週期從以往的6個月縮短到3個月以內。此外，更靈活的響應變化、穩定的版本質量、更高的團隊產能、持續改進的習慣，都逐步顯現出來。

本次分享將通過真實的案例，分享平安科技全面敏捷模式如何在小團隊、大專案，乃至整個組織的實踐和落地。

文章來源：公眾號msup

背景介紹

先簡單介紹一下公司的背景。上圖中左側的高樓是平安金融中心，這是深圳最高的樓，118層。曾幾何時，我們聽到“平安”的時候只能聯想到保險或歌星，如今我們可以驕傲地說，我們是做金融網際網路的高科技企業。

2016年平安在世界五百強企業裡排41，這個成績和平安網際網路+綜合金融的轉型戰略是分不開的。平安現在已經有了40多個APP，近3.5億的網際網路使用者，這個數字還在快速增加。

與之適應的產品策略和管理思路也在全面網際網路化。我們從之前的關注能賣多少錢，到現在關注能為使用者創造多大的價值，這恰恰都是敏捷所倡導的也是網際網路需要的。

上圖是我們從2011年到現在的轉型路線圖。

從2011年開始我們成立了第一個 feature team；2012年引入看板方法進行視覺化管理；2013年是非常重要的一年，我們成立了敏捷中心推行敏捷2.0，也就是scrum+看板+極限程式設計的方法，聘請了大量的敏捷教練，也組織了很多場培訓，開始全面推行敏捷。

2014年開始將敏捷實踐推廣到大型專案，平安是國內第一個引入LeSS（大型敏捷框架）的企業；2015年開始向敏捷的上下游拓展，引入了精益創業和持續整合、持續交付的方法；2016年，我們開始自己研發一個持續交付的工具——神兵，同時通過工具來獲取一些過程資料，並進行價值流分析以提升企業的效能。

2011 元年

2011年是我們開始敏捷轉型的第一年。一般改變總是有原因的，我業餘時間學了些心理學和教練技術，我的老師常說“不夠痛就不會動”。有的痛是切實感受到的，有的是對未來的焦慮。

平安敏捷轉型的出發因素很多還是來自於網際網路，當時網際網路巨頭紛紛涉足金融和保險，淘寶的保險頻道都已經上線了。馬明哲還說BAT才是平安真正的對手。

顯然，之前的標準化、規範化的研發管理模式已經不適應當前變化的網際網路環境了，我們更需要一種靈活多變的多元化的管理思路來更高效地做事情。

從上圖左右側的對比可以看到：2011年之前我們強調的是管理的標準化和規範化，當時還通過了CMMI的三級評審。2011年開始推行敏捷之後，我們開始倡導開發模式的靈活化多元化，應用不同的管理模式來應對不同的場景。

我們還開展了一個叫“百日行動”的活動，就是用一百天去提升效率，具體做了這麼幾件事：

第一，看文件有哪些是必要的，哪些是不需要的。我們把文件分為系統級和過程級兩類。系統級的文件要加強，比如架構文件；過程級的文件要弱化，比如週報日報，這些只是為了溝通，實時性很強，完全可以通過面對面的溝通來取代。

第二，縮短簽報的審批鏈。平安現在有一百多萬人，審批鏈很長也很複雜，我們會分析每一個環節的通過率，如果這個通過率長時間以來一直是100%，那這個環節就應該是可以去掉的。

第三，討論怎麼開會更高效。

第四，搭建部署流水線。嘗試將程式碼從手工移交變成自動化移交。

分享一個車險網銷平臺的案例。我們拿這個專案來做第一個敏捷試點專案。這是一個小團隊，這個平臺要做的功能是實現在網際網路上賣車險。

這是我們第一個特性團隊的照片，這個團隊包括產品經理、前後端開發、測試等各個角色，這樣的一個全功能團隊能夠實現端到端的交付。

當時進入特性團隊的種子成員都是經過挑選的，我們會選擇一些樂於接受新思想、願意尋求改變的人，隨著這樣的實踐他們後來都成長為平安的骨幹人才。

上圖是我們特性團隊的第一個看板，雖然不夠美觀，但是已經有一些樣子。

通過敏捷實踐和落地，我們達到了以下的效果：
上線週期從兩個月縮短到兩週；
外部合作伙伴接入的週期從3個月縮短為1.5個月；
產能提升30%；
版本測試周期壓縮一半，生產問題減少70%。

我們的組織在最初嘗試匯入敏捷的時候做了三件事：

第一，建立全功能團隊，通過面對面的協作改善溝通。業務方代表最好也能夠加入到這個團隊中去，這樣能夠及時給團隊答疑並提供反饋。
第二，通過看板視覺化進度，今早發現問題消除瓶頸。
第三，把需求拆小拆細，以便能夠儘快交付儘早得到反饋，從而降低風險、靈活應對變化。
第四，最重要的是人，需要有一些能夠接受敏捷思想的人去做這樣的一些改變。

2012 起跑

第一個試點專案取得成效之後，我們開始逐步深化我們的看板實踐。上圖是一個壽險的支援專案，這個看板系統比之前的原型看板漂亮多了，從圖中還可以看到它與原型看板的區別：

首先，有了測試就緒、驗收就緒的等待佇列；
第二，卡片上有貼owner的照片；
第三，右下角有一個燃盡圖；
第四，圖中打紅叉的部分是做了一個WIP的限制，就是說這個佇列不能有太多的卡片，卡片不能貼到那個禁止的區域裡。

說到轉型時度量也非常關鍵。上圖是一個累計流圖，縱座標是Story Point，粉色的線是啟動開發的故事點數，深綠色的線是使用者驗收完成的故事點數，這兩條線的寬度對應到橫座標大概是三週的時間，就是說這個需求的lead time，從啟動開發到使用者驗證大概需要三週的時間來完成。

通過改進這個看板實踐，我們可以看到：由於中途發現了優先順序更高的需求，所以有40%的原始需求被捨棄了。從傳統專案管理的強調交付範圍轉化為交付價值，這是網際網路的要求。因為現在的社會充滿了不確定性，我們也很難從一開始就把範圍確定並保證後面不發生變化。

我們需要擁有靈活應對變化的能力，要保證團隊一直在交付高優先順序、高價值的任務。同時我們也不希望這個範圍無限蔓延導致同學們天天加班，質量下降。所以當有一個高優先順序的任務要加進來的時候，我們就會擠掉一個同等工作量的低優先順序任務。這就是為什麼上圖中左下角中途增加的40%優先順序更高的需求，右上角又擠掉了同樣多的需求。

總結一下我們2012年敏捷轉型的幾個關鍵要素：
延遲決策，讓它快速流動；
交付價值勝過交付範圍；
通過約束限制在製品數量來拉動系統；
通過看板實現阻礙和問題的視覺化。

2013 推廣

通過前面兩年的積累，我們取得了一些成果，2013年進入關鍵性的一年，這一年我們成立了敏捷中心推廣敏捷2.0。那時主要主打的是三種方法：看板、Scrum、持續整合。我們提供三天的訓練營打包培訓，有很多團隊成員加入進來參加這樣的培訓。

上圖是我們的學員在玩看板沙盤遊戲。這是一個從國外引進的非常經典的遊戲，能夠幫助我們體會看板方法的精髓。現在這個培訓一直持續在做，也收到了很好的效果。

我們說2013是敏捷推廣最紅火的一年，這一年，我們還做了一件非常重要的事：成熟度的評估。

上圖是一個成熟度評估模型的一部分，左邊可以看到一級二級（後面還有三級）。這是一個在整個公司範圍內發起的活動，由敏捷中心去推行，成立專家小組給團隊評級，然後在全公司公佈結果。這個在當時無形中成為了一個團隊的KPI，但當時達到三級的只有四個團隊，二級的幾十個團隊，其他團隊大部分還處於一級。到2014年的時候，平安科技有4000多人100多個分組，80%的團隊都引入了敏捷方法。

上圖中這個活動叫看板大巡遊，主要是由教練帶隊，他們像導遊一樣舉著旗子帶領大家一站一站地看過去。每個團隊設計的看板都不一樣，我們會考慮美觀、實用等方面去給各個看板打分、寫評語。然後一起討論有哪些好的地方值得大家學習，最後還會有評比和頒獎。

這是鞏固得非常好的一個實踐，實施的效果是80%的團隊都應用敏捷和看板，而且這麼多年在平安能夠很好地落地並延續。敏捷在IT領域的看板方法在剛問世時也會有一些爭議，但是還是被很多公司所採用。因為即使是在各個公司文化、管理風格迥異的環境下，看板方法作為一個漸進式的變革方法還是比較容易切入進去的。

也就是說，它提供了一個更加平滑的路徑，能夠最大限度地減少敏捷轉型帶來的陣痛。其實基於現狀以及實用至上，這是我在平安科技甚至在整個平安集團能夠看到的，一貫執行下來的思想和策略。

我看到過一些自上而下的激進變革的例子，到最後有一些是打回原形的，員工對此產生了諸多的誤解；也有一些自下而上的變革，一般這樣的變革發起者都是比較超前的員工，企業沒跟上最後導致員工心灰意冷離職，變革也草草收場。相比之下，我更欣賞平安這種溫和的演進策略，能夠更持久更有效。

2014 深化

2014年是我們敏捷深化的一年，基於前幾年的成果逐步把敏捷擴充套件到更大型的專案裡來。我們第一個大型的試點專案是做一個直銷銀行，這個專案有幾十個人的研發團隊，其中還有大量的外包，困難也很多。

敏捷轉型之前的場景是業務拼命地加班寫文件，他們也知道寫了要被推翻，但是開發說了沒有文件就不能幹活，雙方的互信度非常低常常僵持不下，後來有人提出來說：咱們不是有敏捷教練嗎？

我們敏捷教練的團隊leader林偉丹（平安科技敏捷中心資深經理、Wizard產品商業化總監）、著名的精益敏捷教練吳穹博士都加入了這個專案，諮詢顧問帶團隊做了一個Quick Start，Quick Start也是平安堅持得非常好的一個實踐，一般小型專案的時間是大概1-2天，像這樣大型的專案可能需要一週時間。

我們把Quick Start方法總結成36計，再加上引導技術、沙盤演練提煉成兩天的工作坊，通過這個工作坊也培養了很多Quick Start的引導師，這個工作坊在平安也是很受歡迎的。

需要所有的決策角色（特別是能拍板的人）都參加到Quick Start工作坊，這樣能快速地把業務需求梳理成開發能夠去做的迭代計劃。達成的效果就是希望會議結束後馬上就能開始去迭代、能夠持續交付一些可見到的東西。

上圖我們在Quick Start之後梳理出來的一個四層的故事牆，從主題到Epic到Feature到Story，看起來還是蠻壯觀的，貼了滿滿的一面牆。

因為會涉及到多個Scrum team的協作，上圖是一個Scrum team的看板，把迭代計劃放到上面，最左邊大的卡片是使用者故事，右邊小點的卡片是任務。我們後面也做了一些改進：用不同顏色的卡片來標示使用者故事和任務，還特別用紅色的卡片標示風險。

我們還有一個專門的看板，用來管理大型專案之間的關聯和依賴。藍色卡片是業務模組、黃色卡片是關聯絡統。裡面會有很多具體的檢查點，每個做完之後就用打鉤的方式跟蹤風險，上圖右邊的五角星是標示一些風險大的地方。

上圖是一個比較完整的分層看板，右邊每個人都有兩張照片，而且只能有兩張照片，這是為了避免一個人手頭同時有多個並行任務、需要頻繁切換任務而導致效率降低的情況，我們鼓勵大家先做完一個任務再去領下一個，這樣有助於任務快速流動提升效率。最左下方有一大堆卡片，這些都是被捨棄的需求。

上圖是我們30多個人參加的每日站會。我們能夠保證在15分鐘內完成，每個人在上面移動卡片。這面牆還是蠻大的能夠將所有的使用者故事、任務都展示出來。

這個直銷銀行的專案從最開始業務和開發的互相不信任、集體焦灼的狀態，到後面啟動Quick Start，並取得驚人的成績：
三個月之後首個版本釋出可以內測；
四個月之後直銷銀行產品正式推向市場；
釋出一年之後，使用者量突破五百萬，並獲得中國最佳直銷銀行的大獎。
這個大型專案的敏捷試點也是相當成功的。

2015 延伸

2015年之前的很多實踐都是在幫助我們把事情做對做好，主要是在解決域方面，而我們面對的問題是其實我們不知道什麼是對的事情，問題域需要我們用精益創業和設計思維的思想來解決。所以，從2014年起我們開始往敏捷的上游拓展，建立上圖這樣的產品側看板，同時我們引入了一些精益創業的實踐。

上圖是業務側看板的一個例項。有澄清、評估、排期，排期就是進入了開發的迭代計劃，這個看板到現在產品經理還在用。

我們也希望能夠往敏捷的下游——持續交付拓展。想要交付得快自動化是不可缺少的，我們要去持續驗證。自動化測試方面，其實要分層的，而介面測試是比較容易做的，我這邊的團隊更傾向於由開發把自動化的介面測試寫好，甚至把這個部分定義到DoD（Definition of Done）裡，以便能夠快速地去測試。

原來都是評估從需求準備好到交付的時間，現在我們可以去評估從創意到投產的lead time，前置時間。上圖中縱座標是天數，從圖中可以看出2015年9月到2016年是有顯著降低的，也就是說從有了初步想法到最後上線的週期在快速縮短。

這是我們2015年實踐敏捷的一些感悟和關鍵要素：
整體優化勝過區域性優化；
形成有價值的閉環；
強調內建質量。

2016 神兵

2016年，我們研發管理部開發了一個能夠實現：從需求管理到自動化測試到自動部署、持續整合還有一些靜態掃描持續交付的工具鏈——神兵。我們也可以通過神兵獲取很多的資料做價值流的分析。當然這個資料不僅是從神兵獲取，還從公司很多系統裡獲取。

我們在IT領域的能力提升之後，將改進的方向擴充套件到了更多的領域，比如運營管理、財務管理、行政管理、法務管理、安全等方面，分析這些過程中的等待返工和浪費，並試圖做出優化，縮短lead time。

我們找到了top 10，也就是最需要改進的十項來進行改善，並取得了明顯的效果，比如合同簽署、新建子系統、公共平臺的接入、移交部署，都有了百分之十幾到三十幾的提升，公司整體的流程效率提升了14%。

2016年的關鍵要素：
實現了端到端的價值流建模；
持續不斷地消除浪費；
慎用“流程”
這裡值得強調的是：很多時候我們發現漏洞的直覺反應是加一個流程去防範這樣的漏洞，這樣做的結果是導致流程越來越臃腫，組織效率越來越低下。

轉型心得

回顧一下我們在敏捷轉型路上的一些心得體會。

首先，系統思考。當我們發現問題的時候，不要像西醫一樣只針對問題治病，而要從整個系統的角度去考慮，優化整個環節中可能的各個部分。
其次，發揮人的創造性和主觀能動性非常重要。
第三，痛點驅動，資料閉環。痛點驅動，通過資料去發現改進的點，然後度量改進的效果。
最後，持續改進，永遠在路上。
像平安這樣的體量能夠做到這樣的變革是很不容易的，可能中小型企業的改變相對容易一些，我們經歷了這麼長時間的嘗試和實踐，後面可能就可以少走一些彎路，也許進展會更快一些。

團隊現在的敏捷實踐

最後分享一下團隊現在的敏捷實踐。

這是我輔導的一個叫伺客的團隊，做線上雲客服專案。我們會有一個這樣的作戰室，所有的角色都坐在一起，包括產品經理、前後端開發、測試等，大家能夠很方便地溝通，效率也有了很大的提升。從圖中可以看到這個專案室的四周也有很多的看板。

隨著現在團隊的擴張，很多異地的小夥伴加入，比如成都、深圳等，我們的看板也從原本的物理看板換成了電子看板，因為我們有神兵的支援，所以我們可以把所有的任務、需求、缺陷、測試用例等都放到神兵的系統裡，每日站會改為站在觸控式螢幕的電子看板前展開。

我對這個看板做了個小小的改動，把我們的DoR、DoD以及一些站會的提醒寫成卡片貼到觸控式螢幕的四周。下面還有一個螢幕來做CI監控，以及一個Sonar的掃描。

我還編了一些口訣來幫助大家記住我們的敏捷實踐：
自治團隊輪值表
開會嚴守時間盒
需求准入例項化
任務拆細兩天工
開發單側介面測
前端後端需並行
內建質量都有責
CI失敗馬上修
程式碼review面對面
技術債務日日清

我們是一個自組織團隊，在平安科技有很多人複用的情況，這是很難避免的，想找一個專職的Scrum master更是難上加難，所以我們就讓大家輪流擔任Scrum master，主持各種會議，有一個輪值表貼在牆壁上。

開會的時候，包括需求的梳理和澄清都要嚴守時間，一個需求的澄清不能超過15分鐘。如果有很多不清楚的、團隊提出質疑的地方，就需要先hold住回去弄清楚了再回來講。

我們希望需求准入例項化場景化，讓大家能有一個統一的語言清晰地理解。

還有任務的拆細，一定要保證這個任務在兩天的時間裡能夠完成；開發人員要負責單元測試和介面測試，前後端是並行工作的；內建質量每個人都要負起責任來；一旦有CI失敗馬上要有人去修復。

因為我們大家都是坐在一起的，面對面溝通非常方便，包括程式碼review。我們有Sonar掃碼監控還有哪些技術債務，隨時發現隨時修復，我們也預留了一些時間去解決這些技術債務。

Q&A：

Q：如何上線快，風險小?

A：做網際網路的都有這樣的訴求，希望快速上線。確定MVP（最小可行的產品）。如何去定義一個最小的可行產品，快速地開發快速地上線，然後得到驗證？埋點也很重要，我們要去分析使用者的行為，因為我們會有很多假設，一定要通過真實的使用者去驗證這些假設是否正確。

Q：有些老闆或者管理者思維固化不願意改變，如何讓他們接受你的提議？

A：現在應該不太會有說為了做敏捷而做敏捷了。我們一定要告訴管理者敏捷能夠解決什麼樣的問題、能夠帶來什麼樣的好處，這樣才有可能會引發一些改變。固有思維每個人都會有，特別是老闆，但是我們要相信他們既然能坐在這個位置上，應該是有很多成功經驗的累積，那些成功經驗可能就是基於他以往的一些方法，我們現在是提出一個新的方法，他沒有嘗試過，所以有一些顧慮和擔心也是正常的。

作為敏捷教練，我們很多時候都是基於痛點去切入的。

首先要深入團隊、深入企業瞭解真實的需求和想要解決的問題。

然後看看已有的實踐哪些可以逐步引入並取得成效，用小成果來鞏固這些實踐。

同時領導能夠看得到的度量指標也是不可少的，要讓高層能夠看得到這個方法帶來的改變，讓他信任我們，繼而再擴大實踐的範圍。

Q：對於跨業務線協作有沒有好的方法+工具？敏捷強調的是每個人都是主人翁，但對於國內的公司環境是普遍非扁平管理，敏捷的理論與實際應用是有差異的，怎麼看待這個問題？

A：跨業務線的方法和工具還是很多的，主要看大家的需求，如果所有人都在一起辦公，有一個物理的看板也是不錯的，如果在不同的地方就需要一些線上的工具來支援。還有就是我們是不是多團隊協作的情況，有很多大型的敏捷框架，比如LeSS、SAFe、scrum of scrums都可以用來解決協作的問題。

敏捷強調每個人都是主人翁，而國內的環境大多是非扁平的管理，我之前還蠻理想主義的，對這個問題也有糾結的時候。我當時有顧慮：這樣的環境是不是能夠支援我們做一些敏捷的實踐呢？事實證明其實也是有不少事情可以做的。

雖然我們在組織架構上很難說做到扁平，也不像國外那樣比較寬鬆的管理方式，但是其實我們在一些小的環境裡是可以做得很好的，比如我帶的這個伺客團隊，大家在一起就非常融洽，我們也沒有什麼層級概念。雖然有些人還是偏向management contorl的方式，但是其實也會慢慢被影響。

我們也提供了很多教練和引導技術去幫助這些管理者，包括我曾在部門推行的管理3.0和讀書會等，這些先進的理念大家也很容易接受。

Q:敏捷團隊有效性衡量指標除了需求完成率、釋出速率等，還有什麼別的具體的指標麼？

A：說到度量其實是一個很大的話題，需求完成率、釋出速率等是一些指標。我們希望通過度量達成什麼樣的目的？得先明確這個目的再來確定要度量什麼。

比如我們希望流動效率更高，那我們就需要知道需求從開始想法到啟動開發到完成需要的時間大概是多少、每個環節耗時多少。然後借用價值流分析非常有用的一些工具來幫助做一些改進。比如我們可能從一個需求產出到釋出需要三個月的時間，但實際工作在這個需求上的時間可能只有五天不到，那我們可以算一個百分比，然後想怎麼能夠讓它加快流動，隨之而來的就會有很多方法和策略可以用上了。

Q：主要是敏捷跑得快了，質量好肯定是前提，不能妥協，但是感覺敏捷和DevOpS在應用中或多或少有點削弱了測試，對此您怎麼看？

A：確實質量是不能妥協的，我發現在咱們國內做網際網路都還是偏向糙快猛的方式，儘快地先上線再說，但實際上質量是一個很大的成本。

敏捷和DevOps實際上應該是加強測試，更多的自動化。而現實情況是大家都在分析計算ROI、急著去趕某個時間點，有的時候可能確實會弱化了測試，這並不是我們希望看到的。

開發和測試在融合，我們也希望業務、產品經理、開發、測試能夠在一起把需求例項化，然後通過ATDD在整個過程中保證質量。質量不是測出來的，而是在需求產生的時候、程式碼構建的時候就需要保證的。

Q：理論和實踐有距離，現實也會有偏差，很多團隊中專職測試人員或多或少都有在減少。現在平安開發人員必須做單元測試吧？還有專門的系統功能測試團隊嗎？

A：我們會有一些專職的測試，但不是說越多越好，有的時候專職測試多了我們反而容易產生依賴。我們更傾向於讓開發團隊做好自測，做好自動化介面測試，就是說必要的測試都是由開發這邊保證、質量也是由開發這邊保證，我們逐步希望培養每個人都能是多面手。

單元測試是肯定要的。專門的團隊負責系統功能測試比較少，多數是和開