vivo 互聯(lián)網(wǎng)研發(fā)效能關(guān)鍵技術(shù)與實踐
一、互聯(lián)網(wǎng)研發(fā)挑戰(zhàn)與方案
隨著互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展，業(yè)務(wù)規(guī)模和用戶體量在不斷擴張，在如此大的規(guī)模和體量下，對研發(fā)交付效率及質(zhì)量也提出了新的要求和挑戰(zhàn)。
（圖中數(shù)據(jù)統(tǒng)計截止時間為2024.07）
vivo互聯(lián)網(wǎng)業(yè)務(wù)廣泛，體量巨大。伴隨而來的是互聯(lián)網(wǎng)項目快速增長，最近5年增長超過了5倍。與此同時，項目的服務(wù)數(shù)量也出現(xiàn)大規(guī)模增長，最近6年從原先少于2500，到快速增長超過8000，服務(wù)數(shù)量增長超過3.7倍；服務(wù)器數(shù)量也同時期增長了2.8倍，研發(fā)交付和穩(wěn)定性保障的復(fù)雜度成幾何式增長?？梢钥吹诫S著項目、服務(wù)、機器的大規(guī)模增長，研發(fā)團隊規(guī)模也發(fā)生了較大的變化，前后增長超過2.7倍。隨之而來研發(fā)協(xié)作難度逐步增加，甚至出現(xiàn)效能下滑的傾向。
（圖中數(shù)據(jù)統(tǒng)計截止時間為2024.07）
隨著研發(fā)復(fù)雜度增加，互聯(lián)網(wǎng)研發(fā)流程也變得規(guī)范，與此同時，支撐的工具和平臺能力也非常豐富。但是這也帶來了交付復(fù)雜度的上升，項目成員往往需要在多個平臺來回切換，非常麻煩！正如圖所示，從需求洞察到需求運營至少需要經(jīng)歷10個階段、10多個角色的高效協(xié)作才能完成，顯然相比以前復(fù)雜了許多，也逐步顯示了需求交付效率下降的情況。
項目流程和平臺復(fù)雜度增加的同時，在技術(shù)層面，研發(fā)基礎(chǔ)設(shè)施也是幾經(jīng)變遷，線上線下環(huán)境的機器復(fù)雜度持續(xù)增長，變更與維護難度逐年上升，對變更質(zhì)量的要求越來越高。
從上圖可以看出，在2017年以前，研發(fā)整體線上交付的機器以物理機為主，所有的線上運維都是交由專門的業(yè)務(wù)運維及DBA角色來執(zhí)行，開發(fā)人員主要參與編碼和測試工作。
但隨著研發(fā)規(guī)模增長，快速交付、低成本的資源也逐步開始引入像OpenStack這樣虛擬化技術(shù)，此時用戶的操作也逐步從原有運維逐步轉(zhuǎn)向類似CICD這樣自助化運維交付平臺。
并且隨著內(nèi)外銷業(yè)務(wù)的發(fā)展，越來越多彈性、快速、低成本的云主機也逐步引入，平臺從簡單流程逐步發(fā)展成體系化、場景化平臺，用戶的使用成本也逐步攀升。
回顧上面業(yè)務(wù)規(guī)模、研發(fā)體量和流程平臺的現(xiàn)狀，以及基礎(chǔ)設(shè)施的變遷，vivo互聯(lián)網(wǎng)業(yè)務(wù)面臨相當大研發(fā)效能提升的挑戰(zhàn)。
總結(jié)來看：
- 研發(fā)規(guī)模攀升，研發(fā)交付復(fù)雜度持續(xù)上升。
- 研發(fā)交付橫跨多個階段，在多個平臺間操作，成本非常高。
- 隨著基礎(chǔ)設(shè)施的變遷發(fā)展，平臺需要不斷兼容不同資源、不同云廠商、不同用戶場景的訴求，為平臺建設(shè)和項目實踐帶來了非常大的挑戰(zhàn)。
回溯過去與當前的困境，結(jié)合公司文化行為準則，vivo研發(fā)效能團隊堅持以用戶導(dǎo)向深入業(yè)務(wù)側(cè)，從頂層進行設(shè)計與規(guī)劃，提出“1-2-3”建設(shè)框架：通過1個雙環(huán)模型、2個標準化、3條研發(fā)管線助力研發(fā)效能持續(xù)提升。
第1層結(jié)合“價值探索”與“價值交付” 的持續(xù)交付雙環(huán)模型。左環(huán)確定方向與目標，強調(diào)采用“提問”-“錨定”-“共創(chuàng)”-“精煉”的方式來循環(huán)驗證；右環(huán)則偏重過程交付，快速實現(xiàn)左環(huán)目標，并保持業(yè)務(wù)結(jié)果與價值達成。
第2層定義了兩個標準化：需求標準化、研發(fā)標準化。需求標準化更加強調(diào)需求從提出到需求實驗全鏈路閉環(huán)管理，最終實現(xiàn)需求端到端交付；研發(fā)標準化更多強調(diào)從分支拉出到交付上線的標準化、自動化過程。
第3層為了重點支撐業(yè)務(wù)、數(shù)據(jù)、以及模型和算法需求的研發(fā)交付，規(guī)劃了3條對應(yīng)的研發(fā)管線，將原有煙囪式能力串聯(lián)成體系化工具鏈，致力于打造絲滑流暢的開發(fā)者體驗。
二、互聯(lián)網(wǎng)研發(fā)效能關(guān)鍵場景技術(shù)
根據(jù)上述研發(fā)效能現(xiàn)狀來看，我們規(guī)劃了研發(fā)效能的需求標準化、研發(fā)標準化。根據(jù)2個標準化，我們梳理了3個關(guān)鍵場景：需求自動化、標準流水線、測試自動化。
需求標準化：需求自動化作為標準化實現(xiàn)的關(guān)鍵，它作為需求整個標準化驅(qū)動引擎，推動需求狀態(tài)自動流轉(zhuǎn)。從而實現(xiàn)分支創(chuàng)建和合并、測試環(huán)境交付、測試自動化驗證等場景串聯(lián)，達到全鏈路需求標準化交付目的。例如：需求拆分任務(wù)時按照分支策略自動拉分支，需求轉(zhuǎn)測時能夠自動合并分支，以及觸發(fā)流水線執(zhí)行測試環(huán)境發(fā)版，及時更新測試環(huán)境版本。
標準流水線：主要流水線內(nèi)卡片類型有明確的規(guī)范，為了減少流水線配置，推進流水線“一人配置、多人共享”，實現(xiàn)流水線并行執(zhí)行，不受運行時流水線的限制，使得滿足所有目標項目符合持續(xù)集成的要求。
測試自動化：作為研發(fā)效能質(zhì)量提升的重要措施，在需求狀態(tài)發(fā)生流轉(zhuǎn)時，則自動觸發(fā)流水線實現(xiàn)測試環(huán)境更新，以及觸發(fā)測試用例的執(zhí)行，主要包含流程管控自動化，以及測試實施自動化兩個方面。
上面需求自動化是為了解決需求端到端過程中自動化串聯(lián)，那原先需求自動化是解決什么問題呢？我們接下來看下目前互聯(lián)網(wǎng)需求流程端到端流程，不同階段的場景之間自動化率較低，大部分靠手工操作。并且根據(jù)該頁下半部分來看，支持研發(fā)效能實施操作的平臺較多，圖上所示的基本只是在平臺層面有單一支持，并沒有實現(xiàn)串聯(lián)，用戶多平臺操作成本較高。
根據(jù)圖上流程顯示多平臺操作成本高，自動化聯(lián)動率較低，面對這樣的用戶痛點問題，我們需要根據(jù)上述流程示意圖，3個大的階段7個關(guān)鍵狀態(tài)和3個核心平臺之間動態(tài)自動化聯(lián)動。
首先，在需求階段，需求從納入迭代時就根據(jù)分支策略自動化拉取分支，完成需求設(shè)計進入開發(fā)階段，當需求狀態(tài)從待開發(fā)狀態(tài)變成已完成開發(fā)時，則自動化觸發(fā)測試環(huán)境流水線運行。
其次，觸發(fā)流水線運行后則首先將分支進行合并，并且將合并后的分支執(zhí)行代碼靜態(tài)檢查和代碼評審，通過之后借助全鏈路能力快速拉取多版本測試環(huán)境，與此同時也同步觸發(fā)測試平臺的測試用例執(zhí)行，涵蓋功能、性能等接口測試用例。
再次，完成測試環(huán)境搭建以及測試用例的執(zhí)行，生成對應(yīng)的測試報告。此時流水線將結(jié)合測試結(jié)果動態(tài)生成上線工單，也同步反饋更新需求狀態(tài)到待上線狀態(tài)。
最后，待上線工單完成相關(guān)審批，此時將按照預(yù)設(shè)策略執(zhí)行線上部署，完成線上交付，則自動反饋需求狀態(tài)更新已上線狀態(tài)。到目前為止，我們能夠看到整體的狀態(tài)流轉(zhuǎn)絕大部分以上都自動化完成。
上述我們談到需求自動化的流轉(zhuǎn)流程，那要實現(xiàn)這樣的自動化流程，我們要如何做到呢？如圖所示我們能夠看到完成整個自動化流轉(zhuǎn)需要4個部分：事件觸發(fā)機、規(guī)則匹配引擎、規(guī)則執(zhí)行器、日志記錄器。
首先，在觸發(fā)執(zhí)行之前，我們需要先配置觸發(fā)執(zhí)行規(guī)則，例如：“當xx發(fā)生時，則執(zhí)行xx事件”等，并且將規(guī)則的執(zhí)行主體、觸發(fā)時機、執(zhí)行動作關(guān)聯(lián)。此時，一旦規(guī)則的觸發(fā)時機達到條件時，則產(chǎn)生觸發(fā)事件，加入事件隊列，采用先進先出模式執(zhí)行。
其次，當事件隊列出列某個觸發(fā)事件之后，則將事件傳播到規(guī)則匹配引擎，此時通過匹配規(guī)則進行模版匹配，一旦匹配通過，則將規(guī)則對應(yīng)的執(zhí)行主體任務(wù)取出，并且觸發(fā)action動作，例如：傳遞xx參數(shù)并調(diào)用指定流水線運行等，最后將執(zhí)行狀態(tài)返回，記錄到日志。
剛剛我們看到的是需求自動化的上下游觸發(fā)，要是能夠讓進一步提升研發(fā)交付效能，我們此時就需要關(guān)注通過流水線實現(xiàn)標準化交付。從圖上我們能夠看到要想實現(xiàn)交付成熟度從1.0提升到2.0，需要提升持續(xù)交付的規(guī)范化，我們知道單純依靠流程規(guī)范來實現(xiàn)流水線按照指定的規(guī)范配置和執(zhí)行，只能通過平臺標準化流水線配置與運行，才能以實現(xiàn)交付流程的標準化和一致性。
為了實現(xiàn)標準化流水線，需要3個部分。
首先，需要定制標準流程，約束所有業(yè)務(wù)研發(fā)團隊統(tǒng)一標準化流程操作；
其次，要考慮多場景觸發(fā)，則需要保證流水線可并行運行；
最后，要通過標準檢查來保證流水線能夠按照設(shè)定好的規(guī)則配置，從而實現(xiàn)標準化交付。
上述我們也提到要實現(xiàn)標準流水線，需要支持流水線在多場景下并行執(zhí)行，提升流水線的使用和運行效率。談到并行執(zhí)行，我們類比類與實例的關(guān)系，目標是一套流水線配置，可以并行根據(jù)參數(shù)動態(tài)運行不同實例。
那我們來一起看看并行流水線如何實現(xiàn)的，考慮到流水線在運行過程中根據(jù)具體配置，固化按照預(yù)設(shè)分支、環(huán)境運行。為此，要想實現(xiàn)并行執(zhí)行。
關(guān)鍵如下：
- 去除排隊限制，讓統(tǒng)一條流水線可以支持運行多個實例；
- 執(zhí)行過程中隔離資源（機器、環(huán)境、任務(wù)等），避免環(huán)境污染；
- 動態(tài)生成不同執(zhí)行任務(wù)，并自動觸發(fā)運行；
- 保證任務(wù)運行過程中資源隔離，避免運行環(huán)境污染；
- 之后要注意運行結(jié)束后隔離資源回收是否全面。
上述談到要實現(xiàn)流水線標準化，靠人工檢查效率低下，此處基于標準規(guī)則和檢查機制來保證。為此，我們來了解下我們是如何實現(xiàn)標準化規(guī)則檢查的，此處核心是將所有配置位運算可解析的格式，通過&和^操作來實現(xiàn)。
正如上圖所示，我們將規(guī)則檢查分為兩個關(guān)鍵步驟：
- 通過&識別是否一致，主要通過二進制位檢查來識別是否有通過檢查；
- 如果不一致，則通過^和&再次識別具體不一致的位置，從實現(xiàn)快速校驗和識別，將得到的結(jié)果到數(shù)據(jù)庫中比對出不一致的流水線及歸屬服務(wù)。
我們從需求自動化到流水線標準化，主要關(guān)注效率維度提升，接下來我們看下在質(zhì)量維度的提升。在測試域我們關(guān)注的測試活動實施，主要分為兩塊：流程管控自動化、測試實施自動化。
流程管控自動化，通過打通了研發(fā)域、交付域、測試域，完成測試任務(wù)的自動流轉(zhuǎn)，從而實現(xiàn)覆蓋了80%項目的測試活動。
對于測試實施自動化而言，測試實施分為客戶端和服務(wù)端兩個維度。
- 對于服務(wù)端測試：接口和性能自動化、變更風險可視化是確保服務(wù)端高質(zhì)量測試交付的關(guān)鍵，兩者的自動化覆蓋度超過70%的核心項目。
- 對于客戶端測試：通過統(tǒng)一的插件化方案實現(xiàn)各類自動化能力（穩(wěn)定性、功能、埋點等），并支持實時監(jiān)控手工測試過程中相關(guān)數(shù)據(jù)，從而保障客戶端測試的整體效果。目前覆蓋超過90%的APK應(yīng)用。
我們提到接口測試自動化，那我們來一起看下如何實現(xiàn)？接口自動化實現(xiàn)總體分為4個大的步驟，分別是：接口管理、用例轉(zhuǎn)化、用例執(zhí)行、輸出報告，其中接口管理考慮場景，又分為接口自動化掃描和流量錄制。
接口錄制階段：接口掃描采用agent組件在java工程測試環(huán)境啟動過程中動態(tài)采集工程所有的java訪問接口，并且實時將接口數(shù)據(jù)上報到接口服務(wù)平臺。
接口管理階段：除了支持工程掃描，也可以借助自研流量錄制平臺進行錄制，并且將線上錄制好的接口鏈接及參數(shù)登記到接口服務(wù)平臺。
用例執(zhí)行階段：通過將接口參數(shù)進行解析，動態(tài)生成接口測試用例，并針對生成的接口測試用例進行驗證是否有效。
報告輸出階段：通過接口測試用例動態(tài)生成，我們后續(xù)可以將單個測試用例進行批量組合成套件，可以根據(jù)代碼變更動態(tài)識別出需要自動化測試的接口用例，通過手工、流水線、定時進行觸發(fā)，并且將測試的接口生成測試報告通知給用戶，便于用戶實時關(guān)注測試結(jié)果。
我們了解了接口的自動化，通過自動化我們可以有效提升測試的質(zhì)量。但是我們都知道，接口的穩(wěn)定性除了功能的完整性測試之外，也需要考慮在目標用戶體量下的穩(wěn)定性和可靠性，我們接下來一起看下關(guān)于接口自動化壓測的實現(xiàn)，談到接口性能壓測，那必然離不開接口、性能測試用例，以及壓測需要的環(huán)境。我們從整體來看，壓測過程分為兩個部分：線上環(huán)境接口錄制、壓測環(huán)境流量回放。
- 線上環(huán)境接口錄制主要是采用我們公司自研的流量錄制回放平臺月光寶盒（MoonBox），通過moonbox-sdk將線上流量采集并推送到平臺，之后將錄制的流量接口數(shù)據(jù)存放在ES數(shù)據(jù)庫中，待壓測平臺IPT需要的時候拉取。
- 用戶在IPT壓測平臺開啟壓測時，平臺根據(jù)用戶指定的配置動態(tài)形成壓測策略推送到壓測服務(wù)，并通過壓測服務(wù)轉(zhuǎn)化為一組組壓測任務(wù)下發(fā)到壓測集群，考慮到壓測任務(wù)體量不同，壓測集群借助容器可以動態(tài)伸縮，實現(xiàn)目標體量的完全模擬。通過壓測集群批量、動態(tài)非線性實時壓測，與此同時IPT壓測平臺會動態(tài)從監(jiān)控平臺獲取壓測環(huán)境監(jiān)測數(shù)據(jù)，并且將性能壓測結(jié)果進行整合，最終形成目標壓測報告發(fā)送給用戶。
三、研發(fā)效能項目實踐與效果
我們介紹了在效能平臺建設(shè)過程中面臨的挑戰(zhàn)和關(guān)鍵技術(shù)。當然所有能力的建設(shè)都會回歸到助力業(yè)務(wù)效能提升上面去，在實際的業(yè)務(wù)中我們是如何實踐這些能力提升研發(fā)效能。
在“應(yīng)用商店”項目中，我們在“需求交付標準化”和“研發(fā)過程標準化”的框架下，重點實踐了需求分層管理和自動化驅(qū)動，標準流水線和自動化測試，有效地解決了在需求管理和研發(fā)流程中的效率問題。
vivo應(yīng)用商店是vivo官方團隊傾力打造的應(yīng)用下載及管理平臺，為vivo手機用戶提供海量的應(yīng)用和游戲，是一款工具產(chǎn)品，也是一款商業(yè)化產(chǎn)品，既協(xié)助開發(fā)者獲客的同時促進合規(guī)，也要在幫助用戶獲取應(yīng)用時做好風險管控。對于上線的需求有著嚴格的評估流程，會經(jīng)過需求、開發(fā)、測試、上線、實驗等各個階段的各類評審與評估。通過對應(yīng)用商店研發(fā)效能成熟度的評估，發(fā)現(xiàn)在需求管理、質(zhì)量保證和持續(xù)集成方面還有很大提升的空間，為此我們的實踐重點也是從這里展開。
首先，通過需求的分層管理，將需求拆分成可以在線上進行獨立商業(yè)驗證的特性。在評審和設(shè)計環(huán)節(jié)，我們的過程涵蓋了產(chǎn)品、需求、策劃以及埋點，通過持續(xù)的評審來保證正在做正確的事情。
其次，在開發(fā)層面，將業(yè)務(wù)特性分端拆分成不同的用戶故事，并進行開發(fā)和測試的閉環(huán)。整個需求流程的推進，更多的依賴工具來驅(qū)動，避免人工導(dǎo)致的錯誤和流程執(zhí)行的不到位。
比如說：
1）在需求的開始，項目管理工具會自動創(chuàng)建需求群，在策劃評審?fù)ㄟ^后，流程引擎會通知數(shù)據(jù)產(chǎn)品和設(shè)計進行埋點和UI設(shè)計，在所有開發(fā)準備工作完成后，自動進行分端拆分用戶故事，并通知項目管理人員組織進行排期。
2）在開發(fā)完成后，項目管理工具會協(xié)助開發(fā)創(chuàng)建驗收單和測試單，并將必要的信息填充在工單中，開發(fā)人員所需要做的就是填寫少量的信息，并提交執(zhí)行。
最后，所有的項目活動，通過項目管理工具流程引擎來驅(qū)動，讓開發(fā)專注于開發(fā)，測試專注于測試，流程的事情交給系統(tǒng)，力求一次性把事情做對。讓項目團隊持續(xù)、高效、高質(zhì)量的進行價值交付，可以看到應(yīng)用商店2024年上半年我們將需求研發(fā)平均交付時長優(yōu)化至17天。
除了上面的需求流程自動化，我們在研發(fā)過程也進行了很多優(yōu)化探索。我們在整個研發(fā)階段打通各個系統(tǒng)之間的交互，詳細如下：
需求階段：我們在項目管理工具VAPD上對需求進行排期，確定好版本號后，通過“分支管理” 功能配合自定義的分支規(guī)范，一鍵創(chuàng)建并拉取各個服務(wù)的代碼分支。并將各個服務(wù)的分支與流水線、工單、代碼評審平臺、發(fā)布等系統(tǒng)關(guān)聯(lián)，后續(xù)所有代碼分支相關(guān)的活動都可以自動化的處理。
開發(fā)階段：我們設(shè)計了六條不同規(guī)格的流水線，涵蓋了我們研發(fā)的各個階段，比如“開發(fā)流水線”，會監(jiān)聽所有人的代碼提交。在代碼發(fā)生變動時會自動執(zhí)行我們的預(yù)先定義好的各項任務(wù)，包括各類安全檢查，靜態(tài)代碼分析及代碼規(guī)范檢查等等，將發(fā)現(xiàn)的問題實時通過V消息反饋給開發(fā)團隊，將盡可能多的檢查工作都放在開發(fā)階段，盡早暴露編碼過程中引入的各種風險和問題，實現(xiàn)驗證左移。
測試階段：當我們的開發(fā)結(jié)束，并通過 測試平臺測試合格，制品晉級成功后，我們開發(fā)的產(chǎn)品就可以進行發(fā)布上線了，當然這個過程仍然伴隨著各種自動化工具的配合，我們的流水線會推進整個發(fā)布過程，自動化點檢平臺會對所有的功能進行回歸、點檢、驗證、灰度，確保發(fā)布功能的完善。
上線階段：最后配合埋點、告警、監(jiān)控、云診斷等手段，將我們的發(fā)布過程可視化。
縱觀整個過程來看，參與的角色和平臺非常的多，平臺很多都是獨立或者自動化能力不可達，需要人工傳遞或者手動編輯，我們將各平臺能力打通，真正實現(xiàn)狀態(tài)和數(shù)據(jù)的自動流轉(zhuǎn)。下方也列出了我們統(tǒng)計到的一系列提效數(shù)據(jù)，從分支管理到工單自助，從需求建群到任務(wù)催辦等等，最終我們在2023年實現(xiàn)開發(fā)人力節(jié)省超過270人天
我們介紹了更多的我們在開發(fā)編碼階段所實踐的內(nèi)容，接下來看看在測試階段，我們做了哪些提升。
首先，測試過程中最重要的一環(huán)是我們要測試什么內(nèi)容？如何圈定測試的范圍？傳統(tǒng)的方式是我們的測試人員根據(jù)需求，配合開發(fā)人員的意見來分析可能的業(yè)務(wù)影響范圍、編寫測試用例，整個過程其實相對主觀，靠的是我們常說的經(jīng)驗主義，依賴于測試、開發(fā)人員的經(jīng)驗，對業(yè)務(wù)的理解深度，以及對上下游關(guān)聯(lián)關(guān)系的掌握程度。
其次，這個能力是因人而異的，過程也是偏主觀的，容易造成判斷錯誤或者遺漏。所以我們要做的第一個提升就是通過工具來更客觀的分析業(yè)務(wù)的影響范圍，依據(jù)的就是代碼的差異性分析和上下游調(diào)用鏈圖譜，即通過編碼前后代碼的變化來確定哪些服務(wù)、接口受到了影響，同時結(jié)合調(diào)用鏈圖譜檢索可能被這些服務(wù)或接口影響到的上下游。這樣在一定程度是彌補了不同測試水平人員在主觀經(jīng)驗上的差距，以及各個業(yè)務(wù)上下文帶來的影響。
再次，通過不同規(guī)格的流水線驅(qū)動，執(zhí)行綁定的各類不同任務(wù)實現(xiàn)持續(xù)測試以及驗證左移，這些任務(wù)包括了各類自動化的檢查與驗證，功能的、性能的以及人工介入的。
最后，通過我們的測試準出門禁，確保制品的輸出質(zhì)量，并將測試過程中產(chǎn)生的數(shù)據(jù)資產(chǎn)沉淀到后續(xù)的準出報告中。最終，在這些流水線和自動化工具的支撐下，我們整個研發(fā)階段的測試活動滲透率提升了 156%，測試執(zhí)行效率提升了 35%，版本發(fā)布的成功率也提升到了 97.27%。
四、研發(fā)效能未來規(guī)劃
從上述的近幾年在研發(fā)效能關(guān)鍵場景和項目上落地情況有了一定了解，那未來計劃如何繼續(xù)推進研發(fā)效能呢？接下來我們就一起聊聊研發(fā)效能未來的規(guī)劃。
談到研發(fā)效能每個公司都面臨不一樣的情況，vivo互聯(lián)網(wǎng)研發(fā)效能也經(jīng)歷前前后后4個大的階段，從早期的開源工具化時代到場景化業(yè)務(wù)賦能時代。
工具化時代：早2018年及以前，vivo互聯(lián)網(wǎng)還是主要以解決當時研發(fā)管理過程中遇到的問題和痛點展開，不斷提升研發(fā)過程白屏化、自動化，盡可能借助開源和商業(yè)化工具JIRA、SVN、Gitlab、Jenkins、SaltStack等來提升研發(fā)運維效率。
平臺化時代：隨著平臺種類規(guī)模增加，用戶需要基于自己的訴求去“找”平臺和工具，然而平臺也面臨著“找不到”用戶的兩難境遇。
體系化時代：我們也考慮建立體系化平臺，消除用戶與平臺的“隔離”，讓用戶能夠在平臺解決自己的訴求。
場景化時代：與大多數(shù)公司的發(fā)展一致，平臺經(jīng)歷多年的發(fā)展以后，隨著用戶體量、業(yè)務(wù)復(fù)雜度增加，平臺個性化、定制化訴求逐步導(dǎo)致平臺維護和使用成本進一步增加，讓平臺研發(fā)團隊維護成本非常高，也讓用戶的訴求受到了影響。為此，如何從用戶場景出發(fā)規(guī)劃和實現(xiàn)成為關(guān)鍵。
談到這里vivo互聯(lián)網(wǎng)研發(fā)效能的未來到底是什么？vivo互聯(lián)網(wǎng)研發(fā)效能團隊結(jié)合自身經(jīng)歷來看，還是要回歸本源。結(jié)合行業(yè)的先進理論體系，進一步走進業(yè)務(wù)研發(fā)團隊，找到真正的痛點與訴求，幫助業(yè)務(wù)團隊“做正確的事，把事情做正確”。
我們前面聊到對研發(fā)效能新的認知和理解，未來我們將進一步走進業(yè)務(wù)來提效。我們?yōu)榇艘捕x三個北極星指標來牽引我們的目標達成，分別為：代碼前置變更時間1小時內(nèi)，需求研發(fā)交付時長在2周內(nèi)，需求實現(xiàn)到結(jié)果閉環(huán)3周內(nèi)。
根據(jù)研發(fā)效能新的理解和目標，我們也多次回滾本源，思考我們的最佳路徑，總結(jié)來看就5個階段，分別為：
第1階段實現(xiàn)工具全面自動化，消除絕大部分黑屏和手工操作。
第2階段工具實現(xiàn)串聯(lián)，能夠結(jié)合項目研發(fā)流程初步具備自動化流轉(zhuǎn)。
第3階段實現(xiàn)研發(fā)效能信息全面拉通，平臺之間的研效信息能夠在多個平臺間自由的共享，實現(xiàn)多維度、多角度度量識別效能低洼，并且結(jié)合研發(fā)流程不斷提升項目的研發(fā)效能。
第4階段之后，平臺能夠基于平臺度量的能力逐步識別項目內(nèi)個性化研發(fā)場景的短板，并且結(jié)合研發(fā)效能實踐專家，深入項目內(nèi)部，真正結(jié)合場景自助化、自動化進一步項目研發(fā)效能。
第5階段就不僅僅關(guān)注項目本身的研效，而是需要回歸需求本身去關(guān)注整體價值達成效果。
我們期望通過目標來牽引業(yè)務(wù)，將OKR、項目、需求等不同層級的要素進行連接。通過可視化看到任務(wù)分解、進展、數(shù)據(jù)效果，以及資源投入和風險，真正意義上做到“一層支撐一層”，層層看得清、管得明。從而實現(xiàn)始終在做正確的事情。除了上面的需求流程自動化，我們在研發(fā)過程也進行了很多優(yōu)化探索。
