背景： JIRA为项目中的所有类型的问题提供单一的状态。
问题： 问题是为任务设置的状态是ToDo，InProgress和Done。而对于同一项目中的UserStory，它可能是设计，开发，测试，发布和完成。它甚至可以与bug或Epic不同。
问题： 如何使用单组JIRA状态跟踪产品的工作流程，同时管理任务的状态。
PS：我知道可以为每个项目自定义它们，但它没有帮助，因为您无法单独为每种问题类型自定义它们。
答案 0 :(得分：4)
我认为JIRA提供To Do，In Progress和Done的原因之一是这些可以适用于任何事情。你要么没有做，要做某事，或者你做完了。该套装适用于任何类型的物品。
话虽这么说，但我觉得你想要更好地了解问题的真实状态。我们发现我们在OnDemand敏捷板上使用的是设置如下内容：
对于大多数类型的问题，这都可以。它增加了一些额外的层，以便能够识别准备好进行测试的内容。
其中一个棘手的问题是依赖任务。例如，我注意到你提到“设计”作为一个舞台，我不确定这在敏捷意义上是否有意义。如果设计从开发中脱颖而出，那么允许设计/开发在开发团队中流动可能会更好。但是，我们都知道，有时您需要在继续之前获得一些细节，或者可能有些人需要在开发人员进行之前参与其中。我们错误地试图将其转变为一个阶段，但我们发现这实际上是对于团队的一部分来说，或者是障碍（阻挡者）。通过标记故事，您可以确定故事需要在开发团队继续之前完成某些事情。
如果您使用的是看板而不是Scrum板，那么子任务方法将不适合您。在这些情况下，您只需要确保您拥有对您创建的所有问题都有意义的阶段。阶段必须是相当“通用的”。听起来很糟糕。
但事实并非如此！
我认为团队通常会使用这些阶段有几个原因：
更多阶段并不一定能在迭代中提供更好的状态，因为您只需要查看已关闭的点数以及正在进行的点数。所以，至少对于这个目标，一组更通用的阶段应该有效。
至于通知团队成员，我经常看到团队退回到数字板，以取代彼此之间的沟通。您拥有的阶段越少，您就越能够强迫您的团队相互交流并共同努力完成故事。事情会以这种方式更好地发挥作用，我保证！稍微分解有助于，特别是如果您一次处理大量项目或让分布式团队在不同时区工作，但保持简单通常会更好。
跟踪通用阶段最难做的“接近完成程度”。但是，多个阶段可能会产生误导。几乎所有方式的项目可能都有一个尚未找到的严重错误，因此无论您对这个项目有多少个阶段，您都不会比单个“进行中”更准确阶段。直到完成它才完成：）
对我来说，建议保持工作流程简单并让团队使用沟通来掌握最新功能，这还有很长的路要走。也许我应该刚刚开始！
答案 1 :(得分：2)
每个项目可用的状态由分配给它的工作流程确定。工作流不仅定义了状态，还定义了可以从特定状态进行的状态。您可以创建自己的工作流程，也可以下载满足您需求的预定义工作流程。 为了为不同的问题类型提供单独的工作流，我们需要定义一个工作流程方案：
1-转到Jira管理 - ＆gt;工作流程方案
2-编辑分配给项目的Wokflow方案
3-单击“添加工作流”，为需要不同工作流的问题类型添加新工作流，并分配这些问题类型。