集體通宵發版怎麼破？阿里敏捷教練開出四道「藥方」

導語

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

 ●  大幅縮短了需求開發時間，從一個月變爲一週；
 ●  從無可用測試環境到具備穩定的測試環境；
 ●  從無自動化測試用例到50%的模塊實現測試自動化；
 ●  從手工部署到自動化部署。

這一切是如何作到的呢？

研發困境

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

能夠看到，產品、前端 、後臺、測試屬於不一樣的職能部門。這是一個很是廣泛的組織形式——職能型組織。

在這樣的組織形式中，一般會存在如下問題：

 ●  工做之間相互依賴，彼此等待；
 ●  職能團隊之間的目標不一致；
 ●  需求變更溝通不及時；
 ●  工做完成標準不一致。

其次，集中批量集成發佈，時間緊、效率低。團隊的迭代週期通常是一個月，需求從準備開發到待測試的週期是4周，測試時間要花掉1天，發佈通常都安排在週五晚上，大約次日天亮才能發完，整個發佈過程徹底靠工程師手工完成。咱們發現測試和發佈的時間相對集中，時間緊，並且是徹底手工操做，出錯的可能性很高。

最後，測試守護薄弱，沒法作到有信心發佈。由於產品須要發佈到公共雲，目前沒有相應的工具能夠幫助公共雲的發佈；而且，產品的構建部署過程均無工具支持，須要手工打包和部署。在測試守護方面，有一些遺留的單元測試，可是這些單元測試根本就沒法運行起來；而集成測試的運行的用例數基本爲零，雖然有同窗努力在加新的用例，但目前這些用例還沒法運行，整個測試守護過程很是薄弱。

這麼多的問題，該從哪裏入手解決呢？下面分享一下咱們的4個迭代措施。

迭代 1 ：可視化研發工做，尋找問題的關鍵點

經過跟團隊的溝通，咱們發現團隊同窗其實已經或多或少地意識到了這些問題，而且他們也作了一些改進的嘗試，可是由於各類緣由沒有繼續下去，致使團隊如今對改變沒有什麼信心。

在這樣的狀況下，須要在儘可能少改變團隊現狀的狀況下，去取得一個比較好的效果。

要解決問題，必須讓你們可以站在全局的視角來分析現狀，從而找到核心問題。所以，咱們經過可視化物理板以及站會，把研發團隊的工做進行了可視化。

1.1 利用可視化物理板與站會，透明團隊工做

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

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

1.2 經過可視化物理板，暴露團隊的測試瓶頸

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

同時咱們發現，在項目初始階段，幾乎全部的需求在同一時期投入到了開發中；大約在中期時，有不少任務慢慢地移到了自測階段，但並無需求能夠移到待測試階段；直到臨近發版前1-2天，大部份需求才一塊兒移到了待測試。整個過程當中，測試同窗除了瞭解當前準備開始的工做以及準備測試用例外，一直在等待測試工做中。以下圖所示。

爲何測試同窗天天都在等待接受新的工做需求，但總沒有需求能夠提測呢？在離發版的前1天，研發才提測。對測試來講，測試時間很緊迫，驗證出來的bug也來不及修，這就會形成上線後仍然須要有一週時間來修復bug。

經過可視化物理板，研發團隊很快明白了測試瓶頸的緣由——咱們是否是能夠儘快讓測試參與工做呢？

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

如何讓測試儘快參與工做呢？咱們發現，需求之因此沒法進行測試，是由於需求的各個子任務與其餘需求之間的子任務相互依賴形成的，多個需求之間耦合在一塊兒，相互等待。其結果就是，全部需求都得一塊兒開發完成才能測試。爲何它們會耦合在一塊兒呢？

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

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

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

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

什麼是有效的需求拆分呢？需求拆分完以後，它必須仍是需求，它必需要：

 ●  足夠小：這樣才能作到可持續交付；
 ●  端到端：這樣才能保證交付有意義的價值；
 ●  獨立性：便於持續集成和靈活安排；
 ●  總體性：拆分完仍能看到總體的結構。

要作到有效的需求拆分，須要：

 ●  澄清目標：需求相關方要共同理解需求的背景，爲何要作需求的緣由；
 ●  梳理需求上下文及用戶的使用場景；
 ●  列出用戶操做及操做步驟。

咱們能夠從一個具體的例子來了解整個拆分的過程。

需求描述：組件商業化

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

若是咱們按照上面描述的方法進行拆分的話，應該：

（1）澄清目標

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

（2）列出上下文及用戶使用場景

（3）列出用戶操做及操做步驟

（4）按用戶端到端的使用拆分爲4個需求：

 ●  組件成功接入到產品，能在產品上展現；
 ●  用戶能經過產品查看已經接入的組件；
 ●  用戶能使用組件功能，能根據使用數據提示已使用金額；
 ●  用戶如已欠費，沒法使用組件功能。

其中，組件成功接入到產品須要依賴組件方技術改造，也是後續幾個需求的依賴，所以這個需求爲其餘需求的依賴，須要最高優先級需求。

在整個拆分的過程，實際上是需求從目標出發，逐層澄清分析的過程，需求拆分並不直接產生價值，產生價值的是需求分析自己，而需求拆分是需求分析的副產品。

當需求拆分完成以後，如何讓需求順暢流動起來，持續開發呢？

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

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

（1）明確需求准入規則

進入開發就緒前，必須進行需求拆分，而且明確驗收標準，不然不能進入開發。每一個需求拆分後的工做量大小不該超過1周，對應需求的每一個任務工做量不該超過1天。

（2）先後職能拉通，任務左右對齊

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

採用新實踐的團隊，需求作到了有效拆分，提早一週完成了全部需求的開發以及測試驗證工做，上線後缺陷比以往顯著減小。而未作改變的團隊，在發佈前一天，仍然有代碼未合併。

合理的需求拆分，使得持續測試成爲可能。如今因爲測試工做變得平常化，基本上迭代開始一週後就有需求進入提測，而這時，卻沒有一個與線上相一致的測試環境。那麼環境就成爲了當前團隊的一個重要瓶頸。

迭代 3 ：構建測試環境，恢復端到端持續測試

要作到持續測試，須要與之相匹配的測試環境。咱們發現測試環境主要存在如下這些問題：

 ●  測試環境中，服務組件之間的依賴多，準備一套環境讓這些組件所有跑通不容易；
 ●  某些外部依賴沒法搭建線下環境；
 ●  整個構建部署全由研發手動操做，缺乏環境監控的有效手段；
 ●  測試環境服務器部在售賣區，與阿里內部不能互通訪問。

問題不少，但解決的方法只有一個，即首先必須修復環境，讓環境可用；其次，須要保證環境持續可用；最後，讓集成測試的流程自動化，讓規則自動化。

3.1 提升優先級，修復環境，讓環境可用

咱們發現，環境的問題並非技術上不可行，而是在研發過程當中，環境修復缺乏足夠的優先級，不能獲得足夠的投入。當環境問題已經影響到持續測試後，咱們在看板中設一個泳道（下圖中的青島VIP），由測試同窗把當前測試環境中的問題在這個泳道展示出來，並做爲最高優先級由研發同窗來修復。而且在站會時，首先去關注環境是否可用。

3.2 創建團隊環境約定，保證環境持續可用

測試環境由測試同窗來守護，作到有效監控、及時反饋、快速恢復（環境壞了要及時知道，知道了要及時將問題拋出來，你們進行修復）。在工具暫時還未支撐時：由開發打完包後，測試同窗到固定的地方去取包進行部署，並作基礎環境是否可用驗證。考慮到驗證的時間成本，先添加了一個端到端的用例來進行驗證。待一個跑通而且持續穩定的前提下，再增長下一個用例。

部署後測試環境有問題的，測試須要判斷是屬於新提交代碼提交致使的仍是自己環境的問題，作到準肯定位，新提交代碼致使的，由代碼合入人修復，自己環境問題指定對應人員修復。

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

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

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

3.4 研發流程規則工具化

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

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

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

當有了可用的測試環境以後，整個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個迭代只是改進的開始，將來，仍然有許多的問題須要團隊持續改進。可是，只要路走對了，就不怕遠。

本文做者：蔡春華

閱讀原文
)

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。