忙不完的事情，解不完的bug，每次發版都得集體熬個大通宵。幹得多，結果還不好。阿裡内部某研發團隊就正處在這樣的漩渦之中。
在這樣的背景下，阿裡雲效靈活教練團隊受邀，和該研發團隊一起，通過4個疊代的持續改進，研發效率和品質取得了顯著提升：
-
·
大幅縮短了需求開發時間，從一個月變為一周；
- 從無可用測試環境到具有穩定的測試環境
- 從無自動化測試用例到50%的子產品實作測試自動化
- 從手工部署到自動化部署
這一切是如何做到的呢？阿裡雲效靈活教練蔡春華将在本文為你一一道來。
閱讀本文大概需要10min,建議收藏細讀。
研發困境首先我們了解了該團隊的組織結構以及各人員的工作内容。如下圖所示。
可以看到，産品、前端 、背景、測試屬于不同的職能部門。這是一個非常普遍的組織形式——職能型組織。
在這樣的組織形式中，通常會存在以下問題：
- 工作之間互相依賴，彼此等待；
- 職能團隊之間的目标不一緻；
- 需求變動溝通不及時；
- 工作完成标準不一緻。
其次，
集中批量內建釋出，時間緊、效率低。團隊的疊代周期一般是一個月，需求從準備開發到待測試的周期是4周，測試時間要花掉1天，釋出一般都安排在周五晚上，大約第二天天亮才能發完，整個釋出過程完全靠工程師手工完成。我們發現測試和釋出的時間相對集中，時間緊，而且是完全手工操作，出錯的可能性很高。
最後，
測試守護薄弱，無法做到有信心釋出。因為産品需要釋出到公共雲，目前集團沒有相應的工具可以幫助公共雲的釋出；并且，産品的建構部署過程均無工具支援，需要手工打包和部署。在測試守護方面，有一些遺留的單元測試，但是這些單元測試根本就無法運作起來；而內建測試的運作的用例數基本為零，雖然有同學努力在加新的用例，但目前這些用例還無法運作，整個測試守護過程非常薄弱。
這麼多的問題，該從哪裡入手解決呢？下面分享一下我們的4個疊代措施。
疊代 1 ：可視化研發工作，尋找問題的關鍵點通過跟團隊的溝通，我們發現團隊同學其實已經或多或少地意識到了這些問題，并且他們也做了一些改進的嘗試，但是因為各種原因沒有繼續下去，導緻團隊現在對改變沒有什麼信心。
在這樣的情況下，需要在盡量少改變團隊現狀的情況下，去取得一個比較好的效果。
要解決問題，必須讓大家能夠站在全局的視角來分析現狀，進而找到核心問題。是以，我們通過可視化實體闆以及站會，把研發團隊的工作進行了可視化。
1.1 利用可視化實體闆與站會，透明團隊工作初期的可視化闆，主要是展現出團隊目前疊代要做的工作以及每天出現的問題。過程中對實體闆的規則并未做太多限制，主要起到可視化的作用。這樣一方面降低了可視化工作的門檻，讓大家願意使用，另一方面，能把大家最真實的工作狀況給反映出來，如下圖所示：
實體闆展示的同時，配置了每日固定站會，時間控制15分鐘，要求産品、前端、後端開發、測試一起參與。每人輪流對所有人透明每天完成的工作、接下來要完成的工作、遇到的問題。
1.2 通過可視化實體闆，暴露團隊的測試瓶頸實體闆與每日站會，很清晰地展現了目前疊代需要完成的工作，團隊在需要完成的目标基本上達成一緻。并且在每日站會的過程中，因為每日不斷需要溝通的需求，團隊能及時調整并更明确研發流程規劃。
同時我們發現，在項目初始階段，幾乎所有的需求在同一時期投入到了開發中；大約在中期時，有很多任務慢慢地移到了自測階段，但并沒有需求可以移到待測試階段；直到臨近發版前1-2天，大部份需求才一起移到了待測試。整個過程中，測試同學除了了解目前準備開始的工作以及準備測試用例外，一直在等待測試工作中。如下圖所示。
為什麼測試同學每天都在等待接受新的工作需求，但總沒有需求可以提測呢？在離發版的前1天，研發才提測。對測試來說，測試時間很緊迫，驗證出來的bug也來不及修，這就會造成上線後仍然需要有一周時間來修複bug。
通過可視化實體闆，研發
團隊很快明白了測試瓶頸的原因——我們是不是可以盡快讓測試參與工作呢？ 疊代 2 ：合理拆分需求，讓需求變小、獨立、可測試如何讓測試盡快參與工作呢？我們發現，需求之是以無法進行測試，是因為需求的各個子任務與其他需求之間的子任務互相依賴造成的，多個需求之間耦合在一起，互相等待。其結果就是，所有需求都得一起開發完成才能測試。為什麼它們會耦合在一起呢？
我們發現，目前的需求拆分方式是以元件或子產品來進行拆分的。例如，一個需求，首先從實作的角度，把它按子產品拆分成多個需求，對子產品的實作，再對該子產品需求拆分成若幹個任務。
但是，從測試的角度來看，需求應該是端到端可測的，這樣拆分出來的子產品需求不能獨立測試，它僅局限在這個子產品的範圍。
那麼如何有效地來拆分需求呢？
2.1 從業務目标出發，由外而内逐漸拆分需求什麼是有效的需求拆分呢？需求拆分完之後，它必須還是需求，它必須要：
- 足夠小：這樣才能做到可持續傳遞；
- 端到端：這樣才能保證傳遞有意義的價值；
- 獨立性：便于持續內建和靈活安排；
- 整體性：拆分完仍能看到整體的結構。
要做到有效的需求拆分，需要：
1.澄清目标：需求相關方要共同了解需求的背景，為什麼要做需求的原因；
2.梳理需求上下文及使用者的使用場景；
3.列出使用者操作及操作步驟。
我們可以從一個具體的例子來了解整個拆分的過程。
需求描述：元件商業化
需求背景：某元件需要接入到E産品,以按量計費的形式提供服務，并通過阿裡雲統一按流量收費；元件接入到E産品後，使用者通過通路産品頁面開通/暫停/使用元件
如果我們按照上面描述的方法進行拆分的話，應該：
（1）澄清目标元件要從免費的形式轉變為按量計費的形式。元件要用統一的接入方式；使用者在産品頁面上可以看到已經接入的元件，在頁面上開通/暫停元件，産生的費用，通過阿裡雲來進行計費并回報給使用者。當使用者欠費時，該元件直接暫停使用，提示使用者進行繳費。
（2）列出上下文及使用者使用場景 系統上下文
使用者使用場景（用例）
（3）列出使用者操作及操作步驟 - 元件成功接入到産品，能在産品上展示；
- 使用者能通過産品檢視已經接入的元件；
- 使用者能使用元件功能，能根據使用資料提示已使用金額；
- 使用者如已欠費，無法使用元件功能。
其中，元件成功接入到産品需要依賴元件方技術改造，也是後續幾個需求的依賴，是以這個需求為其他需求的依賴，需要最高優先級需求。
在整個拆分的過程，其實是需求從目标出發，逐層澄清分析的過程，需求拆分并不直接産生價值，産生價值的是需求分析本身，而需求拆分是需求分析的副産品。
當需求拆分完成之後，如何讓需求順暢流動起來，持續開發呢？
2.2 完善看闆規則，前後職能拉通，任務左右對齊需求除了是傳遞的單元，同樣也是溝通的載體。在整個端到端的傳遞過程中，經過有效拆分的需求，可以更便捷地進行協作，與此同時，看闆的設計也需要做出相應的調整。
（1）明确需求準入規則進入開發就緒前，必須進行需求拆分，并且明确驗收标準，否則不能進入開發。每個需求拆分後的工作量大小不應超過1周，對應需求的每個任務工作量不應超過1天。
（2）前後職能拉通，任務左右對齊通過看闆，呈現需求端到端的傳遞過程，各職能以需求順暢流動為共同目标，從需求層面拉通各職能之間的協作。同樣，在需求的開發階段，分解成不同的任務列，同一需求的各任務被安排在同一泳道（行）上，做到任務在需求層面的對齊。如下圖所示。
采用新實踐的團隊，需求做到了有效拆分，提前一周完成了所有需求的開發以及測試驗證工作，上線後缺陷比以往顯著減少。而未做改變的團隊，在釋出前一天，仍然有代碼未合并。
合理的需求拆分，使得持續測試成為可能。現在由于測試工作變得日常化，基本上疊代開始一周後就有需求進入提測，而這時，卻沒有一個與線上相一緻的測試環境。那麼環境就成為了目前團隊的一個重要瓶頸。
疊代 3 ：建構測試環境，恢複端到端持續測試要做到持續測試，需要與之相比對的測試環境。我們發現測試環境主要存在以下這些問題：
- 測試環境中，服務元件之間的依賴多，準備一套環境讓這些元件全部跑通不容易；
- 某些外部依賴無法搭建線下環境；
- 整個建構部署全由研發手動操作，缺少環境監控的有效手段；
- 測試環境伺服器部在售賣區，與阿裡内部不能互通通路。
問題很多，但解決的方法隻有一個，即首先必須修複環境，讓環境可用；其次，需要保證環境持續可用；最後，讓內建測試的流程自動化，讓規則自動化。
3.1 提高優先級，修複環境，讓環境可用我們發現，環境的問題并不是技術上不可行，而是在研發過程中，環境修複缺少足夠的優先級，不能得到足夠的投入。當環境問題已經影響到持續測試後，我們在看闆中設一個泳道（下圖中的青島VIP），由測試同學把目前測試環境中的問題在這個泳道展現出來，并作為最高優先級由研發同學來修複。并且在站會時，首先去關注環境是否可用。
測試環境由測試同學來守護，做到
有效監控、及時回報、快速恢複（環境壞了要及時知道，知道了要及時将問題抛出來，大家進行修複）。在工具暫時還未支撐時：由開發打完包後，測試同學到固定的地方去取包進行部署，并做基礎環境是否可用驗證。考慮到驗證的時間成本，先添加了一個端到端的用例來進行驗證。待一個跑通并且持續穩定的前提下，再增加下一個用例。
部署後測試環境有問題的，測試需要判斷是屬于新送出代碼送出導緻的還是本身環境的問題，做到
準确定位，新送出代碼導緻的，由代碼合入人修複，本身環境問題指定對應人員修複。
整個環境管理的十六字規則就是：
有效監控、及時回報、準确定位、快速恢複。而這一切得到落地，一是測試的同學負責了環境的守護，二是團隊有足夠的優先級來響應環境的問題。
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個疊代隻是改進的開始，未來，仍然有許多的問題需要團隊持續改進。但是，隻要路走對了，就不怕遠。
作者介紹：蔡春華（花名古茹），阿裡雲效團隊靈活教練，阿裡百年技術講師，曾支援阿裡安全、阿裡中台等多個阿裡事業部靈活轉型。
這是彩蛋的分割線評論區說出你所在團隊在研發協同中遇到的問題，你将得到雲效靈活教練的親自回複～