【问题标题】:Flat list of work items with restriction on parent's Iteration path限制父级迭代路径的工作项的平面列表
【发布时间】:2014-11-19 03:15:43
【问题描述】:

我想要一个向我显示此迭代的未解决错误的查询。 我们的迭代设置在产品积压项目上。

目前我有一个“工作项树”查询。 我首先匹配顶级工作项以获得正确的迭代路径。 然后我过滤类型错误等的孩子。

这为我提供了正确的子项,但也包括所有 PBI 项。 尤其是现在物品的数量是错误的。

我想要的是一个只有错误的列表(最好是扁平的)。

我可以做类似 Parent.IterationPath = "myIterationPath" 的事情吗?

【问题讨论】:

  • 我会考虑切换到 Scrum 模板(唯一可以真正自称为敏捷的模板),因为 bug 会在它们应该出现的地方积压。
  • 如果你在 scrum 模板上,那么 bug 就在积压中,并最终出现在迭代中。那么它只是一个平面查询。
  • 那么,你的意思是bug的迭代路径应该和它们的父级一样?我是这里团队的新手,我将不得不问这些路径的起源是什么。
  • 是的 - 交互中的错误应该有迭代的路径。这是 VS 和 MTM 中开箱即用的行为。
  • 看起来 bug 有它们被发现的路径,但这可能与解决它们的 sprint 不同。如果它们应该始终与它们的父级相同,那么为什么它们有自己的自己的价值?

标签: tfs tfs-workitem


【解决方案1】:

您需要颠倒查询。

使用“带有直接链接的工作项”查询类型将错误添加到顶部,并在底部添加当前迭代的 PBI。

【讨论】:

  • 这给了我每一个错误,它的父级在下面,实际上是项目总数的两倍
【解决方案2】:

迭代中存在的所有错误都应该具有正确的迭代路径。对于团队在工具中创建的错误,这是开箱即用的行为。

您使用术语 PBI,所以我只能假设您使用 Scrum 模板。在 scrum 模板中,bug 与 PBI 处于同一级别,并且在积压中。虽然它们可能与 PBI 相关,但这不是父/子关系。

如果你有一个不需要优先级的小错误,你应该考虑创建一个任务来代替。

【讨论】:

  • 这可能是正确的解决方案,尽管这需要一些努力来切换进程。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-11-28
  • 1970-01-01
  • 2018-07-24
  • 2017-08-15
  • 1970-01-01
  • 2010-09-12
相关资源
最近更新 更多