1

我们所知道的: Tfs 允许我们管理错误。我们可以添加错误并将其移动到不同的状态。

我们需要什么: 我们需要在 bug 中有不同的状态,TFS 2015 不允许开箱即用,尤其是

  • 不是错误”(在 NEW > ACTIVE 之后,如果开发人员说,它不是错误)
  • “重新打开”(其中错误已从 NEW > ACTIVE > RESOLVED > CLOSED 遍历,然后在另一个 Release / Sprint 中重新打开)。

我们可以使用下面提到的哪种方法?

A-我们目前在 TFS 2015 上。我们通过 WITAdmin 方法(https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field)进行定制,它对数据库、报告的影响展望未来,迁移将是另一项努力。

B- 我们将 TFS 2015 迁移到 TFS 2017,并根据 ( https://www.visualstudio.com/en-us/docs/work/process/customize-process ) 获得开箱即用添加新状态的新功能-field#add-a-custom-field )

C- 我们需要改变我们记录错误的做法,我们需要通过 TFS 研究正确的敏捷实现,因为 AGILE 过程确实有上面提到的我们需要的这种场景。


A,B,C是我考虑过的方法。如果专家能分享他们的经验、想法和/或新方法,我将不胜感激。

4

2 回答 2

1

您要添加的“状态”不应该是状态,而最多是“原因”。您会发现设置的默认原因与您想要的开箱即用的结果相近。

由于要使敏捷规划工具正常工作,您需要根据您的配置将错误状态与用户故事或任务具有相同的状态,因此添加其他状态会产生更广泛的影响。尽量避免它。

使用 A 为特定转换添加额外的原因,并长期关注 C。

于 2016-12-22T12:07:24.827 回答
0

方法 B 仅存在于 Visual Studio Team Service 中,TFS 2017 目前没有此功能。

方法 A 将是一个不错的选择。但是您可能需要修改自定义流程才能运行向导,或者您可能必须在 TFS 升级后手动更新您的团队项目。

在以下网站上查看有关维护和升级影响 (TFS) 的更多信息,这些信息告诉我们在定制期间应该避免什么:

https://www.visualstudio.com/en-us/docs/work/customize/customize-work#maintenance-and-upgrade-implications-tfs

于 2016-12-21T04:24:58.217 回答