我们是否错误地使用了TFS 2010？

我们的团队是TFS2010的新手。历史上，我们使用自己的业务需求矩阵（可追溯性矩阵）Excel电子表格。它具有典型的列，如：

需求ID |项目|规则组|业务规则|类型…等

我们的业务规则列如下所示：

• “该系统应提供一种手段，允许参与者搜索研究。”
• “该系统应提供一种手段，允许参与者搜索项目。”
• “系统应为入站包生成移动活动。”
• 要导入条形码舱单，系统应在每个样本占位符中包含一个代码，说明样本是由条形码舱单创建的

由于我们行业在文档、审计等方面的严格性，我们选择MSF for CMMI而不是MSF for Agile作为我们的过程模板选择

我们就如何在2010年TFS世界中实施“我们的工作方式”进行了多次讨论。我们问题的症结似乎归结为以下几点：

• 似乎我们应该遵循“实现”选项卡中“需求->任务”之间的“父/子”关系。然而，这意味着我们对每一个需求都有一个任务（这似乎是多余的和过于细化的）
• 我们喜欢将任务视为粒度较小的任务（即“开发出站控制台屏幕”）
• 我们希望开发人员能够查看分配给他们的任务，并轻松查看与这些任务相关的需求（功能性和非功能性）
• 可追溯性是一个高优先级，然而，我们不一定需要它是非常精细的（直到实际的代码行）。在我们看来，这样做会使发展变得极其乏味和适得其反。我们希望在这方面取得合理的平衡

我们的方法真的像它看起来的那样，是圆钉进方孔吗？或者，我们只是误解/遗漏了什么？我们觉得我们对各种工作项类型有很好的理解

再加上一点上下文，我们的理解是“Feature”类型的需求是更细粒度需求（如功能性、非功能性、QoS）的“父级”。我们理解场景的需求类型类似于用例

因此，我们认为TFS 2010遵循以下层次结构：

• 要求（特征）
要求（功能性）
• 任务
显然，我们面临的问题是，虽然我们在某些方面需要需求/任务之间的父/子关系……但我们几乎同时将任务的需求视为需求的父级
我们相信，我们可以跳过“实现”选项卡（以及它强制执行的父/子关系）…而只使用“所有链接”选项卡。这使我们能够更灵活地通过其他链接类型（如“相关”或“影响/受影响”）来关联需求和任务……但是，最大的问题是，它打破了内置的TFS 2010报告（特别是关于跟踪需求进度/小时）

---

非常感谢您的任何见解。
我认为您必须在这里采用定制的方法。选择对您很重要的报告和指标作为您对TFS的需求。在此基础上，设计工作项之间的链接，使您能够获得报告和指标。另外，您可能已经知道了这一点，但是任务WI确实有一个规程字段，允许它不仅仅用于开发。祝你好运
听起来您需要定制TFS附带的现成流程模板
老实说，我认为每个人都应该自定义模板，以确保他们获得适合其流程的工具，而不是更改流程以适应工具
我不确定您是否知道一些可用的定制选项，因此我只想提及一些我在为我的公司定制TFS时使用的选项
您可以选择流程模板中现成的任何工作项类型。 您可以执行很多定制，例如，在我的公司中，我们只希望测试组中的人员能够关闭bug，因此我们对所有转换到关闭状态设置了该约束
您可以根据需要添加转换、状态、字段、选项卡等
如果您想要一个新的工作项，您可以从空白或基于现有工作项类型创建一个新的工作项，若要从现有类型（即工作项类型）创建一个新的工作项，请编辑xml以将名称更改为新类型，然后导入它
您对不同工作项类型之间的关系的关注应该通过创建自定义，然后将它们包含在新的工作项中来解决
似乎您对要遵循的流程有很好的了解，我认为您需要定制TFS以匹配该流程
执行这么多定制的一个缺点是，标准报告不会为您提供太多有用的信息。这将需要您的团队编写一些新报告。如果能满足您的需要，您还可以在中做一些出色的报告

---

HTH
首先，欢迎来到TFS的世界：
你希望工作的方式没有问题。您概述的层次结构很好，TFS将支持您需要的任何一组工作项类型（WIT）和关系（链接）。“实施”选项卡以及显示与其他WIT关系的所有其他选项卡只是筛选到与您的类型相关的WIT的整个列表（即，“需求”的“实施”选项卡显示所有属于需求或任务类型且具有父/子关系的工作项）
接下来，您应该考虑您的流程需要什么工件（WIT），以及它们应该如何协同工作，并定制您的流程