微軟的Bug 管理指導原則

管理層要求所有的bug 都要通過raid（product studio）來跟蹤處理。這個看起來很簡單的bug 管理工具是每個員工和其他同事有效協作的重要保證

每個產品都細分模組（area，subarea），每個模組都有明確的需求定義者（pm）、開發工程師（dev）和測試工程師（tester）這三個角色。乙個問題出現了，一定會落實到某個人的頭上去跟蹤處理，絕不能出現無主的bug

pm 負責書寫的spec 是這個功能特徵（feature）的合同，以此spec 來指導開發和測試。當dev 和tester 就某個bug 發生爭執的時候，pm 負責給出乙個明確的說明

測試不僅僅是tester 的事情，儘管那是他們的專職工作。研發團隊中的所有人每發現產品的問題時候，都有義務把這個問題告知負責這個模組的測試人員去記錄跟蹤這個bug，或者乾脆自己新建乙個bug 來跟蹤

你可以建立乙個bug 指派給自己，以跟蹤某件事的處理。比如開發人員把源**中的某處問題用bug 記錄下來，以後抽出時間來進行處理

團隊中的所有人都可以建立、指派和更改bug 的狀態

當你建立乙個bug 的時候，描述一定要足夠詳細，讓下面處理bug 的人和其他關心這個bug 的同事能夠通過bug 描述準確的重現這個問題，而不是猜測某些步驟或者跑過來當面問你

通常乙個bug 的處理過程是這樣的：

1. tester 發現乙個問題，到raid 中建立乙個bug，描述這個bug 的詳細資訊，比如重現步驟（repro step）、錯誤結果（result）、期望的改動（expect）、執行版本等；然後把這個bug 指派給負責該模組的dev lead

2. dev lead 判斷後把這個bug 指派給某個特定的dev

3. dev 處理掉這個bug 並返還給原tester，或者請求pm 給出乙個澄清說明

管理層通過raid 來跟蹤整體進度，以及每個員工、團隊在其中的貢獻

有專人定期給相關同事發出bug 的狀態報告

每個人都可以方便的自助查詢bug 的分布處理情況。bug 管理系統對所有的團隊成員都是毫無保留的敞開大門（除了你不能刪除bug，另外所有的操作都被忠實的紀錄下來）

隨著時間的推移，管理層要逐步給出明確的bug 解決指導方針：哪些bug 是可以不理睬的（won』t fix），哪些是可以推遲到下個版本處理（postponed）。比如在最終build到來前的幾周，也許非常嚴重的bug，像資料丟失、程式崩潰之類的也都要推遲到下個版本再解決了。

當一線員工出現爭執、無法達成一致意見的時候（儘管這種情況不多見），管理層要快速給出處理意見。