前言
隨著網際網路的興起，版本交付越來越頻繁，企業開始了敏捷轉型、DevOps落地，專案組雄心勃勃，期望產品能按迭代快速交付。然而常見的現象是，到了迭代的最後一天，還有不少Bug來不及修復，迭代無法產生潛在可交付成果，延期成了必然。然後發現連續幾個迭代都是這樣，團隊沒有成就感，士氣低落。迭代的無法按期交付，讓團隊及公司領導又覺得敏捷只是形式化，並沒有解決問題，久而久之，就乾脆放棄了所採用的敏捷框架，回到老路子上了。
迭代總是因為修復不完Bug而延期，該如何解決呢？本文從流程上需要改進的地方進行討論，對於開發人員能力弱、迭代內需求量過多等人為因素我們不進行討論。
問題分析
我們主要從下面四個方面來分析產生這個問題的原因。
流程上，在迭代內搞小瀑布開發
很多企業在轉型敏捷後，依舊用著以前大瀑布的工作方式，即設計->開發->測試->修Bug，這就是我們常說的：在迭代內玩小瀑布。小瀑布繼承了傳統模式的一個弊端，就是測試工作放在了整個專案週期的最後一個環節，導致問題集中爆發，同時有的需求Bug也會影響到其他需求，而中間過程沒有去檢測bug，以至於導致其他需求又出現了新的Bug。到了後期，集中測試的時候，就發現Bug的關聯性錯綜複雜，增加了修復的時間。
更要命的是，由於使用的是迭代開發，假如是一週的迭代，到了週四下午轉交給測試人員，期望用兩個小時測試透過，然後稍微修補修補小bug，產品就能上生產了。是不是感覺很熟悉？期望XXX結果XXX。按計劃週四下午轉交給測試，週五上生產，結果卻常常是週四發現了太多的Bug，結果週四晚上團隊加班修Bug，重新測，週五常常無法部署到生產，延期到下週。
需求上，需求澄清時沒有明確的驗收標準
這個問題在剛轉型敏捷的團隊中，出現的更多。敏捷強調的是充分溝通需求，再將討論一致的點都記下來，特別是驗收標準要寫明瞭。但是實際中，大家對敏捷常常有個誤區，就是不需要文件，需求也只要頭口溝通下就行了，結果就是既沒做到充分溝通，又沒有最好記錄，最重要的驗收標準都沒討論清楚。這樣，開發人員開發出來的產品到了測試環節，由於測試人員更偏重業務方向，所以對產品的認識和使用提出了一些看法，覺得某些地方的設計不夠好，提了不少需求式的Bug，等測試完畢，在產品經理驗收的時候，又會出於同樣的原因提出一些Bug。這些Bug對於開發人員來說也很委屈，最開始的需求裡並沒有說明這幾點應該做成什麼樣，現在提的這些Bug相當於額外加的需求，又不得不馬上處理掉。
舉個例子，需求澄清時，產品經理說想要個靈動的鯨魚，和團隊達成了一定的共識，雙方討論了下鯨魚大概應該是下面的樣子。
圖1 需求版：靈動的鯨魚
然而最後開發出來的結果卻是下面這樣。
圖2 交付版：靈動的鯨魚
出現這個結果的原因就是，在需求澄清時，沒有清晰的驗收標準，客戶也不是很清楚自己的需求具象化之後什麼樣，團隊和產品負責人以為達成了一致意見，實際上都是腦子中想象的一致，他們對圖片的理解是不同的。真正驗收的時候，產品負責人必然會要求再次改動。
這些我們可以稱為需求變更，也不能說是需求變更，因為在需求澄清的時候，雙方沒有明確驗收標準，在開發一個產品時，產品經理所想的和開發人員想的是不一樣的，最後驗收時就會提出各種可A可B的選擇題，產品經理選的是A，他認為最開始討論的時候達成的共識就是A，而你開發出來的是B，所以最後時刻提出看似新需求的Bug。
質量上，保證的工作全部交給了測試
傳統的質量保證工作，就是在最後一個環節——測試裡做到的。開發人員將做好的產品轉交給測試人員，期望在這個環節裡多多的測出Bug，然後自己很“勤奮”很“努力”的去修復。最終結果就是，大家都加班幹活，專案依舊沒法按時完成。開發疲於奔命的寫（創）代（造）碼（Bug）和修Bug，測試拿到開發好的程式碼後不厭其煩的尋找Bug，這期間並沒有從源頭上去提高質量。這就陷入了誤區-質量是由測試來保證的。測試，只是檢測手段，質量本身沒有做好提高措施的話，光靠檢測，只會事倍功半。
測試上，沒有能力做到持續迴歸測試
新功能測試完畢後，要進行迴歸測試，這時候發現出現很多已有功能的Bug。已有功能的Bug又是新功能程式碼間接引入的，查詢問題原因，修復Bug，再針對這一次修復進行迴歸，流程很長，花費時間比修復新功能的Bug要多。由於迴歸測試常常是放在了測試環節裡面的最後一步來做，時間盒已經消耗殆盡，造成迭代延期。
傳統專案裡，迴歸測試常常做好幾輪。以一個三個月開發週期為例，第四個月開始測試工作，到了月底可能測試+修復的差不多了，進行第一輪迴歸測試，然後繼續修復新發現的Bug。一週後進行第二輪迴歸測試，再修復新Bug，再3天后進行第三輪迴歸測試，再修復，這樣的流程。
我們都知道做軟體開發過程中，會帶來很多已有功能的Bug，但是依舊選擇將這麼重要的迴歸測試放在了專案的最最最後的那幾天，導致集中出現大量的已有功能的Bug。通常這都是由於，做一次迴歸測試需要的時間太久導致的，團隊沒有能力做到每次更改程式碼，都快速的做一遍全量回歸測試。
解決措施
針對上面提出的導致因為修復不完Bug而延期的四個方面問題，給出以下建議。
流程上，避免小瀑布陷阱
一定要避免諸如前半周需求，後半周設計，第一週開發第二週測試這樣的小瀑布開發模式。
無論迭代裡有多少個需求，一個迭代時長是幾周，每開發完一個需求，立刻開始測試工作。
理想狀態如下：
• 第一個需求開發完畢，測試人員開始測試，開發開始為第二個需求進行編碼，期間同時修復第一個需求的Bug。
• 等第二個需求開發完畢，第一個需求的測試及bug修復應該也結束了，然後第三個需求的開發和第二個需求的測試工作應該開始了。
如果團隊使用Scrum框架的話，那麼在每天的站立會議上，團隊在看板上移動需求卡片時，測試人員關注那些已經被開發人員移動到了已解決的卡片，按照實際能力將相應數量的移動到測試中，如下圖所示。
圖3 合理的任務看板
上圖中，進行中和測試中的卡片數量都看上去沒那麼多，比較合理。如果出現類似下面的情況，開發活動開始了，完成了好多需求，但是測試活動遠遠落後，就要注意了，你可能掉進了小瀑布陷阱。
圖4 不合理的任務看板
按照【圖3：合理的任務看板】的卡片流轉情況，這樣可以儘早的發現需求的缺陷，降低了缺陷在系統中存留的時間，就是降低了它帶來的風險。
需求上，澄清需求的時候明確驗收標準
在需求澄清的時候，團隊和產品負責人要對驗收標準達成一致意見，並且記錄下來，以輔助開發團隊編碼時有法可依。下圖為示意圖，在DevCloud記錄使用者故事的工作項裡，同時記錄驗收標準，減少最後驗收時出現需求式的Bug。
圖5 DevCloud使用者故事中的驗收標準
質量上，透過預防來產生質量
質量管理大師克勞士比的質量管理基本原則裡提到，預防產生質量，檢驗不能產生質量。所以，如果我們能在開發的時候就採取預防措施，做到第一次做正確，這才產生了質量，這也是零缺陷管理的核心。
圖6 克勞士比零缺陷管理三要素
根據我們的實踐和總結，推薦如下動作：
1. 溝通需求的時候，團隊一起了解需求，在使用者故事卡片裡幫助新增檢查點，以便於在編碼的時候就會提前考慮這些檢查點，進而編寫程式碼的同時就保證了質量。
2. 在討論需求和設計的時候，團隊（一般由架構師或者技術能力強的測試人員來主導）就針對當前的設計和使用的技術提出需要注意的問題和建議，可以讓開發人員在編碼的時候就規避了潛在質量問題。
透過以上活動，從產品內在提高了質量，可以從本身上大大減少Bug數量。
測試上，加強自動化測試做到持續迴歸
從迭代裡的第一次提交程式碼開始，任何一次提交程式碼，都做一次迴歸測試，這樣可以保證第一時間發現對已有功能的影響，儘早修復，而不是在最後一次迴歸測試的時候發現問題。這個迴歸測試速度要快，也就是不花費太多時間，同時覆蓋的面越廣越好。
考慮到開發人員不愛做測試的共性，所以迴歸測試要做成便於開發人員維護，學習、維護成本低，效果好（如上所述的執行速度快、覆蓋面廣）的特點，比如說介面自動化測試。如下圖所示，以軟體開發平臺 DevCloud 的介面測試為例，配置必要的資訊，即為一個場景下的介面測試用例。
圖7 DevCloud的介面測試配置
將所有介面都寫好測試用例，然後配置到在流水線裡。每次提交新的程式碼，都讓它自動觸發流水線，執行自動化測試用例，失敗的話，就發郵件通知到該開發人員。
圖8 DevCloud的流水線
這樣，就可以高效的做了迴歸測試，最終使得在編碼期間，有任何Bug出現，都可以第一時間發現，不會都堆積到專案的最後時刻爆發。
總結
迭代總是因為修復不完Bug而延期，解決方法並不是團隊繼續加班去工作，而是要找到根本原因，對症下藥，透過諸如避免小瀑布陷阱、透過預防來產生質量、增加介面自動化測試、需求澄清時明確驗收標準等措施來改善工作流程，才能避免陷入惡性迴圈，徹底解決這個問題。
華為開發者空間釋出
讓每位開發者擁有一臺雲主機