臭蟲管理 (之一)
之前曾經約略提到過 M 社對臭蟲以及除錯的管理流程，現在就來更詳細的說明一下作法。一般來說，說到除錯管理或是更廣義的議題管理，多半會從使用的工具開始說起。不過根據我自己的心得，真正發揮效用的，並不是工具的功能或是特點，而是在團隊能不能確切的遵守幾項核心的協同合作準則。這裡就整理幾項讓大家一窺究竟:
任何人都可以開新的 bug。一旦開了，就不能刪除，即使只是暫時測試目的 record 也一樣。
只有開的仍能決定 bug 能不能”關掉” (close)，”關掉” 只是紀錄上的一個狀態，表示告了一個段落，並不是永遠消失。很多情形之下 bug 會被重新啟動。
開了一個新的 bug 之後 (通常是 tester)，如果知道誰可以處理這個問題，會直接 “指派” (assign) 給那個人 (通常是 developer)。如果不確定應該由誰來，就暫時指派給 “Active”。
絕大部分的情況下，被指派的 (assignee) 只能是一個人 (三個和尚沒水喝?)，而且是有能力處理這個 bug 的。少數的情況才會 assign 給一個虛擬的名字，表示需要外部或是更進一步的調查。
Bug在關掉之前，必須下一個 “決議” (resolution)。最好的情況當然是 “已修正” (Fixed)，這個情況下，bug 會 assign 回開 bug 的 tester，一直到這個修正在最近的一個軟體版本確認真的被修好了，才能 close。
除了 “已修正” 的 resolution，還有 “重複” (dup)、”無法重複產生” (not-repro)、”合乎設計” (by-design) 以及 “不修正” (won’t fix)。要使用這些，通常要由 PM 凝聚共識而且代表作成決議。
用一個流程來說明吧: 一位 tester 在某個開發中的版本發現了一個缺陷，就會在系統中開一個新的 bug，並且 assign 給 active。團隊中的 developers 的經理人 (就是 developers 的老闆) 會定期巡視系統，發現了這個 bug 沒有工程師處理，就會將這個指派給負責撰寫這個功能的工程師。這位 developer 一時無法重複產生這個缺陷，就將問題設為 “not-repro” 並 assign 回給這位 tester。而 tester 再次釐清問題產生的步驟，再次指派給工程師。工程師經過研究之後，認為這個缺陷雖然不符測試工程師的期望，但還是在設計的規格中運行，就將問題指派給 PM，由PM 集合功能小組進行討論，評估外部的使用者能不能接受這樣的行為。決議是可接受，PM 就將 resolution 設為 “by-design”，並交回給測試工程師關閉。
當然，這只是其中的一個可能流程。實際發生情況的變化可是成千上萬種，這裡寫三天三夜也寫不完。這裡想說明的是: 其實管理系統的功能相當單純，主要只是資料庫每筆資料的欄位變來變去而已，而且除了基本的讀寫權限設定之外，並沒有太多的限制。真正要能使系統運轉，並且確實紀錄並留下所有臭蟲修正的軌跡，是要團隊的每個角色都能鉻首職責，紮紮實實的對每一次的決策都有確切的討論及結論，才會有作用。所以核心事實上還是以人為主軸，工具只是輔助而已。
也就是如此，即使 M 社的管理機制已經十分成熟，並不代表所有的團隊的開發過程以及缺陷的自我管理都做得很完善，臭蟲數目太高已至於 cut feature 甚至是產品中斷發展的例子並不少見，每一次開發都是挑戰的開始。而且，某種程度團隊對臭蟲的掌握度，會反映團隊的紀律好不好，也算是組織成熟度的指標之一。
從更高的角度來看，這些臭蟲處理紀錄以及歷史資料數據累積起來，如果能做深入的分析，是可以產生有趣，對產品和組織很有幫助的情報。下一篇就來談一下這個層面的應用。