我是JIRA + Greenhopper中敏捷流程的新手。 我试图了解在JIRA + GH中使用敏捷的正确/更好的方法是什么。 我已经在网上阅读了一些信息 - 到目前为止，我知道我们有故事和史诗（这是一个很大的故事）。我想知道创建任务的流程是什么：
这是正确的流量吗？我的问题是：
非常感谢您的快速反应。
答案 0 :(得分：27)
我们如何使用它如下：
当我们计划迭代时，我们将优先考虑我们想要完成的故事。对于每个故事，团队将创建有关如何构建故事的任务（子任务）。这些任务是特定的事情：创建数据库表，更改控制器代码，QA功能，更新公共文档等;以及将执行任务的人和他们的时间估计。
随着迭代的进行，每个团队成员记录他们在每项任务上完成的工作，并在他们拥有更多信息时细化他们对任务的估计。任务完成后，它将关闭。当所有任务完成后，故事就可以部署了。
此外，当您创建子任务时，如果您从齿轮下方的卡片视图中选择添加子任务，它将调出一张卡片来输入任务中的项目（类似于卡片创建） ，您可以继续创建子任务卡，直到完成。我们认为，这是一种快速，简便的方式来输入任务。
希望这会有所帮助。如果您有任何问题或需要更多详细信息，请与我们联系。
答案 1 :(得分：16)
我认为值得注意的是，流程因团队而异。
例如，有些团队的产品所有者从Epic开始，然后将其分解为Stories，随着时间的推移添加验收标准/成功条件。通常在这种情况下，团队将在计划会话中聚集在一起，并将这些故事分解为子任务。
有些团队给故事提供了一个故事点估计（通常是斐波那契），其他团队则为子任务分配一小时的估算。在分配一小时估算时，团队会经常更新剩余估算值。这为小时燃尽图提供了一个很好的指示，即短跑进度。
我还看过团队，产品所有者创建了大量的故事，并在以后手动将它们汇总到Epics中。如果我有一个首选的方法，那将是第一种方便的方法，但总会有错过/遗忘的故事，并在计划会议期间添加。
Epics通常安排在发布积压之外的任何内容，因为它们经常跨越多个sprint积压。 sprint和release都作为JIRA中的Fix Versions处理，父/子backlog的嵌套有助于提供有关计划内容的可视化。
这是针对scrum的。如果您对看板感兴趣，那么我可以分享我在团队中所看到的情况，只需说出这个词。
干杯， 尼古拉斯·马尔登