你在管理著多少個 bug，100，200，還是 2000 個？可能你自己也說不清，因為這個數字一直在變化。

但我卻能說出我們的 bug 數：0 個。

你究竟在 bug 分派和管理上花費了多長時間，還是隻能把它們從這個版本拖到下一個版本？

作為一個團隊經理（group manager），我每個月要花半小時的時間在 bug 管理上，並且同樣的 bug 不會在我眼裡出現第二次。

你有沒有考慮過，當你使用 Scrum 或其他敏捷方法工作時，要如何處理 bug 呢？

答案就是使用 0 bug 策略。過去五年中，我參與過不同產品的 Scrum 專案，這個策略是基於我的工作經驗得出的。

我們也嘗試過其他方法，但都宣告失敗。例如，我們試過提升 bug 在產品待辦事項中的優先順序，但沒什麼用處。比起修復這些 bug，客戶更傾向於給產品開發一些新功能，然後這些 bug 就會被推遲到下一次迭代中。

0 bug 策略解決了這一問題。

下面我們來了解一下 0 bug 策略，以及為什麼我認為這是最好的解決方案。

什麼是 0 bug 策略？

0 bug 策略是一種非常先進的處理 bug 的策略，但同時它也非常易於實施。

你只需要謹記一條準則：不論何時對 bug 的處理方法只有兩種選擇，或修復它，或關閉然後不再去想它。

如何實施？

Bug 可以分為兩類：

• Bugs that were opened during the development of a new feature.
• 開發新功能時出現的 bug。

如果你們正在使用 Scrum 方法（或其他敏捷迭代方法），在實現使用者故事（user story）的 sprint 過程中產生的bug。

這類 bug 必須立刻修復，否則使用者故事，或者說新功能的實現就會受到影響，而且你也違背了敏捷開發的原則：DONE is DONE（木已成舟，指開發完成就不再更改）。只有經過全方面測試，並得到客戶的認可後，使用者故事或新功能才能算得上是真正的完成。

• 其他 bug（非 print 過程中產生的 bug）可以分為以下幾種：
• 迴歸 bug ：由於開發新功能導致其他功能出現 bug 的情況。
• 客戶 bug ：不是由專案組成員提出，而是由客戶或使用者反饋的 bug。
• 在新功能/使用者故事實現後才發現的 bug。這種情況不應該發生，但有時又無法避免，比如說當測試覆蓋不足、進行 bug 跟蹤或產品固化時都可能會發生。

我們應該如何處理第二類 bug？

• 立即修復（或在下一次 sprint 中修復，但不能拖到更晚了）
• 如果修復這個 bug 價值不大，直接關閉不進行修復即可
• 推遲解決（在幾個月後或在下一個版本中再解決）

永遠不要推遲 bug，如果你現在無法修復它，那麼你可能永遠都不會再修復它了。

那我們應該怎麼做呢？或者選擇修復它，或者關閉它，這就是 0 bug 策略的精髓。

如下這種 bug 是必須進行修復的：兩個使用者無法同時進入 UI

如果修復一個 bug 需要超過兩天的時間，可以考慮不進行修復，舉個例子：

在 Safari 的使用過程中，當螢幕解析度為768×1280 時登入頁面中的幫助文字有些模糊。其他瀏覽器或其他的解析度就沒有這樣的問題。

可能有人會問，為什麼不能推遲一些時間再解決這些 bug 呢？

如果以後再修復，你需要花費比現在更多的時間和精力才可以。因為幾周後：

• 你可能記不太清，或你對 bug 的理解沒現在這麼清晰。
• 驗證錯誤和修復 bug 需要恰當的環境，幾周後你需要投入很多時間來搭建環境。
• 導致原始 bug 的程式碼可能發生變動，其他特性也可能會稍有區別。

然而問題不僅僅是你需要投入更多時間才能修復 bug，這只是一個很小的方面。

後續你還要對這些 bug 進行維護、分類和管理。無論是把它們放在產品待辦事項中（在某些 bug 分類系統中），還是作為主要功能清單的一部分，你都需要對這些 bug 按優先順序排序，這無疑會耗費很多時間。處理舊 bug 則需要更長的時間，因為你不能像熟知新 bug 一樣那麼瞭解它們了。同時，bug 分類也是很煩人的。

根據我的經驗來說，當經理、開發人員、產品所有者和架構師坐在一個 bug 法院（試圖決定如何處理 bug）時，這場討論將變成一場沒有贏家的戰爭：

• 開發經理：“現在修復這個 bug 有風險，不如推遲吧。”
• 產品擁有者：“你根本沒有考慮到使用者體驗，你沒有為使用者考慮！”
• 開發人員：“我們可以不使用Java，只要做一個簡單的 Go 模組就可以提升目標系統的效能。”
• 架構師：“我建議放棄 extJS 轉向 Angular，後者功能更強大，但需要一提的是，修復這個 bug 可能會帶來安全方面的影響”
• QA：“測試這個修復很簡單，兩個小時之內就能完成。當然，如果需要模擬多瀏覽器多使用者的情況就需要幾天的時間。並且我們需要確保在規模化的角度不會有迴歸測試。”

你將永遠無法修復這個 bug，它會永遠存在你的系統裡。這類 bug 會越來越多，它們會一直跟著你。你只能一次又一次地進行分類，把它們記錄在每週的報告中，並且在質量指數中計算它們。

為什麼這些 bug 永遠無法被修復？

• 如果你現在不打算修復的話，意味著在現在和以後的版本中，你都有更重要的事做。
• 隨著時間的推移，你會推遲越來越多的 bug，這些舊 bug 還要和新功能和新 bug 進行競爭。所以，如果在沒什麼其他嚴重 bug 情況下這些 bug 還無法被修復的話，你憑什麼認為以後就能修復它們呢？

為什麼不能在釋出最後的加固階段修復非 sprint 期的 bug？

在加固階段，你應該努力讓你的版本更穩定一些。你要盡力尋找未知的問題，而不是在這時修復那些推遲的小 bug。

不論何時，你都不可能修復所有的 bug，總會有一些被推遲到下一個版本解決。而在下一個版本中你肯定會發現新的 bug。那些低優先順序的 bug 永遠不會被修復，但你還需要花時間維護它們。

也許 4 年後你決定不再修復它們，因為不值得的浪費精力。想象一下，如果在建立 bug 時就直接選擇不進行修復，你將節省多少時間。

為什麼不能在空載時間修復它們？

你不會有空載時間的，如果有的話，也會有更重要的問題等著你去處理。

為什麼不能在下一個版本中修復它們？

你確定麼？難道下一個版本沒有新功能、客戶、截止日期和里程碑麼？

當然開發人員都很喜歡那兩週的錯誤修復時間，每次 sprint 有幾個 bug 會使團隊人員更高興。

如果一個新版本剛開始的時候，功能列表還是空白的，不如在創新或社交活動上投入點時間，你會受益良多。

為什麼不能在專門的 sprint 期中修復非 springt  bug？

我們以前嘗試過這種方法，的確有些好處。產品所有者沒有選擇，因為整個團隊這段時間都在修復 bug，每個人都在做這件事，給人一種團隊合作的感覺。

然而我卻不是很推崇它，因為這種方法只是處理了其中一小部分，根本沒法消除日積月累的 bug，後期你仍然會面臨這些問題，而且問題會更復雜。

為什麼不能把 bug 作為待辦列表的一部分解決？

實際上這也是個不錯的選擇，但需要注意：

1. 產品所有者很難理解為什麼這些 bug 的優先順序會比新使用者故事要高，他們更傾向於使用者故事。刪除彈窗中多餘的滾動條和新增搜尋功能，哪個更重要呢？這將會降低產品的質量和研發熱情。
2. 每個現在你無法修復的 bug後期會消耗更多的時間。推遲 bug 不符合成本效益。

下面這張圖展示了 bug 和使用者故事混合記錄的情況。我們嘗試了將幾個使用者故事和 bug 放在一起處理：

在此期間，專案組只需處理前三條內容

產品所有者決定將第三項優先順序降低，因為停止應用程式功能更加重要

產品擁有者還不是很滿意，因為搜尋功能沒在列表中提及

我們和團隊達成協議優先解決前三個使用者故事，同時儘可能修復 bug。Bug 並沒有得到修復。下次 sprint 的模式還是一樣的，更多的bug 被積壓，而新的功能都得到了處理。

現在，我們同意 0 bug 策略是唯一的出路了。

為什麼0 bug 策略不常見？

0 bug 策略不太常見可能有以下幾個原因：

我的產品已經有超過 1000 個 bug 了，我如何開始？

花一個星期的時間瀏覽這些 bug，或者選擇不再修復它們，或者在下一個 sprint 中進行修復。你需要做的就是把 bug 數變為 0，然後保持住。

恐懼

這可能是為什麼人們不喜歡 0 bug 策略的真正原因。我曾向幾個團隊介紹了這種方法，但是由於恐懼他們都拒絕嘗試：

如果我們關閉了這個 bug，它就徹底消失了，我們永遠也找不到它了！

沒錯，就是這樣，難道你沒有感覺到解脫麼？

但是，如果我們關閉這個 bug，使用者在使用產品時又發現它，不是還要重新修復麼？

既然這個 bug 如此重要，不如現在就動手解決吧！

我們團隊只有兩個人，需要遵循 0 bug 策略麼？

如果你們的團隊只有兩個人，就不需要任何策略，因為你們不應該有 bug，更不會去分揀它們。

敏捷開發的主要原則是人大於過程， 0 bug 策略是否違背了這個原則？

的確是，從我的經驗來說，我更喜歡通過文化變革來解決問題，而不是增加過程。0 bug 策略是這個策略的例外。

總結

我可以誠實地說，使用 0 bug 策略並不是微不足道，相反它能帶來很好的成本效益。對我來說，最難的部分可能是如何說服產品經理，這種方法是唯一正確的方式。這要求他們稍微放掉一些權利，這不是一件容易的事情。最好能讓他們意識這個策略沒有拖慢進度，反而大有用處。

0 bug 策略還有另外一個作用，現在的開發人員追求更高的質量，沒有人希望自己的程式碼出現錯誤。有了 0 bug 策略，他們知道如果現在不進行修復的話，bug 將被關閉。因此，開發者和產品才能向更高的質量標準邁進。

這篇文章受到 Joel Spolsky 的部落格 Software Inventory 的影響，但主要是我和同事在 VMware Israel 時完成的。

關於英文作者

Gal Zellermayer 是一個萬事通。在過去 5 年中，他在 VMware 參與過不同研發團隊的管理，Gal 對研發的生命週期有豐富的經驗。通過創新和建立待辦事項列表，領導團隊實施，然後將高質量的產品交付給客戶。他追求的是完美的軟體開發團隊-一個可以快速交付高質量產品的團隊。Gal 對新技術、產品和過程都充滿熱情，但他最熱愛的是與他合作過的人。所有他指導過的人在職業生涯中獲得進步的時候，他都會為之驕傲。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者

打賞支援我翻譯更多好文章，謝謝！