Tfs 我可以将Epics等同于一个业务部门吗？

我管理一个地方县卫生计划的应用程序开发组，我们使用TFS管理生产支持、开发活动和数据分析研究等活动。我们使用Scrum模板

几个月来，我们一直在使用内部TSF 2017，最近又打开了Epics。由于这不是一个纯粹的开发团队，我们不得不调整TFS条款以满足我们的需求，我想了解我们如何使用Epics/Feature/PBI是合理的还是偏离了基础

我们使用Epics和Features只是作为对PBI进行分类的一种方式。我们将PBI视为具有任务的小项目。我们发现将Epics和功能映射到下面的业务术语非常有用：

Epics=业务单位 例如财务、索赔、客户服务 功能=主动性、应用程序、支持 例如，数据仓库、索赔系统、自动化生产问题

正如您所看到的，我们对Epics和一些功能（自动化生产问题）的使用没有一个完成日期，因为它们代表了持续的关注，这是一个问题吗？我们之所以选择这种结构，是因为它为我们的用户提供了一种更自然的方式，通过TFS web界面浏览错综复杂的PBI，从而大大简化了现有PBI的查找，并为正确的功能添加了新的PBI

我知道我们还可以使用其他字段来实现这一点，比如“区域”、“价值区域”、“业务价值”，甚至迭代路径，但它们没有通过Backlog选项卡上的默认web界面向下钻取的内置好处

---

我们这样使用TFS能取得多大的成功？或者我们现在应该停止并重新构建吗？

TFS是一个ALM工具，提供源代码管理、报告、需求管理、项目管理、自动化构建、实验室管理、测试和发布管理功能。它涵盖了整个应用程序生命周期

---

正如我在上述评论中提到的，通常我们将遵循标准流程来使用TFS。是的，正如你所说的，他们都是可以理解的，并且专注于纯软件开发。（对于与Scrum一致的常见实践，您可以参考本文了解详细信息：）

---

但是TFS只是一个帮助我们管理项目的工具。在您的场景中，它更多地基于经验或特殊需求。因此，如果这种做法适用于您的项目管理，那么它是可以的

对于与Scrum框架一致的常见实践，您可以参考本文了解详细信息：。但是TFS只是一个帮助我们管理项目的工具。因此，如果这种做法适用于您的项目管理，那么就没关系了。Andy，感谢您再次保证我们可以以这种方式使用TFS。谢谢你的链接。我读过这些文档和其他类似的文档，但可以理解，它们都专注于纯软件开发。