如何在FogBugz 6中表示功能与任务?

8
在FogBugz 6中,如何表示“特性”和“任务”的概念?根据Fog Creek Software(制造FogBugz的公司)所有者Joel Spolsky的定义,特性基本上是一个用户可见的能力。为了估计实现一个特性所需的时间,开发人员应该将实现分解成短期任务(最多2天),以确保他们考虑到每一步。
FogBugz只有案例。我无法确定它们是否应该对应于特性或任务。一些FogBugz文档表明,每个案例都是一个任务,这很好,只是没有办法将给定特性的所有任务分组在一起。这尤其奇怪,因为在FogBugz 6之前,Joel建议使用电子表格来分组每个特性的所有任务。但他自己的软件似乎并没有有意义地支持该分组。
我意识到我引用的Joel文章包括免责声明,指向后来的文章。然而,后来的文章并没有解决这个问题,事实上它根本没有讨论特性与任务的区别,这令人惊讶,因为Joel在第一篇文章中对这些概念进行了很好的倡导。

Fogbugz 7中的功能集以多种不同的方式解决了这个问题。 - Bob Cross
6个回答

8

对于FogBugz 6.0及以前版本:

为每个工作项目(任务)创建一个案例。FogBugz称之为“特性”,只是为了区别于缺陷,但您确实需要为每个任务创建一个案例。

将一堆任务分组的最佳方法是创建一个发布(Fix-For),并将所有任务分配到该发布中。


那么,如果您在下一个版本中有10个新功能,每个功能需要5个任务来实现,您建议创建10个发布版本吗?我该如何定义这些功能/"发布版本"是要包含在即将发布的版本中的? - AviD
另一方面,我之前考虑过使用区域来解决这个问题,但这也有缺点,并且不太容易添加更多功能... 无论如何,我同意原帖作者的观点,这是一个缺失的功能,能够将任务分组在一起(甚至可能超过一级?) - AviD
@AviD,我在下面的答案中尝试回答了你的问题:https://dev59.com/d0XRa4cB1Zd3GeqPpjCn#127643 - Bob Cross
开心!由于同等评级答案的半随机排序,我的答案有时会出现在Joel的上面。个人得到了证明!;-) - Bob Cross

8

回应AviD对Joel的评论/问题:

所以,如果下一个版本有10个新功能,每个功能需要5个任务来实现,你建议创建10个发布版本吗?那我如何定义这些功能/“发布版本”将包含在即将发布的版本中呢?

这是我们在开发过程中处理这个具体问题的方法:

  1. 首先,我们制定了一个规律的发布计划:每月内部发布和每季度外部发布。这个计划从不改变,但任务分配/功能完成会发生变化。这在简化我们之间的人际交流方面非常重要:不要试图与日历争论。
  2. 主要功能(例如您提到的“10个新功能”)被转换为案例(例如,案例101到案例110)。
  3. 每个作为主要功能子组件的任务也会被创建为一个子案例,并描述了这个工作块是如何成为更大画面中的重要部分的。以前,在Fogbugz 6中,我们使用“另请参阅”功能,让它为我们搜索文本(例如,“这是案例101的子组件”)。虽然效果相同但不够美观。
  4. 现在,我们已经将工作细分到最有用的级别,把实际的开发人员引入讨论。每个任务和主要功能都被单独分配给特定的开发人员。
  5. 开发人员通过选择他们认为可以承诺的适当的内部发布日期来确定何时可以完成分配给他们的工作。
  6. 此时,我们对每个版本大致了解将完成什么。随着工作人员实际估计完成工作所需的时间,进一步的细化会继续进行,从而实现基于证据的调度等。
对于AviD的问题,他可以通过上述步骤5解决发布分配问题。
然而,我认为点6最有趣,因为那是你真正得到一个可靠的时间表的地方。例如,如果开发人员难以估算较大的任务,他们会更进一步地将其细分为子任务。请注意,我的“最高效用级别”评估可能会与真正需要完成工作的人不同(也许差异很大)。
这也是开发人员可以联系其他人并说:“我可以完成大部分工作,但如果X人能帮我完成这个小任务Y,那会非常有帮助。” 这实际上是我获取大多数开发任务的时间:在此过程中,我个人会在多个位置进行,从大规模计划会议到没有其他人有时间做的琐碎任务。
PS:把这个答案评分高于Joel是我的个人目标.... ;-)
PPS:我的原始回应现已被Fogbugz 7的美妙子任务所取代。项目经理喜欢那些报告。

1
@dodgio,谢谢 - Fogbugz 7的答案细节有些变化,但主题仍然相同。 - Bob Cross
谢谢Bob,直到现在我才看到这个消息,但正如你所说,在FB7中要简单得多。 - AviD
@AviD,我同意。子任务也会导致在大纲视图中有一个隐含的总估计完成超级任务。这会引发一些很快的问答环节:“你真的可以在三天内交付一个完全经过测试、文档齐全并且准备好发布的功能集X吗?”“哦,抱歉,我忘记了这个部分和那个部分以及其他部分...”。;-) - Bob Cross

5

1

我们使用多个项目的组合来实现您的分组目标。我们通常还会设置一个项目“停车场”维基,其中可以放置开发案例链接、技术文档、系统要求、用户文档、外部资源链接等等。它为与该项目相关的所有内容提供了一个很好的“一站式”服务。

作为维基的一部分,我们将设置两个特定的项目。一个与大型总体目标/概述有关,类似于您的项目管理图表/等等。另一个与每个功能的开发任务有关,因为它们被分解成更小、更易管理的块。然后,正如之前提到的那样,您可以使用用例链接来引用另一个项目中的“主”用例,以及引用项目维基本身,以便您可以快速轻松地返回到所有方便地位于一个地方的项目相关信息。

您可以使用FogBugz实现各种不同的组织结构,只是有时需要以稍微不同的方式处理事情,以满足每一种情况。

希望这有所帮助。


0

哈哈,那篇文章有免责声明,但我明白你的意思。

我们使用Fogbugz,我知道唯一的“特性”是在类别下,我不认为您可以将其与子任务关联。

如果您只想在用例文本中引用它,可以键入“案例N”作为此任务的功能。

那种东西听起来更像是项目管理领域,而不是用于跟踪错误的软件。


不管名字如何,Fog Creek(和Joel)确实将Fogbugz作为项目管理软件而非仅仅是“缺陷跟踪器”来展示。因此似乎还有一些核心的项目管理功能尚未完善...期待FB 7的发布! :) - AviD

0

这是一个好问题,我自己也曾经问过。我们目前在一个由5名开发人员组成的小组中测试使用FogBugz 45天,并且我们目前为主要功能创建“发布”。实际上,我们不会立即发布它,而是在准备好多个版本后一起发布。

FogBugz中应该有某种高级任务分组功能。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接