2017年1月13日舉辦的云棲計算之旅線下沙龍上，阿里巴巴技術質量架構師范之岳帶來了題為阿里巴巴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研發效能平臺和對外云效平臺的產品負責人，阿里巴巴速賣通業務的技術質量負責人，技術質量架構師。精通研發質量效能平臺產品，在敏捷研發、持續交付、研發團隊管理等方面有豐富的經驗。