在FogBugz 6中，我如何表示"功能"与"任务"的概念？根据Fog Creek软件公司(生产FogBugz)的所有者Joel Spolsky的定义，功能本质上是用户可见的功能。为了估算实现功能所需的时间，开发人员应将实现分解为简短的任务(最多2天)以确保他们考虑每个步骤。

FogBugz只有案例。我不知道它们是否应该与功能或者任务相对应。一些FogBugz文档指出，每种情况都是一个任务，这很好，除了无法将给定功能的所有任务组合在一起。考虑到在FogBugz 6之前，Joel提倡使用电子表格来对每个功能的所有任务进行分组，因此这尤其奇怪。但是他自己的软件似乎并不能有效地支持该分组。

我意识到我引用的Joel文章中有一个免责声明指向后面的文章。但是，后面的文章并没有解决这个问题，实际上，它根本没有讨论功能与任务，考虑到Joel在第一篇文章中对这些概念的拥护程度，这令人惊讶。

解决方案

哈哈，该文章有免责声明，但我理解意思。

我们使用Fogbugz，据我所知，唯一的"功能"在类别下，我认为我们无法将其与子任务相关联。

如果我们只想在案例文本中引用"案例N"，则可以输入"案例N"。

听起来这类东西更多地位于项目管理领域，而不是用于跟踪错误的软件。

多数民众赞成在一个很好的问题，我也问过自己..
我们目前由5个开发人员组成的小组测试了45天的fogbugz，并且我们目前针对主要功能创建了一个"发行版"。实际上，我们不释放它，而是在准备就绪时一起释放多个。

在Foxbugz中肯定应该有某种高级任务分组。

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

So, if you have 10 new features coming
  in the next version, with each feature
  needing 5 tasks to implement, you
  recommend creating 10 releases? And
  how do I define that these are the
  features/"releases" that are to be
  included in the upcoming release?

这是我们在开发过程中如何处理此特定问题的方法：

• 首先，我们制定了定期发布时间表：每月内部发布和季度外部发布。此计划永远不会更改，但任务分配/功能完成不会更改。这对于简化我们的人与人之间的交流非常重要：不要试图与日历争论。
• 主要功能(在示例中为" 10个新功能")变成了案例(例如案例101到案例110)。
• 作为主要功能的子组件的每个任务也将作为子案例创建，并描述使此工作块成为大图重要部分的原因。以前，在Fogbugz 6中，我们通过允许其为我们搜索文本来使用"另请参阅"功能(例如，"这是案例101的子组件")。实际上，这是同一件事，但不那么美观。
• 既然我们已经将工作分解到最大程度的有用性，那么我们将实际的开发人员纳入讨论范围。每个任务和主要功能都分别分配给特定的开发人员。
• 开发人员通过选择他们认为可以承诺的适当内部发布日期来确定何时可以完成分配的工作。
• 在这一点上，我们对每个版本将要完成的工作有一个粗略的草图。随着工作人员实际估算工作所需的时间，启用基于证据的计划等，进一步的改进将继续进行。

但是，对于AviD的问题，他将通过上面的第5步解决发布分配问题。

但是，我认为第6点是最有趣的，因为这是我们真正获得固定时间表的地方。例如，如果开发人员在估计更大的任务时遇到麻烦，则可以将其进一步细分为子案例。请注意，我对"最大程度的有用性"的评估与真正需要完成工作的人之间的差异(也许很大)。

这也是开发人员可以与其他人联系并说"我可以做的大部分事情，但是如果X人可以帮助我解决这个小小的问题，那将真的有帮助"。实际上，这是我完成大部分开发任务的地方：在此过程中，我个人坐在多个地方，从大型计划会议到其他人没有时间做的小巧的任务。

PS：将这个答案的评分高于Joel的评分是个人目标。

PPS：由于Fogbugz 7有可爱的子任务，现在我的最初反应已被事件克服。计划经理喜欢这些报告。

我们可能有更好的机会在FogBugz论坛上提问

我们使用项目组合来完成分组目标。我们通常还会建立一个项目" parking" Wiki，在其中可以放置到开发案例，技术文档，系统要求，用户文档，外部资源链接等的链接。它为与该项目相关的所有事情提供了一个很好的"一站式服务"。

作为该Wiki的一部分，我们将设置两个特定项目。与大型总体目标/大纲相关的一项，可能与项目管理图表/其他类似。与每个功能的开发任务相关的任务，因为它们被分解为更小且更易于管理的块。然后，如前所述，用例链接既可以引用另一个项目中的"主"用例，也可以引用项目Wiki本身，以便我们可以快速轻松地返回所有与项目相关的信息，这些信息可以方便地在一个点。

我们可以使用FogBugz来完成一堆不同的组织结构，只是为了应付各种情况有时有时需要采取一些不同的方法。

希望能有所帮助。

对于FogBugz 6.0及更早版本：

为每个工作项(任务)辩护。 FogBugz称它们为"功能"，只是为了将它们与错误区分开来，但是我们确实希望每种情况都使用一种情况。

对一堆任务进行分组的最佳方法是制作一个发行版(Fix-For)，并将所有任务分配给该发行版。