我们的团队在确定 sprint 中可以工作的任务时遇到了困难。我们使用 Azure DevOps 并将我们的故事和任务分配给 sprint 迭代。我们的团队工作流程以 DevOps Scrum 模板为蓝本。所有任务都是故事的子工作项。此外，我们设置了任务之间的 Successor 和 Predecessor 关系。我们还设置了故事之间的继任者和前任者关系。我们通常将故事分解成足够小的任务，这样我们就可以将一个故事蜂拥而至并更快地完成它。识别并发工作对我们的团队至关重要。
典型的 Azure DevOps Sprint 任务板
sprint 任务板看起来一团糟。每个故事都是一团任务。开发人员和测试人员很难去 sprint 任务板找到下一个打开的任务，因为他们需要查看每个故事下的每个任务，以确保一个任务的前任是关闭的。我不确定如何解释任务板视图以获取相同的信息。
典型的工作项关系
Azure DevOps 允许您可视化工作项以显示其直接的工作项关系。当故事有许多任务并且任务之间的关系很深时，这并不能提供足够的上下文。除了任务之间的前任/后继关系之外，每个任务工作项都是故事的子项。最重要的是，我们也在故事下订购任务。
老实说，我经常像上面那样创建流程图。它从头到尾为整个故事提供了清晰的视觉表现。您可以清楚地看到工作流中我们可以将工作分配给多个开发人员或测试人员的区域。我就是无法摆脱在 DevOps 中缺少某些东西的感觉……
问题：
Azure DevOps 任务板视图中的任务是否有自动顺序，它传达故事下的任务之间的前任/后继关系，而不是冲刺中任务的明确排序？
结语：我知道这个问题会收到评论说我们应该把故事分成更小的部分，或者一个开发人员应该处理一个故事，我们应该计划我们可以同时处理的故事。我和我们的团队多年来一直在尝试这种方法，这是我们完成工作的最有效方式。我为此努力了很长时间，但事实是团队在这种工作分解方面做得非常好——除了确定下一步要工作的事情。