要在TFS Agile模板中添加字段还是使用默认值？

Question

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

我们需要什么： 我们需要在bug中有不同的状态，TFS 2015不允许开箱即用，特别是

• ＆＃34; 不是错误＆＃34; （在NEW＆gt; ACTIVE之后，如果开发人员说，它不是错误）
• ＆＃34;的 RE-开放＆＃34; （其中一个错误已经从NEW＆gt; ACTIVE＆gt; RESOLVED＆gt; CLOSED遍历，然后在另一个Release / Sprint中重新打开）。

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

A-我们​​目前正在使用TFS 2015.我们通过WITAdmin方法（https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field）进行自定义，它对数据库，报告和未来的影响将是另一项努力。

B-我们将TFS 2015迁移到2017年TFS并获得按照（https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-a-custom-field）

开箱即可添加新状态的新功能

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

A，B，C是我想到的方法。如果专家能够分享他们的经验，想法和/或新方法，我将不胜感激。

Answer 1

＆＃34;州＆＃34;你要添加的内容不应该是国家，而应该是最多的＃34;理由＆＃34;。您会发现默认原因设置接近您想要的开箱即用。

由于敏捷规划工具的工作原理，您需要将Bug作为用户故事或任务的相同状态，具体取决于您的配置，添加其他状态会有更广泛的后果。试着避免它。

使用A为特定转换添加其他原因，并长期关注C.

Answer 2

方法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