如何在 FogBugz 6 中表示功能与任务？
在 FogBugz 6 中，如何表示“功能”与“任务”的概念？ 正如由 Fog Creek Software（FogBugz 的开发者）所有者 Joel Spolsky 定义的，特性本质上是用户可见的能力。 要估计实现功能的时间，开发人员应将实现分解为短任务（最多 2 天），以确保他们考虑每个步骤。
FogBugz 只有案例。 我无法判断它们是否应该对应于功能或任务。 一些 FogBugz 文档 表明每个案例都是一个任务，其中很好，只是没有办法将给定功能的所有任务分组在一起。 这尤其奇怪，因为在 FogBugz 6 之前，Joel 提倡使用电子表格来对每个功能的所有任务进行分组。 但他自己的软件似乎并没有有意义地支持这种分组。
我意识到我引用的乔尔文章包含指向后续文章的免责声明。 然而，后面的文章并没有解决这个问题，事实上它根本没有讨论功能与任务，考虑到 Joel 在第一篇文章中对这些概念的大力倡导，这是令人惊讶的。
In FogBugz 6, how do I represent the concepts of a "feature" versus a "task"? As defined by Joel Spolsky, the owner of Fog Creek Software (which makes FogBugz), a feature is essentially a user-visible capability. To estimate the time to implement a feature, the developer should break the implementation into short tasks (2 days max) to ensure they think about each step.
FogBugz has only cases. I can't tell whether they're supposed to correspond to features or tasks. Some FogBugz documentation indicates that each case is a task, which is fine except there is no way to group all the tasks for a given feature together. This is especially odd given that, before FogBugz 6, Joel advocated using a spreadsheet with that grouped all the tasks for each feature. But his own software doesn't appear to meaningfully support that grouping.
I realize that the Joel article I reference includes a disclaimer pointing to a later article. However, the later article does not settle this issue, in fact it doesn't discuss features versus tasks at all, which is surprising given how well Joel advocates for those concepts in the first article.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可能会更幸运地在 FogBugz 论坛 中提出问题
You may have better luck asking your questions in the FogBugz Discussion Forum
我们使用项目组合来实现您的分组目标。 我们通常还设置一个项目“停车”Wiki，其中可以放置开发案例、技术文档、系统要求、用户文档、资源外部链接等的链接。 它为与该项目相关的一切提供了良好的“一站式服务”。
作为该 Wiki 的一部分，我们将设置两个特定项目。 一个与大的总体目标/大纲相关，类似于可能对应于您的项目管理图表/诸如此类的内容。 一个与每个功能的开发任务相关，因为它们被分解为更小、更易于管理的块。 然后，正如前面提到的，您可以链接到引用其他项目中的“主”案例以及引用项目 Wiki 本身，以便您可以快速轻松地返回到所有与项目相关的信息，这些信息可以方便地在一个地点。
您可以使用 FogBugz 完成一堆不同的组织结构，有时您只需要稍微不同地处理事情，以便应对每种情况。
希望有帮助。
We use a combination of projects in order to accomplish your grouping goals. We also commonly setup a project "parking" Wiki where links to development cases, technical documentation, systems requirements, user documentation, external links to resources etc. can all be placed. It provides a good "one-stop-shop" for everything related to that project.
As part of that Wiki, we would then setup two specific projects. One in relation to the large overall goals/outlines similar to what might correspond to your Project Management charts/whatnot. One in relation to the development tasks of each feature as they are broken down into the smaller and more manageable chunks. You can then, as was mentioned use case linking to both reference the "master" cases in the other project as well as reference the project Wiki itself so that you can quickly and easily get back to all of your project related information which is conveniently in one spot.
You can accomplish a pile of different organizational structures using FogBugz, you just have to approach things a little differently sometimes in order to hit each and every situation.
Hope that helps.
回应 AviD 对 Joel 的评论/问题：
以下是我们在开发过程中处理这个具体问题的方法：
不过，对于 AviD 的问题，他将通过上述步骤 5 解决发布分配问题。
然而，我认为第 6 点是最有趣的，因为这是你真正获得可靠时间表的地方。 例如，如果开发人员难以估计较大的任务，他们会进一步将其分解为子案例。 请注意，我对“最佳有用程度”的评估可能与真正需要完成工作的人有所不同（也许很大）。
这也是开发人员可以联系其他人并说“我可以完成大部分工作，但如果 X 可以帮助我完成 Y 的这一小部分，那真的会有帮助。” 这实际上是我获得大部分开发任务的地方：在此过程中，我亲自坐在多个位置，从大型规划会议到其他人没有时间做的小繁琐任务。
PS：个人目标是让这个答案的评分高于 Joel 的......;-)
PPS：我最初的反应现在被事件所克服，因为 Fogbugz 7 有可爱的子任务。 项目经理喜欢这些报告。
Responding to AviD's comment/question to Joel:
Here is how we dealt with this specific problem in our development process:
For AviD's question, though, he would have the release-assignment problem solved by step 5 above.
However, I think point 6 is the most interesting as that's where you really get a solid schedule. For example, if developers are having trouble estimating a larger task, they break it down into sub-cases even further. Notice how my assessment of "finest level of usefulness" can differ (perhaps greatly) from the person who really needs to get the work done.
This is also a time when a developer can reach out to someone else and say "I can do most of this but it would really help if person X could help me with this little piece Y." This is actually where I get most of my development tasking: I personally sit in multiple places during this process, from large-scale planning meetings to little fiddly tasks that no-one else has time to do.
PS: Making it a personal goal to get this answer rated higher than Joel's.... ;-)
PPS: My original response is now overcome by events since Fogbugz 7 has lovely sub-tasks. Program managers love those reports.
对于 FogBugz 6.0 及更早版本：
为每个工作项（任务）制定案例。 FogBugz 将它们称为“功能”，只是为了将它们与错误区分开来，但您确实希望每个任务都有一个案例。
对一堆任务进行分组的最佳方法是创建一个版本 (Fix-For) 并将所有任务分配给该版本。
For FogBugz 6.0 and earlier:
Make a case for each work item (task). FogBugz calls them "Features," only to distinguish them from bugs, but you do want one case for each task.
The best way to group a bunch of tasks is to make a Release (Fix-For) and assign all of the tasks to that release.
哈哈，那篇文章有免责声明，但我明白你在说什么。
我们使用 Fogbugz，据我所知，唯一的“功能”位于类别下，我认为您不能将其与子任务关联起来。
如果您只想在案例文本中引用“案例 N”，则可以输入此任务的功能。
这类东西听起来更多地属于项目管理领域，而不是用于跟踪错误的软件。
haha, that article has a disclaimer, but I understand what you are saying.
We use Fogbugz and the only 'Feature' that I am aware of is under category and I don't think you can associated it with sub-tasks.
You can type in 'Case N' is the feature for this task if you just wanted to reference it in the case text.
That kind of stuff sound like is lies more in the project management domain instead of software used to track bugs.
这是个好问题，我自己也问过。。
目前，我们由 5 名开发人员组成的小组对 Fogbugz 进行了 45 天的测试，目前我们正在为主要功能创建一个“版本”。 事实上我们并不发布它，而是在某些东西准备好时一起发布多个版本。
在fogbugz 中肯定应该有某种高级任务分组。
thats a good question, i have asked that myself, too..
we currently test-drive fogbugz for 45 days in a group of 5 developers, and we currently create a "release" for major features. in fact we do not release it, but multiple releases together when something is ready.
there should definately be some sort of advanced task grouping in fogbugz.