更改工作项类型的工作流

更改工作项类型 (WIT) 的工作流以支持业务和团队过程。 WIT 支持跟踪所有类型的工作（要求、任务、代码缺陷）以支持使用 Team Foundation Server (TFS) 进行软件开发。

工作流确定团队成员将执行的工作的逻辑前进和倒退。 还将指定在“状态”和“原因”字段的下拉菜单中显示的值。

用于产品积压工作 (backlog) 项的工作流（Scrum 过程模板）

有关 TFS 提供的默认过程模板中支持的默认工作流状态的概述，请参阅使用团队项目内容，选择过程指南。 有关生成定义工作流的信息，请参阅自定义生成过程模板。

工作流设计准则

通过先确定状态以及它们之间的有效转换来定义工作流。 WIT 定义的 WORKFLOW 部分指定有效状态、转换、转换的原因以及当团队成员更改工作项状态时将执行的可选操作。

一般而言，将每个状态与团队成员角色以及具有该角色的人员在更改工作项状态之前为处理工作项而必须执行的任务相关联。 转换定义状态之间的有效前进和倒退。 原因确定团队成员为何将工作项从一个状态更改为另一个状态，而操作支持工作项在工作流中某点处的自动转换。

例如，当测试人员打开基于 Team Foundation Server (TFS) 提供的默认敏捷过程模板的新 bug 时，“状态”设置为**“新建”。 开发人员在修复 bug 时将“状态”更改为“活动”，修复之后，开发人员将状态更改为“已解决”并将“原因”字段的值设置为“已修复”。 验证修复之后，测试人员将 bug 状态更改为“已关闭”，“原因”字段更改为“已验证”。 如果测试人员确定开发人员未修复 bug，测试人员会将 bug 状态更改为“活动”，并将“原因”指定为“未修复”或“测试失败”**。

设计或修改工作流时，请考虑以下准则：

• 使用 STATE 元素为将对工作项执行特定操作的每个团队成员角色定义唯一的状态。 定义状态越多，必须定义的转换便越多。 无论采用何种顺序定义状态，它们都会在“状态”列表中按字母数字顺序列出。

  如果将状态添加到显示在 Team Web Access 中的积压工作 (backlog) 或任务板页上的工作项类型，则必须还将状态映射到元状态。 请参阅过程配置 XML 元素参考。

• 使用 TRANSITION 元素为每个有效前进和后退定义从一个状态到另一个状态的转换。

  至少必须为每个状态定义一个转换，以及从 null 状态到初始状态的转换。

  只能定义一个从未分配 (null) 到初始状态的转换。 保存新工作项时，会自动将它分配给初始状态。

  团队成员更改工作项的状态时，该更改会触发转换以及要针对所选状态和转换执行的已定义操作。 用户只能基于为当前状态定义的转换来指定有效的状态。 此外，ACTION 元素（TRANSITION 的子元素）可以更改工作项的状态。

• 对于每个转换，必须使用 DEFAULTREASON 元素定义一个默认原因。 可以使用 REASON 元素定义所需数量的可选原因。 这些值将会出现在“原因”字段的下拉菜单中。

• 可以指定将在工作项更改状态时、它进行转换时或者用户选择特定原因时应用的规则。 其中许多规则可补充在 WORKITEMTYPE 定义的 FIELDS 部分中定义字段时可以应用的条件规则。 有关详细信息，请参阅本主题后面的在工作流更改过程中更新字段。

• 分配给状态和原因的名称区分大小写。

  工作项窗体或查询编辑器中“状态”和“原因”字段的下拉菜单会显示在工作项类型的 WORKFLOW 部分中分配的值。

工作流关系图和代码示例

下面的代码示例演示敏捷过程模板的 Bug WIT 定义的 WORKFLOW。 此示例定义了三个状态和五个转换。 STATE 元素指定 Active、Resolved 和 Closed 状态。 为三个状态定义了前进和后退转换的所有可能组合（除了一个）。 未定义从 Closed 到 Resolved 的转换。 因此，如果工作项已关闭，则团队成员不能解决此类型的工作项。

此示例没有列出 DEFAULTREASON、REASON、ACTION 和 FIELD 的所有元素。

<WORKFLOW> <STATES> <STATE value="Active"> <FIELDS> . . . </FIELDS> </STATE> <STATE value="Resolved"> <FIELDS> . . . </FIELDS> </STATE> <STATE value="Closed"> <FIELDS> . . . </FIELDS> </STATE> </STATES> <TRANSITIONS> <TRANSITION from="" to="Active"> <REASONS> <REASON value="Build Failure" /> <DEFAULTREASON value="New" /> </REASONS> <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Active" to="Resolved"> <ACTIONS> . . . </ACTIONS> <REASONS> . . . </REASONS> </TRANSITION> <TRANSITION from="Resolved" to="Active"> <REASONS> . . . </REASONS> </TRANSITION> <TRANSITION from="Resolved" to="Closed"> <REASONS> <DEFAULTREASON value="Verified" /> </REASONS> <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Closed" to="Active"> <REASONS> <REASON value="Reactivated" /> <DEFAULTREASON value="Regression" /> </REASONS> <FIELDS> . . . </FIELDS> </TRANSITION> </TRANSITIONS> </WORKFLOW>

示例工作流状态关系图 – 敏捷 Bug WIT

确定状态的数量和类型

基于你希望该类型的工作项所具有的不同逻辑状态数来确定有效状态的数量和类型。 此外，如果不同团队成员执行不同操作，则可以考虑基于成员角色定义状态。 每个状态对应于团队成员为使工作项移动到下一个状态而必须对其执行的操作。 对于每个状态，应定义特定操作以及允许执行这些操作的团队成员。

下表提供为跟踪某个功能进度而定义的四个状态以及必须执行所指示操作的有效用户的示例：

定义转换

如果定义了有效状态前进和倒退，则可控制团队成员可以将工作项更改为或从其更改的状态。 如果未定义从一个状态到另一个状态的状态，则团队成员无法将特定类型的工作项从一个特定状态更改为另一个特定状态。

下表定义本主题前面所述的所有四个状态的有效转换以及每个转换的默认原因。

可以使用 TRANSITION 元素的 for 和 not 特性限制允许进行从一个状态到另一个状态的转换的人员。 如下面的示例所示，测试人员可以重新打开 bug，但开发人员不能。

<TRANSITION from="Closed" to="Active"
     for="[Project]\Testers"
      not="[Project]\Developers">
    . . .
</TRANSITION>

指定原因

当某个团队成员更改“状态”字段时，该用户可以保留该转换的默认原因或指定不同的原因（如果定义了其他选项）。 必须使用 DEFAULTREASON 元素指定一个且仅仅一个默认原因。 仅当其他原因可帮助团队跟踪或报告数据时，才应指定这些原因。

例如，开发人员可以在解决 bug 时指定以下原因之一：已修复（默认值）、已延迟、重复、保留原样、无法重现或已过时。 每个原因都指定测试人员对 bug 执行的特定操作。

下面的示例演示定义团队成员可能解决 bug 的原因的元素：

<TRANSITION from="Active" to="Resolved">
   . . .
   <REASONS>
      <DEFAULTREASON value="Fixed"/>
      <REASON value="Deferred"/>
      <REASON value="Duplicate"/>
      <REASON value="As Designed"/>
      <REASON value="Unable to Reproduce"/>
      <REASON value="Obsolete"/>
   </REASONS>
   . . .
</TRANSITION>

指定操作

一般而言，团队成员通过为**“状态”**字段指定不同值，然后保存工作项，来更改工作项的状态。 但是，还可以定义在转换发生时自动更改工作项状态的 ACTION 元素。 如下面的示例所示，可以指定如果 bug 工作项与开发人员签入版本控制的文件关联，则应自动解决这些工作项：

<TRANSITION from="Active" to="Resolved">
   <ACTIONS>
   <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
   </ACTIONS>
. . .
</TRANSITION>

可以使用 ACTION 元素在 Microsoft Visual Studio Application Lifecycle Management 中任何位置或 Visual Studio Application Lifecycle Management 外部（例如，从跟踪调用的工具）发生事件时自动更改特定类型工作项的状态。 有关详细信息，请参阅基于状态、转换或原因自动进行字段赋值。

在工作流更改过程中更新字段

可以定义只要发生以下事件便更新字段的规则：

• 希望规则应用于到该状态的所有转换以及进入该状态的原因时，可在 STATE 下分配字段规则。

• 希望规则应用于到该转换以及进行该转换的所有原因时，可在 TRANSITION 下分配字段规则。

• 希望规则应用于到该特定原因时，可在 DEFAULTREASON 或 REASON 下分配字段规则。

如果某个字段应始终包含相同值，则在定义该字段的 FIELD 元素下定义规则。 若要了解有关规则使用的详细信息，请参阅将规则应用于工作项字段。

应尝试尽量减少为任何一种类型的工作项定义的条件数。 添加每个条件规则时，会增加每次团队成员保存工作项时进行的验证过程的复杂性。 复杂的规则集可能会增加保存工作项所需的时间。

以下示例演示一些应用于 MSF Agile Software Development 2013 过程模板中的系统字段的规则。

状态更改时更改字段的值

当工作项**“状态”字段的值设置为“活动”并保存工作项时，“激活者”和“分配给”**的值会自动设置为当前用户的名称。 该用户必须是 Team Foundation Server 有效用户组的成员。 **“激活日期”**字段值也会自动设置。 下面的示例演示强制执行此规则的元素：

<STATE value="Active">
<FIELDS>
   <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
      <COPY from="currentuser"/>
      <VALIDUSER/>
      <REQUIRED/>
   </FIELD>
   <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
      <SERVERDEFAULT from="clock"/></FIELD>
   <FIELD refname="System.AssignedTo">
      <DEFAULT from="currentuser"/>
   </FIELD>
. . .
</FIELDS>
</STATE>

另一个字段的值更改时清除字段的值

工作项字段**“状态”**字段的值设置为“活动”并保存工作项时，“关闭日期”和“关闭者”字段会自动设置为 null，并且会设为只读（如果使用 EMPTY 元素），如以下示例所示。

<STATE value="Active">
   <FIELDS>
. . .
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>
   </FIELDS>
</STATE>

基于另一个字段的内容定义字段

工作项字段**“状态”字段的值更改为“已解决”并保存工作项时，“解决原因”字段的值会设置为用户在“原因”**字段中指定的值。 下面的示例演示强制执行此规则的元素：

<STATE value="Resolved">
   <FIELDS>
. . .
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
         <COPY from="field" field="System.Reason"/>
      </FIELD>
   </FIELDS>
</STATE>

问题解答

问：是否有用于更改工作流或查看工作流状态关系图的工具？

**答：**可以。 可以使用过程编辑器（Visual Studio 的一个增强工具）更改工作流或查看所定义的工作流状态关系图。 有关详细信息，请参阅 Microsoft 网站上的以下页面：Team Foundation Server 增强工具。

问题：在哪里可以获取 WIT 定义 XML 元素的概述？

**答：**请参见 所有 WITD XML 元素引用。