閱讀245 返回首頁    go 阿裏雲 go 技術社區[雲棲]


500強上市公司:研發模式互聯網轉型實踐

摘要:在Work like Alibaba案例實戰係列第二期9月14日的直播中,新光互聯無線團隊負責人陳聯柯為大家分享了如何借助RDC,實現從需求管理,到多團隊協作,到缺陷管理以及自動化部署等全流程的無縫銜接,並借助RDC的敏捷管理工具,讓敏捷協作更為高效。精彩不容錯過!


直播回顧視頻地址:https://yq.aliyun.com/webinar/play/304


本文內容根據演講嘉賓視頻分享以及PPT整理而成。

本次的分享主要分為以下4個部分:
一、新光集團簡介
二、傳統的研發方式
三、RDC是個好工具
四、RDC數據化管理

一、新光集團簡介
新光集團是一家集實業、地產、投資、金融、互聯網、能源和旅遊等多元業務於一體的產融結合的生態投資集團。目前旗下有1家上市公司,40多家全資子公司及控股公司,近百家參股公司,資產規模近千億。新光互聯是新光集團旗下負責互聯網業務相關的子公司。
b2e7e1db2ec060c2d0c0b97cdc5aaae0771c4ac8

二、傳統的研發方式
接下來首先介紹新光集團在接觸RDC之前所使用的傳統研發方式,這裏以新光集團旗下的兔波波業務為例。從下圖中可以看到兔波波的業務主要分為四個部分,其中兔波波的整個業務線主要可以分為三大塊:眾包、門店和車配,而這裏的“數據”指的是在兔波波內部專門針對於其他三個業務所做的數據收集、分析相關的工作。
4b454ec63ff3e580ef52c623e2a7db3609ebd275
兔波波的眾包業務與現在市麵上比較常見的達達、美團以及餓了麼的配送業務非常相似。在兔波波的眾包業務裏麵存在很多角色,包括發單的商家、送單的騎手以及城市服務商、運營人員等的管理方,而且目前這部分也在擴展驛站和閃送的相關業務。以上所提到的這些其實都屬於不同的業務形態,目前僅與眾包相關的業務就已經有5個項目組在跟進。

門店相關業務其實與菜鳥驛站很類似,也就是各個社區中都會有很多的門店,比如水果店或者小百貨商店,這些門店原本都是在社區中獨立運營的店鋪,當這些店鋪加盟到兔波波之後就可以通過收發快遞的方式幫助自己吸引客流,同時自己門店中的貨物也可以通過眾包係統進行配送,並通過車配係統幫助門店進貨。所以對於門店這部分也有很多項目組在跟進,為門店店主提供了手機端的快遞管理助手、PC端的管理係統,為城市服務商提供了運營管理係統,並為顧客提供的可以實現在線寄件的兔波波微信公眾號等服務,而在兔波波微信公眾號中也能夠提供眾包業務中的閃送服務。

第三部分是車配業務,這部分所做的工作是針對城市內部的次幹線進行物流配送。車配業務將和門店業務結合起來賦能門店的物流。車配業務也涉及了很多方麵,需要為不同的角色比如司機、管理人員以及運營人員提供各自所需要使用的手機應用程序等軟件係統。

對於數據業務部分而言,其包括了對於上述兔波波三大業務的數據分析,這部分需要將數據做成報表並及時向老板匯報,從而幫助管理層更好地做出決策。除此之外,還會涉及到對於自己產品的數據分析,比如在應用上線之後,需要采集運行情況的監控數據,並進行相應的版本管理以及應用的灰度發布等。

單是兔波波這樣的一個業務線算下來就已經達到十幾個項目組,總共四五十個項目成員了。而麵對這麼多的業務,之前的做法相對比較傳統,就是“一個蘿卜一個坑”,每個成員負責固定的項目,這樣就相當於同時有十幾個項目組向前走。從研發資源的把控和安排的角度來講,整個研發管理的複雜度就會大大提升。如果業務比較簡單,隻有一兩個項目團隊,那麼使用傳統的方式進行管理是完全沒有問題的,但是目前單是兔波波這一條業務線就有十幾個項目組同時開展工作,那麼對於項目的進度和風險的把控以及資源的分配工作都需要管理人員花費大量的時間來進行信息收集和數據同步。所以在麵對如此之多的問題的時候,項目的研發管理就會變得令人頭疼。

在最早的時候,新光集團在軟件係統上做法與很多的創業公司一樣:在代碼管理方麵使用GitLab,需求管理和Bug管理使用JIRA,團隊內部的文檔共享使用Confluence的Wiki功能。在最開始的時候,新光無線團隊采用的還是手動在本地進行打包的方式,而後麵隨著業務的增多,也逐漸開始使用Jenkins實現簡單的持續集成。
e999efc01c7148e6c2eaf52e3d0eb42b0f95eece
而上述的GitLab、JIRA以及Jenkins都是相對獨立的係統,新光無線團隊從最開始一路走來,對於這一點的體會也非常深刻:雖然這些子係統都能夠把自己分內的事情做的很好,但是這麼多獨立的係統卻是無法整體進行打通的,這也是令人非常苦惱的一件事情。所以,在後來新光無線技術團隊也開始嚐試地去通過整合來解決問題,如下圖所示的是新光無線團隊內部的開發的一套無線研發支撐係統——無線船塢,圖中所展示的是第一個版本。可以看到,無線船塢中提供了:用於實現持續集成的打包中心,這部分是基於Jenkins進行二次開發實現的,能夠使得持續集成更加簡單和高效;集成了JIRA的Bug中心;代碼檢測中心,這部分是目前自動化測試的一個嚐試,期望能夠將整個產品的質量把控前移到開發階段,所以在這部分也實現了對於靜態代碼的檢測;無線知識庫,這部分其實是團隊自己搭建的博客係統;團隊自己開發的用於承載產品文檔的簡單Web服務的產品原型中心;希望通過在線化的方式把多個業務的接口協議統一起來的接口協議;實現了對於線上數據的監控的線上數據中心;基於Confluence開發的團隊係統。
030f1131b792a1f996f4d32342f95b61c401347b
通過團隊的努力,無線船塢中的每個子係統都還不錯,並且因為這些子係統都是基於第三方、開源的比較成熟的工具或者係統實現的,所以很容易在原有的基礎上搭建出比較好用的工具集合。而後來發現雖然無線船塢這個工具集搭建起來了,但還是會遇到前麵出現的問題,也就是無法將這些工具係統化,無法打破各個工具的邊緣將它們整合到一起。打包中心和代碼檢測都是基於Jenkins實現的,可以很容易的整合,但是Bug管理中心與產品原型甚至是接口的文檔卻是很難統一到一起的。雖然無線船塢提供了統一的入口,但還是需要進入到各自的子係統中。除此之外,還有最關鍵的一點就是雖然無線船塢集成了如此之多的工具,但是這些工具還是獨立地在運行,這樣就導致它們所產生的最具價值的數據無法進行整合和分析,所以雖然已經很努力地去實現了,但是無線船塢還遠遠沒有達到最初所預想的將整個研發流程從需求分析到開發、測試、再到上線有機地串接到一起,比如在需求提出之後,判斷到底哪些需求可以排進項目中去,並將開發的完成情況等有機地串接在一起。所以新光無線團隊非常希望有這樣的一個能夠打通研發全流程的工具或者係統,可以實現研發流程的記錄、監控和反饋以及在最後項目完成的時候進行數據分析。

三、RDC是個好工具
後來經過一位阿裏巴巴的同事的推薦,新光無線團隊開始接觸RDC這款工具。RDC可以用於項目研發全流程的管理,它是由阿裏巴巴內部的AOne係統開放出來的。接下來這部分將與大家分享新光無線團隊在使用RDC過程中的一些收獲。

初識RDC
目前阿裏雲的服務已經相對比較成熟了,像新光集團這樣初創型的公司所使用也基本上都是阿裏雲的服務器,除此之外也使用了很多阿裏雲所提供的服務,所以總體而言對阿裏雲並不陌生。但是因為阿裏雲所提供的功能種類非常多,如下圖所示的菜單中就已經大概有上百項的服務了,而RDC服務就在這樣的一個角落裏,如果不是有同事推薦其實是很難知道的。而且目前RDC還處於公測當中,所以阿裏雲也還沒有大規模地向外推廣,所以新光無線團隊當時能夠接觸到RDC還是比較幸運的。
220dbb6739b171f2c20e48f14f5c9e739c73b7e2

磕磕碰碰上手
新光無線團隊在了解RDC之後馬上就開始了試用,而在一開始的試用過程中,可以說是磕磕碰碰地上手的,因為單單RDC自己的功能就已經非常多,非常強大了,並且它又集成在阿裏雲上麵,而阿裏雲本身的產品又非常豐富,所以在剛開始使用RDC的時候非常不習慣。因為當點到產品與服務菜單,阿裏雲所有的服務一下子都跳出來了,但是當時並不了解這些服務與RDC究竟有什麼關係,所以在一開始,新光無線團隊有一種無從下手的感覺。但是在後來使用的過程中,團隊慢慢地開始摸索出了RDC的使用套路,也逐漸地習慣了RDC的使用。
bc5acc0a5248715e64b894485648383f4728257a

RDC是個好工具—綜述
如下圖所示,整個RDC主要包含幾部分內容:第一部分就是最上麵的“我的”、“項目”和“服務”等這幾大類目。下圖中左側是與此時所選中的類目所對應的菜單,“服務”類目中則列舉出來目前企業中所有可以使用的功能。圖中右上角則是一些常用功能的入口,包括設置、添加項目以及添加企業等。圖中中間部分是顯示區域和操作區域。在幾大類目裏麵,“項目”部分是使用頻率最高的,這是因為RDC本身就是研發協同工具,所以如果想要發揮出RDC最大的價值,那麼肯定是需要被大型的研發團隊一起使用的,後麵的分享也會主要圍繞“項目”這部分進行。
632a5a70937a09f69d7477f76583d1e70f9ef60a

RDC是個好工具—我的
“我的”類目部分的菜單包括工作台、應用、代碼、分支、實驗室和設置等。無論是個人開發者還是企業開發團隊,工作台中展示的都是與個人相關的內容,這部分使用的頻率也比較高。當進入“我的”部分之後主要看到的就是工作台中的內容;應用模塊則是一份代碼構建之後的產物;代碼、分支部分主要是對自己的代碼進行管理;代碼模塊主要做的是代碼庫相關的權限管理;分支模塊則是管理個人相關的所有代碼;實驗室是用於做自動化構建和自動化測試相關的內容的;設置則管理的是與個人相關的設置,比如可以設置開啟哪些功能。
113db1236891f3ff5bcc4b320d120dccb81ed5b3
如下左側圖片所示,在“項目”部分,新光無線團隊在RDC上一共有13個項目在運行。而如下右側圖片所示的是針對於某一項目的詳情展示,在項目詳情頁麵的左側有很多的菜單功能可以使用。
058909202acd714fdb62237472096bbf7ac4e076
在“服務”部分,之前也提到了包括了整個企業可以使用的功能和產品,每個功能都可以點進入查看和開通。
1d8b08deb3192dfdbe76d1723c6efad1ab36d54d
前麵比較粗粒度地分享了RDC的組成部分,接下來會從項目的角度出發,按照項目管理、缺陷管理以及研發管理這三個方麵進行介紹。如下圖中所示的綠色框中的任務、需求、迭代、風險以及圖表都是與具體項目管理相關的,缺陷和測試用例是與缺陷管理相關的,分支、實驗室、應用以及流水線都是與研發管理相關的。
a623da9b840a5fccf85eba35ff185ef808da9167

RDC是個好工具—項目管理
首先從項目管理說起,如下圖所示的是新光無線團隊在RDC中的一個項目的需求,這裏就是一個需求池。回想一下,在還沒有使用RDC的時候是如何管理需求的呢?通常情況都是產品經理使用Excel製作一個需求列表,將需求一條一條地列出來,然後產品經理之間需要拿到這些文檔發來發去內部之間進行共享和修改。產品、開發、測試以及運維之間溝通需求的時候一樣需要傳遞這些Word或者Excel文檔,如果中間有改版就還需要再發一次,用最新的覆蓋老的。
bf3580581f7d3ddd6551b1630030d85564a84d77
而這樣的過程的弊端是很明顯的。首先,溝通的效率會非常低,傳播效率也會非常低;其次,經常會因為傳播不到位,導致大家手中的文檔版本不同,導致信息同步不到位。而在使用了RDC之後,就可以將需求係統化,這也是幫助最大的部分。因為無論是需求管理或者是任務管理,市麵上有很多的工具都在做,但是能夠與研發和缺陷管理都緊密地結合在一起的卻基本上找不到除了RDC以外的工具或者係統。上圖中中間部分就是RDC中的需求池,新提出需求可以向裏麵錄入,但是至於需求什麼時候開發都在這裏進行管理,所以RDC的需求管理比線下的管理要更加高效,同時需求的到達也會更加快捷。

如下圖所示的是項目管理中任務頁麵,這裏管理的是基於產品的需求所進行的開發,也就是將需求拆解成相應的任務。比如在還沒有使用RDC的時候,最開始使用的是甘特圖來分解任務和安排時間,也就是如下左側圖片所示的在牆上釘一個軟木板,之後好幾個項目都在上麵,有時候需求任務多的時候,這個軟木板上基本密密麻麻貼滿了便簽紙。
8658595045bc22d34459075a7c04c59f796134d6
同樣的,如果這時候隻有一個項目,很容易地就能夠看到任務的分配以及進展情況,但是一旦項目多了之後,很多的東西都需要往軟木板上貼,這樣就很難看到每一個項目的具體進度情況了。所以任務的管理非常需要一個電子化、在線化的方式,而RDC就能夠提供這樣的功能。首先電子看板能夠明確顯示出每個任務分配給了誰以及每個任務的完成狀態如何,包括任務相應的完成時間等信息都是有詳細記錄的,在電子看板中能夠很容易地體現出來。

如下圖所示的是RDC項目管理模塊的迭代部分,其實迭代這部分就與線下的版本是很相似的。如下圖所示的迭代部分存在著兩個版本,從1.0.1到1.1.0版本。
e7d2a3914250cb9ffa35b089da554fcedd18f9c1
如下圖所示的是RDC項目管理模塊的風險部分。雖然大家都討厭風險,但是在整個項目的研發過程中,風險又必然會出現。如果通過線下方式去管理風險,大家一般要麼會在筆記本上進行記錄,要麼會在桌子或者顯示器前麵提一張便簽紙,而通過這種線下方式去管理風險的問題與之前所提到的需求管理以及後麵將會提到的Bug管理中出現的問題是非常相似的,就是當項目工作量多的時候,風險數量也會增多。所以到底有哪些風險,其中哪些風險已經解決掉了,每個風險的危險度是什麼樣的,這些是很難通過線下的方式把相對比較多的風險管理起來的。而RDC中所提供的風險管理和需求很像,也是以電子化、在線化的方式對風險進行管理,可以可視化地展示出風險的內容、等級、相關責任人以及解決所需要花費的時間等,這樣就能夠幫助團隊很好地控製風險。
1e29430b1caa12769dc134c3786a015fc664b084
對於項目管理而言,在還沒有使用RDC的傳統方式下,需求方提出需求,產品經理整理好需求之後就開始交給開發人員,開發人員將需求分解成為相應的任務,並在開發過程中形成一係列的版本,也就是迭代,按部就班地進行實現,最終部署上線。這樣的整個研發流程基本上都是通過線下的實現的,而且沒有進行完整的串聯。
abfb02ad08e3121fb779782a080792e36e7edb6d
而在使用RDC工具之後,研發流程的本質是沒有變化的,也就是說使用RDC並不會為研發過程帶來革命性的變革,但是從項目管理的層麵上講,RDC為研發提供了一個很好的工具幫助團隊對於研發的全流程實現更細粒度的、更加全麵的監控和跟蹤、記錄以及最後的分析。從需求的產生方,包括運營、用戶以及老板他們的需求提出來之後,經過產品的整理放到RDC的需求池裏麵,之後產品經理以及業務方會對於需求進行優先級評定,排好優先級的需求經過開發的分解形成不同的任務,這些任務就是對於需求的具體實現,這部分也有相應的工時的估算,並且會將任務放入到相應的迭代裏麵去。
4dc91e77e0d2675bc837c04f09fea5d1c3d001e5
在沒有使用RDC之前,一個版本就是一個迭代,在使用了RDC之後就開始嚐試進行雙迭代,也就是同時運行兩個迭代。比如有些產品更新的比較快,可能就會製定兩周一次迭代,但是有時候會出現用戶反饋的緊急需求,這樣就可能把兩周一次的迭代版本打斷掉,插入一個一周的版本,這樣就可能出現兩周的版本和一周的版本同時在運行的情況,這兩個迭代上線的時間肯定是錯開的,但是研發這部分卻可能同時有兩個迭代在運行。有了RDC這個工具,整個過程下來之後是有記錄、可跟蹤的,相對而言整個研發流程就會比較清晰。而風險管理則貫穿了整個研發過程,從需求提出開始到應用上線,都可以通過RDC實現全流程的風險監控。其實風險和需求一樣,一旦產生了就需要馬上暴露出來並指定好處理的責任人。總之,對於項目管理而言,這樣的一套研發流程是非常清晰和高效的。

使用RDC進行項目管理的整體流程總結
1.將需求寫入需求池。
15a4c8c188a431819d687f2189daf247cbbd7336
2.管理需求詳情。這裏的需求詳情比較簡單,其實可以向其中添加圖片以及交互稿地址。之後開發人員隻需要看這個地方就可以了。
c20e7419368e8a55e7a9d705c90ba0c590d64f48
3.將需求拆解成任務,通過任務看板可以檢查每個任務的狀態、分配情況以及完成進度。
5ecbc9a0ff90154c5bbb9b3bd7c6c225e3569f91
4.在任務下麵可以新建子任務。其實,大部分的任務是和需求綁定在一起的,也是根據需求拆分的。在RDC中的任務下麵可以新建子任務或者子需求。
a024e766b625b44be229c632bd9bdd986b730c49
5.進行開發的迭代。
1abdccff0ef545938062f987ed4f7cb013809751
6.管理迭代詳情。如下圖所示,比如對於1.0.1這個迭代而言,目前已經添加了這麼多的任務進來,而在研發過程中很可能會發生需求和任務的變動,比如有一個緊急的需求需要插進來,這樣就可以從圖中右邊將需求添加進來,同時根據時間和人力的情況判斷是否需要添加人員或者增加時間,也可以將優先級比較低的任務先剔除出去,放到下一個迭代中實現,這樣就可以非常方便靈活地實現迭代管理。
246f369aae7b3af8e03aef902631fc64621425ee
7.查看風險列表。對於每個風險,在這裏都可以都指派跟蹤人或者解決者。
ac8069b4fa391558b0cad55b191e2b84dc638ec6
8.管理風險詳情。在這裏可以指派相應的人員,定義風險等級,劃分風險對應的模塊,並且管理處理該風險所需要的時間以及進度情況。
9ce3b80a0f6522eabd3a58061fc8e3e726a69945
9.項目管理的圖表功能。項目管理部分還提供了圖表功能,也就是把之前的需求、任務、缺陷以及風險以圖形化的方式進行展示。
c03f7ee0e39e3cef83eeb042e5b0489dc6689d20
10.添加新圖表。這裏可以設置新添加的圖表樣式、添加的對象以及圖表的指標,讓這些維度的管理可以更加直觀地體現出來。
48a9a966a09000c3812012af5e40a40585b7f573

RDC是個好工具—開發管理
前麵主要分享了使用RDC進行項目方麵的管理,其實目前市場上也有很多的工具正在做項目管理方麵的事情,而RDC的優勢在於它能夠係統化地與開發、缺陷管理以及數據化管理進行打通並結合在一起。接下來就簡單地分享RDC在開發方麵的使用。最早新光互聯在做研發的時候比較簡單,就是直接開發寫代碼,之後交給QA進行測試,再之後上線部署就完成了。但是實際上,研發所需要追求的不僅僅是完成工作和實現功能,其實這是遠遠不夠的,還需要更加關注所做出來的東西的質量如何、產品是否穩定以及產品能否抵抗得住壓力,同時還需要關注整個團隊的研發效率,是否能夠用盡量少的人以及盡量少的時間做盡量多的事情。但是效率和質量往往存在一定的矛盾,那麼如何實現效率和質量的平衡就需要更加深入地思考。
c33c9a1d970638e68db8324159d5f44711e1b068
目前,新光互聯所希望實現的就是首先保證質量。在使用RDC之前,新光互聯團隊也在嚐試地實現這樣的事情,包括之前開發無線船塢係統也是希望最大程度地保證產品的質量。在最開始產品質量是交給測試進行保障的,而現在希望把質量保證的點盡量向前提,能夠在開發階段就可以保證產品的質量,所以會在開發階段就引入自動化的測試,包括單元測試、壓力測試以及兼容性測試等,並且會實現靜態代碼的掃描和監測,所以前一天提交完代碼,第二天就可以知道所提交的代碼質量如何以及有哪裏需要修改,修改完之前的代碼再去寫新的代碼,這樣就可以盡量地保證已經提交上去的代碼的質量。總而言之,就是將整體的質量保障前移,而不會將質量保障的壓力全部積壓在測試階段,導致因為時間不夠而匆忙上線,進而引起線上故障甚至是事故。
0d08e0d1d97b15f327982a3d2fb7d269a29fbb3d
RDC在這方麵的功能非常強大,因為RDC是基於阿裏內部比較成熟的AOne開放出來的,所以借助RDC的整套開發過程也會非常靈活。在開發階段可以配置各種自動化測試,這些自動化測試並不需要人工進行幹預,而且配置也非常靈活。除此之外,開發階段的持續交付也是非常成熟的。另外,在測試階段,除了人工的測試之外,還有很多自動化的測試可以接入進來,甚至最後從測試到上線的持續交付也是自動的。

任何可以做的持續集成和自動化測試都可以通過實驗室和流水線進行有機的結合。所謂的流水線就是將各個功能節點把所需要做的事情按照自己的需求組合在一起,比如希望在代碼提交到Git的時候觸發一個檢測,如果沒有通過代碼規範就將代碼打回來,直到檢測通過才可以繼續下一步。當代碼提交之後還可以配入壓力測試、性能測試或者兼容性測試,也就是說在整個研發過程當中可以通過流水線向研發流程中部署各種點,當流水線流到相應的點的時候就會觸發相應的功能,執行完成之後繼續向下走,這樣就能夠把整個流程自動化地串到一起。而對於初創公司而言,往往沒有能力自己實現像RDC這樣的產品,所以可以借助阿裏雲的RDC實現同樣的功能。
2058878540332591dfd0cddf4df0daf8b83c0a62

RDC是個好工具—缺陷管理
接下來分享缺陷管理,這部分主要包括了兩部分,第一部分主要是測試用例,第二部分是Bug管理。之前的時候,測試用例也是由QA團隊使用Excel編寫維護的,與之前的需求等做法一樣,都是線下的方式,每人一份傳來傳去,出現的問題也與前麵所提到的相同,到達率不夠高,並且更新率也不夠高,拿到一份測試用例所需要花費的時間也比較長,所以想要獲取最新的測試用例所需要的成本也是比較高的。而通過RDC的在線化電子化的管理,測試用例管理和缺陷管理的問題也就迎刃而解的,團隊中每個人都可以很方便地拿到最新的測試用例。如下圖所示的就是測試用例庫,同樣的Bug管理也很相似,這部分與JIRA很像,而且工作項都可以進行配置。
d3b83df17cc4a991f6016d9f51acc4a90f2221a7
如下圖所示的是針對整個項目的設置,這裏包括了對於項目的基本信息、名稱、成員以及權限的管理,項目開通的服務和功能以及裏程碑管理和工作項的配置。
5e58d1ef86a67ad0856c910823f4fb8f4bd01440

四、RDC的數據化管理
上麵分享了新光互聯團隊在使用RDC工具進行項目管理、研發管理以及缺陷管理方麵的經驗以及收獲。接下來簡單地分享RDC的數據化管理。

數據化管理也是RDC區別於市麵上的各種項目管理工具的地方,這裏的數據化管理不是針對於某一個項目的,而是針對整個團隊、公司以及大型企業內部所有項目的多維度、多角度的數據分析。這部分在RDC的功能中叫做度量,而目前RDC開放出來的功能還不是非常全麵,所以度量的範圍和維度還相對比較少,之後開放出更多維度之後就能夠做一些更加全麵、深入和細致的數據分析。其實隻有經過分析和處理的數據才能發揮出自己最大的價值。而在傳統的研發過程中,數據往往會分散到各個子係統中,而子係統之間是沒有打通的,所以研發過程產生的數據就無法發揮出整合之後的價值。而借助RDC的能力將數據整合到一起進行更加全麵的分析,就可以發揮出更大的價值。

數據管理部分包括研發、應用質量以及項目質量這三個方麵。在研發方麵包括需求、缺陷以及發布相關的數據,這裏展示的是整個團隊的粗粒度的宏觀數據。
3767c86d5189639d095ba2a4f0e527f2fc5c7649
下圖展現的是缺陷趨勢變化。這裏能夠將整個團隊的十幾個項目的總體缺陷情況通過數據分析以圖表的形式非常清楚地體現出來。在沒有使用RDC之前,數據的收集是非常麻煩的,需要從十幾個項目中拿到數據再進行整合,之後再去進行分析。當有了RDC之後,通過數據分析預測缺陷趨勢變化就變得輕而易舉了。
410a05a7f76f376b61a7b48107827d430d605f0d
下圖所示的是項目質量數據頁麵,這裏展示了各個項目的總體進度和整體效率,而這些數據在RDC的度量中都能夠很全麵地體現出來。
234160b1577c4757f0fee6d327f85c8c07847d33

趕緊立即體驗研發協同RDC吧!

最後更新:2017-09-18 11:03:27

  上一篇:go  斯諾登評蘋果Face ID:我更擔心隱私安全
  下一篇:go  非IO優化、經典網絡的ECS實例支持升級到企業級實例