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.
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.
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.
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.
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.
我认为你必须在这里采用定制的方法。选择对您来说重要的报告和指标作为您对 TFS 的要求。从这里开始，设计工作项之间的链接，以便获得报告和指标。另外，您可能已经知道这一点，但任务 WI 确实有一个学科领域，使其不仅可以用于开发。祝你好运！
I think you going to have to go with a customized approach here. Pick the reports and metrics that are important to you as your requirements for TFS. From there, design the linkage between work items in a way that gets you your reports and metrics. Also, you probably already know this, but the Task WI does have a discipline field that allows it to be used for more than just development. Good luck!
There is nothing wrong with how you wish to work. The hierarchy you outlined is fine, and TFS will support any set of Work Item Types (WITs) and relationships (links) you require them to have. The Implementation tab, and all other tabs that show relationships with other WITs are merely filters to the entire list of WITs your type is related to (i.e. the Requirement's Implementation tab shows all work items that are of type Requirement or Task, and have a parent/child relationship).
What follows, is that you should think what artifacts (WITs) your process requires, and how they should work together, and customize your process template to work as you want it to.
This is relatively simple to do, especially when you use the process editor that is part of the Team Foundation Power Tools. If you want to modify the link pages, it is all done in the layout part of the work item type.
Regarding the question of the relationship between requirements and tasks: I always view requirements as the definition of what the user / customer needs. The requirement should be more outward facing, describing the need, the goal and the desired effects (and side effects). The tasks are more inward facing, and should tell the developer how he (or she) should go about achieving the above goals.
With that in mind, I always prefer to have a developer work only on tasks. Moreover tasks should always derive from a requirement (or a bug, or a change request, and so on). A task that doesn't come up as the result of a requirement might indicate that the work is either unnecessary or poorly planned.
发布评论
评论（3）
听起来您需要自定义 TFS 附带的开箱即用的流程模板。
老实说，我认为每个人都应该自定义模板，以确保他们获得适合其流程的工具，而不是更改流程以适应工具。
我不确定您是否了解一些可用的自定义选项，因此我仅提及我在为我的公司自定义 TFS 时使用的一些选项。
您可以编辑任何流程模板中开箱即用的工作项类型。
您可以执行许多自定义操作，例如，在我的公司中，我们只希望测试组中的人员能够关闭错误，因此我们将这一约束限制在所有到关闭状态的转换上。
您可以根据需要添加转换、状态、字段、选项卡等。
如果您想要一个新工作项，您可以从空白创建一个新工作项，或者基于现有工作项类型创建一个新工作项，要从现有类型创建新工作项，导出工作项类型，编辑 xml 以将名称更改为新类型，然后导入它。
您对不同工作项类型之间关系的担忧应通过创建自定义 链接类型，然后将它们包含在新的 模板。
您似乎对要遵循的流程有很好的了解，我认为您需要自定义 TFS 以匹配该流程。
执行如此多的自定义的一个缺点是标准报告不会为您提供太多有用的信息。这将要求您的团队撰写一些新报告。您还可以在 excel 如果这能满足您的需求。
华泰
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.
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.
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.
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.
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 的要求。从这里开始，设计工作项之间的链接，以便获得报告和指标。另外，您可能已经知道这一点，但任务 WI 确实有一个学科领域，使其不仅可以用于开发。祝你好运！
I think you going to have to go with a customized approach here. Pick the reports and metrics that are important to you as your requirements for TFS. From there, design the linkage between work items in a way that gets you your reports and metrics. Also, you probably already know this, but the Task WI does have a discipline field that allows it to be used for more than just development. Good luck!
首先，欢迎来到 TFS 的世界。 :)
你希望如何工作并没有什么问题。您概述的层次结构很好，TFS 将支持您要求它们具有的任何工作项类型 (WIT) 和关系（链接）集。 Implementation 选项卡以及显示与其他 WIT 关系的所有其他选项卡仅是对与您的类型相关的整个 WIT 列表的过滤器（即需求的 Implementation 选项卡显示所有类型为要求或任务且具有父/子关系的工作项）。
接下来，您应该考虑您的流程需要哪些工件 (WIT)，以及它们应如何协同工作，并自定义您的流程模板以按您希望的方式工作。
这相对简单，尤其是当您使用 Team Foundation 电动工具。如果您想修改链接页面，这一切都可以在工作项类型的布局部分中完成。
关于需求和任务之间的关系问题：我始终将需求视为用户/客户需求的定义。需求应该更加面向外部，描述需求、目标和期望的效果（和副作用）。这些任务更加面向内部，并且应该告诉开发人员他（或她）应该如何实现上述目标。
考虑到这一点，我总是更喜欢让开发人员只处理任务。此外，任务应该始终源自需求（或错误、变更请求等）。未按照要求执行的任务可能表明该工作是不必要的或计划不周。
希望这有帮助，
阿萨夫。
First off, welcome to the world of TFS. :)
There is nothing wrong with how you wish to work. The hierarchy you outlined is fine, and TFS will support any set of Work Item Types (WITs) and relationships (links) you require them to have. The Implementation tab, and all other tabs that show relationships with other WITs are merely filters to the entire list of WITs your type is related to (i.e. the Requirement's Implementation tab shows all work items that are of type Requirement or Task, and have a parent/child relationship).
What follows, is that you should think what artifacts (WITs) your process requires, and how they should work together, and customize your process template to work as you want it to.
This is relatively simple to do, especially when you use the process editor that is part of the Team Foundation Power Tools. If you want to modify the link pages, it is all done in the layout part of the work item type.
Regarding the question of the relationship between requirements and tasks: I always view requirements as the definition of what the user / customer needs. The requirement should be more outward facing, describing the need, the goal and the desired effects (and side effects). The tasks are more inward facing, and should tell the developer how he (or she) should go about achieving the above goals.
With that in mind, I always prefer to have a developer work only on tasks. Moreover tasks should always derive from a requirement (or a bug, or a change request, and so on). A task that doesn't come up as the result of a requirement might indicate that the work is either unnecessary or poorly planned.
Hope this helps,
Assaf.