设计工作流

  • 项目

更新：2011 年 1 月

可以为工作项类型设计工作流以支持您的业务流程和团队过程。 工作流可确定将执行的任务的逻辑进度以及任务的执行者。 可通过先确定这些任务的状态以及它们之间的有效转换来定义工作流。 工作项类型的定义的 WORKFLOW 部分将定义有效状态、转换、转换原因以及在团队成员更改工作项状态时将执行的可选操作。 有关类型定义的更多信息，请参见All WITD XML 元素引用。

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

例如，当测试人员打开基于 Microsoft Solutions Framework (MSF) for Agile Software Development 5.0 过程模板的新 Bug 时，“状态”将设置为“活动”。 修复 Bug 后，开发人员会将其状态更改为“已解决”，并将“原因”字段的值设置为“已修复”。 验证修复后，测试人员会将 Bug 的状态更改为“已关闭”，并将“原因”字段的值保留为“已修复”。 如果测试人员确定开发人员未修复 Bug，测试人员会将 Bug 的状态更改为“活动”，并将“原因”指定为“解决方法被拒绝”或“测试未通过”。

提示

进程编辑器是 Visual Studio 的一个增强工具，您可以使用该工具创建和修改工作项类型的定义和用于跟踪工作项的其他对象。 此工具不受支持。 有关更多信息，请参见 Microsoft 网站上的以下页面：Team Foundation Server Power Tools April 2010（Team Foundation Server 增强工具 2010 年 4 月版）。

主题内容

  • 工作流设计准则

  • 工作流关系图和代码示例

  • 确定状态的数量和类型

  • 定义转换

    • 指定原因

    • 指定操作

  • 在状态发生更改时更新字段

    • 在状态发生更改时定义字段

    • 清除字段的值

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

  • 查看工作流状态关系图

工作流设计准则

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

  • 通过使用 STATE 元素，可为每个团队成员角色定义一个唯一状态，这将对工作项执行特定操作。 定义的状态越多，必须定义的转换就越多。 无论您定义状态的顺序如何，这些状态在**“状态”**列表中都会以字母数字顺序列出。

  • 通过使用 TRANSITION 元素，可为每个有效进度和回归定义从一个状态到另一个状态的转换。

  • 您必须至少为每个状态定义一个转换，即从 Null 状态到初始状态的转换。

  • 对于每个转换，您必须使用 DEFAULTREASON 元素定义一个默认原因。 您可使用 REASON 元素定义所需数量的可选原因。

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

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

  • 在工作项更改状态时、工作项进行转换时或当用户选择某个特定原因时，您可定义要应用于任何字段的条件规则。 当您在 WORKITEMTYPE 定义下的 FIELDS 部分中定义字段时，这些规则中的许多规则可以补充可应用的条件规则。 有关更多信息，请参见本主题后面的在状态发生更改时更新字段。

  • 您应尝试最大程度地减少为任一类型的工作项定义的条件数。 利用您添加的每个条件规则，可增加每当团队成员保存工作项时发生的验证过程的复杂性。 复杂规则集可能会增加保存工作项所需的时间。

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

返回页首

工作流关系图和代码示例

下表演示了用于跟踪代码缺陷的工作项类型的定义的 WORKFLOW 部分，以及该部分所定义的工作流状态关系图。 本示例定义了三个状态、六个转换和九个原因。 STATE 元素指定“活动”、“已解决”和“已关闭”状态。 除下面的一种转换组合之外，为这三个状态定义了所有可能的进度和回归转换的组合： 即未定义从“已关闭”到“已解决”的转换。 因此，如果关闭工作项，则团队成员将无法解决此类型的工作项。

提示

该示例未列出 DEFAULTREASON、REASON、ACTION 和 FIELD 的元素。

<WORKFLOW>
<STATES>
  <STATE value="Active">
    <FIELDS> . . . </FIELDS>
  </STATE>
  <STATE value="Resolved">
    <FIELDS> . . . </FIELDS>
  </STATE>
  <STATE value="Closed" />
</STATES>
<TRANSITIONS>
  <TRANSITION from="" to="Active">
    <REASONS>
      <DEFAULTREASON value="New" />
    </REASONS>
    <FIELDS> . . . </FIELDS>
  </TRANSITION>
  <TRANSITION from="Active" to="Resolved">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
    < ACTIONS > . . . </ ACTIONS >
</TRANSITION>
<TRANSITION from="Resolved" to="Closed">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
    < ACTIONS > . . . </ ACTIONS >
</TRANSITION>
<TRANSITION from="Resolved" to="Active">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
</TRANSITION>
<TRANSITION from="Active" to="Closed ">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
</TRANSITION>
<TRANSITION from="Closed" to="Active">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
</TRANSITION>
</TRANSITIONS>
</WORKFLOW>
工作流状态关系图示例

用户情景状态图

确定状态的数量和类型

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

下表提供了一个示例，其中包含为跟踪功能的进度定义的四个状态和必须执行指示的操作的有效用户：

状态

有效用户

要执行的操作

已建议

项目经理

可创建功能工作项的任何人。 但只有项目经理才能批准或否决工作项。 如果项目经理批准某个功能，则他会将工作项的状态更改为“活动”；否则，团队成员将关闭工作项。

活动

开发主管

开发主管负责监督功能的开发。 一旦完成功能，开发主管就会将功能工作项的状态更改为“评审”。

评审

项目经理

如果实现令人满意，则项目经理将评审团队所实现的功能并将工作项的状态更改为“已关闭”。

已关闭

项目经理

不应对已关闭的工作项执行任何其他操作。 这些项将保留在数据库中以作存档和报告之用。

提示

无论您指定状态的顺序如何，所有这些状态都会在特定类型的工作项窗体上的列表中按字母顺序列出。

返回页首

定义转换

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

下表为本主题前面描述的所有四个状态定义了有效转换，并指定了每个转换的默认原因。

状态

转换到的状态

默认原因

已建议

活动（进度）

批准开发

已关闭（进度）

未批准

活动

评审（进度）

满足验收条件

评审

已关闭（进度）

功能已完成

活动（回归）

不满足要求

已关闭

已建议（回归）

重新考虑批准

活动（回归）

错误地关闭

可使用 TRANSITION 元素的 for 和 not 特性来限制可执行从一个状态到另一状态的转换的人员。 如以下示例所示，测试人员可重新打开 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 Application Lifecycle Management 内部或 Visual Studio Application Lifecycle Management 外部（例如，从跟踪调用的工具中）发生时，可以自动更改特定类型的工作项的状态。 有关更多信息，请参见基于状态、转换或原因自动进行字段赋值。

返回页首

更新字段

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

  • 当您希望针对所有转换和进入该状态的原因应用一个字段规则时，请在 STATE 下分配该规则。

  • 当您希望针对该转换和进行该转换的所有原因应用一个字段规则时，请在 TRANSITION 下分配该规则。

  • 当您希望只对该特定原因应用一个字段规则时，请在 DEFAULTREASON 或 REASON 下分配该规则。

如果一个字段应始终包含相同的值，您可以在定义该字段的 FIELD 元素下定义相应规则。 有关更多信息，请参见对工作项字段设置条件。

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

  • 在状态发生更改时更改字段的值

  • 在一个字段的值发生更改时清除另一个字段的值

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

返回页首

在状态发生更改时更改字段的值

在将某个工作项的**“状态”字段的值设置为“活动”并保存该工作项时，“激活者”和“指派给”字段的值将自动设置为当前用户名。 该用户必须是“Team Foundation Server Valid Users”组的成员。 还将自动设置“激活日期”**字段的值。 下面的示例演示了强制实施此规则的元素：

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

返回页首

查看工作流状态关系图

如果您使用 Team Web Access 打开该类型的任意工作项的状态图，则可查看任何类型的工作项的工作流定义。 有关更多信息，请参见使用 Team Web Access 管理工作。

提示

进程编辑器是 Visual Studio 的一个增强工具，您也可以使用该工具来查看正定义的工作流状态图。 此工具不受支持。 有关更多信息，请参见 Microsoft 网站上的以下页面：Team Foundation Server Power Tools April 2010（Team Foundation Server 增强工具 2010 年 4 月版）。

返回页首

请参见

其他资源

定义和自定义工作项工作流

修订记录

日期

修订记录

原因

2011 年 1 月

将 WORKFLOW 元素表移至新主题：All WORKFLOW XML 元素引用。

信息补充。

2010 年 7 月

完全重新编写，以便提供更多信息、示例和所有 WORKFLOW 元素及特性的摘要。

信息补充。