问Jira和Greenhopper中的Sprint版本和发布版本

EN

这里有两个问题。

首先，您的sprint版本实际上是发布版本的"subversions“。这意味着您的故事实际上在fixVersion字段中获得了两个值。

您可以通过设置主版本在Greenhopper中配置这一点。

因此，如果您有版本1.0的3 sprint版本，那么您将发布日期设置为1.0，并将您的故事放在sprint 1、sprint 2和sprint 3中，这样

3

• 1.0
  • Sprint 1
  • Sprint 2
  • Sprint

​

• ...

• 1.1

​

当你在Sprint 1中播放故事-1时，你会发现这个故事-1的fixVersion是"1.0，Sprint 1“。

对于您正在跟踪的发布项，但不是sprint中的项，只需将fixVersion设置为1.0即可。

其次(这只是一个提示)，您可以在sprint工作和生产支持工作中使用单独的项目。这在大型组织中很有帮助。

在不同的组织中，我们都面临着同样的问题，一个团队不仅在处理多个版本(就像您在示例中详细描述的那样)，而且在客户问题提出或用户接受测试之前的版本时，团队还参与帮助支持组织，显示出“需要立即处理”的问题。

因此，我们引入了一个概念，即问题与任务分离，但使用JIRA的“问题链接”功能将问题连接在一起。问题(或我们称之为规范)是在发布项目中管理的，而任务是在团队项目中管理的。

发布项目中的版本控制表示发布(即2.2-patch1 1，1.1 .)团队项目中的版本控制表示sprint (sprint 10-15，sprint 10-20)。

发布项目只包含bug、特性请求、查询。团队项目只包含任务，故事，.

自动化允许我们保持规范和相关任务保持同步:典型的场景运行如下

• A规范是在发布项目中创建的。
• 支持人员在团队项目中创建一个或多个任务，并将规范与使用“是由”链接实现的任务联系起来。从任务开始工作的那一刻起，
• 就升级到“处于开发状态”。一旦所有相关任务都已被处理到

，则认为规范已解决。

规范的转换是自动触发的。这种规范和任务分离的概念允许您支持许多不同的项目组织，例如

• 是一部史诗，需要在多个sprint上开发。
• 这个问题需要由不同地点的多个团队来解决，
• 是一个团队，负责开发一个新产品，并维护一个旧产品。

如果有兴趣的话，我可以向你提供更多关于这个问题的信息。

弗朗西斯·马滕斯

我也受到同样问题的困扰，并在jira/greenhopper中找到了特性请求，以便为sprint添加一个新的字段，以允许对sprint进行跟踪并独立发布版本信息。

如果你和我一样想看到这件事成为现实，那就去http://jira.atlassian.com/browse/GHS-945投票吧。这句话总结说：“如果GreenHopper有作为头等公民的迭代.”

不过目前，我们可能需要在jira中创建一个名为versions的新字段，并使用它来跟踪问题所涉及的“真实产品版本”。我们的源代码库中还有一个提交钩子，所以当开发人员提交时，它将使用与其提交的源代码相关的“真实产品版本”更新jira票据。我们将这些信息保存在一个配置文件中，这样提交钩子就知道要使用什么版本来使用什么源代码存储库/路径。这并不理想，但这是我们目前唯一的选择。