TFS 2012 Scrum模板的Bug报告

一些bug是在客户或其他人发布的代码中发现的，另一些bug是在sprint的开发过程中内部发现的

因此，当查看某个版本的积压工作内容时，我不知道应该向客户传达哪些bug修复，哪些只是内部信息

---

这方面有什么最佳实践吗？您是否使用命名约定，或者可以更改模板以更好地满足我们的需要？

这就是我如何处理发布错误的方法

bug只是另一个PBI，并添加到产品待办事项列表中。PO然后对缺陷进行分类，并将其与其他工作一起订购，因为一些缺陷是关键的，而其他缺陷可以用于下一个版本，然后其他缺陷是低价值和装饰性的

从编码的角度来看，我对下一版本、生产和服务包使用了分支策略

在系统选项卡上，对于缺陷，我使用在构建中找到的来确定它是哪个构建，例如dev、release、SP

然后，我计划在sprint中使用iteration字段修复它，就像其他任何PBI一样

---

面临的挑战是，许多团队都在与构建编号和构建进行斗争，如果是这种情况，您可能希望在bug中添加一个额外的字段，以指示要使用的分支。如果你是偏执狂，在上面建立一个自定义规则，验证链接到需求的签入是否在正确的分支上（使用字段）。

这就是我处理发布错误的方法

bug只是另一个PBI，并添加到产品待办事项列表中。PO然后对缺陷进行分类，并将其与其他工作一起订购，因为一些缺陷是关键的，而其他缺陷可以用于下一个版本，然后其他缺陷是低价值和装饰性的

从编码的角度来看，我对下一版本、生产和服务包使用了分支策略

在系统选项卡上，对于缺陷，我使用在构建中找到的来确定它是哪个构建，例如dev、release、SP

然后，我计划在sprint中使用iteration字段修复它，就像其他任何PBI一样

面临的挑战是，许多团队都在与构建编号和构建进行斗争，如果是这种情况，您可能希望在bug中添加一个额外的字段，以指示要使用的分支。如果您是偏执狂，请在上构建一个自定义规则，以验证链接到需求的签入是否在正确的分支上（使用字段）