如何做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管理系统，具备更优秀、顺畅的使用体验，可以说不仅提升了管理效率，还降低了企业成本，非常值得借鉴。