背景: JIRA 为项目中的所有类型问题提供一组状态。
问题: 问题在于任务的状态设置为“ToDo”、“InProgress”和“Done”。而对于同一项目中的 UserStory 来说，它可能是设计、开发、测试、发布和完成。对于 bug 或 Epic 来说甚至可能有所不同。
问题: 如何跟踪产品的工作流程，同时使用单组 JIRA 状态管理任务的状态。
PS:我知道它们可以针对每个项目进行自定义，但这没有帮助，因为您无法单独针对每个问题类型自定义它们。
最佳答案
我认为 JIRA 提供“待办事项”、“进行中”和“已完成”的原因之一是这些可以适用于任何事情。你要么还没有做，要么你正在做某事，要么你已经完成了。该集合可以应用于任何类型的项目。
话虽这么说，我感受到您想要更好地了解问题真实状况的痛苦。我们发现我们在 OnDemand 敏捷面板中使用的是设置如下内容:
- 待办事项
- 进行中
- 准备审核
- 审核中
- 完成
对于大多数类型的问题，这都是可行的。它添加了一点额外的层，以便能够识别准备测试的内容。
棘手的事情之一是相关任务。例如，我注意到您提到“设计”作为一个阶段，但我不确定这在敏捷意义上是否有意义。如果设计是从开发中产生的，那么最好让设计/开发在开发团队内流动。然而，我们都知道，有时您需要先解决一些细节才能继续，或者可能需要一些人参与才能继续开发。我们犯了一个错误，试图将其变成一个阶段，但我们发现这实际上要么是团队部分人员的子任务，要么是障碍(阻碍)。通过标记故事，您可以确定故事需要在开发团队继续之前完成某些操作。
如果您使用的是看板，而不是 Scrum 板，则子任务方法将不适合您。在这些情况下，您只需要确保您的阶段对您创建的所有问题都有意义。阶段必须相当“通用”。这听起来很糟糕。
但事实并非如此!
我相信团队通常使用这些阶段有以下几个原因:
- 检查迭代状态
- 通知其他团队成员他们可以领取元素
- 尝试直观地估计问题距离完成的程度。
更多阶段并不一定会在迭代中提供更好的状态，因为您实际上只需要查看已关闭的点以及正在进行的点。因此，至少对于这个目标，一组更通用的阶段应该有效。
至于通知团队成员，我经常看到团队退回到数字板以取代彼此之间的沟通。你的阶段越少，你就越能迫使你的团队互相交谈并共同努力完成一个故事。这样事情会进展得更好，我保证!进行一些分割会有所帮助，特别是当您同时处理许多项目或有分散的团队在不同时区工作时，但保持简单通常会更好。
跟踪“距离完成有多近”是通用阶段最难做到的。然而，多个阶段可能会产生误导。几乎完全跨越的项目可能存在尚未发现的严重错误，因此无论您对该项目有多少个阶段的看法，都不会比单个“进行中”更准确阶段。直到完成才算完成:)
对于我来说，建议保持工作流程简单并让您的团队通过沟通来掌握最新情况是很长的路要走。也许我应该从那开始!
关于workflow - 如何在 JIRA 中定义列和状态以使所有问题类型(任务、史诗等)都有意义，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21896021/