更改工作项类型的工作流

Azure DevOps Server 2022 - Azure DevOps Server 2019

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

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

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

注意

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

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

更新工作项类型的 XML 定义

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

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

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

1. WORKFLOW按照本主题中所述修改 WIT 定义的部分。

2. 修改进程配置，将新的工作流状态映射到元状态。

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

工作流设计指南

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

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

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

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

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

  如果将状态添加到 Web 门户中积压工作或板页上显示的工作项类型，则还必须将状态映射到状态类别。 有关详细信息，请查看 工作流状态和状态类别。

• 使用该 TRANSITION 元素定义每个有效进度和从一种状态到另一种状态的转换。

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

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

  当团队成员更改工作项的状态时，该更改将触发转换以及为所选状态和转换定义的操作。 用户只能根据为当前状态定义的转换指定那些有效状态的状态。 此外， ACTION 属于其子元素的 TRANSITION元素可以更改工作项的状态。

• 对于每个转换，使用元素定义默认原因 DEFAULTREASON 。 可以使用元素定义任意 REASON 数量的可选原因。 这些值显示在“原因”字段的下拉菜单中。

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

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

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

工作流关系图和代码示例

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

此示例不列出所有元素，DEFAULTREASONREASONACTION以及。FIELD

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

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

确定状态的数量和类型

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

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

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

注意

所有状态都按字母顺序显示在特定类型的工作项的窗体上的列表中，而不考虑指定它们的顺序。

定义转换

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

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

State	转换为状态	默认原因
Proposed	活动（进度）	已批准进行开发
	闭合（进度）	未批准
活动	评论 （进展）	满足验收条件
审阅	闭合（进度）	功能完成
	活动（回归）	不符合要求
Closed	建议 （回归）	重新考虑审批
	活动（回归）	已关闭错误

可以使用元素的 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 工作项与开发人员签入版本控制的文件相关联，则应自动解决 bug 工作项：

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

当事件发生在 Microsoft Visual Studio 应用程序生命周期管理或 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>  

当另一个字段的值发生更改时，清除字段的值

当工作项的 “状态 ”字段的值设置为“活动”且工作项已保存时，“已关闭日期”和“关闭日期”字段将自动设置为 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 Marketplace 安装 状态模型可视化扩展 来支持用户可视化工作流。