我的公司一直使用JIRA作为需求跟踪工具以及错误跟踪器，而且我们一直在处理一个项目时工作得非常好。
我们现在有一个场景，我们有三个不同的项目提案，其要求部分重叠（例如，要求1适用于项目A和B，要求2适用于项目B和C等）。我希望能够针对每个要求输入一个JIRA问题，但这似乎不可能，因为JIRA问题和项目具有一对一的关系。
是否有人在JIRA中找到了这样做的方法，或者是否有其他一些与JIRA集成的工具？
答案 0 :(得分：8)
虽然没有一个正确的答案，但我可以提出一个想法。我没有足够的有关您工作流程的信息，但您提到您有项目提案。所以我假设项目A，B和C处于早期阶段。要求收集等等，没有错误。
设置一个JIRA项目，比如“早期要求”。将项目A，B和C的所有要求放入该JIRA项目中。要允许需求与实际项目之间的多对多关系，请设置“多个复选框”或等效类型的自定义字段，并将“项目A”，“项目B”和“项目C”配置为其值。对于任何要求，您可以检查它适用于哪个项目。
现在 - 我在这里做了更多的假设 - 让我们说一些提案继续进行，有些提议已经消失。您将需要一个过程来a）将实际项目A的所有要求提取到A新创建的JIRA项目中 - 这可以通过搜索＆amp;批量克隆问题; b）清除所有没有与之相关的实时项目的要求 - 搜索＆amp;批量删除。
警告：如果您需要与不同的客户分享需求，那将会变得棘手。根据JIRA项目配置权限＆amp;问题类型。
尽管如此，JIRA缺乏体面的需求管理功能，例如基线和可追溯性。但是，为了进一步的工作而收集数据可能没问题。
答案 1 :(得分：6)
我们使用jira的“duplicates”或“related to”功能。
因此，您在每个项目中提出了一个问题，但是您将它们联系在一起。这样，您可以让项目“拥有”一个问题，并且可以在对每个项目进行测试后关闭所有相关项目。
如果在项目设置中有意义，您甚至可以使用依赖链接。
答案 2 :(得分：2)
我们遇到同样的问题。如果您遇到涉及多个产品且在它们之间存在依赖关系的问题（错误或新功能）。 （举个例子，我们有一个服务器，一个连接api和一个客户端应用程序）。如果有关于以某种方式扩展客户端应用程序的新想法，那么连接api和服务器也很可能需要某种扩展。可能它们是由不同的团队开发的...所以不是在同一个sprint / iteration中处理，而是作为产品所有者，你想要作为一个组跟踪所有这些新功能。
我们所做的实际上是创建了一些自定义字段。我们介绍的第一个字段是'Cascading Select'，'Program'和'Phase'。这使产品所有者有可能将问题分组到一个程序下，并进行一些粗略的长期规划（几次迭代）。
然后我们为“Epic”（或“主题”）添加了另一个字段（文本字段），这捆绑了与某个Epic / Theme相关的问题。我们的想法是在“程序”中使用“Epics”。如果有更大的“程序”，你可以将它分成不同的部分，然后反映在这些“史诗”中。 （一种故事情节。一组故事（可以分布在多个产品上），为这一系列产品增添价值。）
这两个字段现在可以轻松过滤出多个产品的问题，这些问题基于程序（有或没有相位）和Epic。
确实启用了链接后，您现在还可以在不同的产品中创建不同问题之间的依赖关系。它与默认的Jira产品版本完全分开。这很好，所以正常的发布过程保持不变。
我想要介绍的另一个想法是“迭代”字段。进入计划会议（或之后）。可以使用该sprint的名称更新此字段（Jira在多个问题编辑/更新中非常出色）。然后，可以轻松过滤出该sprint的所有问题。
我最喜欢使用Jira作为Scrum计划/ Sprint跟踪工具，是因为您没有单独的计划和积压工具。错误更明显。没有将错误双重管理到规划工具和/或将项目计划到Bug跟踪工具中（对于正确的cvs / svn / etc提交号）。或者发行发行说明。
答案 3 :(得分：0)
在这种情况下，除了jira之外，你可能更善于使用融合。
将Jira用于最佳状态，并将Confluence用于其他所有事情。
如果您觉得有用，请将各种项目划分为共享的“子模块”，但我倾向于建议使用Jira主要用于跟踪实际实施和相关错误。
答案 4 :(得分：0)
另一种方法是创建一个带有超链接的多选自定义字段（如“XYZ-123”）作为选项发布。
答案 5 :(得分：0)
更好的方法是区分用于开发跟踪的问题和所有项目的80％相同的要求。
存在解决方案： Rmsis a JIRA plugin ：