应该为错误重新打开案例,还是应该以新案例打开错误?


9

目前,在我的工作地点,我们使用FogBugz来管理我们不同Web应用程序的所有功能和错误。

当要将新功能添加到我们的一个Web应用程序中时,将创建一个新的Case。例如“创建CSV上传表单”。

然后,我处理案件,记录我花在该案件上的时间。完成此案例后,我将对其进行解决,然后将其分配回开箱器(通常是项目经理),然后由其关闭该案例。

如果该功能有任何错误,则我的项目管理器将重新打开该案例,并将其归还给我,并附上一系列漏洞的要点。

在我看来,我认为这些指向项目符号的错误应作为单独的错误案例打开,以便可以更轻松地对其进行跟踪,而不会因原始功能案例说明而混乱。

我的经理们不同意我的说法,如果在一种情况下全部花费在该功能上,则更容易计算出该功能所花费的总时间。

此外,他们认为,这对于我们的客户而言不会造成太大的混淆,因为该功能仅具有1个案例编号参考。但是,我要强调指出,这些错误应作为单独的案例处理,因为这是原始案例的完成后。

我是否正确地指出应该重新打开Bug作为新案例?每种管理方式的利弊是什么?



2
我不认为这是一个真正的重复,类似,但是有一个重要的区别:这是关于正在实施的一项新功能以及相对较短的往返于开发人员的往返时间。该答案 威力(也可能不)是相似的,但问题是不同的
约阿希姆·绍尔

1
但是也许我读错了。是否在发布之前由质量检查人员发现错误?还是这是“几个月后”的情况?
约阿希姆·绍尔

2
@Curt:这并没有真正改变他除非确定自己已经完成(除非您对此定义是什么)才应该关闭门票的事实。
约阿希姆·绍尔

3
你可以打开主案件的儿童案件的跟踪,他们都将与主要上市的情况下,当你进行搜索
JF翁

Answers:


10

您和您的经理都有充分的理由来应对你们每个人都喜欢的方式,并且没有真正的妥协的必要。有一种对我有效的解决方案,可以解决这两个问题。

对于像你这样的情况下,我使用高级别任务/低级别的子任务的方法(概念,我从挑选JIRA,不能告诉,如果FogBugz的支持明确看起来像它)。这样,“面向客户”的项目符号列表可以执行高级任务,而对我来说很重要的“开发人员迭代”则反映在子任务中。

当高级任务“重新打开”时,我创建一个新的子任务来跟踪为self增加的工作量。

http://i.stack.imgur.com/ng4jn.jpg

这样一来,开发人员就可以清楚地反映出功能说明所传递的所有排列,变态和曲折,同时仍允许经理将其按需呈现给客户。顺便说一下,完美的演示文稿对我作为开发人员来说具有其价值-因为让客户更容易阅读它有助于获得更准确的调整。

当然,在功能实现所花费的时间比最初预期的时间长得多的情况下,这自然也有明确的理由。

至于每个任务或子任务的时间跟踪-因为JIRA允许将子任务跟踪包括到更高级别的摘要中,所以对于经理来说,我可以跟踪子任务中的时间。但是,即使不是这种情况,我也可以正式跟踪“父”任务中的时间-在这种情况下,我将仅使用子任务注释来说明在特定迭代上花费了多少时间。


3
FogBugz支持子任务-为每个错误创建一个案例,然后将原始案例分配为每个错误案例的父对象。它甚至可以汇总每个错误加上父项花费的总时间,同时还可以分别跟踪每个错误案例花费的时间。
Tacroy

+1感谢gnat,这对于我在论点中使用单独的bug案例以及如何将它们仍然与原始功能联系在一起提供了极大的帮助
Curt 2012年

@祝你好运。请记住,这与正确选择战斗有很大关系。无论他们坚持要执行“父项任务”是什么,都不要太努力-让他们挂在自己的绳子上。您的子任务是您的堡垒-这些应该是您的防线。顺便说一句,您可能真的需要为其辩护-事实是您的经理无法找到解决方案,这使我想知道他们是否有足够的资格来跟踪开发人员的工作
gnat 2012年

7

如果这一切在功能发布给客户之前发生,那么只需一个案例。这里的论点是,只有通过质量检查并准备好发布,案件才能真正完成。其他好处-计费和最终用户参考的单个案例编号是有效且重要的。

释放该功能并发现错误后,应将其作为问题跟踪软件中的新问题引发。


5

我完全同意您的看法,FogBugz也完全同意-这就是为什么它为错误和功能定义了不同的类别的原因。FogBugz并非旨在跟踪时间使用的工具。这是引入基于证据的计划的偶然副产品。

可以将已完成功能的错误链接到该功能的主要情况(在FogBugz中,通过使用标签名称或交叉引用,或者通过使其成为小写情况)。我可以看到,对于您的PM来说,要在几种情况下合并信息还需要做更多的工作,但是通常能够区分原始开发时间和维护时间(尤其是固定价格合同的时间)也很有意义。如果将所有内容放到一个案例中,您将失去执行此操作的能力。


3

我认为,一旦关闭票证,票证应保持关闭状态,无论如何,您的错误跟踪器都应该能够链接到其他情况。我会尝试指出,与您描述的方法相比,创建新的bug并将它们链接到原始案例提供了更好的好处。

  • 客户仍然可以使用一个参考号,其中包含每个错误的链接。
  • 每个错误的状态都可以单独跟踪,从而可以更好地确定优先级和状态报告。
  • 拥有单独的错误将使您的经理可以将花费在错误上的时间与花费在开发新功能上的时间相比较,并且仅需最小的额外努力即可获得与变更和变更开发相关的所有错误的总数。
  • 分离错误使您的经理可以更轻松地收集其他指标,例如错误总数,每次错误修复的平均时间,已关闭/进行中/已修复错误的比率。
  • 每个错误使用不同的案例可以更好地将任务分配给所有开发人员,并使每个工作人员对自己的工作负责,或者允许这种可能性,如果以后雇用更多的开发人员。

当前设置的唯一优点是,对于不是系统主要用户的人员来说,它非常简单。Bug跟踪器的目的是使开发人员可以在一个地方报告关于Bug的所有信息,而且该信息恰好足以让其他人看到进度,您的当前系统似乎破坏了它的几乎所有部分。


我大体上同意“关闭的票证应保持关闭”位,但是总是有例外,例如重新引入错误(如回滚可能发生)(或更糟的是,如果项目的一部分丢失并需要恢复)从备份)。
zzzzBov 2012年

@zzzzBov是非常重要的例外,如果您发现自己处于这个位置,我怀疑此时如何处理错误跟踪是一个问题。
Ryathal

1

是否在将产品“运送/发布”给客户之前或之后发现错误?

如果是在发行前,则应根据原始票证跟踪错误。

如果是在发行后,则每个错误都应该是其自己的凭单。


我们将应用程序复制到客户端可以访问该站点的开发服务器。有时,错误是在内部发现的,有时是由客户端发现的。您是否建议在内部(由PM)发现的错误意味着应该重新打开外壳并将该错误附加到外壳/票证的底部?
Curt 2012年

如果发现这些错误是在发行前发现的,则应将其视为未完成功能。请参阅ChrisF的答案。
科林D

1

在我工作的地方,只有质量检查人员才能结案。我们有用于代码审查,经过工程师测试和向利益相关者演示的复选框(在您的情况下是项目经理)。如果质量检查小组看到一个标有“完成”的案例,而该案例没有标记所有这些字段,则他们会将其标记为“未完成”,然后将其发送回给我们。

一旦案件通过所有这些阶段,并且质量检查结束了案件,他们发现的任何新问题都将记录为错误。

这个系统似乎对我们来说运作良好。


0

我认为您可以双向争论。我将尝试与总理坐下来,向您解释为什么您认为离散问题会帮助您。我个人希望每个待办事项都应该是自己的票,但我可以理解他为什么要这样。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.