当使用Greenhopper和Jira时，显然Greenhopper正在使用Jira问题中的“固定版本”字段来表示正在处理该问题的scrum sprint。这本身就有些苛刻，因为可以想象一个问题可以在多个sprint中进行，并且因为问题和sprint之间的关系恰恰是它在sprint期间工作，认识到您可能无法在计划的时间内完成任务。
但是，好吧，它可能是一个可以忍受的黑客，至少如果没有其他任何东西试图使用“固定版本”字段中的其他东西。
但我发现其他问题也建立在“固定版本”字段上。具体来说，应该能够看到哪些计划要解决哪些问题发布版本（现实版本），并将此信息用作验证方式/ QA。
其他Greenhopper用户如何结合使用“固定版本”字段的这两种用途？您是否将sprint版本设置为发布版本的子版本？您是否在发布版本中使用了一些自定义字段？我发现这很困难，因为scrum团队正在研究多个组件，独立版本。此外，可能会在同一个组件上发生错误修复版本和功能开发，发生在同一个sprint上。
总而言之，我发现该团队将不可避免地开发“Some Product 3.4.0”（功能发布），“Some Product 3.3.1”（修正版本发布）和“Other Product 1.2”同样的冲刺。将这个sprint标记为这三个版本中的每个版本（跨两个不同的组件）都是不可能的。在Greenhopper中制作三个不同的冲刺，真的会稀释Greenhopper的价值。
其他Greenhopper用户处于同样的情况吗？你是怎么处理它的？
答案 0 :(得分：13)
这里有两个问题。
首先，您的sprint版本实际上是您的发布版本的“颠覆”。这意味着您的故事实际上在fixVersion字段中获得了两个值。
您可以通过设置主版本在Greenhopper中进行配置。
因此，如果您有1.0版本的3 sprint版本，那么您将发布日期设置为1.0 并将你的故事放在sprint 1，sprint 2和sprint 3中，以便
当您在Sprint 1中播放STORY-1时，您会发现STORY-1的fixVersion为“1.0，Sprint 1”
对于您要跟踪发布但未在sprint中跟踪的项目，只需将fixVersion设置为1.0。
其次（这只是一个提示），您可以使用单独的项目进行sprint工作和生产支持工作。这在大型组织中很有用
答案 1 :(得分：6)
我们在各个组织中遇到过同样的问题，一个团队不仅在处理多个版本（比如您在示例中详细说明），而且还有团队在客户问题时帮助支持组织的工作。提出或在以前版本的用户验收测试中，显示“需要立即处理”的问题。
因此，我们引入了一个概念，即问题与任务分离，但使用JIRA的“问题链接”功能链接在一起。问题（或我们称之为的规范）在发布项目中进行管理，而任务则在团队项目中进行管理。
发布项目中的版本控制表示发布（即2.2-patch1,1.1 ......） 团队项目中的版本控制表示冲刺（sprint 10-15，sprint 10-20）
发布项目仅包含错误，功能请求，查询.. 团队项目只包含任务，故事......
自动化允许我们保持规范和相关任务的同步： 典型情况如下：
自动触发规格的转换。 规范和任务之间的这种分离概念允许您支持许多不同的项目组织 - 例如
如果感兴趣，我可以为您提供有关此主题的更多信息。
Francis Martens
答案 2 :(得分：5)
我也一直受到同样问题的困扰，并在jira / greenhopper中找到了功能请求，为sprint添加了一个新字段，以便独立跟踪sprint和发布版本信息。
如果你想像我一样看到这变成现实，那么请转到http://jira.atlassian.com/browse/GHS-945并投票支持这个问题。这句话总结了一下：“如果GreenHopper有迭代作为一等公民......”
目前，我们可能需要在jira中创建一个名为版本的新字段，并使用它来跟踪与问题相关的“真实产品版本”。我们的源代码存储库中也有一个提交钩子，因此当开发人员进行提交时，它将使用与他们提交的源代码相关的“真实产品版本”更新jira票证。我们将此信息保存在配置文件中，以便提交挂钩知道要用于哪个版本的源代码存储库/路径。这不是理想的，但它是我们目前唯一的选择。
答案 3 :(得分：3)
只需在GreenHopper中使用快速电路板，它们是在很久以前推出的，但它们几乎可以满足您的所有需求。
您可以在问题上加上 LABELS ，例如'sprint-1'，'sprint-2'等等。然后创建问题过滤器。然后根据过滤器创建 RAPID BOARD 。最后，你会得到一个漂亮的板子，当前的sprint-X 问题无论版本甚至是项目。
请检查Sprint本质上不是软件版本。在现实世界中，当您拥有多个客户时，您需要修复并支持许多版本，但您仍需要保持一切正常。在这种情况下，冲刺仍然很好但它们只代表应该在时间段内完成的工作量。无论如何，版本是您在开发时间之外向任何人展示的版本。所以，不要混合软件版本和sprint（时间和任务之间的“映射”）！不使用sprint版本是真实软件版本的子级的层次结构！把不相关的东西分开!!!
答案 4 :(得分：1)
冲刺在理论上不应该是最终的“可交付”产品吗？这意味着sprint的问题要么已经解决，要么“失败”。 这就是为什么我建议将问题分成小块。
答案 5 :(得分：0)
我尝试使用K.I.S.S.尽可能，所以我一直在使用标签字段来标记版本。我很少需要在scrum / taskboard的上下文中看到这个版本。因此，当需要查看发布中的所有项目时，我只是搜索我的发布名称。