更改某个工作项类型的工作流

Azure DevOps Server |Azure DevOps Server 2022

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

工作流确定团队成员执行的工作的逻辑进度和回归。它还指定“状态”和“原因”字段的下拉菜单中显示的值。有关详细信息，请参阅关于进程和进程模板。

产品积压工作项的工作流（Scrum 进程模板）

产品待处理项工作流，Scrum 流程

注意

本文介绍如何自定义工作流状态。若要更改分配给特定工作项 的状态 ，请参阅以下文章之一：开发板、跟踪正在进行的工作或任务板、更新任务状态。您还可以对许多工作项的状态进行批量更新。

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

更新工作项类型的 XML 定义

如果你不熟悉 WIT 自定义，请注意以下几点：

若要自定义工作项类型的任何方面，请更新其 XML 定义。有关详细信息，请参阅所有 WITD XML 元素参考。
如果要自定义使用新工作项体验的 Web 窗体，请参阅 WebLayout 和 Control 元素。
如果要自定义用于 Visual Studio 的客户端窗体，请参阅 Layout XML 元素引用。
按照自定义工作项跟踪 Web 窗体中概述的步骤序列进行操作。

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

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

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

工作流设计指南

首先通过标识状态和它们之间的有效转换来定义工作流。 WORKFLOW WIT 定义的节指定在团队成员更改工作项状态时运行的有效状态、转换、转换原因和可选操作。

通常，将每个状态与团队成员的角色以及该角色中的人员在更改状态之前必须执行的任务相关联，用于处理工作项。转换定义状态之间的有效进度和回归。原因确定团队成员将工作项从一个状态更改为另一个状态的原因，并且操作支持在工作流中某个点自动转换工作项。

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

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

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

如果在 Web 门户中将状态添加到显示在积压工作或板页上的工作项类型，则还必须将状态映射到状态类别。有关详细信息，请参阅工作流状态和状态类别。
使用 TRANSITION 元素定义每个有效的前进和后退状态之间的转换。

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

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

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

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

工作流关系图和代码示例

下面的代码示例展示了敏捷过程模板中 Bug WIT 的定义 WORKFLOW。此示例定义三种状态和五种转换。这些 STATE 元素指定活动状态、已解决状态和已关闭状态。对于进度转换和回归转换，所有可能的组合都针对三种状态进行了定义，但其中一种状态除外。未定义从“已关闭”转换到“已解决”的转换。因此，如果关闭工作项，团队成员无法解析此类型的工作项。

此示例不列出DEFAULTREASON、REASON、ACTION以及FIELD的所有元素。

示例工作流状态图：敏捷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>

确定状态的数量和类型

根据希望该类型的工作项存在的不同逻辑状态数来决定有效状态的数量和类型。此外，如果不同的团队成员执行不同的操作，请考虑根据成员角色定义状态。每个状态对应于团队成员必须对工作项执行的操作，以将其移动到下一个状态。对于每个状态，定义允许执行这些操作的特定操作和团队成员。

下表提供了四种状态的示例，这些状态跟踪功能进度以及必须执行指示操作的有效用户：

状态	有效用户	要执行的操作
提议	项目经理	任何人都可以创建功能工作项。但是，只有项目经理才能批准或取消批准工作项。如果项目经理批准某个功能，项目经理会将工作项的状态更改为“活动”;否则，团队成员将其关闭。
活跃的	开发主管	开发主管负责监督功能的开发。功能完成后，开发主管会将功能工作项的状态更改为“审阅”。
审查	项目经理	项目经理查看团队实现的功能，并将工作项的状态更改为“已关闭”（如果实现令人满意）。
关闭	项目经理	不会对关闭的工作项执行任何其他操作。出于存档和报告目的，这些项目保留在数据库中。

注意

在特定类型的工作项的表单中的列表中，所有状态按字母顺序排列显示；不考虑指定它们的顺序。

定义转换

可以通过定义有效的状态进度和回归来控制团队成员可以更改工作项的状态。如果未定义从一种状态到另一个状态的转换，团队成员无法将特定类型的工作项从特定状态更改为另一个特定状态。

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

状态	转换为状态	默认原因
提议	进行中（进展）	已批准进行开发
	闭合（进度）	未批准
活跃的	评审（进展）	满足验收条件
审查	完成（进展）	功能已完成开发
	主动（回归）	不符合要求
关闭	拟议（回归分析）	重新考虑以便批准
	活跃（回归）	因错误关闭

可以使用元素的 for 和 not 属性 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>

当事件在 Microsoft Visual Studio 应用程序生命周期管理或该系统之外的其他位置发生时（例如，从跟踪通话的工具），请使用 ACTION 元素自动更改特定类型的工作项状态。有关详细信息，请参阅 ACTION。

在工作流更改期间更新字段

可以定义每当发生以下事件时更新字段的规则：

请在想要将规则应用于所有过渡及进入该状态的原因时，为 STATE 分配一个字段规则。
当希望规则应用于该转换时，请分配字段规则 TRANSITION ，以及进行该转换的所有原因。
当您希望规则仅适用于某个特定情况时，请为 DEFAULTREASON 或 REASON 分配字段规则。

如果字段应始终包含相同的值，请在定义该字段的 FIELD 元素下定义规则。有关规则用法的详细信息，请参阅规则和规则评估。

最大程度地减少为任意一种类型的工作项定义的条件数。每个条件规则都会为每次团队成员保存工作项时发生的验证过程增加复杂性。复杂的规则集可能会增加保存工作项所需的时间。

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

更改字段的值，当状态发生变化时

将工作项的 “状态 ”字段的值设置为“活动”并保存工作项时，“ 激活者 ”和 “分配给” 字段的值会自动设置为当前用户的名称。该用户必须是 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 元素会自动将“已关闭日期”和“关闭依据”字段设置为 null，并将其设为只读，如以下示例所示。

<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 安装状态模型可视化扩展。

反馈

此页面是否有帮助？

Last updated on 2026-03-28