鮮豐水果，創始于1997年，歷經25年發展史的鮮豐水果，目前已成為一家集新零售、智慧冷鏈物流和供應鏈B2B平臺的全球化企業，是全國知名水果連鎖企業之一，目前全國門店數超2200家， 并擁有23個共計48萬方的現代化冷鏈倉儲中心，
隨著外部環境的變化，2021年初鮮豐水果數字化轉型再次加速，短短幾個月時間，研發團隊人員擴張2倍有余，一些問題開始暴露：
- 研發基礎設施不完善，也缺乏相關領域的專業人員，需投入的人力及時間成本很高，且見效慢，
- 很多環節感覺有問題，但是不知道如何觀測，也不知道比較好的實踐是什么，隨著公司在產研側的投入越來越大，更快、更好地交付業務價值的訴求也愈發緊迫，
簡單、快速地提升產研團隊的交付質量和交付效率，成為了支持組織業務創新的必選項，讓我們一起看看鮮豐究竟如何逐步破局，
一、梳理流程，發現問題
解決問題，前提得知道問題在哪兒，
鮮豐水果研發負責人皮雪鋒深知團隊內部缺乏專業的研發轉型人士，要想盡快推動轉型落地，必須請外援，皮雪鋒綜合考慮成本、云產品集成性、功能全面性和易用性，最終選擇了阿里云云效DevOps平臺，也因此結識了由業內資深研發轉型專家何勉帶領的阿里云云效最佳實踐團隊，邀請他們對鮮豐水果整個研發流程進行端到端調研，幫助明確團隊各個環節中碰到的問題，
鮮豐水果辦公室研發流程梳理的便簽貼滿了透明墻
云效最佳實踐團隊和皮雪鋒團隊，經過梳理把問題歸納為兩類，
1、端到端產研協作問題
- 散裝的產研協作工具帶來的高協作成本和資料孤島問題，
產品經理的PRD檔案有的存在語雀、有的使用釘釘檔案、有的則直接在本地，開發使用gitlab，測驗卻在xmind上維護用例和測驗計劃，
- 缺乏統一、透明的協作流程導致的交付資源浪費、交付進展不清晰和交付質量差的問題，
產品無法無法及時了解需求的進展，研發是否遇到瓶頸，上線以后問題集中暴露，返工率極高，
2、工程交付能力和交付質量問題
先明確工程問題定義：把接受一個開發任務后，進行代碼撰寫、聯調、測驗、集成，直到部署上線稱為一次應用變更，整個變更程序中的問題均稱為工程問題，
經過梳理分析，鮮豐的工程問題主要有3個：
- 變更程序不順暢，各個角色的等待、沖突多，
測驗角色與開發角色關注在不同分支上，分支的管理依賴開發角色手工操作，由于雙方的步調不一致，導致分支管理成本高，溝通成本高，
- 交付質量嚴重依賴測驗手工驗證，
在當前的CI/CD流程中，沒有內建的快速質量守護能力，必須依靠線下測驗角色的手工驗證，導致質量反饋滯后，
- 云原生應用架構下的部署運維依賴少數專家，
鮮豐的應用架構已經全面轉向無狀態，基礎設施全面轉向云原生，但與此同時，對應用的部署和運維能力提出了新的要求，這些能力依賴少數幾個專家，鮮豐希望能把這些實踐經驗沉淀下來，讓每個研發都可以進行應用的部署和運維，
二、“三步走”解決問題
基于上述關鍵問題，鮮豐水果在阿里云云效最佳實踐團隊的建議下，實施了“三步走”的策略，明確了團隊效能提升目標，并建立了相應的流程和機制，跑通以應用為核心的持續交付實踐，實作了研發的“小步快跑”，
第一步，拉通跨職能團隊達成目標-反饋倍訓共識
由于工具鏈分散以及協同流程不透明帶來的協同效率低、交付慢等問題，皮雪鋒首先拉通了以業務目標為導向的跨職能團隊，包含產品、設計、開發和測驗在內，并明確每個跨職能團隊的效能目標為提升交付效率和質量，為了讓團隊在執行落地的程序中更加清晰，做到“1+1>2”的合力效果，團隊共識后皮雪鋒給團隊制定了兩個階段性目標：
- 交付效率目標，主要指縮短需求開發周期，需求提交給開發后，85%的需要在兩周內能上線；
- 交付質量目標，明確開發準入和開發進入提測的標準，持續降低缺陷和線上問題的數量下降20%，
鮮豐在內部成立了的跨職能團隊人員構成
在明確了團隊成員的組成后，進一步明確了需求的整體交付程序，尤其是從效能視角，需要建立交付效能反饋倍訓的機制，
經過討論，最終確立的機制如下：從對齊業務目標出發，定期進行業務規劃，基于業務規劃進行對應的需求評審和研發排期，團隊通過雙周迭代或單周迭代進行需求開發、測驗和驗收，在這個基礎之上，還通過建立每月規劃、每周排期和每日站會，對齊規劃、計劃和進度，
整體交付流程
關于需求的交付周期和開發周期也做了明確的定義，如下圖，需求交付周期從“已選擇”到“已發布”，需求開發周期從“待開發”到“待發布”，在實際落地程序中，開發周期的終點會算到“已發布”，這樣更能體現業務的視角，
第二步，基于共識確定流程和機制
1、需求流轉機制和狀態共識
通過對團隊現狀的調研，明確團隊協作程序中的問題后，有針對性地設計出需求的流轉狀態和流轉機制，并與團隊成員達成共識，共識的背后是為了建議統一的認知和溝通語言，
2、拉通和可視化端到端的業務價值流
在明確需求流轉狀態和流轉機制后，需要把機制和共識在云效上進行落地，用戶價值驅動：各團隊基于需求進行協作，每個需求都需要關注用戶價值，一方面需要明確用戶是誰，目標是什么，另一方需求需要被拆分到小顆粒度（一個需求開發測驗完成要在兩周內），當然對于小需求需要達到可測可發布，
前后職能拉通：在需求的整個流轉機制中，需要關注需求階段、開發階段、測驗階段和發布階段，需要全流程打通，拉齊各個階段的角色一起協作，讓整個協作程序順暢和高效，
左右模塊對齊：在開發中，需求會被拆分為開發任務，往往一個需求會被拆分為前端的開發任務和后端的開發任務，有時，后端的開發任務還是拆分到各個不同的模塊，此時，需求下的各個開發任務，需要對齊介面，對齊聯調和測驗時間，
業務價值流在云效產品上的落地
3、明確各階段準入規則，形成內建質量機制
需求的作業流明確后，接下來是需要明確需求流入各個狀態的準入規則，不但要讓需求能順暢流轉，更需要高質量的流轉，同時從內建質量的視角出發，需求的質量不是靠最后環節的把關，而是需要從源頭上就明確質量要求，讓各個環節的質量都能達到明確的要求，直到最后高質量地交付，
我們會明確定義各階段的流轉規則，尤其是需求準入開發和準出開發的規則，因為這兩個是產品、開發和測驗這三個角色的需求拋接程序，而需求的拋接程序是最容易出問題的，
4、明確需求優先級機制
明確需求優先級機制在團隊共識環節特別重要，因為需求優先級的高低代表價值的高低，價值的高低是直接和目標強相關的，在實時落地中，發現團隊排入迭代的需求優先級都是緊急的，而沒有明確排出優先級的順序來，
咱們需要有一個按照絕對優先級排序的需求串列，最高優先級的需求要能被最先交付，同時還方便團隊對需求的優先級進行積極的挑戰，最終形成最合理的需求優先級串列，
5、明確進入開發后的需求責任人
進入開發中的需求，需求Owner需要負責協調把需求拆分成任務，并需協調至需求開發完成到提測，測驗和發布完成為止，一方面讓進入開發的需求有專人負責，另一方面也培養團隊成員的責任感，
6、形成月規劃、周排期和日站會的節奏
建立整體的節奏，形成月規劃、周排期和日站會的節奏，同時各個是和需求的狀態有緊密的集合的，
通過規劃后的需求，需求狀態會更新到“已選擇”，通過排期后的需求，需求狀態會更到“待開發”，通過站會后需求，需求的狀態會更新到最新，
第三步，實踐以應用為核心的持續交付
在工程方面，基于當前鮮豐水果的現狀，皮雪鋒決定全面擁抱以云原生應用為核心的工程實踐方法，具體來講，主要有兩點：
1. 制定基于特性分支的研發模式，并落地到應用的變更流程中
為了保證變更程序中各角色的協同效率，結合團隊實際情況，鮮豐決定去除測驗分支，采用類似特性分支的研發模式，只保留一條長期分支，其分支模式類似下圖：
基于該分支模式，鮮豐將master分支設定為保護分支，通過應用維度的云效流水線定義和串聯整個流程，避免手工的部署和分支管理操作，保證所發即所測，其應用流水線模板如下：
上述流程按應用落地到云效AppStack的發布流水線中，類似下圖：
2. 以云原生應用為核心聚合編排、環境、監控和研發流程
鮮豐從前兩年開始進行云原生應用架構的轉型，研發團隊中只有很少的SRE（site reliability engineer），負責制定整體的研發和運維規則，應用的部署運維都由一線研發負責，但之前一直缺乏一個研發視角的工具平臺，將應用研發相關的資源和操作都聚合起來，而這剛好是云效AppStack應用交付平臺的設計初衷，為此，AppStack開啟公測后，鮮豐便第一時間開始了試用，并逐漸把所有應用都搬了上來，
從上圖可以看出，研發團隊不直接操作云資源，對資源的操作都可以通過操作AppStack的應用環境進行，一方面更符合云原生研發的習慣，另一方面也更為安全，
當然，工具只是云原生轉型的一部分，鮮豐的云原生轉型包含了技術架構、部署架構和工程實踐3個方面，
2.1 在技術架構上，做到每個應用可以獨立地部署、驗證和運維，并充分利用云原生基礎設施提升彈性和韌性，
鮮豐的研發基礎設施全面上云，基于云資源和開放標準來構建應用，主要采用了以下云產品：
- 阿里云ACK：完全兼容K8S且免運維，無論生產還是測驗環境的應用容器都承載在其上；
- 阿里云RDS等資料庫產品：遵循開源協議標準（如MySQL），可以無縫遷移，方便運維，且性能更好；；
- MSE NacOS：開源的配置中心NacOS的商業版本；
- 阿里云ARMS：一站式的可觀測性平臺，主要采用其中的k8s監控和應用監控，也可以集成RDS等的監控，對Java應用無侵入；
在選型的時候，鮮豐充分考慮了標準的開放性，保證應用可以無修改地承載在不同的云服務商上，
2.2 在部署架構上，做到每個應用一套編排作用于多套環境，環境差異通過變數來體現，做到鏡像與配置分離，
鮮豐對部署架構的期望是：一個應用定義一個部署架構，不同的環境的差異通過變數區分，一個鏡像可以部署到多個環境中，鏡像內部不保留環境相關配置，為此，鮮豐基于AppStack采用了如下的實踐方式，
首先，SRE定義企業的編排模板（如包含一個Service、一個Deployment），
其次，在每個應用中，應用負責人選擇該模板定義自己的部署編排，解決環境間有差異的地方定義變數來解決，
第三，應用負責人定義不同的變陣列以適應不同的環境，
第四，應用負責人將變陣列系結環境，
最后，研發團隊直接在環境上進行部署和運維操作，
2.3 在工程實踐上，做到研發自發布、自運維，但SRE又能在全域上進行權限和策略的配置和管控，
鮮豐將研發角色分為應用負責人、開發、測驗3類，以及一個企業級的SRE角色，SRE為其他每個角色配置對應的權限，
SRE為每個角色定義不同環境的操作權限，開發和測驗角色可以部署和運維開發測驗環境，但不能操作生產環境；只有應用負責人可以執行生產環境的部署和運維，
三、效能提升效果
開發周期縮短
經過三個月的落地，鮮豐水果的產研團隊已經能夠實作85%的需求兩周內發布上線，
在這個指標制定/實作的程序中，也有一些小插曲，
一開始我們把開發周期的“85線”定為兩周的時候，有產研同學會問，需求的交付時長不是和需求的大小強相關嗎？是的，我們跟產研團隊會先達成一個共識，即什么是一個需求？我們定義需求的標準是可獨立交付和驗收測驗，在此基礎上，顆粒度越小越好，
下圖是鮮豐水果轉型三個月之后的開發周期的統計圖表，通過下面這個圖表，我們不難看到，該試點團隊在二月份交付的需求中，已經有85%的需求開發周期在13天以內，達到了我們預設的兩個周的目標，
另外通過這個圖表，我們也能看到一些其他的問題，比如還是出現了需求批量交付的情況，沒有做到單需求持續發布，
相對理想的需求交付周期圖：
平均交付周期：10天（兩周以內）
期望的散點分布：
- 縱向上向下集中----回應能力及可預測性提升；
- 散點密度提高----提升交付效率；
- 橫向上更均勻分布----持續交付；
交付質量提升
經過三個月的落地，鮮豐水果的產研團隊的線上問題數下降20% ，并且研發模式有根本性的變更，
前期，鮮豐水果的產研團隊采用類似小瀑布的開發模式，團隊集中設計、編碼，引入缺陷，但并未即時地集成和驗證，缺陷一直掩藏在系統中，直到專案后期，團隊才開始集成和測驗，缺陷集中爆發，越到后期發現的缺陷，修復難度大幅提升，修復成本大幅增加，
經過對現狀問題的分析，團隊開始向持續交付模式演進，在整個迭代程序中，通過上面的“三步走”策略，基本實作了“單應用部署，單需求交付”，團隊以小粒度的需求為單位開發，持續地集成和測驗它們，即時發現和解決問題，缺陷庫存得到控制，系統始終處于接近可發布狀態，這一模式更接近持續發布狀態，團隊對外的回應能力隨之增強，
四、傳統企業研發轉型建議
經過三個月的實踐落地，鮮豐水果的產研團隊實作了研發流程的數字化轉型，達到了預期的研發效率提升的目標，但是仍然有一些問題需要團隊持續改進、提升，如從業務需求開始的整個業務監控的倍訓建設，以及測驗自動化能力的提升等等，
鮮豐水果作為“傳統行業”研發轉型“數字化”的新零售代表，其在轉型中碰到的一些問題也是很多類似企業，已經遇到或者將要遇到的，這里我們做一個簡單的小結，希望能夠給有相似問題的企業以幫助：
- 團隊共識很重要，在鮮豐水果整個落地程序中，不管是一開始指標的確立，還是后續諸如流程、規范等的設定，讓整個團隊能夠共識，達成理解一致是非常重要的一環，譬如我們為什么要看這個指標，什么是需求，需求完成的定義又是什么等等，只有團隊真正共識，才能確保后續整個流程的順暢，
- 業務驅動是根本，研發的目的是為了業務價值的實作，所以通過業務需求拉通端到端的交付程序，對齊各個功能開發的作業，才能保證我們是以“用戶”為目標在作業，最后的產出才是有價值的，
- 擁抱云原生，云原生的技術堆疊已經成熟，同時隨著業務的快速發展，不管從資源利用率、人力成本、可用性還是回應速度上，傳統的基礎設施構建方式已經很難滿足企業發展的訴求，適時的“擁抱云原生” ，提高業務的靈活性以及快速回應的能力也變得愈發重要，
如果你對鮮豐水果轉型實踐感興趣，或也想要進行研發數字化轉型，可以點擊下方鏈接填寫表單，聯系云效最佳實踐團隊，
https://yida.alibaba-inc.com/o/yunxiao2020#/
想深度了解鮮豐水果研發數字化轉型負責人皮雪鋒背后的思考，你可以點擊閱讀《對話｜鮮豐水果：“看不見”的門店數字化》
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/445547.html
標籤：其他