问JIRA日常会议、回顾和规范的工作日志

EN

所以我和我的团队一起面对这个问题，这就是我们(目前)对YMMV所起的作用。

我们目前的结构是，我们有一个路线图类型的项目(称为这个计划)，所有的问题都会在这里出现。此后，我们在相关的产品项目中创建问题(称为“此产品”)。

1. 在生命周期开始时，任何会议、范围界定等都会创建子任务，时间将在计划中被跟踪。一旦确定范围并计划工作，就会在Product上创建一个新问题，并将其链接到这个原始问题。
2. 一旦产品问题被分配，开发人员被调用到任何会议，而这个问题正在冲刺，我们将创建一个关于产品的子任务并分配时间。如果问题不在冲刺中，我们将继续在计划中创建一个新的子任务，并在那里分配时间。
3. 那时还有一个项目，我们在那里做管家式的工作。因此，如果我们需要改变JIRA，存储，汇合点，我们将在这里创建问题。然后，我们将创建一个新的问题的规划，联系的问题和时间表，因此。
4. 我们有一个元项目，作为一个桶，任何不属于其他类别的东西，我们不时地筛选，以确定我们是否需要创建单独的项目。
5. 我创建了一个自定义字段，将计划委员会中所有链接问题的所有时间都卷起来

看看尼古拉斯·穆尔多恩( Nicholas )的推特博客在JIRA中可视化Epics和依赖项，也许这在某种程度上对你也有帮助。

请注意，我们仍在探索实现这一目标的最佳方法。每个环境都是不同的，对我们有用的可能对你不起作用。

我们使用节奏记录我们针对JIRA问题的可计费工作，无论是一个小型项目的单个Epic，还是大型项目的单个任务。对于不收费的工作，我们有一个项目，人们可以选择日志工作，我们也使用它来规划我们的时间。所以选项1是最近的。我们还可以为不同的工作记录不同的类别，并以这种方式处理这种情况。

我也面临着同样的问题，试图跟踪团队成员的工作时间，这些小时与项目无关，或与项目相关，但与特定的故事或任务无关。

最初，我们使用了选项3，&有几个管理任务在sprint中持久化。虽然这是相对容易实现的，但我们失败了，因为我们的团队成员跨多个项目&因此，每个项目中驻留的这些管理任务不可能对这些团队成员进行管理/报告。

最后，我们讨论了您所描述的选项1。通过创建一个具有“非任务相关”问题的单独项目，例如计划会议、技术问题和客户端工作，然后安装JIRA Misc Time Log & Report Extensions，我们可以为用户提供一种简单的登录时间方法，而无需更改项目或板(因为插件向顶部导航添加了下拉菜单)。

然后，这个插件允许我们得到关于团队成员在哪里记录休假项目的报告，而不管他们同时处理了多少个项目。