我们公司一直在使用JIRA作为需求跟踪工具和缺陷跟踪器，当我们一次只开展一个项目时效果还不错。
现在我们有一个情况，我们有三个不同的项目提案，它们的需求部分重叠（例如，需求1适用于A和B项目，需求2适用于B和C项目等）。我希望能够为每个需求输入一个单独的JIRA问题，但似乎不可能，因为JIRA问题和项目之间是一对一的关系。
是否有人发现了在JIRA中实现这一点的方法，或者通过与JIRA集成的其他工具？
6个回答
8
虽然没有唯一正确的答案，但我可以提供一个想法。我不知道您的工作流程有多少信息，但您提到了项目建议书。因此，我假设A、B和C项目处于早期阶段。需求收集等工作还未完成，也没有出现任何错误。
设置一个单独的JIRA项目，比如“早期需求”。将A、B和C项目的所有需求放入该JIRA项目中。为了允许需求与实际项目之间的多对多关系，设置一个类型为“多选框”或等效的自定义字段，并将“项目A”、“项目B”和“项目C”配置为其值。对于任何需求，您都可以检查它适用于哪个项目。
现在——我在这里做更多的假设——假设一些建议进展顺利，而一些则失败了。您需要一个过程来a）提取所有实际项目A的需求并将其放入新创建的A JIRA项目中——这可以通过搜索和批量克隆问题来完成；b）清除所有没有关联活动项目的需求——搜索和批量删除。
注意：如果您需要与不同客户共享需求，情况可能会变得棘手。权限是按JIRA项目和问题类型配置的。
话虽如此，JIRA缺乏良好的需求管理功能，例如基线和可追溯性。但它可能适用于仅收集数据以进行进一步工作的情况。
设置一个单独的JIRA项目，比如“早期需求”。将A、B和C项目的所有需求放入该JIRA项目中。为了允许需求与实际项目之间的多对多关系，设置一个类型为“多选框”或等效的自定义字段，并将“项目A”、“项目B”和“项目C”配置为其值。对于任何需求，您都可以检查它适用于哪个项目。
现在——我在这里做更多的假设——假设一些建议进展顺利，而一些则失败了。您需要一个过程来a）提取所有实际项目A的需求并将其放入新创建的A JIRA项目中——这可以通过搜索和批量克隆问题来完成；b）清除所有没有关联活动项目的需求——搜索和批量删除。
注意：如果您需要与不同客户共享需求，情况可能会变得棘手。权限是按JIRA项目和问题类型配置的。
话虽如此，JIRA缺乏良好的需求管理功能，例如基线和可追溯性。但它可能适用于仅收集数据以进行进一步工作的情况。
- sereda
1
谢谢，这是一个有趣的想法；我更喜欢将需求问题与相关项目一起处理，但我会看看你的建议如何运作。 - gareth_bowles
6
我们使用Jira的“重复”或“关联到”功能。
因此，在每个项目中提出一个问题，但是将它们相互关联。这样，您可以拥有一个问题由一个项目“拥有”，并且在每个测试更改后可以关闭所有相关项目。
如果在您的项目设置中有意义，甚至可以使用“依赖”链接。
因此，在每个项目中提出一个问题，但是将它们相互关联。这样，您可以拥有一个问题由一个项目“拥有”，并且在每个测试更改后可以关闭所有相关项目。
如果在您的项目设置中有意义，甚至可以使用“依赖”链接。
- Spence
1
谢谢你的回答 - 我稍微倾向于Sereda的建议，但如果它不起作用，我可能会尝试你的建议。 - gareth_bowles
2
我们有同样的问题。在涉及多个产品并存在依赖关系的问题（例如，我们有一个服务器、连接api和客户端应用程序），如果有一个新想法关于以某种方式扩展客户端应用程序，很可能还需要扩展连接api和服务器。这些可能由不同的团队开发...因此并没有在同一次迭代中处理，但是作为产品负责人，您希望将所有这些新功能作为一组进行跟踪。
我们做的实际上是创建了几个自定义字段。我们引入的第一个字段是'级联选择器'，如'程序'和'阶段'。这使得产品负责人可以将问题分组到程序下，进行一些粗略的长期规划（数个迭代）。
然后，我们添加了另一个字段（文本字段）来表示'Epic'（或'Theme'），这个字段将与特定Epic / Theme相关的问题捆绑在一起。这个想法是在“Program”中使用“Epics”。对于较大的“Program”，您可以将其分成不同的部分，然后在这些“Epics”中反映出来（一种故事情节。一组故事（可以延伸到多个产品），可以为产品系列增添价值）。
这两个字段现在使得根据程序（带或不带其阶段）和Epic过滤跨多个产品的问题变得很容易。
确实，启用链接后，您现在还可以在不同产品中的不同问题之间创建依赖关系。这完全与默认的Jira产品版本控制分离。这很棒，因此正常的发布流程保持不变。
我正在考虑引入的另一个想法是'迭代'字段。在进入计划会议（或仅在会议后），可以更新此字段以使用该sprint的名称（Jira在多个问题编辑/更新方面非常出色）。然后，就可以很容易地对该迭代的所有问题进行过滤。
我最喜欢使用Jira作为Scrum计划/ Sprint跟踪工具的原因是您不需要单独的计划和待办事项工具。Bug更可见。无需将漏洞重复管理到计划工具中或将计划项管理到漏洞跟踪工具中（以获取正确的cvs / svn /等提交号码）。或生成发行说明。
我们做的实际上是创建了几个自定义字段。我们引入的第一个字段是'级联选择器'，如'程序'和'阶段'。这使得产品负责人可以将问题分组到程序下，进行一些粗略的长期规划（数个迭代）。
然后，我们添加了另一个字段（文本字段）来表示'Epic'（或'Theme'），这个字段将与特定Epic / Theme相关的问题捆绑在一起。这个想法是在“Program”中使用“Epics”。对于较大的“Program”，您可以将其分成不同的部分，然后在这些“Epics”中反映出来（一种故事情节。一组故事（可以延伸到多个产品），可以为产品系列增添价值）。
这两个字段现在使得根据程序（带或不带其阶段）和Epic过滤跨多个产品的问题变得很容易。
确实，启用链接后，您现在还可以在不同产品中的不同问题之间创建依赖关系。这完全与默认的Jira产品版本控制分离。这很棒，因此正常的发布流程保持不变。
我正在考虑引入的另一个想法是'迭代'字段。在进入计划会议（或仅在会议后），可以更新此字段以使用该sprint的名称（Jira在多个问题编辑/更新方面非常出色）。然后，就可以很容易地对该迭代的所有问题进行过滤。
我最喜欢使用Jira作为Scrum计划/ Sprint跟踪工具的原因是您不需要单独的计划和待办事项工具。Bug更可见。无需将漏洞重复管理到计划工具中或将计划项管理到漏洞跟踪工具中（以获取正确的cvs / svn /等提交号码）。或生成发行说明。
- Verhagen
0
在这种情况下，您最好同时使用Confluence和Jira。
将Jira用于其最擅长的领域，将Confluence用于其他所有事项。
如果您觉得有用，可以将各个项目划分为共享的“子模块”，但我倾向于建议主要使用Jira来跟踪实际实现和相关错误。
- Arafangion
2
我们使用Confluence进行自由形式的文档编写，例如最初的需求收集和讨论，但是Confluence不适合我需要做的详细需求跟踪。 - gareth_bowles
尽管如此，使用Confluence宏仍然可以做很多疯狂的事情...而且你可以从中引用Jira任务。 - Arafangion
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接