2017年1月13日舉辦的云棲計(jì)算之旅線下沙龍上，阿里巴巴技術(shù)質(zhì)量架構(gòu)師范之岳帶來(lái)了題為阿里巴巴B2B高效研發(fā)管理實(shí)踐的演講。本文主要從互聯(lián)網(wǎng)無(wú)線研發(fā)的問(wèn)題與挑戰(zhàn)開(kāi)始講起，重點(diǎn)講解了阿里工程效能技術(shù)平臺(tái)，包括云效平臺(tái)等，最后對(duì)阿里一線PL的職責(zé)進(jìn)行了思考。一起來(lái)了解下吧。

以下是精彩內(nèi)容整理：

互聯(lián)網(wǎng)無(wú)線研發(fā)的問(wèn)題與挑戰(zhàn)

B2B技術(shù)部這幾年來(lái)面對(duì)了很多的問(wèn)題與挑戰(zhàn)，具體如下：

對(duì)于不同管理者來(lái)說(shuō)，他們的訴求是有區(qū)別的。對(duì)于創(chuàng)業(yè)團(tuán)隊(duì)來(lái)說(shuō)，一開(kāi)始只有三到五個(gè)人，須全民皆研發(fā)、全民皆測(cè)試、全民皆運(yùn)維，大家一起考慮怎么將業(yè)務(wù)發(fā)上線，并且拉來(lái)更多的用戶，考慮不到工程效能、效率的體現(xiàn)和度量等問(wèn)題。但當(dāng)業(yè)務(wù)增長(zhǎng)上去之后，團(tuán)隊(duì)就會(huì)擴(kuò)大，團(tuán)隊(duì)層次區(qū)分出來(lái)，業(yè)務(wù)迭代快速，項(xiàng)目并行量大，業(yè)務(wù)很難快速交付到用戶手中；而且，研發(fā)團(tuán)隊(duì)變大，項(xiàng)目資源管理成本就會(huì)提升、透明度低；用戶體驗(yàn)要求高，測(cè)試成本增長(zhǎng)迅速，人肉測(cè)試多，應(yīng)用增長(zhǎng)迅速，環(huán)境構(gòu)建復(fù)雜，驗(yàn)證難度增加；很多創(chuàng)業(yè)公司都用無(wú)線，包括大型公司，阿里所有的海外B2B、外貿(mào)B2B都有對(duì)應(yīng)的APP，就會(huì)帶來(lái)手機(jī)預(yù)算大、手機(jī)設(shè)備雜、手機(jī)測(cè)試難等問(wèn)題；對(duì)于大型組織來(lái)說(shuō)，我們要和業(yè)務(wù)方以及不同研發(fā)團(tuán)隊(duì)打交道，研發(fā)過(guò)程中各角色協(xié)作成本高；還有金融、保險(xiǎn)等傳統(tǒng)產(chǎn)業(yè)的互聯(lián)網(wǎng)研發(fā)思維的轉(zhuǎn)變。

對(duì)于老板來(lái)說(shuō)，業(yè)務(wù)老板尤其關(guān)心研發(fā)團(tuán)隊(duì)在干什么，業(yè)務(wù)什么時(shí)候發(fā)布，技術(shù)老板關(guān)心團(tuán)隊(duì)的效率如何，怎么砍業(yè)務(wù)需求，人手夠不夠，產(chǎn)品質(zhì)量如何等。對(duì)于開(kāi)發(fā)、測(cè)試、運(yùn)維工程師們來(lái)說(shuō)，他們希望想怎么發(fā)就怎么發(fā)，隨時(shí)隨地發(fā)布需求，高效高質(zhì)的發(fā)布，不要倒排。

老板希望更多集中式的資源與需求管理，研發(fā)者們希望有敏捷化的工程實(shí)踐支撐，包含研發(fā)過(guò)程到最終上線的過(guò)程。

那么，敏捷框架是不是解決這些問(wèn)題最終的方案呢？

事實(shí)上不是，當(dāng)敏捷思想在中國(guó)廣泛傳播時(shí)，更多的是一種理念。所有開(kāi)發(fā)者、業(yè)務(wù)方、需求方對(duì)于敏捷的理解要求是非常高的，有時(shí)候落實(shí)下去形式上很敏捷，但交付速度并沒(méi)有變快，敏捷還提倡輕文檔輕流程，導(dǎo)致有些公司搞了好久敏捷什么文檔沒(méi)有留下來(lái)，敏捷只是一種思想，解決不了實(shí)質(zhì)性工程效能問(wèn)題。

如果你的組織做了敏捷轉(zhuǎn)型，一個(gè)Scrum團(tuán)隊(duì)將業(yè)務(wù)人員、開(kāi)發(fā)人員、測(cè)試人員以及運(yùn)維人員都納入一個(gè)團(tuán)隊(duì)，就可以解決互相推卸責(zé)任的問(wèn)題，但兩個(gè)Scrum團(tuán)隊(duì)間沒(méi)辦法解開(kāi)耦合，會(huì)出現(xiàn)協(xié)作上的問(wèn)題，敏捷解決不了這樣的問(wèn)題。

技術(shù)債與服務(wù)化

對(duì)于工程效能的實(shí)現(xiàn)，需要有平臺(tái)來(lái)支撐持續(xù)集成、快速發(fā)布、持續(xù)交付等，這種需要工程效能平臺(tái)的前提是我們的系統(tǒng)本身，如果是幾百萬(wàn)行代碼、幾十個(gè)交付模塊的大應(yīng)用，就算有再好的持續(xù)交付通道平臺(tái)也無(wú)濟(jì)于事，因?yàn)樾I(yè)務(wù)改動(dòng)需要大應(yīng)用發(fā)布，項(xiàng)目沒(méi)法并行起來(lái)，無(wú)法輕快！

近幾年，阿里在做服務(wù)化的改造以及微服務(wù)的實(shí)踐，微服務(wù)改造應(yīng)用的拆解、去耦合是所有持續(xù)交付目標(biāo)的前提。

工程效能技術(shù)中臺(tái)

技術(shù)中臺(tái)支撐整個(gè)研發(fā)管理、研發(fā)行為、持續(xù)交付通道。技術(shù)中臺(tái)分為兩部分，綜合管理有對(duì)應(yīng)的產(chǎn)品支撐，它對(duì)應(yīng)到老板們想要的東西；研發(fā)工程效能對(duì)應(yīng)到一線研發(fā)工程師的訴求，它本身也進(jìn)行了分層，上層就是直接的應(yīng)用，比如分層自動(dòng)化、無(wú)線適配、遠(yuǎn)程真機(jī)以及性能測(cè)試等，下面的服務(wù)層我們有持續(xù)集成服務(wù)、自動(dòng)化服務(wù)、測(cè)試數(shù)據(jù)服務(wù)、測(cè)試環(huán)境服務(wù)，對(duì)于B2B技術(shù)部現(xiàn)在使用的平臺(tái)，只要拉出代碼一鍵即可部署完項(xiàng)目需要的整個(gè)環(huán)境。

技術(shù)中臺(tái)管理閉環(huán)

我們希望建設(shè)從需求規(guī)劃——立項(xiàng)——部署環(huán)境、持續(xù)集成——最終的驗(yàn)證測(cè)試——再集成——進(jìn)入準(zhǔn)生產(chǎn)環(huán)境——全自動(dòng)化驗(yàn)證——最后發(fā)布是上線，上線后要做業(yè)務(wù)的數(shù)據(jù)盤(pán)點(diǎn)，整個(gè)過(guò)程是閉環(huán)，我們希望每個(gè)節(jié)點(diǎn)都有對(duì)應(yīng)的產(chǎn)品支撐，經(jīng)過(guò)三四年的建設(shè)，大部分的節(jié)點(diǎn)我們已經(jīng)都有產(chǎn)品做支撐，高效優(yōu)質(zhì)且透明，無(wú)線工程目前也在起步階段。

云效平臺(tái)

上圖為云效平臺(tái)持續(xù)交付通道圖，對(duì)于項(xiàng)目上的各種并發(fā)的小需求，我們會(huì)有前臺(tái)分圈的概念，把一些有相關(guān)業(yè)務(wù)耦合的應(yīng)用模塊放在同一個(gè)分圈里面，不同分圈的業(yè)務(wù)模塊可以做獨(dú)立的發(fā)布。為什么要做分圈呢，就是有時(shí)候我們做自動(dòng)化驗(yàn)證時(shí)，需要把關(guān)聯(lián)度放在一起來(lái)驗(yàn)證，所以A、B、C、D就會(huì)有獨(dú)立分圈的發(fā)布通道，不同的分圈做完自動(dòng)化驗(yàn)證后，就會(huì)直接進(jìn)入到自動(dòng)化生產(chǎn)環(huán)境中去，達(dá)到持續(xù)發(fā)布效果，它是有一定條件限制的完全自由的獨(dú)立發(fā)布，這個(gè)限制主要還是出于質(zhì)量保障，質(zhì)量保障基本基于全自動(dòng)化驗(yàn)證。

差異化的研發(fā)流程策略

阿里B2B技術(shù)部非常強(qiáng)調(diào)差異化的研發(fā)流程策略，我們把重點(diǎn)的大型項(xiàng)目和小型需求是分的很開(kāi)的，目前，我們測(cè)試與開(kāi)發(fā)的配比基本達(dá)到1比10，所以我們肯定做不到所有的變更、所有的項(xiàng)目都有測(cè)試同學(xué)直接來(lái)接手，但不代表沒(méi)有那樣的測(cè)試行為。

大型項(xiàng)目：對(duì)于重點(diǎn)大型項(xiàng)目，我們有測(cè)試人員直接進(jìn)入，走分迭代的瀑布式項(xiàng)目流程，Milestone的保障，每個(gè)節(jié)點(diǎn)都有要求輸出，比如文檔評(píng)審等；

小型需求、bugfix： 小型需求的改動(dòng)量不大，如果開(kāi)發(fā)有足夠的分析結(jié)果證明需求不需要測(cè)試人員參與，但并不意味著不需要測(cè)試，項(xiàng)目里的持續(xù)集成是一鍵觸發(fā)測(cè)試過(guò)程，然后在發(fā)布之前和別的需求合完代碼后，還有一道全自動(dòng)化流程保障，可以跑單元測(cè)試、接口測(cè)試、UI測(cè)試、安全測(cè)試等，只有在失敗的時(shí)候測(cè)試人員才會(huì)介入查看問(wèn)題；

核心應(yīng)用：對(duì)于業(yè)務(wù)來(lái)說(shuō)，不同的應(yīng)用承擔(dān)不同的業(yè)務(wù)，通過(guò)流程限制的發(fā)布窗口，分層自動(dòng)化的要求非常高，我們要將核心應(yīng)用和非核心應(yīng)用區(qū)分開(kāi)；

核心服務(wù)：通過(guò)流程限制的發(fā)布窗口，讓核心服務(wù)關(guān)聯(lián)的自動(dòng)化范圍。

阿里一線P Leader的職責(zé)與思考

阿里對(duì)于一線的研發(fā)管理者都是專業(yè)技術(shù)出身，業(yè)務(wù)、管理、技術(shù)三塊缺一不可，阿里是一個(gè)業(yè)務(wù)導(dǎo)向的公司，只有依靠中臺(tái)，才能快速的支持上層的改變，如果業(yè)務(wù)想要什么，你做什么出來(lái)，你會(huì)發(fā)現(xiàn)研發(fā)成本非常高。只有把業(yè)務(wù)和技術(shù)結(jié)合在一起思考，才能做到最好，阿里很多架構(gòu)師、P Leader都要進(jìn)行這樣的思考，P Leader更多的是要與業(yè)務(wù)掛鉤，團(tuán)隊(duì)的考核、團(tuán)隊(duì)的方向、團(tuán)隊(duì)的目標(biāo)和建設(shè)都是由P Leader來(lái)做的。

范之岳：2011年加入阿里巴巴。擔(dān)任阿里巴巴B2B研發(fā)效能平臺(tái)和對(duì)外云效平臺(tái)的產(chǎn)品負(fù)責(zé)人，阿里巴巴速賣通業(yè)務(wù)的技術(shù)質(zhì)量負(fù)責(zé)人，技術(shù)質(zhì)量架構(gòu)師。精通研發(fā)質(zhì)量效能平臺(tái)產(chǎn)品，在敏捷研發(fā)、持續(xù)交付、研發(fā)團(tuán)隊(duì)管理等方面有豐富的經(jīng)驗(yàn)。