我不熟悉 JIRA + Greenhopper 中的敏捷流程。 我试图了解在 JIRA + GH 中敏捷工作的正确/更好的方法是什么。 我在网上阅读了一些信息 - 到目前为止，我知道我们有故事和史诗（它们是大故事）。我想知道创建任务的流程是什么：
这是正确的流程吗？我的问题是：
非常感谢您的快速回复。
【问题讨论】：
标签： jira jira-agile
我们的使用方法如下：
当我们计划迭代时，我们会优先考虑我们想要完成的故事。对于每个故事，团队将创建有关如何构建故事的任务（子任务）。这些任务是要完成的具体事情：创建数据库表、更改控制器代码、QA 功能、更新公共文档等；以及将执行任务的人员及其按时的估计。
随着迭代的进行，每个团队成员都会记录他们在每个任务上完成的工作，并在获得更多信息时改进他们对任务的估计。任务完成后关闭。完成所有任务后，故事就可以部署了。
另外，当你创建子任务时，如果你在齿轮下的卡片视图中选择添加子任务，它会弹出一张卡片进入任务上的项目（类似于卡片创建） ，您可以在其中继续创建子任务卡，直到完成。在我们看来，这是一种非常快速、简单的任务输入方式。
希望这会有所帮助。如果您有任何问题或想了解更多详情，请告诉我。
【讨论】：
我认为重要的是要注意流程因团队而异。
例如，一些团队有一个产品负责人，他从 Epic 开始，然后将其分解为故事，在他们进行过程中添加验收标准/成功条件。通常在这种情况下，团队将在计划会议中聚集在一起，并将这些故事分解为子任务。
一些团队为故事提供故事点估计（通常是斐波那契），其他团队为子任务分配一个小时估计。在分配小时估算时，团队通常会随着进度更新剩余估算。这在小时燃尽图上很好地指示了 sprint 的进度。
我还见过一些团队，他们的产品负责人创建了很多故事，并在以后手动将它们聚合到 Epics 中。如果我有一个首选的方法，那将是第一种方便的方法，但总会有一些故事被遗漏/遗忘并在计划会议期间添加。
Epics 通常安排在发布待办事项之外的任何内容中，因为它们通常跨越多个 sprint 待办事项。 sprint 和发布都在 JIRA 中作为修复版本处理，父/子积压的嵌套有助于提供计划内容的可视化。
这是为 Scrum 准备的。如果您对看板感兴趣，那么我可以分享我看到的团队在这种情况下所做的事情，只需说出这个词。
干杯， 尼古拉斯·马尔登
【讨论】：