我们是否错误地使用了 TFS 2010? [英] Are we using TFS 2010 incorrectly?

问题描述

我们的团队是 TFS2010 的新手.过去，我们一直使用我们自己的业务需求矩阵(可追溯性矩阵)Excel 电子表格.它具有典型的列，例如:

Our team is new to TFS2010. Historically, we have used our own Business Requirements Matrix (traceability matrix) Excel spreadsheet. It has typical columns like:

需求 ID |项目 |规则组 |商业规则 |输入...等

Requirement ID | Project | Rule Group | Business Rule | Type ...etc

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

Our Business Rule column reads something like the following:

• 系统应提供一种方法，允许参与者搜索研究."
• 系统应提供一种方法，允许参与者搜索项目."
• 系统应为入库包裹生成移动活动."
• 要导入条形码清单，系统应在每个样本占位符中包含一个代码，说明样本是由条形码清单创建的."

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

Due to the rigor of our industry regarding documentation, audits, etc, we opted for MSF for CMMI instead of MSF for Agile as our Process Template choice.

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

We have had numerous discussions about the best way to go about implementing "the way we work" into the TFS 2010 world. The crux of our problems seem to come down to the following:

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

• It seems like we should follow the "parent/child" relationship between Requirement -> Task in the Implementation tab. However, this means that we have a task for every Requirement (which seems redundant and overly granular).
• We like to think of a Task as something less granular (i.e. "Develop an Outbound Console screen.")
• We would like for the developer to be able to look at the Tasks assigned to them, and easily see what Requirements (Functional and Non-Functional) are associated with those Tasks.
• Traceability is a high-priority, however, we don't necessarily need it to be extremely granular (down to actual lines of code). As we see it, doing so would make development extremely tedious and counter-productive. We want a sensible balance in this respect.

我们的方法真的是圆钉插入方孔吗?或者，我们只是误解/遗漏了什么?我们觉得我们对各种工作项类型有了充分的了解.

Is our approach really the round-peg into square-hole that it seems to be? Or, are we just misunderstanding/missing something? We feel like we have a sound understanding of the various Work Item Types.

为了添加更多上下文，我们的理解是功能"类型的需求是更细粒度的需求(例如功能性、非功能性、QoS)的父级".我们知道场景的需求类型类似于用例.

To add a bit more context, our understanding is that Requirements of type "Feature" are the "parent" of more granular requirements such as Functional, Non-Functional, QoS. We understand that the Requirement type of Scenario is analogous to a Use Case.

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

So, we believe that TFS 2010 follows this hierarchy:

• 要求(功能)
• 需求(功能性)
• 任务

显然，我们的问题是，虽然我们希望在某些方面需要 Requirement/Task 之间的父/子关系……但我们几乎同时看到了 Task 需要作为 Requirements 的父级.

Obviously, the problem for us is that while we want the parent/child relationship between Requirement/Task in some respects...we almost see the need for a Task as the parent of Requirements at the same time.

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

We believe that we could skip the Implementation tab (and the parent/child relationship it enforces)...and just use the All Links tab. This allows us more flexibility to relate Requirements and Tasks via other Link Types such as "Related" or "Affects/Affected By"...but, the big catch there, is that it breaks the built-in TFS 2010 reporting (especially regarding tracking Requirement progress/hours).

感谢任何见解.

推荐答案

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

It sounds like you need to customize the out of the box process template that comes with TFS.

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

To be honest I think everyone should customize the templates to make sure they get the tools to fit their process, not change their process to fit the tools.

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

I'm not sure if you're aware of some of the customization options that are available so I'll just mention some of the ones I've used when customizing TFS for my company.

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

You can edit any work item type that comes out of the box in the process template. There are lots of customizations you can perform, for example, in my company we only wanted people in the test group to be able to close bugs, so we put that constraint on all transitions to the closed state.

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

You can add transitions, states, fields, tabs etc. as required.

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

If you want a new work item you can create a new one from blank or base one on an existing work item type, to create a new one from an existing type, export the work item type, edit the xml to change the name to your new type and then import it.

您对不同工作项类型之间关系的担忧应通过创建自定义链接类型，然后将它们包含在您的新 模板.

The concerns you have about relationship between the different work item types should be addressed by creating custom link types and then including them in your new template.

您似乎很清楚要遵循的流程，我认为您需要自定义 TFS 以匹配该流程.

It seems like you have a good sense of the process you want to follow, I think you need to customize TFS to match that process.

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

The one drawback about performing this much customization is that the standard reports won't provide you with much useful info. This will require your team to write some new reports. You can also do some nice reporting in excel if that would meet your needs.

HTH

这篇关于我们是否错误地使用了 TFS 2010?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！