為什麼你應該遵守0 Bug 原則？

你處理過無數 Bug ，卻不見得明白正確處理 Bug 的真正鐵則。本文僅介紹作者一家之言，歡迎討論。今日書單彩蛋：《數據科學家修鍊之道》。

你處理了多少 Bug ？100個？200個？還是2000個？ 

可能你自己也不能說出準確的數字到底是多少，因為它始終在變化。 

但我知道我們究竟有多少 Bug ：0個。 

你究竟參加過多少次 Bug 分揀會議？你在 Bug 管理上用了多少時間（還是僅僅將缺陷從這個版本帶到下個版本）？ 

作為團隊經理，我每月會花費半小時在 Bug 管理上。並且，同一個 Bug 從未在我眼中出現過第二次。 

答案是使用0 Bug 規則。 

這是基於我在過去的5年中，在不同scrum團隊中實現不同產品的經驗所得。 

我們也嘗試過其他的辦法，但全部都失敗了：例如說，我們曾嘗試過提升 Bug 管理在產品待辦事項中的優先順序，但是這完全沒有用。

客戶總希望多開發一些功能，而不是解決 Bug 。所以在這種情況下， Bug 管理就會被推遲到下一次迭代。 

但使用0 Bug 規則的話， Bug 管理就可以有條不紊地進行。 

0 Bug 規則非常先進，但是它是處理 Bug 的非常簡單的過程。 

它強調了一個你需要遵循的簡單規則——每當你遇到一個新的 Bug ，你可以選擇立刻去修復它，或者你選擇不再修復它，然後也不再去想到它。就是這麼簡單。

現在，讓我們來看看為什麼這是唯一可行的辦法。

 Bug 可以分為2類：

1. Bug 是在開發新功能時帶來的。

比如說你在用Scrum方法工作（或是用任何敏捷迭代方法）， Bug 是在「sprint」階段，在你正在實現的新的用戶故事中被找到的。

這類 Bug 必須立刻修復，否則用戶故事，或是說功能並沒有真正完成。同時，你違反了敏捷基本原則：該做的做完了就好了，這表示只有在用戶故事或是說功能經過完全測試，並得到客戶的認同，才是真正的完成。如果有任一點沒滿足，就不能成為結束。 

如果你還是沒有弄懂這個概念，那我們可能需要重新回到敏捷基礎，你可能需要參考一些其他文章，本文中將不再重複。

2.其他的 Bug （非sprint缺陷） 

a.回歸 Bug ——由於開發了功能B，在功能A中出現的 Bug  

b.客戶 Bug ——客戶，或是不是開發組成員的產品用戶所報告的 Bug  

c.在開發完功能/用戶故事後發現的 Bug 。從理論上來說這不應該發生，但是當我們發現缺少測試覆蓋，或是在做 Bug 跟蹤和產品固化時可能會發生。

所以，讓我們從理論上來討論一下如何處理第二類 Bug ——非sprint Bug ： 

1. 你可以選擇立刻修復它（或者在下一個sprint修復，但不能再晚了） 

2. 如果修復這個 Bug 的價值不大，你可以選擇不再修復它 

3. 你可以將 Bug 推遲到之後處理（幾個月後，或是下一個版本中）

請你永遠，永遠，永遠不要推遲 Bug 。請儘力避免。如果你現在不修復它，那你永遠都不會再修復它。 

那我們該怎麼辦？我認為你只需要立刻修復它，或選擇永遠不修復。這是我們在文章一開始就討論過的簡單規則。 

立刻需要修復的 Bug 包括：「兩名用戶不能同時進入UI。」 

如果修復它需要超過2天，你可以選擇不修復的 Bug 包括：「當屏幕解析度為768X1280的用戶使用Safari時，登錄頁面的幫助文本是模糊的。對於其他的瀏覽器，或者其他的屏幕解析度來說就沒有這個問題。」 

《皇帝的新衣》故事中的小男孩哭著對皇帝說：「可是他什麼都沒有穿！」。對於這個問題他將會問，「為什麼？為什麼這些 Bug 不能推遲？為什麼我不能等到以後再修復它？」 

如果以後修復，你會用更多時間，非常多，大概是好幾萬倍時間！ 

噓！這是一個大秘密！如果你選擇幾周後修復（這裡說的不是下次版本發布時）：

• 你可能不太記得，或者你對這個 Bug 的理解沒有現在來得強烈。

• 修復需要好的環境——驗證錯誤和修復錯誤的好環境，在幾周以後可能不復存在了。這意味著你需要投入更多的時間來搭建環境。

• 導致原始 Bug 的代碼已經更改，其特性也會略有不同。

事實就是，你在未來需要用更多時間修復的這個 Bug 只是一個小問題。

第二部分是你需要維護、分類和管理推遲的 Bug 。無論它們是在產品待辦事項中（在一些 Bug 分揀系統），還是在主要功能清單中。

無論是哪種，你都要對它們進行優先順序排序，這也需要時間。越久遠的缺陷要用越長的時間，因為你不能像對待新的缺陷一樣這麼了解它們。 

這還不是全部。同時，分揀錯誤很煩人。你曾經參加過 Bug 分揀會議嗎？相信我，這個會得開好久。 

照我的經驗來說，如果你的團隊有幾個經理，幾個開發者，幾個產品擁有者和幾個架構師，他們坐在「 Bug 的法庭」中，討論如何處理 Bug ，這場談話最終會變成沒有贏家的戰爭：

• 開發經理：「現在修復這個危險很危險！我們不如推遲吧！」

• 產品擁有者：「你根本沒有考慮到用戶體驗！沒有為用戶考慮！」

• 開發者：「我們不用使用Java，只要做一個簡單的GO模塊就可以提升目標機器的性能。」

• 架構師：「如果要修復這個 Bug ，我建議我們放棄extJS而轉向Angular，它性能很強大。但我們要記住，修復可能會帶來安全影響。」

• QE：「測試這次修復非常簡單，我可以在2小時內完成。當然，如果需要在所有瀏覽器中測試，模擬多用戶使用就會要好多天。我們要確保從規模的角度不會有回歸測試。」

然後這將繼續下去……

大家已經知道這個秘密了，你將永遠不再修復這個 Bug ，它將永遠在你的系統里。 Bug 的數量會越來越多，無論你將系統部署在哪裡，這些 Bug 都會跟著你。

你一次一次的分揀它們，在每周報告中提到它們，在質量指標中計算它們。但是，在任何情況下，這些 Bug 都不會被修復。

還記得《皇帝的新衣》中的孩子嗎，他哭著說：「這是為什麼？為什麼？為什麼呢？」

• 如果你決定了現在不修復它，這意味著你現在有更重要的事情要處理。可能是添加新功能。

• 隨著時間的流逝，你會推遲更多的 Bug ，這個 Bug 需要和那些新的 Bug 競爭到底先處理誰。所以如果在現在，只有這個 Bug 的時候你不去修復它，那將來有更多 Bug ，你憑什麼覺得你會再回頭來修復這個 Bug ？

40 Bug 原則厲害在哪？

1.首先我們來分析一下為什麼其他的方法不能起效。

為什麼在發布的最後，加固階段不修復非sprint Bug ？在加固階段你要努力讓你的發布版本穩定一些。你要投入精力來尋找未知的錯誤，而不是修復你之前推遲的小 Bug 。 

在任何情況下，你都不會去修復 Bug ，所以你就把這些 Bug 推遲到了下個版本。在下個版本中會有新的 Bug ，所以這些低優先順序的 Bug 將永遠得不到修復，但你卻需要用一些時間來維護它們。 

可能在4年以後你會決定不再修復它們，因為不值得再修復它們了。想想入你在一開始就選擇不修復它們，你得節約多少時間。

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

你可能根本沒有空載時間。即使你有，你也需要先處理那些優先順序更高的問題。

3.為什麼不在下個版本中，我們有更多時間的情況下來修復費sprint Bug ？你是認真的嗎？你認為下個版本沒有新功能？沒有客戶？沒有截止時間？沒有里程碑嗎？ 

當然開發者都喜歡這2周修復 Bug ，每個sprint都有一些 Bug 會讓團隊更高興。 

如果你還處在一個新版本的最初階段，功能列表還沒準備好，不如花時間在創新和社交活動上吧，你會從中受益更多。

4.為什麼不在專門的 Bug 修復sprints中修復非sprint Bug ？我們之前用過這個辦法，它是有一些優勢——PO沒有選擇，因為整個團隊決定好這段時間只修復 Bug 。每個人都修復 Bug ，就感覺上像是「我們都在一起解決 Bug 麻煩」。 

然而，我並不建議用這個方法，因為這個方法僅僅處理了一部分積壓已久的大問題，但沒有徹底消除它，在後期我們還會碰到修復 Bug 的問題，而且這個問題會變得更複雜。

5.為什麼不把修復非sprin Bug 作為用戶故事列表的一部分？ 

是的，這不是一個壞的選擇。但它有兩個主要的問題： 

a. 產品擁有者很難理解這些缺陷為什麼比他們的用戶故事優先順序高。如果讓他來選，他更傾向於選擇用戶故事。

更重要的是什麼？刪除彈出窗口中的冗餘滾動條還是添加搜索功能？這會導致低產品質量和失敗的研究與開發。 

b. 每個你現在不修復的 Bug 在未來會花費更多時間。所以推遲 Bug 不符合成本效益。

當我們選擇混合 Bug 和用戶故事列表時會發生以下這些事情：

1.我們預先計劃好將幾個故事和 Bug 一起處理，如下所示： 

2.團隊只承諾保證前3項完成 

3.然後PO決定將第三項優先順序降低，因為「停止應用程序」的功能更加重要： 

4.PO還不是很滿意，因為「研究」用戶故事不再團隊的承諾列表中。 

我們和團隊協商完畢，他們承諾會完成前三個用戶故事，也會儘可能修復 Bug 。 Bug 並未得到解決。 

類似的sprint又發生了，更多的 Bug 在積壓，而新功能卻都得到了處理。 

我們現在也同意，0Bug原則是唯一的解決方法。

紅包系統由三部分組成：信息

1.我的產品有1000個 Bug 積壓，我從何開始？ 

回顧所有的 Bug 要花費1周的時間。如果你選擇不再修復 Bug ，或在下一個sprint中修復，那你就沒有 Bug ，你也不需要維護它們了。

2.恐懼因素： 

這可能是人們不喜歡0 Bug 規則的真正理由。它們害怕。我向好多個團隊介紹了這個方法，由於恐懼他們拒絕嘗試它。我聽到他們說： 

「如果我們決定不修復這個 Bug ，它就不在了！我們將永遠失去它！」 

是的，這是真的，難道你沒有感覺到解放嗎？ 

「但是，如果我們不修復這個 Bug ，那以後客戶在產品中發現這個 Bug ，難道我們要再來修復它嗎？」 

很好，也許我們現在會將這個 Bug 列為最高優先順序，並決定立刻修復它！

3.我們的團隊只有兩個人，我們也要使用0 Bug 規則嗎？ 

如果你們團隊只有兩個人，你不需要任何 Bug 規則，你不該有這些 Bug ，你絕對不會分揀它們。

4.敏捷的一個主要原則不就是人高於過程，0 Bug 規則不是違背了這個原則嗎？是的，確實是，根據我的經驗，我更喜歡通過文化變革來解決問題，而不是增加過程來解決問題。

0 Bug 規則是這個規則的例外，因為只有這個方法起效，其他辦法都不能解決 Bug 。

我可以誠實地告訴大家，使用0 Bug 規則對項目不是可有可無的，它非常有效。對我來說最難的一部分就是告訴產品經理，這個方法是唯一有效的正確方法。

這需要產品經理稍微放掉一些手中的權利，這可能不是一件很容易的事情。最好的事情，就是讓他們了解到使用這個規則並沒有拖延進度，反而能事半功倍。 

0 Bug 規則的另外一個副作用，由於文化影響，現在開發者都盡自己所能追求高質量，沒有一個開發者希望自己的代碼中有 Bug 。

對大多數（優秀的）開發者來說，如果決定不解決 Bug ，就感覺自己的作品不完美了。由於這個文化，開發者和產品都轉而追求高質量標準。 

Gal Zellermayer是一位「萬事通」。在過去的5年中，Gal在VMware公司中管理不同的R&D團隊，所以他對於產品研發周期有很多經驗。

通過創新，通過建立產品待辦事項列表，領導團隊實現項目的同時保持產品高質量，將產品滿意地交付給客戶。但他最追求的是建立完美的軟體團隊，一個可以快速交付高質量產品的團隊。

Gal熱愛新技術，新產品，以及過程。但是最讓他興奮的是和他一起工作的人，能看到他所輔導過的人在事業上取得進步是最令他感到驕傲的事情。

推薦閱讀：