我正在审查 JIRA 是否可能在我工作的公司的几个开发团队中使用。我们使用 Scrum 作为我们项目管理的基础。我们有优秀的自组织团队，几乎没有分配的工作，等等。JIRA 似乎对其中一些项目非常有用，但我们正在努力处理的问题是处理流程与技术任务的管理以及我们称之为“问题捆绑”的事情。
过程控制。目前我们将创建一个故事，例如“损益报告上的图表存在重叠图例文本的问题”。好吧，够好了。然后，我们将创建一个技术子任务，为简单起见，假设它是“研究并纠正问题”。接下来，我们创建了一组流程子任务。同行评审、构建、QA 测试、合并、跟踪。然后可以将这些中的每一个独立分配给用户并放入我们的 scrum 板上的 Pending bin 中（顺便说一句，我们使用 Pending、Awaiting Action、In Progress、Done、Merged 模型而不是 todo、in progress、done 模型）。待定基本上意味着，如果我是下一个优先级，我正在等待。在开发过程中，程序员将抓住技术任务，将自己设置为受让人并进入进行中。完成后，他们会将其移至 Done bin，然后将 Peer Review 流程子任务更新为“Awaiting Action”，并将受理人设置为他们的代码合作伙伴。发送电子邮件，完成同行评审。完成后，同行评审合作伙伴会将 Peer Review 移至 Done bin，并将 Make Build 子任务设置为构建管理器，并将其移至 Awaiting Action。构建经理看到这一点，进行构建，将其移至完成并将 QA 测试票证更新为等待操作状态，您就明白了。完成后，同行评审合作伙伴会将 Peer Review 移至 Done bin，并将 Make Build 子任务设置为构建管理器，并将其移至 Awaiting Action。构建经理看到这一点，进行构建，将其移至完成并将 QA 测试票证更新为等待操作状态，您就明白了。完成后，同行评审合作伙伴会将 Peer Review 移至 Done bin，并将 Make Build 子任务设置为构建管理器，并将其移至 Awaiting Action。构建经理看到这一点，进行构建，将其移至完成并将 QA 测试票证更新为等待操作状态，您就明白了。
它正在工作，但是他们对替代方案、最佳实践等有什么建议吗？创建技术和流程子任务不是要走的路吗？我注意到的一件事是，我们必须过滤问题列表以隐藏子任务，并且对于只想查看父故事状态的利益相关者来说，Scrum 板可能会变得相当难以应付。由于父故事在子任务移动之前不会移动，因此他们看不到任何他们感兴趣的东西，即使在子任务移动时故事正在“进行中”也是如此。啊。
问题捆绑。我们经常有一组可能紧密相关但通常更普遍的问题。例如，与我们软件中的报告相关的所有问题。目前有 15 个已知问题。这些问题可能在系统中的不同报告中，具有重现的特定步骤等。当我们为冲刺做准备时，我们将选择这些相关问题的捆绑包。原因是 QA 可以更有效地测试一堆通常在一次通过中相关的小修复，而不是将每个报告作为单独的过程进行测试。
目前，我们将每个问题移到捆绑包的子任务中。例如，捆绑包可能简称为“Report Fixes 1”，例如，它将具有 5 个技术子任务，每个子任务都是要修复的不同报告错误。然后，我们可以将上面的过程控制项添加到整个捆绑包中。我们还知道，在捆绑包中的所有项目都完成之前，我们不会合并，所以它们都得到相同的版本。
但是，如上所述，可见性会降低，因为您现在无法轻松查看子任务的状态，因为它们位于捆绑包中。
再次，最佳实践？想法？其他人是如何处理这个问题的？