一 序言

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

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

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

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

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

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

這一切是如何做到的呢？

二 研發困境 

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

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

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

• 工作之間相互依賴，彼此等待；

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

• 需求變動溝通不及時；

• 工作完成標準不一致。

其次，集中批量整合釋出，時間緊、效率低。團隊的迭代週期一般是一個月，需求從準備開發到待測試的週期是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）列出使用者操作及操作步驟

（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個迭代只是改進的開始，未來，仍然有許多的問題需要團隊持續改進。但是，只要路走對了，就不怕遠。

參考文獻：

https://www.cnblogs.com/byvar/p/7235650.html

https://www.cnblogs.com/derekchen/p/3575428.html

https://download.csdn.net/psearch/0/10/0/2/1/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

 宣告：部分圖片來源於網路，相互借鑑、相互學習、共同提高