通常關於處理bug的准則是
修復bug使得結果盡可能的正確
這個道理似乎是顯而易見的
但是確實是這樣嗎？不
不是這樣的
我敢打賭在你使用過的那些存在很多bug
性能極不可靠的軟件中
大多數並不是因為開發者沒有時間改善它們
而是因為他們只是簡單地修復了錯誤的bug
想要修復正確的bug和知道如何修復是兩件不同的事情
要做出准確的處理bug的決定
需要回答兩個問題
首先
要明白如何才能做出一個好的修復bug的決定
其次
制定一個步驟
要求這個步驟能夠在項目壓力大的情況下也能很容易得到執行
並且執行這個步驟
明智的領導者和有經驗的團隊知道
每當項目快結束
或者出現重大轉機
或者項目重復循環中
他們將非常容易疲憊不堪
在這個過程中
他們可能睡得更少
更努力工作
並且消耗無數的咖啡
聰明的領導者如果提前考慮的話
就會訂制簡單的規則
在適當的位置預先放置急救裝置
那麼當時間緊迫的時候
就能很容易的定制快速簡單的bug修復方案
這篇論文分為兩個部分
簡單描述了上面說的定制的規則和那些預先放置的急救裝置
更重要的是
我將提供讓你制定自己的規則所需要的核心思想
我們將這個建議分為四個等級
從簡單急救(第一等級)到高性能計劃(第四等級)
但是首先
要避免那些看上去有趣但是完全沒有必要的方法
十種最糟糕的處理方法 只修復那些讓你的CEO苦惱的bug
修復每一個bug
(總也不交貨)
不修復任何bug
只修復那些讓CEO的配偶
女兒或其寵物感覺煩惱的bug
需要將每個決定讓團隊中最令人討厭
最愚蠢的人批准(這點和第十點比較起來有點多余)
沒有規律地開始修復一個bug
當你做到一半的時候
又轉向另一個bug
一直重復循環如此
看待bug就如同一個燙紅薯
不修復它
只是將你的bug委托給其他人
給bug編號
按照字母順序由A到Z
跳過元音字母
(如果你重新將它們適當的編號
這一條和第八條是相同的)
成立一個復雜的議會機構
並從三分之二的主要成員中選舉出代表
來起草一個規章制度作為小組委員會的正式文件
使得將來與管理人員談論項目中的缺點時
可以有緩沖的余地
花費所有的時間來討論當前的操作是否在上面這些列表裡
真心的希望
你從來沒有在實際的工作中遇到這些行為
現在你已經得到了警告
所以你們在將來能夠避開它們
如果你的上司建議你做上面所說的任何一條
那麼你可以馬上站起來
安靜地轉身
然後跑得能有多快就跑多快
第一等級急救 在最好的網站和軟件開發公司
bug管理就如同醫學上的優先治療選擇(譯者注
將受傷人員按輕重緩急或立即治療的可能性進行分類的過程)
一些人根據一些規則將收到的bug歸為三到四個基本的種類裡
(這叫做
治療等級選擇
bug競爭
或者叫做缺陷管理
)就像那些你可能大量擁有的事物
比如CD碟片
書籍
債務
或者女朋友
組織管理bug的唯一方式就是將它們歸結成更高一級的組群
這將能使你更容易的了解到你得到的到底是什麼
使你更加方便的同其他人討論它
並且找到合適的處理它的專家
一個普遍的規則是
把事物歸為三到四個組群比成千上萬個獨立的個體更容易管理和工作
當bug數量增加到嚴重影響工作的時候
最好的急救是停下你手中的所有工作
拿出一個下午來做修復歸類
(如果你記不起來上一次做修復歸類工作是什麼時候
那麼你現在應該停止閱讀這篇文章
馬上去做這件事情
)你無法使用魔法讓你的bug數據庫自動變得整齊規律
必須要有某個人親自動手
忙的滿頭大汗的將它們歸類整理好
我向你保證在這件事情上沒有其他的路可走
如果你曾經受過訓練
你有能力非常有規律的將它們歸類
直到整個工程結束
沒有任何事情超出你的控制
或者你能鼓勵每一個程序員經常對他們自己負責的bug進行歸類
這非常的好
但是無論你用什麼方式來處理
這件任務是必須要完成的
你跳過前面的這段
並且說
我知道歸類
但是我從來不這麼做
因為這樣做無聊透頂了
要知道
對於任何急救工作
要想成功有效的話
歸類是必須的
無論是在醫學領域還是在技術領域
如果病人的背部被射中十來支毒箭
那麼你在他擦破的膝蓋上貼上邦迪創可貼是沒有任何意義的
如果沒有歸類
你沒有辦法知道如何讓你的團隊在最恰當的地方花費精力
在受傷的人身上你能很明顯的看到那支箭還顫抖地插在他的肩頭上
但是你的代碼是不同的
代碼不會告訴你它的哪個部位受傷最嚴重
你必須親自將它們查出來
歸類還能導致一些其他有用的事情發生
負責歸類的成員能夠通過通查所有的bug使得每個人都能夠更好的了解整個項目
他將發現許多bug是重復出現的
已經被修復的
信息不完整的(這需要將這個bug返回給它的發現者)
允許忽略的
或者非常簡單可笑的
比如
有客戶抱怨這個網站不能預報下一期的樂透開獎號碼
通常
在初次歸類後
bug的數量可以減少
%
很明顯這一點能大大的提高團隊的士氣
但是你如果不做這些工作的話
是無法這麼輕松的得到這樣的成果的
最簡單的歸類 在歸類的時候
會有無數的方式來組織bug
而每一個有經驗的人都有他自己認為是最佳方式的看法
通常
這個問題沒有唯一正確的答案
使用一些簡單的方法
並且計劃在下回改進要取決於在這期間你學到的東西和下一個項目是如何改變的
最簡單的安排是劃分成三個類
必須得到修復的
可能需要修復的和不需要修復的
當給每一個bug歸類的時候
將它們放入這三類中的其中一類
你放入後兩類的bug越多
你歸類的效率就越高
這些類的名稱已經很明顯的解釋了原因
當然最糟糕的情況就是
%的bug都被歸到必須被修復的那一類中
這種行為被稱為
膽小鬼的歸類
如果每件事都是必須被修復的
那就是說你認為所有的事情都有著完全相同的重要性
這是沒有任何意義的
因為過於膽小謹慎
你這項工作是失敗的
如果所有的bug的地位是相等的
這表示沒有順序
成功是不可能的
如果你在做bug急救過程
你的目標是將
%的bug歸為必須修復
而其他的歸為可能需要修復和不需要修復
做個警戒標記讓自己認真嚴肅的對待你的bug
在你做判斷的時候
需要考慮到目前可以使用的資源(包括時間和人員)和你認為對於一個項目最重要的因素(客戶和業務)
在一個項目的後期
沒有其他的行為能比預先有效的bug管理和公開問題來的有效果
將目標定為將
%的bug歸為必須修復
如果目標沒有達到
%則需要尋找其他類中的bug歸入此類
只有當你覺得這麼做令你痛苦的時候
才能說明你所做的確實是bug歸類
急診室中的醫生沒有辦法搖白旗說不干了
也沒有叫暫停的時間
他們只能不停的將一個接一個的病人區分病情的優先處理順序
既然他們能夠為了人們的生命這麼做
你也能夠為了你的bug這麼做
所以
不要做無用的畏首畏尾的
膽小鬼的歸類
認真起來
強硬起來
領導你的團隊做的更好
最簡單的歸類的規則 三類歸類法的基本規則是
如果一個bug要歸為必須修復類
那麼它必須比其他兩類中的bug更重要
如果一個bug歸為了可能需要修復類
那麼它必須比不需要修復類中的bug更重要
如果一個bug歸為了不需要修復類
那麼它必須比其他兩類中的bug更不重要
所有的bug修復決定都是相關的
沒有例外
定義bug的重要性需要考慮許多因素
這些因素會影響到把bug歸為三類中的不同的類
聰明的團隊會設置一些明確的標記
稱為退出標准(exit criteria)
使得做修復決定變得很簡單
(我會在以後的第二部分的第三等級中解釋退出標准)但是如果爭論時常發生
不用著急
我保證每個分類中的只有很少一部分會引起異議
讓大家把焦點放在那些確定的
大家都同意的bug上
比如在必須修復類中有
個bug屬於大家都已經認定的
在其他的那些需要討論的bug提到議事日程前
這
個bug會花費大家幾天到幾個禮拜的工作時間
必須修復類是程序員們工作的起始入口
如果可能需要修復類中的bug對歸類工作沒有幫助
則沒有必要理會它們
原因是非常簡單的
不用擔心那些可能需要的東西
直到你確定你已經得到了所有你知道的必須得到的東西
(比如
沒有必要考慮餐後的甜點除非你已經吃飽了
)
從可能需要修復類中偷點bug出來一直都是很誘惑人的事情
因為這些bug中可能會有一些很誘惑你的
包括那些使你的團隊覺得苦惱的bug
那些影響到項目中你喜愛的一些性能的bug
或者只是因為修復這些bug修復起來很有意思
但是工作的優先級別標准是修復那些對於項目和客戶來說最重要的bug
一個團隊對一個項目的服務結果是經常隨著有質量的工作和無效的工作而改變
何時開始歸類 通常
一個禮拜一次歸類已經足夠了
每個禮拜一早晨
你招呼相應的人員來進行歸類
然後得出這個星期中使你的團隊工作最有效率的工作計劃
必須修復類中的問題應該合理地分配給整個團隊——無論他們是自願的
或者被指派為特定模塊的程序員並且很樂意做這個工作
如果必須修復類過於龐大
那麼需要對它進行進一步歸類
這個禮拜必須修復的和最終必須被修復的
根據bug報告的速度和客戶或者管理者決定的變化
你可能需要更加經常的進行你的bug歸類工作
第二等級更加巧妙的歸類 除非你一邊編程一邊修復你的bug(很不錯
但很奇怪
這是不普遍的策略)
大多數bug修復都是在項目工作壓力很大的時候進行的
要知道
對於每一個bug
你需要很恰當的數據來讓你
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26370.html
