我们正在努力转向 Azure DevOps (ADO)。我们过去使用过它(当它是 VSTS 时)。看起来有点奇怪的一件事是我们将直接处理“Bug”类型的工作项,将工作直接与 Bug 相关联。
在某些文档中似乎暗示不应直接处理错误。相反,在错误下创建了子“任务”项目。
我无法找到这方面的文档。是否存在这方面的文档?在 ADO 中处理错误的最佳实践是什么?
最初,它取决于所使用的流程模板。Scrum 模板的错误等同于产品待办列表项,这意味着它们在产品待办列表中,不能是 Sprint 待办列表中的任务。敏捷模板则相反,因为在 MSF Agile 中直接针对错误报告工作是很常见的。
2013 年引入了一项功能,允许错误配置错误出现的位置:
可以在此处找到此功能的指南:
作为一名 Scrum.org 培训师,我对此也有更偏颇的看法。当您处理产品待办列表项(或用户故事,取决于您的命名约定)并在 sprint 中发现它的问题时,那么这不是错误,您只是发现了一项您不知道的任务还没有完成作为一个团队。因此,冲刺中的错误被注册为原始产品待办列表项(/用户故事)下的任务。
如果您在 sprint 中发现与手头工作无关的错误,您不会立即发现并修复它,而是将其放在产品待办列表中并与产品负责人一起找出当将其拉入冲刺是有意义的时候。然后,您将创建一个计划来修复它,作为 Sprint 计划的一部分(并像处理任何其他产品待办事项一样向 Bug 添加任务)。
在这种设置中,您永远不会直接针对错误工作,当然也不会针对错误进行代码更改。
您当然应该弄清楚什么对您和您的团队最有效,但这是一种“按书本”的方式来查看与产品待办事项列表和 Sprint 待办事项列表相关的错误。
来源:https : //scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/
| 归档时间: |
|
| 查看次数: |
1912 次 |
| 最近记录: |