如何在FogBugz 6中表示功能和任务？

在FogBugz 6中,我如何表示"特征"与"任务"的概念？正如Fog Creek Software(制作FogBugz)的所有者Joel Spolsky所定义的,一个功能本质上是一个用户可见的功能.为了估计实现功能的时间,开发人员应该将实现分解为短任务(最多2天),以确保他们考虑每个步骤.

FogBugz只有案例.我不知道它们是否应该与功能或任务相对应. 一些FogBugz文档表明每个案例都是一个任务,除了没有办法将给定特征的所有任务分组在一起之外,这是很好的.这一点特别奇怪,因为在FogBugz 6之前,Joel主张使用电子表格将每个功能的所有任务分组.但是他自己的软件似乎并不能有意义地支持这种分组.

我意识到我引用的Joel文章包括一个指向后续文章的免责声明.然而,后面的文章没有解决这个问题,事实上它根本没有讨论功能与任务,这是令人惊讶的,因为Joel在第一篇文章中提倡这些概念.

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

因此,如果您在下一个版本中有10个新功能,每个功能需要执行5个任务,您建议创建10个版本吗？我如何定义这些是即将发布的版本中包含的功能/"发布"？

以下是我们在开发过程中处理此特定问题的方法:

首先,我们制定了定期发布计划:每月内部发布和季度外部发布.此计划永远不会更改,但任务分配/功能完成.这在简化人际交流方面非常重要:不要试图与日历争论.

主要功能(在您的示例中为"10个新功能")将变为案例(例如,案例101至案例110).

作为主要特征的子组件的每个任务也被创建为子案例,其中描述了使这一块工作成为更大图片的重要部分的原因.以前,在Fogbugz 6中,我们使用"See also"功能,允许它为我们搜索文本(例如,"这是案例101的子组件").这实际上是相同的,但不太美观.

现在我们已经将工作分解为最高级别的有用性,我们将实际开发人员纳入讨论.每个任务和主要功能都单独分配给特定的开发人员.

开发人员通过选择他们认为可以承诺的适当内部发布日期来确定何时可以完成分配的工作.

在这一点上,我们粗略地概述了每个版本将要完成的工作.随着工作人员实际估计他们完成工作所需的时间,实现基于证据的安排等,继续进一步完善.

但是,对于AviD的问题,他将通过上面的步骤5解决发布分配问题.

但是,我认为第6点是最有趣的,因为那是你真正得到一个可靠的时间表.例如,如果开发人员在估算较大任务时遇到问题,他们会进一步将其分解为子案例.请注意我对"最佳实用程度"的评估可能与真正需要完成工作的人有所不同(可能很大).

这也是一个开发人员可以与其他人联系并说"我能做到这一点但是如果X人可以帮我解决这个小片Y会真的有帮助的时候".这实际上是我获得大部分开发任务的地方:在这个过程中我个人坐在多个地方,从大规模的计划会议到没有人有时间做的小任务.

PS:将这个答案评为高于Joel的......是个人的目标...... ;-)

PPS:由于Fogbugz 7有可爱的子任务,我的原始回应现在被事件所克服.项目经理喜欢这些报道.

对于FogBugz 6.0及更早版本:

为每个工作项(任务)创建一个案例.FogBugz称它们为"特征",只是为了将它们与错误区分开来,但你确实需要为每个任务分配一个案例.

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

您可以在FogBugz论坛中提出更好的问题