五項原則之漏洞跟蹤
2014年11月24日
遠程團隊協作不像本地團隊那樣在同一個辦公室裏，遠程需要更好的規範約束。
首先，我要說的是交流規範。在teamed.io這個團隊中， 我們在最後的五年裏，是通過遠程協作來進行軟件開發的。我們通過管理系統（如：Github, JIRA, Trac, Basecamp 等等）來嚴格的管理我們的任務，並且不鼓勵任何其他形式的通信交流方式，像網絡電話, HipChat聊天工具, 電子郵件或是電話。每個管理系統對於我們來說都是一個帶有單獨的有其生命週期的任務，有其特有的參與者和目標。多年來，我想分享一些我經歷過的經驗。如果你和你的團隊是遠程工作的話，那麼你將發現它是多麼的有用。
電視劇 巨蟒劇團（1969-1974）
1.保持一對一
每個錯誤標籤都作爲連接兩個人的紐帶:問題的識別和問題的解決。如果是個錯誤，我來報告出來，你來解決它。如果是個問題的話，我要知道是什麼原因，你解釋出來。如果是個任務，我讓你做什麼，你就做什麼。任何情況下，都有兩種主要的角色。無論在解決錯誤的過程中有多少人，只有這兩個角色纔是正式的。
錯誤標籤記錄者的責任是負責維護這個問題，當我報告了一個錯誤，我必須確定它的存在—這是我的職責。其他人也許會告訴我，我報告錯了，這個錯誤不存在。他們也許還會說，他們不能探測到錯誤。他們也許還會說，我描述的任務太模糊，沒人明白。有許多的爭議。我的責任就是努力爲了保維護標籤的的正常。很明顯，如果錯誤不存在，我就必須將錯誤錯誤取消。我就是其守護天使。
另一方面，錯誤解決者的責任是找到解決方案。當一個錯誤分配給我，我就必須解決它。我的職責就是確保我的解決方案是完美的。他也許會告訴我，我的解決方案有不足之處，不是很有效，或是不完整。而我的工作就是確信我是對的，他是錯的。當然，是以合理的方式。爲了找到足夠的可被接受的解決方案，我不得不首先調查所有的可能性來了解問題，然後找到一種簡潔的解決方式。但是，這是次要的，最主要的還是關注怎麼說服錯誤記錄者。我要時刻謹記，我最主要的目的是解決錯誤。
我的觀點就是，無論有多少人討論解決問題，永遠都要記住，到底發生了什麼—只有一個人負責提出解決方案，其他的人負責討論（請看下文）。
2.解決它
記住，錯誤標籤不是一個對話。你不是來這聊天的，你是來這解決問題的。當這個問題分配給你了，那麼你就儘可能的解決它。
此外，切記，儘早的解決問題，對於項目的進展是很有好處的。時間越長，項目管理起來越麻煩。以爲追蹤和控制這些問題不是很容易的。很難知道到底發生了什麼。你見過哪個開源項目有一些持續了2年的問題，並且有幾百條評論，然後沒有交付的？
對於項目管理者和參與者來說，這是不對的。每個錯誤應該有一些簡短的認知，-1）一個問題，2）一個準確的詢問，3）一個簡短的解釋，4)一個解決方案，5）解決，謝謝。這是理想的方案。
一旦你意識到問題進入了長期討論的階段，就要儘快的解決它。如果報告者不喜歡我的解決方案，該怎麼辦呢？那就找一個暫時的另他們滿意的方案來解決它。可以在代碼中使用“TODO”—這總比被問題長期困擾好吧。
一旦你發現提出的解決方案足夠解決問題了，這時候就讓報告者來解決它。如果你不介意周圍的人說這個解決方案可能被接受，那麼就明確的說，這是可以的。你要明確表示解決這個問題。試着這樣：“@jeff，如果你沒有任何疑問，請解決這個問題。”
3.不要解決它
每次你提出了一個問題，你就消耗了一些項目資源。每個問題報告者都意味着項目中花費了錢：1）這些錢用於發現問題和修復問題；2）對於項目管理者來說，他來找到解決問題的人；3）對於問題解決者來說，他儘量的來了解你提出的報告和解決方案；此外，4）其他人將會參與到討論中。
如果你在沒有在恰當的解決問題的時候，就把標籤關閉了，而是將標籤扔進了垃圾箱。一旦錯誤標籤的內容發生了，是無法恢復的。所以，我們不能只是說,“這個標籤不再有用了。”你的錯誤標籤已經消耗了項目資源，並且花費了時間，爲了使它們有可用之處，你不得不確定出來解決方案。
也許會是暫時的解決方法。可以改變項目中一行的內容。可以在代碼中使用TODO標記來說明“我們意識到這個問題了，由於我們很懶，還沒修復它”。總要做些事情，而不是什麼也不做。
從不同觀點角度來觀察問題。當你開始發現這個錯誤標籤，你在腦海裏就要有東西了，關於你爲什麼報告了這個問題。即使有時候跟項目沒有關係。如果你關了這個問題標籤，在沒有任何人看到這段代碼的情況下，也許其他人可能會在這個問題上困擾幾天甚至幾年。然後，這個項目不能不再次花錢來重新標記錯誤標籤，並討論和解決這個相同的問題。即使你認爲你發現的問題實際上不算是個問題，
那你也要讓一個問題解決者來看看源代碼，爲了防止同樣的問題在以後再次出現。
4.避免無意義—寫下你的註解
每次你在標記錯誤的時候，都要寫下註解。否則，如果你僅僅是因爲想表達下觀點就標記的話，你的評論將會變爲無意義的垃圾。記住，標籤是兩個人之間的通信媒介—其中一個人報告了錯誤，同時，另個人要試圖修復它。像“我試試其他方法怎麼樣”或是“我記得我之前修復了一個相同的問題”這些評論，都是讓人惱火的和分心的。讓我們真誠點，沒有人真的需要或是關注什麼觀點。真正需要的是錯誤的解決方案。
如果你認爲錯誤標籤應該關閉了，因爲解決方案足夠好的。那你就寫個註解給錯誤報告者，註解以“@jeff，我認爲你的解決方案已經足夠好了，因爲…”開頭。這樣的話，你就幫助了他關閉了這個標籤。
如果你認爲解決方案是錯誤的，也記下的註解給標籤報告者，以“@jeff，我認爲你的解決方案不是很好，因爲…”開頭。這樣的話，你就使得標籤一直存在在這，直到有合適的解決方案出現。
再一次提醒，不要有無用的觀點。而是，明確的在旁邊注解出來—如果你喜歡這個解決方案，就關閉它。如果不喜歡這個解決方案，就保持它的開啓。否則，只是讓解決方案更加複雜，而對項目根本沒有好處。
5.當產品出現問題，報告出來
我認爲這是很明顯的，但是我還有重申一次：每個問題都可能再次出現。每次你報告了一個問題，你就應該很好的解釋產品爲什麼會出現問題。是的，產品沒有像預期那樣工作，或是沒有正確的工作，甚至沒有滿足需求等等，這都是你的工作。
每個錯誤報告都應該伴有類似的結構：“這纔是我們需要的，這是我們需要修改的，修復它”。每個錯誤標籤，都是一個問題，一項任務，一個疑難，或是一個建議，都要以這種方式來處理。在提交的時候，你需要將項目從A點轉移到B點。有時候，A點是不合適的，在B點可能會更好。所以，你需要解釋A點和B點的情況。如果你可以解釋怎麼轉移—問題是怎麼再生的，怎麼修復它，這會是非常令人滿意的。
即使當你有問題，你也要以這種規範格式來處理。如果你有問題，就說明項目文檔沒有滿足你找到問題的所在。這就叫做錯誤。應該修復它。以報告的形式，像“我怎麼纔可以看到X.class？”這麼說，“目前的文檔不完整，不能解釋我怎麼使用X.class，請修復。”
如果你不能解釋怎麼轉移到另個地方的，那你就在標籤中這麼說：“我發現這個類不能像預期那樣工作，但是我也不知道怎麼處理這個問題。”這將給每個人一個明確的信息是你意識到了問題報告是不完整的。解決問題的第一步就是提取問題，使之在現。如果不能再現，很明顯你的問題就會被關閉。
讓我再次重申：每個錯誤標籤都牽引着項目從A點到更合適的可以修復項目的B點轉移。作爲錯誤標籤報告者，你的工作就是明確的清晰的記錄出來出問題的那一行代碼。
相關帖子
你也許會在這找到你感興趣的話題：
本內容原文地址：http://www.yegor256.com/2014/11/24/principles-of-bug-tracking.html
