我认为JIRA提供要做的、正在做的和已经做的事情的原因之一是这些可以适用于任何事情。你要么没有做，要么你做了什么，要么你完成了。该集合可以应用于任何类型的项。

话虽如此，我感受到你的痛苦，因为我想更好地看待问题的真实状况。我们在OnDemand敏捷板中使用的是设置如下内容：

去做正在进行中准备好接受审查在审查中完成

对于大多数类型的问题，这是可行的。它增加了一些额外的层，以确定什么是准备好的测试。

其中一个棘手的事情是依赖的任务。例如，我注意到您提到了“设计”作为一个阶段，我不确定这在敏捷的意义上是否合理。如果设计是从开发中产生的，那么最好允许设计/开发在开发团队中流动。但是，我们都知道，有时您需要在处理之前解决一些细节，或者在开发人员能够继续之前，可能有一些人需要参与进来。我们犯了一个错误，试图把它变成一个阶段，但我们发现，这实际上要么是团队的一部分的子任务，要么是障碍(阻碍者)。通过标记故事，您可以识别一个故事需要在开发团队进行之前做一些事情。

如果您使用的是看板，而不是Scrum板，那么子任务方法将不适合您。在这些情况下，您只需要确保您的阶段对您创建的所有问题都有意义。阶段必须是相当“通用”的。这听起来很糟糕。

但事实并非如此！

我相信球队使用这个阶段通常有以下几个原因：

检查迭代的状态通知其他团队成员他们可以拿起一件物品。试着从视觉上估计出问题发生的距离有多近。

在迭代中，更多的阶段并不一定会给出更好的状态，因为您只需要查看您已经关闭了多少个点，以及有多少正在进行中。因此，至少为了实现这一目标，一套更通用的阶段应该能发挥作用。

至于告知团队成员，我经常看到团队撤退到数字董事会，以取代彼此之间的交流。你拥有的阶段越少，你就越能强迫你的团队互相交谈，一起工作来完成一个故事。事情这样会更好的，我保证！进行一些分解会有所帮助，特别是当您同时处理许多项目或在不同的时区中分配团队时，但是保持简单通常更好。

跟踪“有多接近完成”是最难做的通用阶段。然而，多个阶段可能会产生误导。一个项目几乎所有的跨越可能有一个严重的错误，但尚未发现，因此，无论您有多少个阶段，您对这个项目的看法并不比一个单一的“正在进行”阶段更准确。直到它完成，它才完成:)

对于我来说，这是一条很长的路，我建议让你的工作流程保持简单，让你的团队利用沟通来控制事情。也许我应该从这个开始！