更改工作项类型的工作流

项目
02/23/2023

Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018

可以更改工作项类型的工作流 (WIT) ，以支持业务和团队流程。 WIT 支持跟踪所有类型的工作（要求、任务、代码缺陷），以支持软件开发。

工作流确定团队成员将执行的工作的逻辑前进和倒退。还将指定在“状态”和“原因”字段的下拉菜单中显示的值。有关默认流程模板中支持的默认工作流状态的概述，请参阅选择进程。

产品积压工作项 (Scrum 流程模板的工作流)

产品积压工作 (backlog) 项工作流，Scrum 过程

注意

本文介绍如何自定义工作流状态。如果想要更改分配给特定工作项的状态，请参阅以下主题之一：添加工作项、更新工作状态、看板、跟踪正在进行的工作或任务板、更新任务状态。还可以对多个工作项执行状态的批量更新。

有关生成管道工作流的信息，请参阅 CI/CD 入门。

更新工作项类型的 XML 定义

如果不熟悉 WIT 自定义，请注意以下事项：

若要自定义工作项类型的任何方面，必须更新其 XML 定义。所有 WITD XML 元素引用中介绍了 XML 定义
如果要自定义使用新工作项体验的 Web 窗体，则需要引用 WebLayout 和 Control 元素
如果要自定义用于 Visual Studio 的客户端窗体，则需要引用 Layout XML 元素引用
按照自定义工作项跟踪 Web 窗体中概述的步骤顺序进行操作。

若要自定义工作流，请执行以下两个步骤：

WORKFLOW如本主题中所述，修改 WIT 定义的部分。
修改进程配置，将新的工作流状态映射到元状态。

更改显示在敏捷工具页上的 WIT 的工作流时，需要执行第二个步骤。这些 WIT 属于“需求”或“任务”类别。若要详细了解状态类别，请参阅工作流状态和状态类别。

工作流设计准则

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

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

例如，当测试人员打开基于默认敏捷过程的新 bug 时，“状态”设置为“ 新建 ”。开发人员在修复 bug 时将“状态”更改为 “活动” ，修复后，开发人员将其状态更改为“ 已解决 ”，并将“原因”字段的值设置为“ 已修复”。验证修补程序后，测试人员将 bug 的状态更改为 “已关闭 ”，“原因”字段更改为“ 已验证”。如果测试人员确定开发人员尚未修复该 bug，测试人员会将 bug 的状态更改为 “活动” ，并将“原因”指定为 “未修复 ”或“ 测试失败”。

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

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

如果将状态添加到 Web 门户中积压工作或板页上显示的工作项类型，则还必须将该状态映射到状态类别。若要了解详细信息，请查看工作流状态和状态类别。
TRANSITION使用元素定义从一种状态到另一种状态的每个有效进度和回归的转换。

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

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

团队成员更改工作项的状态时，该更改会触发转换以及要针对所选状态和转换执行的已定义操作。用户只能基于为当前状态定义的转换来指定有效的状态。此外， ACTION 元素（它是的 TRANSITION子元素）可以更改工作项的状态。
对于每个转换，使用元素定义默认原因 DEFAULTREASON 。可以使用元素定义任意数量的可选原因 REASON 。这些值显示在“ 原因 ”字段的下拉菜单中。
可以指定将在工作项更改状态时、它进行转换时或者用户选择特定原因时应用的规则。其中许多规则是对在定义下的节中 FIELDS 定义字段时可以应用的条件规则的 WORKITEMTYPE 补充。有关详细信息，请参阅本主题后面的工作流更改期间更新字段。
分配给状态和原因的名称区分大小写。

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

工作流关系图和代码示例

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

此示例未列出、、 REASONACTION和 FIELD的所有元素DEFAULTREASON。

示例工作流状态图 - 敏捷 Bug WIT

Bug 工作流状态，敏捷过程模板

<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>

确定状态的数量和类型

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

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

状态	有效用户	要执行的操作
Proposed	项目经理	任何人都可以创建功能工作项。但是，只有项目经理才能批准或否决工作项。如果项目经理批准一个功能，则项目经理会将工作项的状态更改为“活动”；否则团队成员会关闭它。
可用	开发主管	开发主管监督功能的开发。功能完成时，开发主管会将功能工作项的状态更改为“评审”。
检查	项目经理	项目经理会评审团队实现的功能，并在实现令人满意时将工作项的状态更改为“已关闭”。
已关闭	项目经理	不应对已关闭的工作项执行任何其他操作。这些项将保留在数据库中以进行存档和报告。

注意

对于特定类型的工作项，所有状态都按字母顺序显示在工作项窗体上的列表中（无论采用何种顺序指定它们）。

定义转换

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

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

状态	到状态的转换	默认原因
Proposed	活动（前进）	批准进行开发
	已关闭（前进）	未批准
可用	评审（前进）	满足验收条件
检查	已关闭（前进）	功能完整
	活动（倒退）	不满足需求
已关闭	已建议（倒退）	重新考虑是否批准
	活动（倒退）	在出现错误的情况下关闭

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

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

指定原因

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

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

注意

对于特定类型的工作项，所有原因都按字母顺序显示在工作窗体的列表中，而不管指定 REASON 元素的顺序如何。

下面的示例演示定义团队成员可能解决 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 应用程序生命周期管理中的其他位置或 Visual Studio 应用程序生命周期管理 (外部发生事件时，可以使用元素自动更改特定类型的工作项的状态，例如，从跟踪调用) 的工具。有关详细信息，请参阅 ACTION。

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

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

如果希望规则应用于所有转换，以及进入该状态的原因，可在下 STATE 分配字段规则。
如果希望规则应用于该转换，以及进行该转换的所有原因，可在下 TRANSITION 分配字段规则。
如果希望规则仅出于该特定原因应用，请根据 DEFAULTREASON 或 REASON 分配字段规则。

如果字段应始终包含相同的值，则可以在定义该字段的 FIELD 元素下定义规则。若要详细了解规则用法，请参阅规则和规则评估。

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

以下示例演示了一些应用于 MSF 敏捷软件开发过程模板中的系统字段的规则。

状态更改时更改字段的值

当工作项的 “状态” 字段的值设置为“活动”并保存工作项时，“ 激活者 ”和“ 分配到 ”字段的值将自动设置为当前用户的名称。该用户必须是 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>

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

当工作项的 “状态” 字段的值设置为“活动”并保存工作项时，如果使用 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 Marketplace 安装状态模型可视化扩展来支持用户可视化工作流。

更改工作项类型的工作流

更新工作项类型的 XML 定义

工作流设计准则

工作流关系图和代码示例

确定状态的数量和类型

定义转换

指定原因

指定操作

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

状态更改时更改字段的值

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

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

工具支持

其他资源

其他资源

更改工作项类型的工作流

更新工作项类型的 XML 定义

工作流设计准则

工作流关系图和代码示例

确定状态的数量和类型

定义转换

指定原因

指定操作

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

状态更改时更改字段的值

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

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

相关文章

工具支持

其他资源

其他资源