Atlassian GreenHopper 和发布管理答案

【问题标题】：Atlassian GreenHopper and Release ManagementAtlassian GreenHopper 和发布管理
【发布时间】：2012-06-11 06:10:15
【问题描述】：

我们正在使用 Atlassian 产品，我已经使用 GreenHopper 准备了一个敏捷冲刺，并且对流程几乎没有混淆。

这是我们在我的办公室进行当前开发的方式：

开发人员完成分配给他们的问题。将它们标记为已解决。
完成冲刺的所有问题后，我们将获得一张提供发布详细信息的发布票，并将其分配给 INF 团队以在 QA 中构建和部署。如果事情在 QA 中获得批准，则将其转移到暂存、生产。
如果发现任何问题或未解决任何问题，我们将拒绝该版本并将其分配给开发人员。开发人员更正它们并准备另一个版本。

是否有人对使用 JIRA+GreenHopper 实现类似的目标或任何更好的想法有任何建议。

【问题讨论】：

【解决方案1】：

听起来您的过程相当简单。我建议您使用 GreenHopper 5.10.1 中的新快速板。快速委员会有一个明确的计划 > 工作 > 向他们报告流程。

根据您的具体情况，我建议以下内容：

首先为一般开发创建一个快速板。该板将用于您的开发团队，并具有包含错误修复、故事和积压项目的 Sprint。该板的最后一列将是“完成”或“准备好进行 QA”
- 在 Sprint 结束时，团队只需“完成”该 Sprint 并记录一张票，以完成构建并将其部署到 QA
然后，我建议将与 Sprint 中的相同问题转移到 QA 流程中，这样每个问题都可以被拒绝。要做到这一点，QA 团队可以简单地拥有一个单独的 Scrum Rapid Board，第一列是“为 QA 做好准备”。这将允许他们运行一个单独的 Sprint，其中包括刚刚完成的 Sprint 中的问题
- 在这个 Sprint 结束时，只有好的故事才会出现在“完成”列中，团队可以决定只部署正确的故事或拒绝整个发布
- 未通过 QA 的故事可以更新回一个状态，使它们重新回到开发团队的待办事项列表中，以包含在下一个 Sprint 中。或者，可以将它们单独提出来与开发团队一起修复

【讨论】：

【解决方案2】：

我们在这里做了一些非常相似的事情，并且在 JIRA / Greenhopper 中运行良好：

产品所有者在 JIRA/Grasshopper 中创建史诗/主题/用户故事
进行积压梳理，故事经过一番梳理，故事点输入到用户故事中
Sprint 计划：为即将到来的 sprint 选择故事，并使用 greenhopper 创建将故事添加到 sprint。见下文
Sprint 开始。开发人员在 JIRA 中创建任务以跟踪进度，并链接到用户故事。一旦故事的所有任务完成，用户故事就完成了。
我们在 JIRA 中放置了脚本，以便有一个“完成”按钮，它会自动将故事分配给我们的构建团队，他们将其合并到我们的主要基线中（不确定这是否适用于您）。一旦他们将其投入生产构建，用户故事就会分配给 QA 团队。
QA 团队测试生产版本...如果通过，故事结束。

我可能会补充一点，QA 团队可能需要比 sprint 允许的时间更长的时间来测试故事 - 因此，为了团队的 sprint 和速度，故事在分配给构建团队时被视为已完成。

这有意义吗？

JIRA 能够完成所有这些，这很棒 - 尽管您可能需要进行一些配置来设置史诗/主题等条目。

我们使用 Greenhopper 功能来创建和跟踪故事和冲刺，但对于任务进度等，我们使用白板 - 更显眼，更适合日常站立。

希望这会有所帮助..任何问题我都会很乐意回答:)

【讨论】：

非常感谢！！！.. 在我们的场景中，sprint 将包括错误修复、故事以及积压项目。除此之外，我们还维护一张单独的票，以将版本从 dev=> build=>QA（发布票）中移出。
非常感谢！！！.. 在我们的场景中，sprint 将包括错误修复、故事以及积压项目。除此之外，我们还维护一张单独的票，以将版本从 dev=> build=>QA（发布票）中移出。一旦发布在 QA 中部署，其他问题也会手动分配给 QA 团队。问题> 当 QA 拒绝时会发生什么，我怎么说构建团队来构建特定版本。并继续前进……抱歉问了太多问题。对此有点困惑。