将工作项目相互联系起来

经常有人询问要如何将工作项目之间彼此联系起来。这一问题看似简单但要回答这一问题往往非常复杂。

　　在Team Foundation Server2008中这一问题比在TFS2010中要更为突出。TFS2008 没有层级工作项目的优势，但是即便是有了这种优势，要修复工作项目的结构也是既重要又有难度。因此有没有一个好的方法能解决这一问题呢?

　　在本文中，我们会要看一看用于CMMI/process Improvement 模板的MSF。为什么这里省去了Agile模板呢?相比较而言，它有些简单，因为里面没有Change Request，这项请求添加了额外的难度。为了解决这一问题，笔者假设Agile模板中的Scenario等同于CMMI模板中的 Requirement。

　　纵观2008和2010两个版本中所有的工作项目层级，Requirement通常顶级的项目。该工作项目对期望的性能进行了展示，即便是如此也引发了问题。Requirement是用户能理解的目标。而Task就从属于Requirements。Task列出了程序员要完成Requirement所需要进行的操作列表。它们存在是为了做两件事：为程序员提供方法分解Requirement，使其成为可以管理的任务;允许团队追踪Requirement的进展。

　　在TFS2008中，其关系甚至更为重要因为你无法在毫不费力的情况下查询过去的某个环节。为了进一步说明这一点，你可以想象一下自己拥有Requirement中Task与另一个Task有关联。你无法轻易确定Requirment由两个Task组成。

　　这就出现了我们之前提到的TFS2008中的Requirements问题。

　　将Requirement视为一个usecase。一个Use Case由Normal path和0-n Alternate Paths以及Exceptions Paths组成。除非Use Case太大而不能评估或编写，否则每条通向Use Case的路径应该都是合乎逻辑的分解。Alternate和Exception 路径是已有性能的修改。因此主要的Requirement或许是带有子请求的Use Case，且与主要的请求有关联。

　　这样以来运行报告很难对状态进行追踪。记住在创建层级的时候要将这一点考虑进来。在TFS2010中，就不存在这个问题因为Parent/Child link Type告诉了我们上一层级和下一层级分别是什么。

　　现在，让我们继续往下。Change Requests应该只与Requirements有关系。不存在默认的用于识别Task的Change Request。但是，Change Request可能与多个Requirement相关联。要注意报告过程中本身就产生了问题因为Change Request可以重复计算。

　　漏洞也仅与出现异常的Requirement相关，因为Requirement不能运行而这也是用户所关心的问题。这就是你使用Test Case Work Item Type时所产生的异常。在2010里面，这是嵌入型的。在2008中，我们推荐客户创建自定义的Test Case WIT。在本例中，一个漏洞可以与Test Case相关联，事实上，这也是我们所希望的因为这意味着你在一个稳固的测试进程中发现了漏洞。这样也会导致报告中出现重复计算的问题。

　　任务可能涉及Change Request因为它请求分解由Change Request启动的工作。

　　

　　这其中的简单关系在上图所示。了解这一点后，你就可以轻松实现Requirements树以及代码与Requirement之间的关系。