如果Bugs与PBI处于同一水平，我怎么知道TFS 2015中的bug来自何处？

Question

我们的主管心态是，如果将来发现一个错误，他想要这样做：

1. 查找描述无法正常工作的功能的PBI。
2. 将PBI更新为当前的Sprint。
3. 创建一个Bug并将其放在该PBI下。
4. 创建一个任务并将其放在该Bug下。
   • 这背后的理由是他认为PBI没有正确完成，因此必须重新打开，他希望Bug在PBI下，以便他知道哪些功能无法正常工作。 / LI>

我认为正确的方式实际上只有2个选项：

1. 在未来的迭代中找到与PBI相同级别的Bugs - 创建Bug但只是尽可能具有描述性，以便您知道问题的功能。
2. 将Bugs视为一项任务，因此要么创建一个新的PBI，要么将之前的PBI复制\移动到当前的sprint，并将Bug放在该PBI下，但是DON＆＃T; T在Bug下创建一个任务， Bug本质上是一项任务。

我们的商店会有什么解决方案？

Answer 1

实际上，您只需要关联工作项（PBI＆gt; Bug＆gt; Task）。创建关联后，您可以在相关工作下找到链接的工作项。

在我看来，两种选择都可以。您提到的两个选项仅反映了积压和板上显示的工作项。但是，如果您已经关联了相关的PBIs，Bugs，Tasks，那么打开任何工作项就可以找到它们之间的关系（父/子 〜那里的bug来自。）

例如：

1. 将错误处理与PBI（Bugs are managed with requirements）
处于同一级别



1. 将错误视为任务（Bugs are managed with tasks）



<强>更新

他们都无法完全实现您的要求（没有更好的方法来实现基于当前功能）。

但是，如果您更关心错误的来源，那么选项2 （Treat the Bugs as a Task）会更好，因为它可以在积压中直观地显示依赖关系/关系（Bug在特定的PBI）。

如果您更关心工作项的层次结构，那么 option1 （Treat Bugs at the same level as PBIs）会更好（PBI > Bug > Task）。

无论您通过related link找到错误来自哪里。

Answer 2

我工作的很多团队都采用以下两种方式之一对错误进行分类：

• 在sprint中发现的短片中发现的短片
• 所有其他错误

对于在sprint中发现的错误，他们将它们与工作项相关联。所有其他错误都被视为独立的积压项目。

这有几个原因，包括：

• 在工作完成后的某个时间发现错误时，可能很难找出与之关联的工作项
• 并非所有错误都巧妙地与单个工作项相关联，特别是那些未在sprint
中找到的工作项
• 应该立即解决在sprint中发现的错误，或者工作项通常不符合已完成的定义
• 从sprint中发现的错误需要与其他工作项一起优先考虑

除非您特别需要将错误与工作项相关联（例如，它是计费机制的一部分），否则您为此付出的任何努力都可能被视为浪费。将冲刺中的错误与工作项相关联不需要太多努力，因此不会产生太多浪费。使用sprint项目进行这项工作通常会花费很多时间，并且很难证明其合理性。