在TFS PBI工作流程中有多少个州是合理的？

Question

我的团队要求我在PBI工作流程中添加所有这些状态。

新， 优先级， 设计， 商业评论， IT评论， 批准， 承诺， 开发中， 发展完成， QA测试， 准备好UAT， 发布到UAT， UAT测试， 可在UAT中使用， 准备生产， 发布， 重新打开， 解决。

我知道我们可以通过使用“任务”或“原因”字段来完成相同的操作，并且我们必须保持工作流程“简单”，但我的团队坚持使用单个字段（状态）来跟踪它，以便明确。我想知道这是不是一个好主意。

感谢您的想法和反馈。

Answer 1

我们无法说出有多少州是合理的或最好的。 TFS是可扩展和可定制的，它旨在为客户提供满足组织需求的能力。

但正如我们所知，您定义的状态越多，您必须定义的转换越多。维护和进一步升级将更加复杂。更改工作项的工作流状态（特别是任务和需求类别中的工作流状态）可能会导致现有功能以及将来升级中的意外挑战。更改为需求类型（产品Backlog项目和Scrum的错误，敏捷的用户故事和CMMI的要求）将需要修改Agile或Kanban板。他们也肯定会阻止自动轻松模板升级。

应该仔细考虑自定义，而不是更改现有的State字段，您可以考虑添加一个新的＆＃34; customStatus＆＃34;不会影响现有报告和升级的领域。

一个很好的博客供您参考：http://blog.nwcadence.com/tfs-customization-pitfalls-payoffs/

Answer 2

这是您考虑的另一个选择，但您不一定需要修改状态。您可以使用可在Kanban板上设置的 Board Columns 。对于每列，您可以选择拆分包含执行和完成，这可能意味着您需要更少的状态。

然后，您可以在 Board Column 上查询，而不是状态

在设置我们的TFS时，我遇到了类似的情况（虽然没有那么多州请求！）我最终选择了Board Columns。这是我们的，它似乎对我们有用：

除了在开发中之外，所有这些都没有拆分，因为在开发完成后，它不一定准备好进行测试。

此功能随TFS 2015 Update 1一起提供，因此如果您不在该版本上，则需要升级。

以下是我们如何使用每个州：

• 新 - 新的PBI或Bug
• 已批准 - 确认工作将完成并符合DOR（就绪定义）...（包含足够的信息，分配优先级，创建任务，创建测试计划等）
• 已提交 - 已分配给未来的sprint
• 在开发中 - 包含执行和完成
• 在测试中 - 质量保证
• 准备发布 - 已签名并准备发布
• 完成 - 已发布，DOD（已完成的定义）已完成。