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