騰訊TAPD合作樂信：敏捷研發之路
(1)客戶介紹
從13年成立到17年納斯達克上市，年輕的科技金融公司樂信在互聯網金融的賽道上快速成長。截至2019第一季度，樂信注冊用戶數超過4220萬，旗下擁有 分期樂、桔子理財 等多款知名產品，打造了集電商智能風險管理、信息中介服務為一體的金融科技生態。
(2)項目背景
“互聯網＋金融”的特色給樂信帶來了更多研發管理上的挑戰，今天我們有幸邀請到 樂信質量管理中心的胡其麗女士 來到TAPD思享匯的現場，為大家講述樂信打造高效研發模式的探索。
(3)解決方案
一、敏捷：時不我待，艱難出發
大家下午好，我是來自樂信研發管理部質量管理中心的胡其麗，很高興能夠受邀來參加TAPD思享匯。 樂信是一家年輕的公司，但其實跟騰訊TAPD已經是老朋友了。實現質量和效率的共贏是我們追求的方向，接下來我會為大家介紹樂信是如何打造樂信特色研發模式的。我們的敏捷實踐，需要從一次艱難的變革開始講起。
1.產品與開發之爭：要不要固定發布時間？
最初，樂信是7x24小時可以進行發布。這是業務部門期望的狀態，卻也是開發人員的噩夢。每次上線需求或發布應用就會有告警，開發負責人經常緊張得睡不著覺。 為了降低故障率，開發團隊決定改用單周迭代開發的形式，把發布時間固定在周二和周四。
當然，產品和業務團隊肯定不會同意這個決策，我們遭到四五個業務團隊的反對。他們在討論會上直接表明了態度：“業務要發展，你們開發跟不上是你們自己的事情，你們一定要支持我們快速的響應用戶和快速的業務發展。周二和周四發布，那是不可能的事情。”
萬幸，我們研發vp、研發負責人扛住了壓力。最后老板決定讓我們進行這次嘗試。這就是樂信敏捷探索的艱難出發，雖然艱難但是最終證明有效。從這次嘗試開始到現在大概有三年的時間，我們還在沿用敏捷迭代的方式，這個痛我們算是挺過來了。當然，我們之所以堅決進行這次嘗試，和我們的業務特色和發展狀態有直接的關系。接下來我就向大家介紹樂信敏捷探索的現實背景。
2、變革背景：樂信的成長煩惱
樂信是一家快速成長的金融科技公司，但和所有初創公司一樣，樂信也有自己成長的煩惱。我們的煩惱和自己所處的賽道有關，也和我們過快的成長速度有關。了解自身的特點，才能找到最合適的解決方案。
（一）業務煩惱：產品復雜，協調困難
作為一家金融科技公司，樂信的業務同時包含了互聯網和金融兩個方面。我們的研發環節主要有三個特點：
①鏈路較長： 從前端首頁的瀏覽到生成訂單的過程中，涉及到風控規則，以及外部接口，整體鏈路較長。
②邏輯復雜： 業務會涉及到借款，還款以及風控等方面，在研發的每一個階段和流程當中，邏輯復雜程度高。
③跨團隊較多： 因為涉及到業務方、平臺方、資金方、風控方技術等方面，所以會經常出現跨團隊合作的項目。
（二）團隊擴張：讓人歡喜讓人憂
樂信的團隊經歷了一個迅速壯大的過程。2015年6月樂信的產品加研發只有近百人，到今天四年間有了七倍的增長。團隊擴張是把雙刃劍，如何實現這么多人協同作戰，是提升公司效能的難題。
3、解題思路：打造敏捷文化和理念
打造敏捷不是靠一兩個制度就能實現的。研發需要一定的文化作為背景，而我們也打造了樂信自己的研發文化理念。
在樂信的文化理念里，敏捷和質量是原則，管理和工程實際是支撐，最終目標是實現效率和質量的共贏。
原則是敏捷： 因為我們要快速響應市場和用戶，也讓用戶給與我們反饋。
質量是底線： 作為一家金融科技公司，質量是我們在研發管理過程當中最重要的一環，是不可以被突破的底線。
在管理實踐中，我們會有一些創新的實踐，比如產品會用到一些分析的方法和手段。再比如精益看板、故事墻、電子或物理看板等等方法，用它們去讓價值的流動可視化。工程實踐部分有持續構建、持續集成，自動化測試、服務架構、流水線部署等等一系列實踐的方法。
4、工具支撐：工欲善其事，必先利其器
其實我們堅持采用單周迭代的另一個原因，是我們引入了TAPD作為研發管理的工具。從這個層面來看，TAPD也是樂信敏捷之旅的開始。 從前，樂信用的還是比較原始的協同方式。需求的來往溝通，其實都是用郵件來進行。后來我們在TAPD的協助下，我們打通了研發中的信息同步難題。
以及開頭講到的單周迭代發布模式。我們當時改用單周迭代開發，因為產品側還做不到雙周發布。到今天，在TAPD的幫助下大多數的團隊已經可以進行雙周迭代的方式，團隊之間的協作難題已經被大大解決了。
除了溝通效率和迭代計劃之外，TAPD平臺在樂信的實踐中還有更為豐富的支持和幫助。我們下面就為大家展示，樂信的敏捷實踐是怎樣一步步打通的。
二、敏捷實踐：六個維度，逐一突破
在進行了一系列準備工作后，我們就需要從全局的層面規劃樂信整個的研發模式，逐步去化解我們在研發環節中遇到的痛點。 樂信的實踐中，有六個非常關鍵的維度，分別是：組織、過程、架構、工具、基礎設施和度量。
1、組織：打破部門墻，聚焦價值流動
（一）部門墻：該打破的是要打破的
我們首先要承認在工作中，一些技術問題其實是由組織結構帶來的。 比如早期的樂信團隊里，研發和產品同在一個部門下面，所以產品側的需求天天來找項目經理要排期，理由可能是這個需求非常緊急，或者是老板要求一定要上線。總之，這種搶占資源的方式一直存在著。
組織合作中有一些部門墻導致合作不順暢?；谶@個原因，我們的組織架構從早期的資源共享式變成為以業務為導向，這種閉環式建立了面向由產品而非項目的跨職能的組織模式，為后續我們的敏捷和價值拉動做好準備。到2016年，我們將組織調整成以業務團隊為導向，將公共資源池變成了以閉環的方式去走敏捷。組織架構的調整，為我們打造樂信研發模式和實踐敏捷帶來了一個很好的開端。
（二）資源效率：以更快的速度到達用戶
如果把開發當做一種資源，最初我們最大化的去使用資源，每個開發人員每天要排滿需求，可真正值得考慮的問題是我們的需求能否以最快的速度到達用戶和市場。
敏捷講究的是用戶價值，是需求以最快的速度到達用戶。 所以組織架構的調整，讓我們從早期的只關注開發資源，變成了現在這種聚焦在流動效率上面?，F在如果我們想做一個項目，我們會最大化的拉動這個用戶的需求或者說用戶的價值，讓這個價值以最快的速度去面向市場。
從早期聚焦資源效率，到現在關注流動效率的聚焦。現在的樂信聚焦在用戶價值以及用戶需求上面。這對我們來說是一次重要的組織架構調整，帶動了我們做事的方式和方法。
TAPD在這個過程中提供了很多的支持，讓這種價值的流動變得可視化。非常清楚地呈現出研發瓶頸在哪兒以及應該如何調整。企業的資源應該讓價值的流動更快一些，從這個看板、故事墻這些工具中上面就可以看出。
2、過程：理順管理流程，善用工具支撐
過程跟這個流程有些不同，這里說的過程更偏輕流程和工具的結合。把控過程，既包括研發流程化質量管理的過程，也包括運營流程化管理的過程。 樂信將這兩者打通，將前端的研發管理過程作為價值是輸入到給到用戶，而用戶這邊持續反饋，讓我們得以不斷地去優化和去迭代產品。
當然，如果僅僅有流程還不夠的，提升研發效能還需要工具和系統上的支持。我們把研發管理過程中去鑲嵌我們的流程。里面也鑲嵌相應的工具，這對企業研發效來說是一個極大的提升。 在過程中，我們的需求和項目管理都是承載在TAPD上。針對金融產品研發，我們還會采用極為嚴苛的定制流程。
在每個流程的節點，我們都會在TAPD上去設置對應的一個準入檢查和評審的checklist。因為每一個過程，輸入不可以影響到后面的一個；作為下一方的輸入，輸出的結果也不可以影響到下一方的輸入。所以在每一個節點，我們都會在TAPD上做這種準入和準出的規則設置。
3、架構：搭建穩定環境，減少資源消耗
在微服務化了之后，我們發現了研發過程中特別多的問題。 其中研發方面，最大的問題就是開發測試環境。 環境搭建的耗時大于開發時間，而測試定位、定位環境的耗時又大于項目測試的時間。對運維來說，因為每個項目部署都意味著全套服務，所以資源消耗和維護的成本會非常大。
我們的解決方案是基于環境出發的。 我們搭建了一個公共穩定環境，它其實就是生產環境的一個鏡像。每一次更新代碼、更新服務，我們只拉取更新的服務到項目環境上面。 那如果沒有更新服務，我們拉取和調用的還是這個stable環境，也就不需要去做全套的部署和維護的工作。
4、工具：打破信息壁壘，串聯研發過程
早期的時候，從研發到發布的過程中每個系統或工具都是割裂的一個信息孤島。所以到17、18年的時候，樂信開始著手解決這個問題。從TAPD開始，串聯需求到發布的整個全流程的一體化。我們做了一個樂效系統，來管理我們整個研發過程。
當時，我們的工具很多，每一個工具和系統都給樂效系統提供API接口，把我們的過程和管理都鑲嵌在樂效系統當中。從一開始的版本規劃、版本質檢測試管理、版本發布和發布觀察其實是一體化的。尤其是在版本質檢當中，我們把質量管理鑲嵌在其中。
這里會有一定的質量閥值的設置，必須要達到一定的標準，比如：單側的覆蓋率、靜態代碼檢查的阻斷率等待。 我們會在每一個節點去根據不同的業務團隊的特色設置相應的閥值。在進行管理時，每一個業務都是自定義化去實現的，所以每月走的是同樣的系統，但是在過程當中會有一些個性化定制的地方，這也可以使我們在整個研發管理的過程當中，盡量做到 “質量流程化，流程系統化” 的概念。
5、基礎建設：聯結開發運維，提升工作效率
在基礎建設方面，樂信的運維開發和運維團隊的組織架構是割裂的。這種情況導致腳本運維和手工運維常常陷入低效的困境。為了解決我們運維內部的矛盾，后來我們做了一個叫galaxy的一個平臺，由運維、 開發去提供這種Paas的服務，提升基礎層面的工作效率。
6、度量：明確評估標準，提升合作滿意度
接下來到度量的部分。 在早期，我們對度量這一塊其實沒有一個明確的標準，即使有也是比較零散的。后面我們建立了一個PCB，也就是過程能力的一個基線，主要含有這個三大模塊和一個加減分的指標、質量指標、技術指標以及團隊滿意度。
敏捷講究的最終是人，所以我們最看重的是人跟人之間在合作中是否滿意。 合理的加減分標準，可以鼓勵團隊去做一些優秀的實踐，同時讓不足之處得到監督和修正。我們的PCB中很多的數據是由TAPD開放api的接口，然后才能夠實現的。所以需要感謝TAPD對樂信研發管理提供的強大支持。
三、展望：打造樂信DevOps模式
樂信對未來的研發管理有不小的一個愿景，包括目前我們正在去做的一些事情， 就是打造屬于樂信的DevOps的一個模式，TAPD在模式中屬于項目管理微服務和持續集成部分。
關于如何去實踐樂信的DevOps，我們主要是有一些自己的一些原則，或者說心得：
①價值和理念的先行： 價值驅動理念可以保證方向的這個正確性和路徑的合理性。
②從小做起，逐步突破： 一開始不要把盤子鋪得過大，用小步快跑的方式，一點一點去做起。
③痛苦的事情有效解決： 要清楚現階段最痛苦的事情是什么。著力解決那些對用戶或者業務團隊來說最痛苦的地方。
④用戶價值拉動，而非事務拉動： 要把交付用戶價值放在首位。
這四點是我們落地DevOps時的基礎原則，每個團隊在不同的階段，都會有不同的痛點。 今天的樂信在研發管理上依舊有改善的空間，我們會朝著高效的方向繼續努力。
(4)價值體現
TAPD也是樂信敏捷之旅的開始。 非常感謝TAPD這樣優秀的工具，為樂信提供了如此強大的研發管理支持。樂信和TAPD都在朝著提升研發效能的方向努力，未來希望我們能夠有更大的碰撞，收獲更耀眼的火花。
