过程控制和scrum的JIRA实现

我正在审查JIRA，以便在我工作的公司的几个开发团队中使用。我们使用Scrum作为项目管理的基础。我们拥有优秀的、自组织的团队，几乎没有分配的工作，等等。JIRA对于其中一些项目来说似乎很棒，但我们正在努力处理的是过程管理与技术任务以及我们称之为“问题捆绑”的事情

过程控制。目前，我们将创建一个故事，比如“损益表上的图表存在图例文本重叠的问题”。好的，很好。然后我们将创建一个技术子任务，为了简单起见，我们可以说它是“研究并纠正问题”。接下来，我们将创建一组流程子任务。同行评审、构建、QA测试、合并、跟踪。然后，每一个都可以独立地分配给用户，并将其放入scrum板上的挂起bin（顺便说一句，我们使用挂起、等待操作、进行中、完成、合并模型，而不是todo、进行中、完成模型）。等待基本上意味着，我在等待，如果我是下一个优先。在开发过程中，程序员将抓住技术任务，将自己设定为受让人，并转移到进行中。完成后，他们会将其移动到“完成”bin，然后将同行评审流程子任务更新为“等待操作”，并将受让人设置为他们的代码合作伙伴。发送电子邮件，完成同行评审。完成后，同行评审合作伙伴将同行评审移动到“完成”bin，并将“生成生成”子任务设置为“生成经理”，并将其移动到“等待操作”。构建经理看到这一点，进行构建，将其移动到完成状态，并将QA测试记录更新为等待操作状态，您就明白了

这是可行的，但是他们对替代方案、最佳实践等有什么建议吗？创建技术和流程子任务不是可行的方法吗？我注意到的一件事是，我们必须过滤问题列表以隐藏子任务，而scrum董事会可能会让那些只想看到父故事状态的利益相关者感到非常不安。由于父故事在子任务移动之前不会移动，因此它们看不到自己感兴趣的任何内容，即使子任务移动时故事“正在进行”。啊

发行捆绑。我们通常有一系列的问题，这些问题可能紧密相关，但通常更一般。例如，与软件中的报告相关的所有问题。目前有15个已知问题。这些问题可能出现在系统中的不同报告上，并有具体的复制步骤等。当我们准备冲刺时，我们将选择这些相关问题的捆绑包。原因是QA可以更有效地测试通常在一个过程中相关的一系列小修复，而不是将每个报告作为单独的过程进行测试

目前，我们将每个问题移动到捆绑包的子任务中。例如，捆绑包可以简单地称为“Report Fixes 1”，它将有5个子任务，这些子任务都是技术性的，每个子任务都是要修复的不同报告bug。然后，我们可以将上面的过程控制项添加到整个捆绑包中。我们还知道，在包中的所有项目都完成之前，我们不会合并，因此它们都得到相同的版本

但是，如上所述，可见性会降低，因为现在子任务在捆绑包中，您无法轻松查看它们的状态

再说一遍，最佳实践？思想？其他人是如何处理这件事的？

布赖恩

您是否考虑过将您的流程子任务（同行评审、构建）和您的Scrum委员会“BIN”（待定、等待行动）结合起来？子任务是JIRA中提供并行任务的常用方式，但您描述整个过程的方式听起来更线性。如果每个故事真的从一个受让人跳到另一个受让人，只需更改受让人和状态即可

对我来说，“问题捆绑”听起来像《绿霍珀》中的史诗。您还可以使用标签字段（标准或自定义）对问题进行类似的分组

---

~Matt

以下是我们处理此事的方式-

您提到的流程子任务是我们实现中的状态。因此，我将把故事分解为开发人员完成的技术任务，然后将故事移动到“待定审查”状态，从那里进行构建和QA测试等等。马特也是这么说的。这个工作流程为涉众提供了sprint进展的感觉，因此非常有用

因此，JIRA中没有什么比最佳实践更好的了，它非常灵活，人们可以按照自己想要/需要的方式使用它

---

我同意你的观点，史诗不是一个完整的解决方案。我们通过添加标签并基于这些过滤器创建过滤器和泳道来克服这一问题。

我不确定我是否理解响应的第一项。在我们的设置中挂起基本上意味着没有采取任何行动（打开/新建）。等待操作表示有人已经投入了一些精力，但可能已经停止（等待支持人员向我们更新复制步骤，等待客户回电提供有关功能请求的更多详细信息，等等）。我们目前使用单独的子任务，因为我们希望提供步骤的可见性。我的部分问题是“这是最好的吗？”。在你的回答中，我没有看到任何关于它如何不是最好的描述。关于第二个回答。史诗，我们试过史诗。我发现它们有点有限，我不确定史诗中的物品流。例如，epic中的所有项目都不会在黑板上分组。这对我们没有好处。当我们使用白板时，我们可以通过在分组的项目周围画线或使用相同颜色的post-it注释对分组的项目进行分组。两者都是整个过程非常好的视觉指标。与上面的列和子任务相同。这种方法也能很好地指明谁有下一个步骤