20

将 Greenhopper 与 Jira 一起使用时，很明显 Greenhopper 使用 Jira 问题中的“已修复版本”字段来表示该问题正在处理哪个 scrum 冲刺。这本身有点骇人听闻，因为可以想象一个问题可以在多个 sprint 中处理，并且因为问题和 sprint 之间的关系正是它在 sprint 期间已经处理过，并且认识到您可能无法完成计划时间内的任务。

但是好吧，它可能是一个可以忍受的黑客，至少如果没有其他东西试图将“固定版本”字段用于其他东西。

但我发现还有其他问题也建立在“固定版本”字段上。具体来说，应该能够看到计划在哪些发布版本（实际版本）中解决哪些问题，并将此信息用作验证/质量保证的一种手段。

其他 Greenhopper 用户如何结合“固定版本”字段的这两种用途？您是否将 sprint 版本设置为发布版本的子版本？您是否为发布版本使用了一些自定义字段？我发现这很困难，因为 Scrum 团队正在开发多个独立版本的组件。此外，在同一个 sprint 上可能会在同一个组件上发布错误修复和功能开发。

总而言之，我发现团队不可避免地会在同一个 sprint 中开发“Some Product 3.4.0”（一个功能版本）、“Some Product 3.3.1”（一个错误修复版本）和“Other Product 1.2” . 不可能将此 sprint 标记为这三个版本中的每一个的颠覆（跨两个不同的组件）。而在 Greenhopper 中进行三个不同的 sprint，确实会削弱 Greenhopper 的价值。

其他 Greenhopper 用户是否也有同样的情况？你是怎么处理的？

4

6 回答 6

13

这里有两个问题。

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

您可以通过设置主版本在 Greenhopper 中进行配置。

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

  • 1.0
    • 冲刺 1
    • 冲刺 2
    • 冲刺 3
  • 1.1
    • ...

当你在 Sprint 1 中玩 STORY-1 时，你会发现 STORY-1 的 fixVersion 为 "1.0, Sprint 1"

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

其次（这只是一个提示），您可以为冲刺工作和生产支持工作使用单独的项目。这对大型组织很有帮助

于 2011-09-29T01:04:45.570 回答
6

我们在不同的组织中都遇到过同样的问题，其中一个团队不仅在处理多个版本（就像您在示例中详细说明的那样），而且当出现客户问题时，该团队还参与帮助支持组织或当对以前版本的用户验收测试时，立即显示“需要处理”的问题。

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

发布项目中的版本控制表示发布（即 2.2-patch1、1.1 ...）团队项目中的版本控制表示冲刺（冲刺 10-15、冲刺 10-20）

发布项目仅包含错误、功能请求、查询.. 团队项目仅包含任务、故事、...

自动化使我们能够使规范和相关任务保持同步：典型场景运行如下

  • 在发布项目中创建规范。
  • 支持人员在团队项目中创建一个或多个任务，并使用“由实施者”链接将规范与任务链接起来。
  • 从任务开始工作的那一刻起，规范就进入了“开发中”状态。
  • 一旦解决了所有相关任务，规范就被认为已解决

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

  • 需要在多个冲刺中开发的史诗。
  • 需要由不同地点的多个团队解决的问题
  • 一个开发新产品并维护旧产品的团队。

如果有兴趣，我可以为您提供有关此主题的更多信息。

弗朗西斯·马滕斯

于 2010-07-09T07:06:34.593 回答
5

我也被同样的问题所困扰，并在 jira/greenhopper 中找到了为 sprint 添加一个新字段以允许独立跟踪 sprint 和发布版本信息的功能请求。

如果您和我一样希望看到这成为现实，请访问http://jira.atlassian.com/browse/GHS-945并为该问题投票。这句话总结了它：“如果 GreenHopper 有迭代作为一等公民......”

但目前，我们可能必须在 jira 中创建一个名为 versions 的新字段，并使用它来跟踪与问题相关的“真实产品版本”。我们的源代码存储库中还有一个提交挂钩，因此当开发人员进行提交时，它将使用与他们提交的源代码相关的“真实产品版本”更新 jira 票证。我们将此信息保存在配置文件中，以便提交挂钩知道要使用哪个版本用于哪个源代码存储库/路径。这并不理想，但这是我们目前唯一的选择。

于 2010-08-10T10:07:28.067 回答
3

只需在 GreenHopper 中使用快速板，它们是不久前推出的，但它们几乎可以满足您的所有需求。

您可以将LABELS放在您的问题上，例如“sprint-1”、“sprint-2”等。然后创建问题FILTER。然后根据过滤器创建RAPID BOARD 。最后，无论版本甚至项目，您都将获得具有当前问题的 sprint-X 的好板。

请检查 Sprint 本质上不是软件版本。在现实世界中，当您拥有多个客户时，您需要修复和支持很多版本，但您仍然需要保持一切正常。在这种情况下，sprint 仍然很棒，但它们只代表了在一段时间内应该完成的工作量。无论如何，版本是您将在开发时间之外向任何人展示的内容。所以，不要混合软件版本和冲刺（时间和任务之间的“映射”）！不要使用 sprint 版本是真实软件版本的子级的层次结构！把无关的东西分开！！！

于 2011-12-20T15:43:35.850 回答
1

理论上，冲刺不应该在最后拥有“可交付”的产品吗？这意味着冲刺的问题要么已解决，要么“失败”。这就是为什么我建议将问题分成较小的部分。

于 2010-07-08T05:36:44.257 回答
0

我尽可能使用 KISS，所以我一直使用标签字段来标记发布。我很少需要在 scrum/taskboard 的上下文中查看发布。因此，当需要查看版本中的所有项目时，我只需搜索我的版本名称即可。

于 2011-09-29T12:13:40.900 回答