天天看點

業務技術協同線上化的硬碟式研發管理實踐

<b>摘要:</b>在雲效平台策劃推出的《持續內建與傳遞:阿裡最佳實踐》專題中,阿裡雲效産品專家代平為大家深入淺出地分享了網際網路的研發管理理念,解析了企業研發管理面臨的挑戰和困難,揭密了如何結合雲效産品進行業務技術協同線上化的硬碟式研發管理實踐。

<b>以下内容根據演講嘉賓視訊以及ppt整理而成。</b>

<b>演講嘉賓介紹</b>

業務技術協同線上化的硬碟式研發管理實踐

<b>代平,</b>阿裡雲效産品專家。在本次分享中,代平談到自己的職業生涯目前總共經曆了三個階段,第一個階段她從事研發、測試以及項目管理工作,在這個階段水深火熱地工作了四年,積累了大量的項目開發、測試以及管理經驗。第二個階段從事測試的提效工具和項目管理産品的設計工作,在之前做過四年的研發測試以及項目管理之後,代平發現很多事情都是需要針對性地做産品才可能提高效率的,是以她轉型開始做了一些提效的工具以及項目管理産品的相關工作。在第三個階段,随着對于研發全鍊路産品的了解,加上行業客戶的使用訴求就轉型去做研發全過程閉環整合的産品,并且在這個時候就開始結合行業客戶所遇到的問題對于一些專項性的産品進行探索。

本期分享的主題是業務技術協同線上化的硬碟式研發管理實踐,在分享中主要将和大家探讨研發綜合産品管理效能平台應該如何實作,以及如何打通需求、開發、測試、釋出這樣的産品研發全過程,希望能夠給大家帶來收獲。

本次分享的内容主要分為以下四個部分:

一、網際網路研發管理背景

二、常見的研發提效政策及其問題

三、雲效支撐的研發管理實踐

四、實踐最佳路徑和效果

<b>一、網際網路研發管理背景</b>

<b>網際網路研發的特點</b>

業務技術協同線上化的硬碟式研發管理實踐

随着網際網路的發展,不僅僅是網際網路公司的研發,就連傳統企業的研發模式也開始受到網際網路的影響,各行各業都在向“網際網路+”模式轉型,這就導緻網際網路的研發有如下的這些特點:

<b>變化,</b>市場需求變化的速度非常快,這就導緻研發需要快速适應市場需求的變化。

<b>體驗,</b>給使用者帶來的體驗要好,現在因為人們擷取資訊擷取産品實在是太便捷了,因為客戶往往會有非常多的選擇,是以如果産品在功能、安全或者體驗上稍稍落後就會被客戶摒棄。

<b>速度,</b>網際網路市場的競争非常激烈,産品的研發速度是關乎生死的,也會影響最終的成果。

<b>網際網路研發的問題</b>

業務技術協同線上化的硬碟式研發管理實踐

因為網際網路研發有着前面提到的這些特點,也就導緻了在研發過程中出現了如上圖所示的這一些常見的問題,比如業務疊代速度非常快,直接導緻項目的并行量非常大;因為業務發展速度快,是以應用的增長也非常迅速,導緻無論是開發同學還是測試同學在搭建環境時的工作都會變得非常複雜;除此之外因為研發同學在研發過程中需要與各個角色進行一些協調,是以這帶來的研發成本也會非常高;與此同時,測試的成本也在急劇增長,而且使用的人肉測試也會比較多。這樣就直接導緻最終的結果是業務很難快速地傳遞到客戶手中。

<b>網際網路研發終極大招</b>

業務技術協同線上化的硬碟式研發管理實踐

那麼,對于這些問題應該如何應對呢?其實就需要網際網路研發的終極大招。大家都知道,天下武功是唯快不破的,是以提高效率就是網際網路研發的關鍵。

<b>二、常見的研發提效政策及其問題</b>

既然知道了網際網路研發的終極大招是唯快不破,那又應該如何去提高研發的效率呢?

對于這個問題,有一些公司首先會想到的就是使用一些通訊工具進行即時溝通,比如使用電話或者會議等方式推動一些事務的進展。然而如果站在開發同學的角度來看,因為他們的日常工作産出的最終結果是代碼,而程式設計這項工作需要在大段整段的時間内進行才能夠保證有較高的效率。如下圖所示,前面淺綠色的時間段指的是進入狀态的時間,因為開發同學往往需要這樣的一段時間進行狀态的轉換,中間這段深綠色的時間段就是進入狀态的時間,這段時間就是比較高效的程式設計的黃金時間,在一天當中大概會有四五個小時,而後面的這段灰色的時間段指的就是在後面會慢慢變得疲憊,狀态也開始松懈下來。是以真正有效的就是中間的這段黃金時間,在這個時間段内是研發同學最不希望被打擾的,因為一旦被打擾了那麼效率就會降低。據說在facebook不少程式員在編碼的時候就喜歡在桌子面前放一張牌,上面寫着“don't disturb i'm coding”,也就是“請勿打擾,我在程式設計”的意思。

業務技術協同線上化的硬碟式研發管理實踐

而且使用溝通的方式推動事務進展也會存在一些問題,一般而言,溝通的方式主要分為三種:同步型,比如電話或者會議;異步型,像微信、釘釘這些通訊工具;郵件,其實郵件也可以看做是異步通信的方式,但是一般用于釋出通知。

同步的溝通工具存在一個比較大的問題就是具有破壞性,就像上面提到的當開發同學正在高效地程式設計的時候,這時候突然有一個電話打進來或者有個會議需要參加,那麼效率就必然會降低。同時這樣的溝通方式也有一定的延遲性,比如在開會時需要協調的人越多,時間的延遲就會越嚴重,因為需要約定一個大家都有時間的時刻才能開會,舉個例子今天下午需要決定的事情,突然有個關鍵人物沒有時間了,就隻能将會議推遲到明天或者更後面,是以對于開會而言,人員越多時間效率就會越低,延遲性也就會越高。與此同時,還需要進行調頻,這就如同之前大家使用收音機在找到自己想要收聽的節目之前需要進行調台一樣,在開會這種方式中,當将相關的人聚集在一起之後,還需要将大家的注意力集中在目前的這個事件上,也就是需要将大家的注意力從他們原來做的事情上拉到現在要做的事情上去。而這對于參與者而言往往是被動接受的,是以參與度也會比較低,在這樣的情況下往往無法取得預期的結果。

這樣的溝通方式不僅僅是效率比較低的問題,同時還有兩個更深層次的問題。第一個問題就是如果一個公司沒有統一的任務處理機制,不同團隊就可能采用不同的任務處理方式,那麼可能某些團隊就會使用郵件作為溝通方式,而有的就可能采用開會的方式,甚至有些協作是靠刷臉進行的,誰和我更熟悉就先解決誰的問題,這樣的效率就會比較低。其實這樣的方式很容易讓大家聯想到鄉村小路,有的是這樣走的,有的是那樣走的,鄉村小路的特點就是不平、不直、不通并且不一緻。大家都知道“要想富,先修路”,隻有統一并且寬敞的資訊高速公路才能加快研發任務的處理速度。

業務技術協同線上化的硬碟式研發管理實踐

第二個問題就是内容沒有沉澱下來,如果後面的人想要檢視前面的人沉澱下來的經驗的話,就需要到處去找、到處去問。代平談到自己所在的團隊之前也是這樣的,最早需要做一些項目的統計以及彙報工作的時候,就需要專門找一個人,花費一個星期或者兩個星期的時間去向各個項目管理者搜集各個項目的情況去做彙總的展示。可以試想一下,這種方式下,在研發中的無論是過程資料還是結果資料都會是散落的,而對于公司而言,這些資料就如同寶石一樣是非常寶貴的東西,但是卻是散落在各處的。那麼如果整個研發過程的資料就如同在一個硬碟上一樣全部存儲下來,那麼對于公司而言将會是多麼巨大的一筆财富,後續即使以前的同學離職了,新的同學也可以通過這些沉澱下來的資料參考查證以前同學留下來的路徑以及路徑上記錄了什麼東西。舉個例子,大家都知道的每年天貓的雙11,在前幾年剛開始做的時候它的沉澱是很少的,是以成本也會比較高,準備雙11都需要提前很長時間,而且這個周期會非常長,而現在準備的時間周期就會變得越來越短了,這正是因為有了前面的經驗積累。比如之前就看到去年雙11的成交額預測項目組的同學在自己的項目文檔中就寫道他們在采取分時成交預測方案的時候就參考了之前承擔這項任務的同學的方案,然後對于原來的算法進行調優。那麼可以設想在2017年,對于負責雙11的同學而言,之前幾年的算法或許都可以作為參考,這樣就可以站在前人的肩膀上繼續前進。

是以不僅僅需要将原本不平、不直、不通并且不一緻的溝通路徑用資訊高速公路取代,并且需要将公司的一些項目的資料資産包括過程、文檔、結果以及代碼統一用于建造公司的類似于資料資産金字塔的硬碟中,将這些資料全部儲存下來,這就是雲效平台硬碟式研發管理的主體思路,也就是從各種路徑獨立轉變到建立一條整體相通的資訊大道,并将資料進行彙總進而做統一的展示、記錄和存儲的構想。

其實作在也有不少公司也意識到了這一點并開始建立自己公司的研發資訊高速公路,他們的做法往往是通過引入一些平台産品來建設自己的資訊高速公路,并且通過這樣方式沉澱出自己公司的硬碟式金字塔将資料存儲下來。這樣的趨勢如下圖所示,通過這些資料不難發現,之前的一部分比例有自建的,也就是使用一些開源工具做內建;也有一些公司使用各自獨立的環節獨立分割的工具平台實作的,為什麼這樣做呢,其實在很早之前大家記錄bug往往會使用qc,而這個工具在網際網路的“原始年代”還是比較好用的;還有的就是傾向于使用單個廠商的工具平台,也有一些國外的公司能夠提供一些比較全面的産品工具平台。在剛開始時,大家很少采取這種單個廠商的全工具平台,因為之前這樣的最佳實踐也比較少,是以技術也不是很成熟,而慢慢發現随着技術的發展,現在大家開始傾向于選擇單個廠商的具有最佳實踐的全工具平台,同時如果這樣的平台能夠具有松耦合性,能夠使用多種複合開源或者第三方工具進行良好的內建将是最好的。

業務技術協同線上化的硬碟式研發管理實踐

<b>三、雲效支撐的研發管理實踐</b>

接下來分享一下雲效是如何支撐研發管理實踐的。如下圖所示的是雲效平台整體的架構圖,這就是雲效的研發資訊高速公路,它可以讓研發同學以及包括産品、測試和運維等其他的相關同學将自己的日常工作放在這個平台上。需求、做項目、設計技術方案、編碼、代碼的審閱、測試、釋出以及所有工作項的評論等全部記錄在雲效平台上。

業務技術協同線上化的硬碟式研發管理實踐

因為雲效平台的核心原則就是平台化、流程化和自動化,也就是說希望制定一套标準化的流程,例如持續部署流程、代碼流程、代碼管理流程等,之後将這些流程通過自動化的方式以及自動化的工具實作出來,這就是雲效平台的基本原則。有了這些原則之後就在平台之上建立了配置管理、持續內建、持續傳遞、環境自動化、分層自動化以及內建自動化這些相關的子系統。有了這些子系統之後就建立了一個可靠可重複的傳遞流水線,這應該如何了解呢?也就是比如說在送出與編譯階段的并行研發、編譯建構和單元測試,在測試與驗證階段的環境部署、系統測試和內建測試,以及在釋出與運維階段的生産傳遞、釋出復原和生産監控都是可以通過雲效平台的相關産品進行效率提升的。在可靠可重複的傳遞流水線建設完成之後,雲效團隊又将之前所做的研發綜合效能管理方面的東西,包括業務模型分層、業務規劃、研發資源管理以及roi複盤等,全部在雲效平台上進行呈現。而将包括需求跟蹤矩陣、疊代計劃、任務分解流轉以及度量與改進在内的這些建構成了協同工作流,每一個人都可以在平台上評論所有的工作項并提出方案或者進行頂踩,這樣就保證了開發的品質、效率以及評論和文檔等所有相關的資料都存儲在平台之上。項目次元的互動和多角色之間的溝通協作全部都是在雲效平台上進行的,參與項目的人員使用相同的系統進行互相協作,這樣對組織效率和業務也能夠起到很好的促進作用。除此之外,雲效平台還支援私有雲部署,而且對于docker等開發架構以及最簡單的j2ee工程項目等也能夠提供良好的支援。

以上就是對于一整套的資訊高速公路的展現。接下來帶領大家大概看一下雲效平台硬碟式研發管理的總體流程,下圖展示的是偏重研發的過程。下圖所示的就是研發流程的示意,從上層的業務方進行業務規劃開始,之後需要進行組織人員的安排,再到立項之後的需求确立。對于需求的确立而言,需要通過需求跟蹤矩陣将需求橫向化、标準化。需求是可以分解和拆解的,也是可以配置的,需求的變更記錄、評審記錄包括對于需求的評論、頂踩全部會在這個平台上記錄下來,在平台之上還可以實作責任人以及狀态的流轉和變更來記錄需求到了什麼樣狀态,這樣就能夠提升需求的品質,控制需求的範圍,這是從橫向上來看這條線。而從縱向上來看,需求是和後面的整個項目串聯起來的,因為需求确定之後就可以進行疊代拆分、評估工作項的資源以及進行任務分解、測試用例的設計實作以及與bug相關的一些東西都是可以通過需求串接起來的,這樣就保證了需求與後續工作的關系都可以透視出來,這樣有利于對于整體風險的把控。在整個項目過程結束之後,可以将項目的全部代碼釋出到代碼庫中,然後通過雲效平台的指揮部這個産品對于整個項目進行複盤并評估出項目的投入和産出。

業務技術協同線上化的硬碟式研發管理實踐

這裡大家可能會産生一個疑問,看上去整個研發過程的工作都是記錄在這個平台上面的,那麼有沒有一些研發相關工作是沒有記錄在雲效平台之上的呢?這個問題的回答是:沒有!雲效平台提倡硬碟式記錄,如果工作沒有在平台上記錄,那就相當于沒有工作的産出。可以設想一下如果公司的一名員工來到公司之後做了很多年,既沒有留下一行代碼,也沒有留下任何對于技術方案或者需求的變更、評審進行讨論的東西,這樣對于公司而言這名員工又給公司留下了什麼呢?是以,站在公司的角度,希望每一個來公司的員工都能夠積累下一些屬于這個員工自己的在公司所做的工作,并且全部都記錄在公司的平台之上,進而固化成公司的數字資産。

在阿裡巴巴一些比較進階的技術專家可以在雲效平台上做些什麼事情呢?其實可能一些高p的技術專家不會親自去寫代碼了,但是可以在平台上review一些技術方案并給出一些評論和指導,甚至還可以進行代碼的審閱。對于這些高p的技術專家而言,可能他們的一個技術評論就可能幫助開發同學避免很多坑,這樣就能夠節省大量的時間。而對于管理者而言,在這個平台之上,他們所需要做的事情就是促使團隊在這個平台上産出有價值的東西并記錄在這個硬碟上面,進而沉澱出整個公司的數字金字塔。并且管理者m是可以看到自己團隊的所有成員的全部産出的。那麼既然主管可以看到每個人的産出,那麼是不是就可以看到究竟誰的工作做得多或者少呢?

談到這裡就有一個問題了,主管看到員工都在做什麼,是為了抓到偷懶的還是鼓勵幹活多的同學呢?代平談到作為管理者而言,他們的答案是鼓勵幹活比較多的同學,其實在工作中要想偷懶太容易了,而管理者所關注的則是團隊中成員在平台上面寫了多少行代碼,寫出了多少個測試用例,提出了多少個bug以及設計了多少個技術方案,以及對這些技術方案的評論是什麼。

接下來帶領大家一起看一下雲效産品的部分頁面,也就是雲效産品是如何呈現員工的工作情況的。以下圖所展示的是項目概況頁面,這裡包含了項目的整體進度、概要、裡程碑資訊、風險資訊、負責人以及項目成員、相關的子項目、及時滾動顯示的項目動态、通知資訊等。除此之外,項目中各個角色所需要做的工作項等的内容也是通過一些服務呈現的,比如需求頁、任務頁、疊代、測試用例缺陷、以及自動化、單測內建、環境搭建以及整個系統資料的報表還有釋出等,這些内容都會以項目的次元進行展示。

業務技術協同線上化的硬碟式研發管理實踐

一個項目的管理者或者項目成員到雲效平台上就可以看到與項目相關的所有内容。以産品為例,從源頭的需求角度來看平台上的頁面又會記錄什麼呢?如下圖所示的就是需求頁面的展示,在這裡就可以看到整個需求跟蹤矩陣的清單,這裡提供了看闆和數表這兩種模式來顯示項目需求的優先級、是否上線、疊代情況、建立者以及目前的負責人等狀态資訊,點選每個需求條目之後就可以看到這條需求的詳細情況,包括需求的具體内容以及相關聯的需求的狀态以及相關的一些任務的狀态,需求詳細資訊中還包含一些相關的評論,這樣做是為了鼓勵将需求拿出來給大家分析是否合理,項目中的每個成員都可以去評論或者頂踩,也可以提出更好的方案。

業務技術協同線上化的硬碟式研發管理實踐

除此之外,需求的詳細内容頁面還會顯示需求各個版本的修訂記錄、變更記錄、評審記錄以及操作記錄等資訊,對于每一個工作項都有這樣類似硬碟式的記錄,包括這個需求所包含的任務、用例、缺陷、分支等工作項也會在詳細資訊中進行展示。上圖的頁面中最右邊展示的則是需求屬性以及附件,這裡包含了優先級資訊、疊代資訊、所屬的項目、關聯的項目、子產品資訊、版本資訊、進度資訊以及經過技術同學評估之後計算出的大概的工作量,還有就是一些自定義的标簽、發生變更之後需要通知的對象資訊,以及與該需求相關的附件。這就是需求頁面的大緻情況,因為這部分是項目的源頭,是以其包含的資訊量是非常大的,是以需要以硬碟的形式全部存儲下來。總之,雲效平台在橫向上會将需求所有相關的資訊全部記錄下來;對于縱向而言,像任務拆分、用例、缺陷以及開發分支等所有項目相關的内容都可以在這裡記錄下來,以此串聯起整個需求的過程,直到産品釋出上線。

接下來再為大家介紹一下如下圖所示的內建自動化的頁面。下圖的頁面所展示的就是某一個項目的內建自動化的情況。因為雲效平台最擅長的一面就是相關的ui自動化、接口自動化以及單測的情況,這些都是可以全部內建在一個平台上執行的,而且曆史的執行結果将會全部展示在頁面上,內建的通過率情況如何,有多少成功和失敗也都會在頁面上展示出來。測試件在執行的時候綁定的環境情況,項目中各個部分所執行的測試件情況等,這些項目相關的自動化情況也都會頁面上得到展示。這樣大家對于硬碟資料的管理就會有一個直接的概念,項目中所有的資訊都可以在一個統一的平台上呈現出來。

業務技術協同線上化的硬碟式研發管理實踐

<b>四、實踐最佳路徑和效果</b>

那麼,在雲效平台上的最佳實踐路徑和實踐效果是如何的呢?其實對于雲效平台而言,阿裡的實踐也不是一帆風順的,在剛開始起步階段也不是非正常範,從最初的最簡單的bug系統再到項目和任務、再到讨論以及文檔管理,都是一步步實作的,并且在後面将很多的自動化工具和産品也內建到一起。

<b>實踐并非一步到位</b>

之後在實踐的過程中發現了與其他公司一樣的問題,這些工具都是比較零散的,那麼就一邊将這些系統進行內建,一邊進行系統重構,讓這些子系統的資料能夠互通,這樣才得以統一,形成了阿裡巴巴統一的資訊高速公路。隻有這個資訊高速公路建成之後才有可能建構出阿裡研發資産的金字塔,将資料全部像硬碟一樣存儲下來。在實踐的過程中有一個基本的原則就是統一高于好用,這又應該如何了解呢?其實就是在剛開始的時候,各個團隊想要使用的工具往往會是不同的,如果不同團隊溝通方式不同或者使用的工具不同,那麼對于整個公司而言,效率就會比較低下。是以在雲效平台的實踐中堅持的基本原則是統一高于好用,公司是需要一個統一的研發管理平台的,而不是各種好用的工具的簡單堆疊。

業務技術協同線上化的硬碟式研發管理實踐

<b></b>

實踐中遇到的挑戰

其實在雲效平台的實踐過程中也遇到了不少的挑戰。引入一整套的研發管理工具平台,無論對于阿裡巴巴自己還是客戶而言,都會需要轉變工作習慣,需要從線下的各種不同的方式引導到線上并且使用統一的方式,使得從業務同學到研發同學都是按照這一套規範的路徑完成工作。總結下來有這樣三個比較好的措施:

<b>宣導,</b>就是告訴大家我們為什麼要做這件事情,引導大家進行思維的轉變。阿裡巴巴也在這個方面開過不少的會議來讨論為什麼要建構大中台來支撐前台的業務,是以也是需要不停地進行宣傳的。

<b>由易到難,</b>要從簡單的事情出發,從易到難地推動這件事情。這在雲效平台的實踐中也是一樣的,雲效平台也是從最簡單的缺陷的錄入,到項目的錄入,再到任務的拆解,最後到将各種工具引入上來進行統一的,存在一個循序漸進的過程,因為想要建立的是統一的研發管理大中台,是以推動的團隊也是先從技術團隊入手,一直推廣到業務團隊,讓他們也在平台上做需求以及業務規劃。

<b>專人負責,</b>無論是對于阿裡巴巴還是客戶的公司而言,如果有專人負責的話實施往往會比較順利。常見的負責的組織就是pmo組織,也就是項目管理專員,如果有專人去負責、宣導、實施和複盤,并且從系統中拿到一些資料并發現問題或者可預見性的瓶頸,并進行彙報,再通過管理層的資源解決問題,如此就能夠加速硬碟式研發管理實踐的落地。

業務技術協同線上化的硬碟式研發管理實踐

<b>效果</b>

硬碟式研發管理實踐的最終的效果一方面是把員工腦海中的資訊都資料化成為公司的研發資産,員工的工作也都會固化成為資料存儲在公司的平台上面;另一方面統一的研發效能平台就如同資訊高速公路一樣,因為其是透明的,是以可以營造出一種在意工作過程并且在意互相幫助的工作氛圍,團隊成員之間也會鼓勵積極共享代碼并且參與讨論,這樣他們也不會再去争搶地盤。最終會使得研發的效率更高,并且帶來高效的橫向協同。

業務技術協同線上化的硬碟式研發管理實踐

在2015年9月底的時候,阿裡巴巴的ceo逍遙子帶領公司的總裁班子在美國走訪了10餘家百年老店,包括一些品牌翹楚以及創新公司,像google、facebook、蘋果、特斯拉等。在他們回國後進行分享中,不少的總裁提到令他們印象深刻的是這些國外的創新公司的辦公區都是有一些非常自在的休閑設施的,因為這些公司鼓勵員工在一個最舒适的狀态進行工作,比如會在園區中提供一些沙發、小花台、零食吧、咖啡吧等,甚至允許員工在家裡辦公。當然這些是有前提條件的,如果允許員工在家辦公就需要有一套堅實的工程管理基礎,要有一條可以幫助員工高效研發的資訊高速公路,使得所有人的工作都是透明的,這樣才能夠讓員工在這樣舒适的條件下辦公,這也是建構成資訊高速公路之後,未來大家辦公的場景。

繼續閱讀