集體通宵發版怎麼破?阿里敏捷教練開出四道“藥方”

阿里技術_發表於2018-10-17

640?wx_fmt=jpeg

阿里妹導讀:忙不完的事情,解不完的bug,每次發版都得集體熬個大通宵。幹得多,結果還不好。相信絕大部分技術工作者都有過這樣的困擾。今天,阿里雲效敏捷教練蔡春華以團隊敏捷實踐為例,與大家分享如何提升研發效率。


導語

 

某研發團隊處在事多、效果差的漩渦之中。在這樣的背景下,阿里雲效敏捷教練團隊受邀,和該研發團隊一起,通過4個迭代的持續改進,研發效率和質量取得了顯著提升:


  • 大幅縮短了需求開發時間,從一個月變為一週;

  • 從無可用測試環境到具有穩定的測試環境;

  • 從無自動化測試用例到50%的模組實現測試自動化;

  • 從手工部署到自動化部署。

 

這一切是如何做到的呢?

 

研發困境 

 

首先我們瞭解了該團隊的組織結構以及各人員的工作內容。如下圖所示。


640?wx_fmt=png

 

可以看到,產品、前端 、後臺、測試屬於不同的職能部門。這是一個非常普遍的組織形式——職能型組織。

 

在這樣的組織形式中,通常會存在以下問題:

 

  • 工作之間相互依賴,彼此等待;

  • 職能團隊之間的目標不一致;

  • 需求變動溝通不及時;

  • 工作完成標準不一致。

 

其次,集中批量整合釋出,時間緊、效率低。團隊的迭代週期一般是一個月,需求從準備開發到待測試的週期是4周,測試時間要花掉1天,釋出一般都安排在週五晚上,大約第二天天亮才能發完,整個釋出過程完全靠工程師手工完成。我們發現測試和釋出的時間相對集中,時間緊,而且是完全手工操作,出錯的可能性很高。

 

最後,測試守護薄弱,無法做到有信心釋出。因為產品需要釋出到公共雲,目前沒有相應的工具可以幫助公共雲的釋出;並且,產品的構建部署過程均無工具支援,需要手工打包和部署。在測試守護方面,有一些遺留的單元測試,但是這些單元測試根本就無法執行起來;而整合測試的執行的用例數基本為零,雖然有同學努力在加新的用例,但目前這些用例還無法執行,整個測試守護過程非常薄弱。

 

這麼多的問題,該從哪裡入手解決呢?下面分享一下我們的4個迭代措施。

 

迭代 1 :視覺化研發工作,尋找問題的關鍵點

 

通過跟團隊的溝通,我們發現團隊同學其實已經或多或少地意識到了這些問題,並且他們也做了一些改進的嘗試,但是因為各種原因沒有繼續下去,導致團隊現在對改變沒有什麼信心。


在這樣的情況下,需要在儘量少改變團隊現狀的情況下,去取得一個比較好的效果。

 

要解決問題,必須讓大家能夠站在全域性的視角來分析現狀,從而找到核心問題。因此,我們通過視覺化物理板以及站會,把研發團隊的工作進行了視覺化。

 

1.1 利用視覺化物理板與站會,透明團隊工作


初期的視覺化板,主要是展現出團隊當前迭代要做的工作以及每天出現的問題。過程中對物理板的規則並未做太多約束,主要起到視覺化的作用。這樣一方面降低了視覺化工作的門檻,讓大家願意使用,另一方面,能把大家最真實的工作狀況給反映出來,如下圖所示:

 

640?wx_fmt=png

 

物理板展示的同時,配置了每日固定站會,時間控制15分鐘,要求產品、前端、後端開發、測試一起參與。每人輪流對所有人透明每天完成的工作、接下來要完成的工作、遇到的問題。

 

1.2 通過視覺化物理板,暴露團隊的測試瓶頸


物理板與每日站會,很清晰地展現了當前迭代需要完成的工作,團隊在需要完成的目標基本上達成一致。並且在每日站會的過程中,因為每日不斷需要溝通的需求,團隊能及時調整並更明確研發流程規劃。

 

同時我們發現,在專案初始階段,幾乎所有的需求在同一時期投入到了開發中;大約在中期時,有很多工慢慢地移到了自測階段,但並沒有需求可以移到待測試階段;直到臨近發版前1-2天,大部份需求才一起移到了待測試。整個過程中,測試同學除了瞭解當前準備開始的工作以及準備測試用例外,一直在等待測試工作中。如下圖所示。

 

640?wx_fmt=png

 

為什麼測試同學每天都在等待接受新的工作需求,但總沒有需求可以提測呢?在離發版的前1天,研發才提測。對測試來說,測試時間很緊迫,驗證出來的bug也來不及修,這就會造成上線後仍然需要有一週時間來修復bug。

 

通過視覺化物理板,研發團隊很快明白了測試瓶頸的原因——我們是不是可以儘快讓測試參與工作呢?

 

迭代 2 :合理拆分需求,讓需求變小、獨立、可測試

 

如何讓測試儘快參與工作呢?我們發現,需求之所以無法進行測試,是因為需求的各個子任務與其他需求之間的子任務相互依賴造成的,多個需求之間耦合在一起,相互等待。其結果就是,所有需求都得一起開發完成才能測試。為什麼它們會耦合在一起呢?

 

我們發現,當前的需求拆分方式是以元件或模組來進行拆分的。例如,一個需求,首先從實現的角度,把它按模組拆分成多個需求,對模組的實現,再對該模組需求拆分成若干個任務。

 

但是,從測試的角度來看,需求應該是端到端可測的,這樣拆分出來的模組需求不能獨立測試,它僅侷限在這個模組的範圍。

 

那麼如何有效地來拆分需求呢?

 

2.1 從業務目標出發,由外而內逐步拆分需求


什麼是有效的需求拆分呢?需求拆分完之後,它必須還是需求,它必須要:

 

  • 足夠小:這樣才能做到可持續交付;

  • 端到端:這樣才能保證交付有意義的價值;

  • 獨立性:便於持續整合和靈活安排;

  • 整體性:拆分完仍能看到整體的結構。

 

要做到有效的需求拆分,需要:

 

  1. 澄清目標:需求相關方要共同理解需求的背景,為什麼要做需求的原因;

  2. 梳理需求上下文及使用者的使用場景;

  3. 列出使用者操作及操作步驟。

 

我們可以從一個具體的例子來了解整個拆分的過程。

 

需求描述:元件商業化

需求背景:某元件需要接入到E產品,以按量計費的形式提供服務,並通過阿里雲統一按流量收費;元件接入到E產品後,使用者通過訪問產品頁面開通/暫停/使用元件

 

如果我們按照上面描述的方法進行拆分的話,應該:

 

(1)澄清目標

 

元件要從免費的形式轉變為按量計費的形式。元件要用統一的接入方式;使用者在產品頁面上可以看到已經接入的元件,在頁面上開通/暫停元件,產生的費用,通過阿里雲來進行計費並反饋給使用者。當使用者欠費時,該元件直接暫停使用,提示使用者進行繳費。

 

(2)列出上下文及使用者使用場景

 

640?wx_fmt=png

系統上下文

 

640?wx_fmt=png

使用者使用場景(用例)

 

(3)列出使用者操作及操作步驟

 

640?wx_fmt=png

(4)按使用者端到端的使用拆分為4個需求:

 

  • 元件成功接入到產品,能在產品上展示;

  • 使用者能通過產品檢視已經接入的元件;

  • 使用者能使用元件功能,能根據使用資料提示已使用金額;

  • 使用者如已欠費,無法使用元件功能。

 

其中,元件成功接入到產品需要依賴元件方技術改造,也是後續幾個需求的依賴,因此這個需求為其他需求的依賴,需要最高優先順序需求。

 

在整個拆分的過程,其實是需求從目標出發,逐層澄清分析的過程,需求拆分並不直接產生價值,產生價值的是需求分析本身,而需求拆分是需求分析的副產品。

 

當需求拆分完成之後,如何讓需求順暢流動起來,持續開發呢?


2.2 完善看板規則,前後職能拉通,任務左右對齊

 

需求除了是交付的單元,同樣也是溝通的載體。在整個端到端的交付過程中,經過有效拆分的需求,可以更便捷地進行協作,與此同時,看板的設計也需要做出相應的調整。


(1)明確需求准入規則


進入開發就緒前,必須進行需求拆分,並且明確驗收標準,否則不能進入開發。每個需求拆分後的工作量大小不應超過1周,對應需求的每個任務工作量不應超過1天。

 

(2)前後職能拉通,任務左右對齊


通過看板,呈現需求端到端的交付過程,各職能以需求順暢流動為共同目標,從需求層面拉通各職能之間的協作。同樣,在需求的開發階段,分解成不同的任務列,同一需求的各任務被安排在同一泳道(行)上,做到任務在需求層面的對齊。如下圖所示。

 

640?wx_fmt=png


採用新實踐的團隊,需求做到了有效拆分,提前一週完成了所有需求的開發以及測試驗證工作,上線後缺陷比以往顯著減少。而未做改變的團隊,在釋出前一天,仍然有程式碼未合併。

 

合理的需求拆分,使得持續測試成為可能。現在由於測試工作變得日常化,基本上迭代開始一週後就有需求進入提測,而這時,卻沒有一個與線上相一致的測試環境。那麼環境就成為了當前團隊的一個重要瓶頸。

 

迭代 3 :構建測試環境,恢復端到端持續測試


要做到持續測試,需要與之相匹配的測試環境。我們發現測試環境主要存在以下這些問題:

 

  • 測試環境中,服務元件之間的依賴多,準備一套環境讓這些元件全部跑通不容易;

  • 某些外部依賴無法搭建線下環境;

  • 整個構建部署全由研發手動操作,缺少環境監控的有效手段;

  • 測試環境伺服器部在售賣區,與阿里內部不能互通訪問。

 

問題很多,但解決的方法只有一個,即首先必須修復環境,讓環境可用;其次,需要保證環境持續可用;最後,讓整合測試的流程自動化,讓規則自動化。


3.1 提高優先順序,修復環境,讓環境可用


我們發現,環境的問題並不是技術上不可行,而是在研發過程中,環境修復缺少足夠的優先順序,不能得到足夠的投入。當環境問題已經影響到持續測試後,我們在看板中設一個泳道(下圖中的青島VIP),由測試同學把當前測試環境中的問題在這個泳道展現出來,並作為最高優先順序由研發同學來修復。並且在站會時,首先去關注環境是否可用。


640?wx_fmt=png

 

3.2 建立團隊環境約定,保證環境持續可用


測試環境由測試同學來守護,做到有效監控、及時反饋、快速恢復(環境壞了要及時知道,知道了要及時將問題丟擲來,大家進行修復)。在工具暫時還未支撐時:由開發打完包後,測試同學到固定的地方去取包進行部署,並做基礎環境是否可用驗證。考慮到驗證的時間成本,先新增了一個端到端的用例來進行驗證。待一個跑通並且持續穩定的前提下,再增加下一個用例。

 

部署後測試環境有問題的,測試需要判斷是屬於新提交程式碼提交導致的還是本身環境的問題,做到準確定位,新提交程式碼導致的,由程式碼合入人修復,本身環境問題指定對應人員修復。

 

整個環境管理的十六字規則就是:有效監控、及時反饋、準確定位、快速恢復。而這一切得到落地,一是測試的同學負責了環境的守護,二是團隊有足夠的優先順序來響應環境的問題。

 

3.3 有效利用雲效自定義流水線,實現構建部署測試全自動化

 

為了讓環境持續可用,整個流程可以不再依靠人力的管控,團隊決定接入阿里一站式研發平臺——雲效來打通整個釋出過程。因此,研發團隊與雲效團隊一起,打通了從雲效到售賣區的整個部署流程,形成一個從程式碼提交、構建、部署、測試和釋出的完整流水線,該方案對後續上雲的團隊也可以借鑑。有了這樣的測試環境和流水線,我們從新增一個完整端到端的測試用例開始,逐步完善測試自動化。


3.4 研發流程規則工具化


經過前面幾個迭代的改進,團隊嚐到了改進帶來的好處,PD、測試及TL都要求其他研發團隊也按照該研發模式進行協作。另外,如果其他團隊仍然按照以前的模式進行工作的話,測試環境的穩定性也會難於維繫,因此,整個大團隊統一切換到新的研發模式中。

 

大團隊的匯入,我們發現需要對原來的規則和模式做一些調整,才能適應大團隊的運作,因此,我們將團隊的研發過程規則進行了細化,補充和明確了完成標準和提測標準等。如下圖所示。


640?wx_fmt=png

 

 研發流程並非一成不變,應該是一個不斷演進調整的過程。規則調整由團隊共同商議決定,尤其對於就緒、待測試、待發布幾個關鍵狀態的規則定義顯得尤為重要,這是因為就緒規則是要控住入口,明確需求是否合理拆分;待測試規則是為了確定提測前是否做過自測,以保證不要一上去就把測試環境給弄趴下了;待發布是要保證釋出質量。

 

當有了可用的測試環境之後,整個CI/CD的流水線打通,並且能夠跑通30+自動化用例,該迭代準時釋出,開發到測試的時間也縮短為1周。

 

似乎所有的問題得到了解決,但是,這個時候我們發現每一次部署都會block測試環境120分鐘以上,如此長時間的block是什麼原因導致的呢?有沒有有效的方法可以解決?

 

迭代 4 :環境穩定並持續可用


測試環境被block120min以上,影響了每一次的驗證工作。針對所有block的問題進行分析,發現問題有以下幾類:

 

  • 新提交程式碼產生的問題

  • 歷史bug導致的

  • 測試環境本身未搭建好

  • 暫時無法判斷原因的

 

分析原因主要是背後的理念,是先開始重要呢?還是先完成重要?我們從兩方面進行了改進:

 

4.1 明確優先順序以及需求owner意識


目標是更早的交付價值。每個需求提交應該更早的去驗證、整合,再去做下一個需求。

 

4.2 bug的修復流程


★ 快速排查問題:

 

  • 測試環境問題,測試同學先做基本的排查;

  • 在雲效釋出工具上更多的展示釋出單的反饋狀態與資訊,幫助排查;

 

★ 缺陷消滅:

 

  • 新Feature引入的bug,研發同學預設高優先順序解決,以加速單個需求的快速流轉;

  • 整理一份當前測試環境功能點的Feature列表及其對應的Owner;

  • 遺留歷史bug,版本owner組織review一遍,判斷影響,影響度不大,修復成本高的,產品進行排期;

 

★ 提前預防:

 

  • 提測前自動觸發輕量級版本的自動化測試;

  • 程式碼強制codereview,程式碼合到測試分支的前提是自動化測試用例通過。

 

第四個迭代結束,測試環境已經明顯不再有block的現象;團隊研發流程也比較順暢,迭代中也解決了異地站會同步問題。並且自動化測試用例已經覆蓋主要核心業務。經團隊評估,團隊有能力在白天釋出,釋出熬夜已經不是團隊的困擾了。

 

總結


通過4個迭代,研發團隊達到了很多0到1的效果。從不被看好到大家都更有信心成為更高效的研發團隊,最主要的原因是:大家能在同一高度來看到團隊共同的問題,每次選擇一個當前最迫切最重要的問題來改進,不貪多。

 

4個迭代後,通過資料我們來看整體的改進效果:

 

1.自動化測試釋放人力的變化

 

以前每輪迴歸測試,需要7個開發*4小時的手動測試,通過自動化用例的新增,在迴歸測試人力上已經釋放了2個研發人力。

 

2.研發週期時長明顯縮短

 

從團隊開始開發到提測從原來的4周縮短到了1周;測試的時間更充分了;限制了提測最後時間點,需求的釋出時間也更充分,再沒有通宵釋出的情形。

 

3.軟體質量也得到提升

 

從圖中所示,由於需求的拆分、環境的穩定、讓每個需求可以提前測試創造了有利的條件,測試時間更充分,缺陷在測試期間暴露得更多,因此遺留到線上的缺陷也就降低。

 

研發流程並非一成不變,應該是一個不斷演進調整的過程。規則調整由團隊共同商議決定,尤其對於就緒、待測試、待發布幾個關鍵狀態的規則定義顯得尤為重要,這是因為就緒規則是要控住入口,明確需求是否合理拆分;待測試規則是為了確定提測前是否做過自測,以保證不要一上去就把測試環境給弄趴下了;待發布是要保證釋出質量。

 

最後


4個迭代只是改進的開始,未來,仍然有許多的問題需要團隊持續改進。但是,只要路走對了,就不怕遠。

 

作者介紹:蔡春華(花名古茹),阿里雲效團隊敏捷教練,阿里百年技術講師,曾支援阿里安全、阿里中臺等多個阿里事業部敏捷轉型。


640?wx_fmt=png

阿里巴巴數學大賽賽題、官方參考答案現已公佈。

長按識別以下二維碼,關注“阿里巴巴機器智慧”公眾號,回覆“數學大賽”,即可下載。


640?wx_fmt=jpeg

 ↑ 翹首以盼等你關注


640?wx_fmt=gif

你可能還喜歡

點選下方圖片即可閱讀


640?wx_fmt=jpeg

阿里巴巴為什麼選擇Apache Flink?


640?wx_fmt=jpeg

領域驅動設計,盒馬技術團隊這麼做


640?wx_fmt=jpeg

看完這8本演算法好書,才算真正懂了 AI



640?wx_fmt=jpeg

關注「阿里技術」

把握前沿技術脈搏

相關文章