用于项目规范的错误跟踪器和 wiki [关闭]

Question

小问题

如果您想跳过下面的详细信息，这是一个简短的问题：

我想知道您是否在 bugtracker + wiki 中保持类似的应用规范，以及如何拆分信息以进行良好的管理。我寻找一个简单的解决方案或只是一个开始。

详情

我需要跟踪我想要构建的网络应用程序的功能。因此，我使用 MediaWiki 来收集功能列表。

对于每个功能，我都有一个 wiki 页面，其中包含 FreeMind 格式或纯文本的功能规格、技术规格和各种相关的头脑风暴。此外，我还包括了一系列与它相关的开放式问题作为 TODO 和大量用于各种用例的图像。我发现 wiki 是保存所有这些内容的好地方。

我在 wiki 中有一个页面，其中包含手动嵌入的所有功能，因此我可以在一个页面中以特定格式查看它们。 我在 wiki 中也有一个页面，其中说明了 v1.0 的目标是什么，以及此版本的手动嵌入功能列表。

在错误跟踪器（我使用 ClockingIT）中，我想跟踪任务、错误等，以便构建产品的 1.0 版。

问题

由于我在 wiki 中保留了所有功能（嗯，至少是主要功能），我现在觉得有必要在错误跟踪器中复制它们。此外，在 V1.0 集思广益之后，我意识到我需要在错误跟踪器中跟踪许多较小的功能（它们太小而无法包含在 wiki 中）。

问题是我最终得到了 2 个系统，它们将保留和管理一组功能，并且会出现大量重复项，例如：

• V1.0 中有哪些功能 -> 这作为一个页面存在于 wiki 中，并且 bugtracker 为此保留了一个里程碑；将功能从 v1.0 移动到另一个版本，意味着更新 bugtracker 和 wiki
• 在 bugtracker 中，我将 cmets 添加为我在开发该功能时所做的工作的日志，因此该 wiki 将被弃用，因为部分头脑风暴转移到 bugtracker 中
• wiki 将倾向于包含主要功能，而 bugtracker 将包含次要功能（如添加按钮以显示/隐藏部分或其他内容）...但主要和次要功能之间的限制是非常主观的，并且会倾向于弄得乱七八糟，所以我很难搜索某个功能 - 我必须同时在 wiki 和 bugtracker 中搜索，否则我必须记住它是主要功能还是次要功能

问题

由于我需要保留 wiki 中的功能，因为它是集思广益、信息保存等的绝佳工具。我应该在 bugtracker 中包含哪些内容？我怎样才能有效地分离这两个工具的功能，以便它们彼此很好地集成并且我不会复制任何（或少量）数据？

谢谢！

Answer 1

我使用混合的东西。在 wiki 上有一个需求页面（在其他页面中），它描述了特性和交付数据。某些功能已将解释设计/实现细节的主题分开。需求主题包括错误链接以及错误/功能的简短描述。并非所有功能都反映为错误。如果计划在该版本中修复所有错误，则所有错误都列在当前版本部分中。一个单独的链接转到错误跟踪系统以显示产品的所有错误（错误跟踪器中有许多产品）。所以：

• 所有功能、错误修复都列在特定版本下的要求页面上；
• 错误跟踪系统包含在测试期间发现的错误；
• 没有确切的定义，哪些请求进入错误跟踪器，哪些没有。外部审核者可能会在错误跟踪器中将功能请求报告为工单。
• 关键是将所有要求放在一起，并在每个版本中进行组织。

也许有更好的方法来组织事情，但这个对我来说是最简单的，不需要很多时间。

Answer 2

您需要根据自己的需要进行定制，但您是否看过 trac：http://trac.edgewall.org/。

这将满足您的许多目的。它将错误跟踪器与 wiki 和其他方面结合在一起。

Trac 是用于软件开发项目的增强型 wiki 和问题跟踪系统。它提供了一个 Subversion（或其他版本控制系统）的接口、一个集成的 Wiki 和方便的报告工具。