我管理当地县健康计划的应用程序开发小组，我们正在使用TFS来管理生产支持，开发活动和数据分析研究等各种活动。我们使用Scrum模板。
我们一直在使用On Premise TSF 2017几个月，最近开启了Epics。由于这不是一个纯粹的开发组，我们必须调整TFS术语以满足我们的需求，我想了解我们如何使用Epics / Feature / PBIs是在合理范围内还是偏离基础。
我们正在使用Epics和Features作为分类PBI的方法。我们将PBI视为具有任务的小型项目。我们发现将Epics和Features映射到下面的业务术语非常有用：
Epics =业务部门 例如。财务，索赔，客户服务 特点=倡议，应用，支持 例如。数据仓库，索赔系统，自动化生产问题
正如您所看到的，我们对Epics的使用以及我们的一些功能（自动化生产问题）没有完成日期，因为它们代表了持续存在的问题，这是一个问题吗？我们之所以选择这种结构，是因为它为我们的用户提供了一种更自然的方式来通过TFS网络界面导航PBI的迷宫，大大简化了现有的PBI并将新的PBI添加到正确的功能。
我知道还有其他领域可以用来实现这一目标，如'区域'，'价值区'，'商业价值'，甚至是迭代路径，但它们没有内在的好处Backlogs选项卡上的默认Web界面。
我们如何成功使用这样的TFS，或者我们现在应该停止重组吗？
答案 0 :(得分：0)
TFS是一个ALM工具，提供源代码管理，报告，需求管理，项目管理，自动构建，实验室管理，测试和发布管理功能。它涵盖了整个应用程序生命周期。
正如我在上述评论中所做的那样，我们通常会遵循标准流程来使用TFS。是的，正如您所说，他们都可以理解并专注于纯软件开发。 （对于与Scrum一致的常见做法，您可以参考这篇文章了解详细信息：Requirements (Epic, Feature, User Story), Task Size and Estimation in Agile and Scrum。）
但TFS只是一个帮助我们管理项目的工具。在您的场景中，它更多地基于经验或特殊要求。所以，如果这种做法适用于你的项目管理，那就没关系。