Bug改不完，迭代總延期，咋辦？

摘要：本文從流程上需要改進的地方進行討論，分四個方面來分析產生這個問題的原因，

本文分享自華為云社區《Bug改不完，迭代總延期，咋辦？》，作者： 華為云PaaS服務小智，

前言

隨著互聯網的興起，版本交付越來越頻繁，企業開始了敏捷轉型、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而延期，解決方法并不是團隊繼續加班去作業，而是要找到根本原因，對癥下藥，通過諸如避免小瀑布陷阱、通過預防來產生質量、增加介面自動化測驗、需求澄清時明確驗收標準等措施來改善作業流程，才能避免陷入惡性回圈，徹底解決這個問題，

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：WEB自動化-13-Cypress 截圖和錄頻

下一篇：老照片修復、人像優化的代碼與問題