Dan*_*iel 3 agile workflow jira
背景：JIRA为项目中的所有类型的问题提供了一套状态。
问题：问题在于为任务设置的状态为ToDo，InProgress和Done。对于同一项目中的UserStory，可能是设计，开发，测试，发布和完成。错误或Epic甚至可能不同。
问题：如何跟踪产品的工作流程，同时如何使用一组JIRA状态来管理任务的状态。
PS：我知道可以为每个项目自定义它们，但这无济于事，因为您不能分别为每个问题类型自定义它们。
我认为JIRA提供“待办事项”，“进行中”和“完成”的原因之一是，它们可以适用于任何事物。您要么没有做，要么在做某事，或者您完成了。该集合可以应用于任何类型的项目。
话虽如此，我感到您为想要更好地了解问题的真实状态而感到痛苦。我们发现用于OnDemand敏捷板的是建立类似于以下内容的东西：
对于大多数类型的问题，这都可以解决。它增加了一点额外的层，以便能够识别准备进行测试的内容。
棘手的事情之一是依赖任务。例如，我注意到您提到“设计”是一个阶段，但我不确定这在敏捷意义上是否有意义。如果设计是从开发中衍生出来的，那么最好允许设计/开发在开发团队中流动。但是，我们都知道，有时您需要先弄清一些细节，然后才能继续进行，或者可能有些人需要参与才能进行开发。我们犯了试图将其变成一个阶段的错误，但是我们发现这确实是团队一部分的子任务，或者是障碍（阻碍者）。通过标记故事，您可以确定故事需要在开发团队进行之前完成一些工作。
如果您使用的是看板，而不是Scrum板，则子任务方法将不适合您。在这种情况下，您只需要确保您具有对您创建的所有问题都有意义的阶段即可。阶段必须相当“通用”。听起来不好
但这不是！
我认为团队通常使用这些阶段有以下几个原因：
更多的阶段不一定会在迭代中提供更好的状态，因为您只需要查看已关闭的点数和正在进行的点数即可。因此，至少对于该目标，应该使用一组更通用的阶段。
至于通知团队成员，我经常看到团队撤退到数字董事会以取代彼此的交流。您拥有的阶段越少，您就可以迫使您的团队互相交谈并共同努力完成故事。我保证，这样会更好。进行细微的分类会有所帮助，尤其是当您一次处理很多项目或在不同时区有分散的团队工作时，但保持简单通常会更好。
跟踪通用阶段的“完成距离”是最困难的。但是，多个阶段可能会产生误导。几乎所有项目都可能存在尚未发现的严重错误，因此，无论您对项目有多少个阶段的看法，都不会比单个“进行中”更为准确阶段。直到完成才完成:)
对于我来说，建议您简化工作流程并让您的团队使用沟通来保持最重要状态是很长的路要走。也许我应该从此开始！