我的团队要求我在 PBI 工作流程中添加所有这些状态。
新的， 优先级， 设计， 商业评论， 它审查， 得到正式认可的， 坚定的， 开发中， 开发完成， 质量检查测试， 准备好 UAT， 发布到 UAT， UAT 测试， 在 UAT 中可用， 准备生产， 发布， 重新打开， 已解决。
我知道我们可以通过使用 Tasks 或 Reason 字段来完成相同的工作，我们必须保持工作流程“简单”，但我的团队坚持使用单个字段（状态）来跟踪它，以便清楚。我想知道这是否是个好主意。
感谢您的想法和反馈。
【问题讨论】：
我们不能说有多少州是合理的或最好的。 TFS 是可扩展和可定制的，它专为客户设计就能满足组织的需求。
但正如我们所知，您定义的状态越多，您必须定义的转换就越多。维护和进一步升级将更加复杂。更改工作项的工作流状态，特别是任务和需求类别中的工作流状态，可能会对现有功能以及未来的升级造成意想不到的挑战。更改为需求类型（Scrum 的产品待办事项和错误、敏捷的用户故事和 CMMI 的需求）将需要修改敏捷或看板板。它们也肯定会阻止自动简单的模板升级。
自定义应经过深思熟虑，您可以考虑添加一个不会影响现有报告和升级的新“customStatus”字段，而不是更改现有的 State 字段。
一个不错的博客供你参考：http://blog.nwcadence.com/tfs-customization-pitfalls-payoffs/
【讨论】：
这是您可以考虑的另一种选择，但您不一定需要修改状态。您可以使用可以在看板上设置的Board Columns。对于每一列，您可以选择包含 Doing 和 Done 的拆分，这可能意味着您需要更少的状态。
然后您可以查询 Board Column 而不是 State
在设置我们的 TFS 时，我的情况与您类似（尽管没有像要求的那样多的状态！），我最终选择了 Board Columns。这是我们的，它似乎对我们有用：
除了开发中之外，所有这些都没有拆分，因为当开发完成时，它不一定准备好进行测试。
此功能随 TFS 2015 Update 1 提供，因此如果您不在该版本上，则需要升级。
下面是我们如何使用每个状态：
【讨论】：