在 FogBugz 6 中，我如何表示“功能”与“任务”的概念？正如Fog Creek Software（制造 FogBugz）的所有者Joel Spolsky 所定义的，功能本质上是一种用户可见的能力。为了估计实现某个功能的时间，开发人员应该将实现分解为简短的任务（最多 2 天），以确保他们考虑每个步骤。
FogBugz 只有案例。我不知道它们是否应该对应于功能或任务。 一些 FogBugz 文档表明每个案例都是一个任务，这很好，除非无法将给定功能的所有任务组合在一起。考虑到在 FogBugz 6 之前，Joel 提倡使用将每个功能的所有任务分组的电子表格，这尤其奇怪。但他自己的软件似乎并没有有意义地支持这种分组。
我意识到我引用的 Joel 文章包含指向稍后文章的免责声明。然而，后面的文章并没有解决这个问题，事实上它根本没有讨论特性与任务，考虑到 Joel 在第一篇文章中对这些概念的倡导程度，这令人惊讶。
那么，如果您在下一个版本中有 10 个新功能，每个功能需要 5 个任务来实现，您建议创建 10 个版本吗？我如何定义这些是即将发布的版本中包含的功能/“版本”？
以下是我们在开发过程中如何处理这个特定问题：
不过，对于 AviD 的问题，他将通过上面的第 5 步解决发布分配问题。
但是，我认为第 6 点是最有趣的，因为这是您真正获得稳定时间表的地方。例如，如果开发人员在估计更大的任务时遇到困难，他们会进一步将其分解为子案例。请注意，我对“最佳有用性”的评估与真正需要完成工作的人有什么不同（可能有很大差异）。
这也是开发人员可以联系其他人并说“我可以完成大部分工作，但如果 X 可以帮助我完成这个小部分 Y，那将真的很有帮助。” 这实际上是我完成大部分开发任务的地方：在这个过程中，我个人坐在多个地方，从大型计划会议到其他人没有时间做的小任务。
PS：将这个答案的评分高于乔尔的评分作为个人目标.... ;-)
PPS：我最初的反应现在被事件所克服，因为 Fogbugz 7 有可爱的子任务。项目经理喜欢这些报告。
对于 FogBugz 6.0 及更早版本：
为每个工作项（任务）创建一个案例。FogBugz 称它们为“功能”，只是为了将它们与错误区分开来，但您确实希望每个任务都有一个案例。
对一堆任务进行分组的最佳方式是创建一个发布（Fix-For）并将所有任务分配给该发布。
在FogBugz 论坛中提问可能会更好
我们使用项目组合来实现您的分组目标。我们通常还会设置一个项目“停车”Wiki，其中可以放置指向开发案例、技术文档、系统要求、用户文档、资源的外部链接等的链接。它为与该项目相关的所有内容提供了一个很好的“一站式商店”。
作为该 Wiki 的一部分，我们将设置两个特定项目。一个与大型总体目标/大纲相关，类似于可能对应于您的项目管理图表/诸如此类的内容。一个与每个功能的开发任务有关，因为它们被分解成更小且更易于管理的块。然后，您可以，如前所述，用例链接既可以引用另一个项目中的“主”案例，也可以引用项目 Wiki 本身，以便您可以快速轻松地返回所有与项目相关的信息，这些信息在一处。
您可以使用 FogBugz 完成一堆不同的组织结构，您只需有时以不同的方式处理事情，以应对每种情况。
希望有帮助。
哈哈，那篇文章有免责声明，但我明白你在说什么。
我们使用 Fogbugz，我知道的唯一“功能”在类别下，我认为您不能将其与子任务相关联。
如果您只是想在案例文本中引用它，您可以输入“案例 N”是此任务的功能。
这种听起来更像是在项目管理领域，而不是用于跟踪错误的软件。
这是一个很好的问题，我自己也问过这个问题。我们目前在 5 名开发人员的小组中测试了fogbugz 45 天，并且我们目前为主要功能创建了一个“发布”。事实上，我们并没有发布它，而是在准备好时一起发布多个版本。
在fogbugz 中肯定应该有某种高级任务分组。