2017年1月13日舉辦的云棲計算之旅線下沙龍上，阿里巴巴技術(shù)質(zhì)量架構(gòu)師范之岳帶來了題為阿里巴巴B2B高效研發(fā)管理實踐的演講。本文主要從互聯(lián)網(wǎng)無線研發(fā)的問題與挑戰(zhàn)開始講起，重點講解了阿里工程效能技術(shù)平臺，包括云效平臺等，最后對阿里一線PL的職責(zé)進(jìn)行了思考。一起來了解下吧。
以下是精彩內(nèi)容整理：
互聯(lián)網(wǎng)無線研發(fā)的問題與挑戰(zhàn)
B2B技術(shù)部這幾年來面對了很多的問題與挑戰(zhàn)，具體如下：
對于不同管理者來說，他們的訴求是有區(qū)別的。對于創(chuàng)業(yè)團(tuán)隊來說，一開始只有三到五個人，須全民皆研發(fā)、全民皆測試、全民皆運維，大家一起考慮怎么將業(yè)務(wù)發(fā)上線，并且拉來更多的用戶，考慮不到工程效能、效率的體現(xiàn)和度量等問題。但當(dāng)業(yè)務(wù)增長上去之后，團(tuán)隊就會擴大，團(tuán)隊層次區(qū)分出來，業(yè)務(wù)迭代快速，項目并行量大，業(yè)務(wù)很難快速交付到用戶手中；而且，研發(fā)團(tuán)隊變大，項目資源管理成本就會提升、透明度低；用戶體驗要求高，測試成本增長迅速，人肉測試多，應(yīng)用增長迅速，環(huán)境構(gòu)建復(fù)雜，驗證難度增加；很多創(chuàng)業(yè)公司都用無線，包括大型公司，阿里所有的海外B2B、外貿(mào)B2B都有對應(yīng)的APP，就會帶來手機預(yù)算大、手機設(shè)備雜、手機測試難等問題；對于大型組織來說，我們要和業(yè)務(wù)方以及不同研發(fā)團(tuán)隊打交道，研發(fā)過程中各角色協(xié)作成本高；還有金融、保險等傳統(tǒng)產(chǎn)業(yè)的互聯(lián)網(wǎng)研發(fā)思維的轉(zhuǎn)變。
對于老板來說，業(yè)務(wù)老板尤其關(guān)心研發(fā)團(tuán)隊在干什么，業(yè)務(wù)什么時候發(fā)布，技術(shù)老板關(guān)心團(tuán)隊的效率如何，怎么砍業(yè)務(wù)需求，人手夠不夠，產(chǎn)品質(zhì)量如何等。對于開發(fā)、測試、運維工程師們來說，他們希望想怎么發(fā)就怎么發(fā)，隨時隨地發(fā)布需求，高效高質(zhì)的發(fā)布，不要倒排。
老板希望更多集中式的資源與需求管理，研發(fā)者們希望有敏捷化的工程實踐支撐，包含研發(fā)過程到最終上線的過程。
那么，敏捷框架是不是解決這些問題最終的方案呢？
事實上不是，當(dāng)敏捷思想在中國廣泛傳播時，更多的是一種理念。所有開發(fā)者、業(yè)務(wù)方、需求方對于敏捷的理解要求是非常高的，有時候落實下去形式上很敏捷，但交付速度并沒有變快，敏捷還提倡輕文檔輕流程，導(dǎo)致有些公司搞了好久敏捷什么文檔沒有留下來，敏捷只是一種思想，解決不了實質(zhì)性工程效能問題。
如果你的組織做了敏捷轉(zhuǎn)型，一個Scrum團(tuán)隊將業(yè)務(wù)人員、開發(fā)人員、測試人員以及運維人員都納入一個團(tuán)隊，就可以解決互相推卸責(zé)任的問題，但兩個Scrum團(tuán)隊間沒辦法解開耦合，會出現(xiàn)協(xié)作上的問題，敏捷解決不了這樣的問題。
技術(shù)債與服務(wù)化
對于工程效能的實現(xiàn)，需要有平臺來支撐持續(xù)集成、快速發(fā)布、持續(xù)交付等，這種需要工程效能平臺的前提是我們的系統(tǒng)本身，如果是幾百萬行代碼、幾十個交付模塊的大應(yīng)用，就算有再好的持續(xù)交付通道平臺也無濟于事，因為小業(yè)務(wù)改動需要大應(yīng)用發(fā)布，項目沒法并行起來，無法輕快！
近幾年，阿里在做服務(wù)化的改造以及微服務(wù)的實踐，微服務(wù)改造應(yīng)用的拆解、去耦合是所有持續(xù)交付目標(biāo)的前提。
工程效能技術(shù)中臺
技術(shù)中臺支撐整個研發(fā)管理、研發(fā)行為、持續(xù)交付通道。技術(shù)中臺分為兩部分，綜合管理有對應(yīng)的產(chǎn)品支撐，它對應(yīng)到老板們想要的東西；研發(fā)工程效能對應(yīng)到一線研發(fā)工程師的訴求，它本身也進(jìn)行了分層，上層就是直接的應(yīng)用，比如分層自動化、無線適配、遠(yuǎn)程真機以及性能測試等，下面的服務(wù)層我們有持續(xù)集成服務(wù)、自動化服務(wù)、測試數(shù)據(jù)服務(wù)、測試環(huán)境服務(wù)，對于B2B技術(shù)部現(xiàn)在使用的平臺，只要拉出代碼一鍵即可部署完項目需要的整個環(huán)境。
技術(shù)中臺管理閉環(huán)
我們希望建設(shè)從需求規(guī)劃——立項——部署環(huán)境、持續(xù)集成——最終的驗證測試——再集成——進(jìn)入準(zhǔn)生產(chǎn)環(huán)境——全自動化驗證——最后發(fā)布是上線，上線后要做業(yè)務(wù)的數(shù)據(jù)盤點，整個過程是閉環(huán)，我們希望每個節(jié)點都有對應(yīng)的產(chǎn)品支撐，經(jīng)過三四年的建設(shè)，大部分的節(jié)點我們已經(jīng)都有產(chǎn)品做支撐，高效優(yōu)質(zhì)且透明，無線工程目前也在起步階段。
云效平臺
上圖為云效平臺持續(xù)交付通道圖，對于項目上的各種并發(fā)的小需求，我們會有前臺分圈的概念，把一些有相關(guān)業(yè)務(wù)耦合的應(yīng)用模塊放在同一個分圈里面，不同分圈的業(yè)務(wù)模塊可以做獨立的發(fā)布。為什么要做分圈呢，就是有時候我們做自動化驗證時，需要把關(guān)聯(lián)度放在一起來驗證，所以A、B、C、D就會有獨立分圈的發(fā)布通道，不同的分圈做完自動化驗證后，就會直接進(jìn)入到自動化生產(chǎn)環(huán)境中去，達(dá)到持續(xù)發(fā)布效果，它是有一定條件限制的完全自由的獨立發(fā)布，這個限制主要還是出于質(zhì)量保障，質(zhì)量保障基本基于全自動化驗證。
差異化的研發(fā)流程策略
阿里B2B技術(shù)部非常強調(diào)差異化的研發(fā)流程策略，我們把重點的大型項目和小型需求是分的很開的，目前，我們測試與開發(fā)的配比基本達(dá)到1比10，所以我們肯定做不到所有的變更、所有的項目都有測試同學(xué)直接來接手，但不代表沒有那樣的測試行為。
大型項目：對于重點大型項目，我們有測試人員直接進(jìn)入，走分迭代的瀑布式項目流程，Milestone的保障，每個節(jié)點都有要求輸出，比如文檔評審等；
小型需求、bugfix： 小型需求的改動量不大，如果開發(fā)有足夠的分析結(jié)果證明需求不需要測試人員參與，但并不意味著不需要測試，項目里的持續(xù)集成是一鍵觸發(fā)測試過程，然后在發(fā)布之前和別的需求合完代碼后，還有一道全自動化流程保障，可以跑單元測試、接口測試、UI測試、安全測試等，只有在失敗的時候測試人員才會介入查看問題；
核心應(yīng)用：對于業(yè)務(wù)來說，不同的應(yīng)用承擔(dān)不同的業(yè)務(wù)，通過流程限制的發(fā)布窗口，分層自動化的要求非常高，我們要將核心應(yīng)用和非核心應(yīng)用區(qū)分開；
核心服務(wù)：通過流程限制的發(fā)布窗口，讓核心服務(wù)關(guān)聯(lián)的自動化范圍。
阿里一線P Leader的職責(zé)與思考
阿里對于一線的研發(fā)管理者都是專業(yè)技術(shù)出身，業(yè)務(wù)、管理、技術(shù)三塊缺一不可，阿里是一個業(yè)務(wù)導(dǎo)向的公司，只有依靠中臺，才能快速的支持上層的改變，如果業(yè)務(wù)想要什么，你做什么出來，你會發(fā)現(xiàn)研發(fā)成本非常高。只有把業(yè)務(wù)和技術(shù)結(jié)合在一起思考，才能做到最好，阿里很多架構(gòu)師、P Leader都要進(jìn)行這樣的思考，P Leader更多的是要與業(yè)務(wù)掛鉤，團(tuán)隊的考核、團(tuán)隊的方向、團(tuán)隊的目標(biāo)和建設(shè)都是由P Leader來做的。
范之岳：2011年加入阿里巴巴。擔(dān)任阿里巴巴B2B研發(fā)效能平臺和對外云效平臺的產(chǎn)品負(fù)責(zé)人，阿里巴巴速賣通業(yè)務(wù)的技術(shù)質(zhì)量負(fù)責(zé)人，技術(shù)質(zhì)量架構(gòu)師。精通研發(fā)質(zhì)量效能平臺產(chǎn)品，在敏捷研發(fā)、持續(xù)交付、研發(fā)團(tuán)隊管理等方面有豐富的經(jīng)驗。
