【IT168 技术文档】

    介绍

    工作事件跟踪（WIT）是Microsoft Visual Studio 2005 Team System中的一个新特性，这一新特性不只帮助开发者，也帮助我们的项目经理，分析者和测试者。作为名称指示，工作事件跟踪提供了一个跟踪多种项目的跟踪方法，而这些项目是在开发项目中作为个体必不可少的部分。工作项目在项目计划，bug列表和特性列表方面与任务列表没有区别，有所不同的是如何在Visual Studio Team System中整合工作项目跟踪。这篇文章包括多种项目组成员如何确认工作项目跟踪系统，以用来提升软件开发项目的价值。

    最初的用户使用工作事件跟踪包括所有人直接相关的开发处理过程：项目经理，分析者，开发者和测试者。而其他的个体，例如商业赞助商，则通过视图报告间接的使用工作项目系统。

    Visual Studio Team System提供多个版本来提供这个新特性以用来满足不同类型的个体用户的需求。其中一个版本将是团队资源管理器，一个基于Visual Studio IDE的客户端工具，但是这个工具要求特性连接到Team Foundation Server。

    Team Explorer 窗口

    Visual Studio Team Editions (架构师,开发者，测试者和团队资源管理器) 包括连接Team Foundation Server (TFS)的能力. 用户可以使用Team Explorer窗口在TFS中添加项目。在Team Explorer窗口中允许用户查看和创建新的工作事件（见图1）工作项目数据和多样的工作事件类型在你所选择的方法模板中被定义，当创建一个新的团队项目时，我们要在选项中选择一个方法模板以用于这个项目，例如，为了灵活的软件项目开发选择MSF创建一些标准工作事件作为处理的一部分。此外，为了灵活的软件项目开发而选择的MSF使用五个明显的工作事件：场景，任务，服务需求质量，bug和风险，在Team Explorer中整合了团队资源管理器应用程序，同时也被作为团队基础客户提及。
图 1. 添加新的工作事件

    工作事件的项目管理

    项目经理可能是最了解工作事件跟踪的，他们工作中重要的一部分就是负责创建和管理多样的任务，他们通常负责映射出整个开发项目完成所必须的所有任务。在Visual Studio Team System中的工作事件跟踪将会允许他们获得他们现在正要做的工作，并且使得他们在项目中更加具有影响力。

    作为一个新的团队项目的一部分，项目经理将会选择合适的处理模板。这个处理模板将会为工作时间类型，项目的初始工作事件列表和其他的例如文档模板和处理向导文件等等提供定义。模板是基于项目的类型选择的。例如，一个小型的非正规的内网应用程序可以使用一个基于一个少量非正规的处理，例如一个灵活的软件开发模板MSF，然而一些更大的工程，例如一个飞机飞行控制系统将会要求一个更加正式的处理过程，例如CMMI处理改进的MSF。我们选择的处理模板的类型是非常重要的，因为在工程中他是不能被修改的，软件的更高的版本可以根据不同的处理模板处理，当然工作事件的列表和文档库的内容将会在工程中修改。项目经理安装了Team Explorer（原来叫做Team Foundation Client）将会连接团队基础服务器和从Excel 和Project中输入输出工作表的数据，在计算机上实现安装了Team Explorer后，项目经理将会希望安装Microsoft Excel 或Microsoft Project

    用于Microsoft .NET协同工作能力。一旦安装完成，在Project 和 Excel中将添加一个新的菜单选项（看图2是这样的例子）这个菜单中将会允许项目经理去连接Team Foundation Server并且从他们可以访问的服务器上的任意一个项目中下载工作事件。一旦他们按照这样的方法操作，他们也可以添加额外的事件。以用来改变资源的分配，并且完成工程的计划，当他们准备好以后，他们就可以在Team Foundation Server中使用Publish Changes选项同步他们的变化。作为单个实体，他们使用工作事件跟踪系统，将会通过运行在Visual Studio中的My Work Items query看到那些单个实体。

    为了团队成员完成任务，他们使用Visual Studio 或Team Explorer标记了那些完成的任务，项目经理将会接受到在Team Foundation Server上同步过后的升级的状态。

    Microsoft 项目整合

    安装Visual Studio Team System或者Team Explorer应用程序提供了Microsoft Project 和 Microsoft Excel的扩展。使用Microsoft Project，项目经理可以从Team Foundation Server中重新得到数据。使用Microsoft Project可以管理和计划工作。然后发布为其他的团队成员发布工作事件数据库的更新反馈。图2中就为我们展现了Microsoft Project允许工作事件同步的扩展能力。
    Microsoft Project文件自身将会被存储成为一个文档库在这个项目团队的站点中。这将允许对于文件的基本版本的控制，使得这些文档对于其他用户查看时有效。
图 2. 在Microsoft Project的工作事件整合

   

    工作事件的商业分析

    商业分析可以在开发处理过程中管理和整合相同的工作事件跟踪系统，不同类型的文档将由商业分析产生出来，他们将被存储在团队项目的门户站点中，举个例子，一个需求文档的创建，将会作为一个商业分析的任务被分配。一旦完成，这些文档将会被存储在WSS中，同时商业分析将会把工作事件标记为完成。一个新的工作事件可以在实际的执行需求中被创建。同时一个工作事件的链接将会出现在WSS站点的需求文档中。这个链接允许开发者快速的导航和定位与项目相关联的文档，从而快速的分配任务。，为了在工作事件系统中增前商业分析的影响。我们应该安装Team Explorer 并且拥有一个Team Foundation Server的客户访问许可。

    开发者

    从一个介绍工作事件跟踪的工作流的观点去看，开发者和测试者将会是非常重要的。系统被设计为开发者平滑的使用工作事件。甚至为开发者发送e-mail通知，在这里我们可以花费数小时来规划和确定会议，或者查看工程计划。开发者将会收到他们在Visual Studio中的工作分配。他们可以简单的使用Team Explorer窗口运行My Work Items query（图3）
图 3. 在为软件开发者的Visual Studio 2005 Team Edition中的工作事件列表

    开发者可以开始他们检查自己工作事件的日期。作为他们按照任务工作，他们可以通过两种不同的方法升级他们自己的工作事件状态。第一，他们可以直接在Visual Studio中通过简单的选择那些在工作事件列表工作事件编辑工作事件的信息。在这个情况下，他们可以直接的键入数据，这些数据包括状态升级，或者修改在工作事件中暴露的任一个类型。依靠自定义的处理，单独的个体的类型在这种情况下是被保护的，其他的角色可以设置工作事件的值，但是开发过程对于他们来说是只读的，作为一个项目经理或者是测试者可以区分出工作事件中bug的优先次序。同样的，一些类型可以被开发者所修改，但是却不能被其他的角色所修改。图4为我们展现了一个简单的工作事件细节屏幕，这里包括一个用户范围Start Date添加到默认的灵活软件开发处理的MSF中，而在Visual Studio Team System中的其他用户自定义工作事件则是在这篇文章的后半部分提到。
图 4. 为了软件开发者的开发的Visual Studio 2005 Team Edition中的工作事件细节

   

    第二种方法就是作为一个登记处理的副作用来升级工作事件的状态升级。当联合到Team Foundation Source Control时，很多强大的功能将被添加。依靠团队项目的策略定义，登记处理可以允许或要求开发者去链接到一个工作事件去一个changeset（一个组的文件集合的登陆）在登记处理中。作为一个开发者为了完成他们的代码编制任务，他们简单的联合了代码在工作事件上的登记处理。

    举个例子，假设一个开发者有一个代码编制任务叫做“"implement customer feedback form."当开发者完成了他们的代码任务并且提交了他们的工作以后。开发者可以有一个选项将工作事件连接到提交的代码上。所有的被提交的不同的文件都叫作changeset，工作事件将会连接到changeset，而不是一个单独的文件。工作事件可以简单的被连接，或者做标定。图5提供了一个样例展现了在提交过程中工作事件是如何连接到changeset的。
图 5. 提交的工作事件的联合

    这是一个简单的处理过程和允许工作事件状态自动的升级。这个升级状态可以在项目经理同步他们的项目计划时使用，这个联合工作事件也将在编译时使用，而报告可以使用Team Build自动的产生在分布式的自动的编译处理中。这将允许测试者能够知道在新项目中他们应该测试的部分。

    工作时间登记策略

    工作项目的联合可以被执行也可以通过登记策略进行强制。登记策略强制确定了在团队成员试图提交项目到资源控制系统时的行为。一个标准的策略可以require开发者去将工作事件与提交的代码进行联合。这一点确保了所有的开发过程的效果都是可见的和可跟踪的。这里有一个高一级的策略的选项，利用它我们可以制定一个通知以用来提醒和警告项目经理（或者其他人）
图 6. 添加登记策略

        工作事件中的bug和问题

    使用典型的开发习惯，开发者和测试者可以从多种不同的资源中完成工作。项目计划工作时间表中的工作，例如开发代码和编写测试计划，单独的列表保持和在项目计划外的计划，项目经理可以设置aside buckets of time来允许团队的成员在其他的列表中工作，或者他们也可以创建单独的项目计划，不管在同一个开发资源中对多种不同类型的工作进行管理可能存在的错误可能性。

    团队系统中的工作事件跟踪允许用户灵活的定制化的跟踪在一个单一库中跟踪所有的类型的工作，并且使得管理这些不同类型的任务变得更加简单，不同类型的工作事件可以被分离成为不同的工作事件查询来管理，然而，如果他们是在一个相同的团队项目中，那么为了开发者创建的一个工作事件列表将会有新的开发任务，与这个项目任务有关的研究任务，修复bug任务等等，所有的这些任务会在一个单独的列表中区分出优先顺序。

    测试

    在前面的部分已经暗示过，测试者作为工作事件跟踪的结果在整个开发生命周期的整合中也有着重要的意义。测试者使用Visual Studio Team Edition for Software Testers可以完全访问Team Explorer从而查看他们自己的工作项目。例如，许多的项目要求创建手动测试事件，这些手动测试在Visual Studio Team Edition for Software Testers中被创建和管理，哪些测试用例需要被写入，以及那些测试用例的状态可以在工作事件跟踪系统中被跟踪。项目经理可以想管理和跟踪开发人员一样为了跟踪和管理测试组的效果同步数据。测试者根据开发者相同的处理，然后进行工作事件跟踪系统的任务委派。他们开发的手动测试用例将会提交到资源控制中，并且以一个与开发者代码相同的风格与工作事件相结合。

    此外，测试者可以对编译的报道进行评论，从而找到那些已经测试完成的特性。作为开发者完成了开发的任务并且联合他们在工作项目中提交，这些关系在Team Foundation Server中存储，在编译处理过程中，这些工作事件的状态可以升级的指出他们完成的和在编译中包括的。在编译中所包括的那些事件已经是测试过的。在运行一个编译报告时，一个软件测试者将会清楚的知晓哪些工作事件是他们应该集中精力进行测试的，那些工作事件可能是必须的条件，bugs或者一些其他类型的任务。

    然而，这只是个开始，作为测试者发现了系统的问题，他们可以在Team Foundation Server上报告这个反馈，使用工作事件，可以报告一个“Bug”或者相似的用户工作事件，测试者可以记录他们在工作中需要做的工作。这些新的“Bug”任务可以发送到一个开发领导，或者一个项目经理，或者是一个恰当的开发者那里，并且在处理模板中指定。此外，测试者可以设置一个工作事件关系，用于将有bug的工作事件连接到测试者所测试的原始的工作事件。

    当开发者收到一个工作事件分配和定位错误地址后，开发者将继续工作流，开发者定位“错误”的工作事件将会出现在编译报告中，已使得测试团队可以验证这个错误得修复情况。Team Foundation Server作为一个后端得处理来进行整个处理，需求，开发任务和错误得报告，同时问题得确定可以被绑定在一起。这些事件可以在团队成员得最小影响下被描述和报告出来。

    报告和工作事件数据库

    Visual Studio Team System 和 Team Foundation Server得一个重要得方面就是一个工作事件的存储。所有的工作事件数据是由Microsoft SQL Server 2005数据库中的Team Foundation Server 维护的。此外，在这个方法的灵活性，稳定性和可测量性方面，在报告观点上都有着极大的价值。

    作为基于一个特定的处理模板的团队工程的创建的结果，项目的入口被适当的报告出来。在开发项目中感兴趣的个体，不可以直接的卷入，可以运行报告去得到开发任务的状态，bug数量和其他的工作事件或者非工作事件报告。这在企业价值和IT管理方面方面有着很大的价值，在WSS团队的项目门户站点中包括一个Web part去允许查看在SQL Reporting Services中创建的报告。这个报告在站点中可以通过方法模板进行定制化。

    工作事件定制化

    由Visual Studio 组系统所提供的处理模版被高度的定制化。独立的组织和群能够修改几乎所有方面的方法，来与他们自己的需求达到一致。实际上，某些组织将打算要创建多重的自定义处理模版类型，以使其适合不同的发展项目类型。

    在一个更高的层次，处理模版体系结构提供了以下几个范围的定制化： 

    1. 分类结构服务 (CSS)—为组项目定义了结构，包含为项目生命周期和项目层次的反复定义。 
    2. 组安全服务 (GSS)—定义了初始组和处理模版的许可。 
    3. 报表—定义了由处理过程所提供的报告的标准。 
    4. 来源控制 (SCC)—定义了许可和为来源控制提供的可用的记录。 
    5. Windows 共享点服务 (WSS)—定义了文档模版，文档库，以及处理指导。
    6. 工作事件 (Currituck)—定义了类型和工作事件的特征，工作事件查询，为一个新的组项目提供一个默认的列表或者一些工作事件，以及从工作事件到Microsoft Project的映射。

    在你的处理模版之中，工作事件跟踪系统可以自发的实现高度定制化。你拥有自定义工作事件类型的能力，或者根据一个典型的具体情况而定，在现有的程序基础上重定义工作事件类型。举个例子来说，代替了在MSF中进行灵活软件开发所提供的默认的五个工作事件，取而代之的是，你可以定义工作任务类型为，“需求”，“bugs”，“风险”和“问题”。你甚至可以为工作事件取任何你喜欢的名字；举个例子来说，也许你喜欢“缺点”更甚于“Bug”。你可以更改很多，或者只改其中的一小部分的工作事件的类型作为你用途的需要。

    另外，你实际上可以改变工作事件定义的内容。举个例子来说，你可能设定如下，一个特殊的工作事件类型需要额外的属性，用这种方法来使你的环境更加实用。 增加一个Severity 领域到你的"缺点" 工作事件类型是与编辑一个XML文件一样简单的。 另外，你可能为你的新领域(例如，Very Severe 和 Unimportant)制定正确的值。你同样可以设定这个领域怎样才能被看见，而且若修改值的话需要获得许可。 除此之外，基本的流程是被支持的，而且将会允许组建立服务以使它能够自动地影响领域中的值作为你的工作事件，从而在他们的生命周期中传输。

    作为不同领域的工作事件被普遍关联的一个例子来说，下面的列表包含了使用了MSF为灵活软件开发定义的"Bug"工作事件默认的领域，测试第二版： Id, Title, Assigned To, Area Path, Iteration Path, History, Reason, Changed Date, Changed By, Created Date, Created By, Summary, Issue, State Change Date, Activated Date, Activated By, Resolved Date, Resolved By, Closed Date, Closed By, Priority, Triage, Test Name, Test Id, Test Path, Found In, 和 Integration Build.能够注意到与所有领域一起可能会为工作事件保存数据这一点是非常好的，他们之中有很多是在标准处理过程中自动地捕获数据，而没有为组成员提供扩展性的数据入口。 

  

     Microsoft Project 整合定制化（Integration Customization）

    工作事件领域数据库在项目内部不是数据存储的一个直接的映射。一个项目管理员将会使用Microsoft Project来定期的管理项目，就好像他或她平常所做的一样，但是将会出现额外的领域，而这些领域将会与工作事件跟踪系统同步。某些领域，举个例子来说，任务从属，它不被包含在在工作事件数据库中，而是单独的在任务上工作而且可能仍旧在一定场合下需要参考项目计划。在为灵活软件开发方法模版提供的MSF 测试第二版中，下面的领域会在工作事件数据库和Microsoft Project 之间被映射。
表1，在工作事件数据库和Microsoft Project之间的领域映射

工作事件数据库领域	Microsoft Project字段
System.Id	pjTaskText10
System.Title	pjTaskName
System.WorkItemType	pjTaskText24
Microsoft.VSTS.Common.Discipline	pjTastText17
System.AssignedTo	pjTaskText11
Microsoft.VSTS.Common.Scheduling.CompletedWork	pjTaskActualWork
Microsoft.VSTS.Common.RemainingWork	pjTaskRemainingWork
Microsoft.VSTS.Common.BaselineWork	pjTaskBaselineWork
System.State	pjTaskText13
System.Reason	pjTastText14
Microsoft.VSTS.Common.Rank	pjTastText16
Microsoft.VSTS.Common.Issue	pjTastText15
Microsoft.VSTS.Common.ExitCriteria	pjTaskText20
Microsoft.VSTS.Common.QualityOfServiceType	pjTaskText21
Microsoft.VSTS.Common.Priority	pjTaskText19
Microsoft.VSTS.Scheduling.Scheduled	pjTaskText18
Microsoft.VSTS.Common.Specified	pjTaskText22
System.Rev	pjTaskText23

    虽然这个工作事件领域的名字看起来似乎有些威胁，但是它们只不过包含了前后关系的信息用以描述领域的来源。这些名字实际上是在工作事件领域中用xml标记语言定义在xml文档中的参考名字。当定义你自己的客户端工作事件领域时，你应该也用类似的样式提供参考名字---举个例子来说，MyCompany.VSTS.StartDateField。这些同样的工作事件类型定义也提供了友好的名字例如，Start Date.

    在Microsoft Project映射一侧，所有名称均用pjTask 作前缀，这样能够显示它们是Microsoft Project任务领域。虽然Microsoft Project也支持资源领域，但是这些类型并不能够用来应用在工作事件之中。当在映射中为一个Microsoft Project领域命名时，人们应该先找到在项目中这个领域的名称，然后剔除空格以及加入前缀。举个例子来说，，一个Microsoft Project任务领域的名字被叫做Resource Names ，则应该在映射中被引用且命名为pjTaskResourceNames 。应该注意的是，默认的映射使用了很多普通的微软项目任务领域用来存储工作事件---特殊的数据。若想知道更多信息，你可能希望能够参考Microsoft Project SDK

    在工作事件数据库和微软计划服务器之间并没有直接的同步。那些希望在两个系统之间往回和往外移动数据的项目管理员可以同样使用Microsoft Project Professional来让每个独立系统能够实现同步。

    总结

    工作事件跟踪提供了一个非常好的方法来跟踪所有的必需发生的个别工作事件用以开发一个成功的软件应用程序。请记住，工作事件系统在开发组中被当作对象，而它不仅仅是开发者，它也同样能够定制用以来迎合一个广阔的多样性组织结构。