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

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 提供事实和引用来回答它.

1年前关闭。




Improve this question




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

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

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

“该系统应提供一种允许参与者搜索研究的方法。”

“系统应提供允许参与者搜索项目的方法。”

“系统应为入站包裹生成移动事件。”

“要导入条形码 list ，系统应在每个 sample 占位符中包含一个代码，说明 sample 是由条形码 list 创建的。”

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

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

看来我们应该遵循“实现”选项卡中“需求”->“任务”之间的“父/子”关系。然而，这意味着我们对每个需求都有一个任务(这似乎是多余的并且过于细化)。

我们喜欢将任务视为不那么精细的东西(即“开发出站控制台屏幕。”)

我们希望开发人员能够查看分配给他们的任务，并轻松查看与这些任务相关联的需求(功能性和非功能性)。

可追溯性是一个高优先级，但是，我们不一定需要它非常精细(细化到实际的代码行)。正如我们所看到的，这样做会使开发变得极其乏味和适得其反。我们希望在这方面取得合理的平衡。

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

为了添加更多上下文，我们的理解是“功能”类型的需求是更精细需求(例如功能性、非功能性、QoS)的“父级”。我们知道 Scenario 的 Requirement 类型类似于用例。

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

要求(功能)

需求(功能)

任务

显然，对我们来说的问题是，虽然我们在某些方面想要 Requirement/Task 之间的父/子关系……但我们几乎看到需要同时将 Task 作为Requirements 的父级。

我们相信我们可以跳过 Implementation 选项卡(以及它强制执行的父/子关系)......而只需使用 All Links 选项卡。这使我们能够更灵活地通过其他链接类型(例如“相关”或“影响/受影响者”)关联需求和任务……但是，最大的问题是它破坏了内置的 TFS 2010 报告(尤其是关于跟踪需求进度/小时)。

任何见解都值得赞赏。

Answer 1

听起来您需要自定义 TFS 附带的开箱即用的流程模板。

老实说，我认为每个人都应该自定义模板以确保他们获得适合他们流程的工具，而不是改变他们的流程以适合工具。

我不确定您是否知道一些可用的自定义选项，因此我将仅提及我在为我的公司自定义 TFS 时使用的一些选项。

您可以edit流程模板中开箱即用的任何工作项类型。
您可以执行许多自定义操作，例如，在我的公司中，我们只希望测试组中的人员能够关闭错误，因此我们对所有转换为关闭状态进行了限制。

您可以根据需要添加转换、状态、字段、选项卡等。

如果您想要一个新工作项，您可以从空白创建一个新工作项或基于现有工作项类型创建一个新工作项，以从现有类型创建一个新工作项，export工作项类型，编辑 xml 以将名称更改为您的新类型，然后将其导入。

您对不同工作项类型之间关系的担忧应该通过创建自定义 link types 来解决。然后将它们包含在您的新 template 中.

似乎您对要遵循的过程有很好的了解，我认为您需要自定义 TFS 以匹配该过程。

执行如此多的自定义的一个缺点是标准报告不会为您提供很多有用的信息。这将需要您的团队编写一些新报告。您还可以在 excel 中做一些不错的报告。如果那能满足您的需求。

高温高压