我正在寻找解释为什么以及何时使用每个系统以及哪些功能区分错误与问题跟踪应用程序的解释.
问题跟踪系统通常会更多地与客户和客户问题集成.一个问题可能是"帮助我安装这个"或"如何让fubar进入flim flam".它们甚至可能是"我需要为您的软件提供评估密钥".
错误跟踪系统可帮助您跟踪程序中的错误或遗漏内容.
在查看网络系统时,通常会有很大的不同,无论是帮助客户还是跟踪软件问题.
从以下示例可以更清楚地看出差异.
假设您今天遇到影响5个客户的生产问题,但是由单个软件缺陷引起.
在您的问题跟踪系统中,您打开了5张故障单并开始跟踪每个客户报告的内容,与他们沟通的内容,应用软件补丁的时间等.您可以为每个客户单独跟踪这类内容.
在您的错误跟踪系统中,您为软件缺陷创建了一个条目,开始跟踪重现步骤,代码更改等内容.
客户问题可以在客户满意时得到纠正,并且可能涉及或可能不涉及修复软件.当bug被修复并重新测试时,它可以被关闭.
两个系统,向外和向内,跟踪两种不同的事物,每种都有自己的生命周期.
像Trac这样的Bug跟踪系统被设计为针对程序固有的每个问题都有一张票,因此通过修改程序来关闭票证.
IssueTrackerProduct等客户支持票证系统旨在为遇到情况的每个客户提供一张票证,因此通过计算该客户的情况(可能通过修改程序)来关闭票证.
有关每个的示例,请参阅维基百科的问题跟踪系统比较
错误是问题的子类.所有错误都是问题,但并非所有问题都是错误.
通常,错误是代码库中的缺陷.这与一个不完整/尚未实现的功能不同,或者像开发人员订票处理技术债务或者关注UI一样更难以确定.从语义上讲,所有这些都是"问题".
一般性问题,当不属于其他类别时,往往是最终用户报告的事物的表示.在大多数系统中,此报告的问题本身作为错误报告处理.我冒昧地说这是一个错误.
棘手的部分是有时多个问题可能与其他问题有关.它可能涉及相同的错误,多个错误,或实际上是一个功能请求.也就是说,问题之间可能存在多对多的关系.
为什么区别很重要？那么,内部有一棵天然树 - 解决一个问题可以间接完成(或有助于完成)一百万个其他问题.它也解决了问题的解决方法.缺陷本身可以通过修复它的代码更改来解决,或者使其无关紧要.如果是用户投诉,可以通过向他们发送解决方案来解决,然后在原始缺陷解决后继续进行跟进.
能够以有用的方式更好地表示和处理这些细微差别的功能实际上是在票务跟踪系统中寻找的.
在某些时候,您所谈论的流程和方法不仅仅是实际的票务系统,事实的名称应该开始变得无关紧要.主流和面向企业的解决方案倾向于在像ITIL这样的流行系统上运行,但是如果团队中的每个人都对客户服务需求有很好的理解,那么您就可以获得特别的东西.我个人将其视为瀑布(ITIL)与敏捷(DevOps)情况.
它只是语义学.错误是一个问题,一个问题是可以做的.它们在其他方面大致相同.
京公网安备 11010802040832号 | 京ICP备19059560号-6 