2017年1月13日舉辦的【雲棲計算之旅】線下沙龍第4期研發管理專場，阿里巴巴技術質量架構師範之嶽帶來了題爲阿里巴巴B2B高效研發管理實踐的演講。本文主要從互聯網無線研發的問題與挑戰開始講起，重點講解了阿里工程效能技術平臺，包括雲效平臺等，最後對阿里一線PL的職責進行了思考。一塊兒來了解下吧。
安全
如下是精彩內容整理：網絡
互聯網無線研發的問題與挑戰架構
B2B技術部這幾年來面對了不少的問題與挑戰，具體以下：併發
對於不一樣管理者來講，他們的訴求是有區別的。對於創業團隊來講，一開始只有三到五我的，須全民皆研發、全民皆測試、全民皆運維，你們一塊兒考慮怎麼將業務發上線，而且拉來更多的用戶，考慮不到工程效能、效率的體現和度量等問題。但當業務增加上去以後，團隊就會擴大，團隊層次區分出來，業務迭代快速，項目並行量大，業務很難快速交付到用戶手中；並且，研發團隊變大，項目資源管理成本就會提高、透明度低；用戶體驗要求高，測試成本增加迅速，人肉測試多，應用增加迅速，環境構建複雜，驗證難度增長；不少創業公司都用無線，包括大型公司，阿里全部的海外B2B、外貿B2B都有對應的APP，就會帶來手機預算大、手機設備雜、手機測試難等問題；對於大型組織來講，咱們要和業務方以及不一樣研發團隊打交道，研發過程當中各角色協做成本高；還有金融、保險等傳統產業的互聯網研發思惟的轉變。框架
對於老闆來講，業務老闆尤爲關心研發團隊在幹什麼，業務何時發佈，技術老闆關心團隊的效率如何，怎麼砍業務需求，人手夠不夠，產品質量如何等。對於開發、測試、運維工程師們來講，他們但願想怎麼發就怎麼發，隨時隨地發佈需求，高效高質的發佈，不要倒排。運維
老闆但願更多集中式的資源與需求管理，研發者們但願有敏捷化的工程實踐支撐，包含研發過程到最終上線的過程。微服務
那麼，敏捷框架是否是解決這些問題最終的方案呢？性能
事實上不是，當敏捷思想在中國普遍傳播時，更多的是一種理念。全部開發者、業務方、需求方對於敏捷的理解要求是很是高的，有時候落實下去形式上很敏捷，但交付速度並無變快，敏捷還提倡輕文檔輕流程，致使有些公司搞了很久敏捷什麼文檔沒有留下來，敏捷只是一種思想，解決不了實質性工程效能問題。單元測試
若是你的組織作了敏捷轉型，一個Scrum團隊將業務人員、開發人員、測試人員以及運維人員都歸入一個團隊，就能夠解決互相推卸責任的問題，但兩個Scrum團隊間沒辦法解開耦合，會出現協做上的問題，敏捷解決不了這樣的問題。測試
技術債與服務化
對於工程效能的實現，須要有平臺來支撐持續集成、快速發佈、持續交付等，這種須要工程效能平臺的前提是咱們的系統自己，若是是幾百萬行代碼、幾十個交付模塊的大應用，就算有再好的持續交付通道平臺也無濟於事，由於小業務改動須要大應用發佈，項目無法並行起來，沒法輕快！
近幾年，阿里在作服務化的改造以及微服務的實踐，微服務改造應用的拆解、去耦合是全部持續交付目標的前提。
工程效能技術中臺
技術中臺支撐整個研發管理、研發行爲、持續交付通道。技術中臺分爲兩部分，綜合管理有對應的產品支撐，它對應到老闆們想要的東西；研發工程效能對應到一線研發工程師的訴求，它自己也進行了分層，上層就是直接的應用，好比分層自動化、無線適配、遠程真機以及性能測試等，下面的服務層咱們有持續集成服務、自動化服務、測試數據服務、測試環境服務，對於B2B技術部如今使用的平臺，只要拉出代碼一鍵便可部署完項目須要的整個環境。
技術中臺管理閉環
咱們但願建設從需求規劃——立項——部署環境、持續集成——最終的驗證測試——再集成——進入準生產環境——全自動化驗證——最後發佈是上線，上線後要作業務的數據盤點，整個過程是閉環，咱們但願每一個節點都有對應的產品支撐，通過三四年的建設，大部分的節點咱們已經都有產品作支撐，高效優質且透明，無線工程目前也在起步階段。
雲效平臺
上圖爲雲效平臺持續交付通道圖，對於項目上的各類併發的小需求，咱們會有前臺分圈的概念，把一些有相關業務耦合的應用模塊放在同一個分圈裏面，不一樣分圈的業務模塊能夠作獨立的發佈。爲何要作分圈呢，就是有時候咱們作自動化驗證時，須要把關聯度放在一塊兒來驗證，因此A、B、C、D就會有獨立分圈的發佈通道，不一樣的分圈作完自動化驗證後，就會直接進入到自動化生產環境中去，達到持續發佈效果，它是有必定條件限制的徹底自由的獨立發佈，這個限制主要仍是出於質量保障，質量保障基本基於全自動化驗證。
差別化的研發流程策略
阿里B2B技術部很是強調差別化的研發流程策略，咱們把重點的大型項目和小型需求是分的很開的，目前，咱們測試與開發的配比基本達到1比10，因此咱們確定作不到全部的變動、全部的項目都有測試同窗直接來接手，但不表明沒有那樣的測試行爲。
大型項目：對於重點大型項目，咱們有測試人員直接進入，走分迭代的瀑布式項目流程，Milestone的保障，每一個節點都有要求輸出，好比文檔評審等；
小型需求、bugfix： 小型需求的改動量不大，若是開發有足夠的分析結果證實需求不須要測試人員參與，但並不意味着不須要測試，項目裏的持續集成是一鍵觸發測試過程，而後在發佈以前和別的需求合完代碼後，還有一道全自動化流程保障，能夠跑單元測試、接口測試、UI測試、安全測試等，只有在失敗的時候測試人員纔會介入查看問題；
核心應用：對於業務來講，不一樣的應用承擔不一樣的業務，經過流程限制的發佈窗口，分層自動化的要求很是高，咱們要將核心應用和非核心應用區分開；
核心服務：經過流程限制的發佈窗口，讓核心服務關聯的自動化範圍。
阿里一線P Leader的職責與思考
阿里對於一線的研發管理者都是專業技術出身，業務、管理、技術三塊缺一不可，阿里是一個業務導向的公司，只有依靠中臺，才能快速的支持上層的改變，若是業務想要什麼，你作什麼出來，你會發現研發成本很是高。只有把業務和技術結合在一塊兒思考，才能作到最好，阿里不少架構師、P Leader都要進行這樣的思考，P Leader更多的是要與業務掛鉤，團隊的考覈、團隊的方向、團隊的目標和建設都是由P Leader來作的。
範之嶽：2011年加入阿里巴巴。擔任阿里巴巴B2B研發效能平臺和對外雲效平臺的產品負責人，阿里巴巴速賣通業務的技術質量負責人，技術質量架構師。精通研發質量效能平臺產品，在敏捷研發、持續交付、研發團隊管理等方面有豐富的經驗。