如何做BUG在線管理？

如何做好bug在線管理我們在日常工作中都可能都會遇到軟件bug問題，而bug也是各種各樣的：功能未實現，功能不完整，重複，多餘等；軟件功能和需求規格書中描述的功能不一致；係統不能正常工作，死機，沒反應；邊界條件，在邊界條件時發生的功能缺少或錯誤；界麵、消息、提示不夠準確，不友好；兼容，對某種軟硬件不兼容；當管理團隊收到各部門發出的BUG信息時，首先要按照對工作影響的大小，把BUG的嚴重程度分類：1) 致命：造成係統死機、程序崩潰、死循環、造成係統主要功能無法實現的異常等；產品的關鍵功能和性能不能符合用戶要求。2) 嚴重：重要功能基本實現，但係統不穩定、會導致數據破壞丟失、運行錯誤、操作性錯誤、功能不能實現、功能遺漏、錯誤結果。3)一般：不影響業務的BUG或可避免的BUG，有避免的操作；打印內容、格式錯誤、信息內容錯誤，前台未做輸入限製等問題。4)輕微：操作不方便、視圖不友好、顏色搭配、小問題、錯別字、界麵布局、罕見故障。5)建議：極有必要的建議，仍作為BUG處理。BUG被提交到了BUG係統後，應該先改哪些BUG呢？結合每個BUG的影響程度，來分配每個BUG修改的優先級，BUG優先級定義的規則如下：P0級，必須要盡快修複的BUG，這些BUG直接影響到產品發布進度和最重要的功能使用，這些BUG不修複，將會阻礙其他任務的完成，項目組必須組織人力，馬上進行修複；P1級，在每個裏程碑結束前必須修複的BUG，對修正的要求不是非常迫切，但是必須在裏程碑版本發布之前修複掉；P2級，如果時間允許就修正的BUG，這樣的BUG一般來說不會影響裏程碑版本的使用，是否需要修複根據項目組的時間和資源情況考慮，如果時間允許，就會修正；P3級，很低優先級的BUG，可以根據項目組時間和資源情況，決定是否修複，或遺留到產品發布後作為遺留BUG進行修複，在下一個版本中進行發布。現在稍大點的中小團隊往往讓技術人員開發一套異常簡陋的“bug管理”係統，按照通用的bug管理流程進行係統設計，忽略UI、交互等等一切“次要”元素，保證順暢使用基本職能；這套內部的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狀態，提bug人員更可階段性點擊“bug管理”模塊查看實時狀態 ； 並且無需單獨購置一套bug管理係統，直接在辦公平台流暢解決，降低企業運營成本； 相比自己開發的bug管理係統，具備更優秀、順暢的使用體驗，可以說不僅提升了管理效率，還降低了企業成本，非常值得借鑒。