Cambiar el flujo de trabajo de un tipo de elemento de trabajo

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

Puede cambiar el flujo de trabajo de un tipo de elemento de trabajo (WIT) para admitir los procesos empresariales y de equipo. Los WIT admiten el seguimiento de todos los tipos de trabajo (requisitos, tareas, defectos de código) para admitir el desarrollo de software.

El flujo de trabajo determina la progresión y regresión lógicas del trabajo que realizarán los miembros del equipo. También especifica los valores que aparecen en los menús desplegables de los campos Estado y Razón. Para obtener información general sobre los estados de flujo de trabajo predeterminados admitidos en las plantillas de proceso predeterminadas, vea Elegir un proceso.

Flujo de trabajo del elemento de trabajo pendiente del producto (plantilla de proceso de scrum)

Actualización de la definición XML para wit

Si no está nuevo en la personalización de WIT, tenga en cuenta lo siguiente:

• Para personalizar cualquier aspecto de un WIT, es necesario actualizar la definición XML del WIT. La definición DE WIT XML se describe en Referencia de todos los elementos XML DE WITD
• Si va a personalizar el formulario web que usa la nueva experiencia de elemento de trabajo, querrá hacer referencia a los elementos WebLayout y Control.
• Si va a personalizar un formulario de cliente para su Visual Studio, querrá hacer referencia a la referencia del elemento XML de diseño.
• Siga la secuencia de pasos que se describen en Personalización del formulario web de seguimiento de elementos de trabajo.

Para personalizar el flujo de trabajo, siga estos dos pasos:

1. Modifique la WORKFLOW sección de la definición de WIT como se describe en este tema.

2. Modifique la configuración del proceso para asignar nuevos estados de flujo de trabajo a metaestados.

   Este segundo paso es necesario cuando se cambia el flujo de trabajo de un WIT que aparece en una página de herramientas de Agile. Estos WIT pertenecen a las categorías de requisitos o tareas. Para obtener más información sobre las categorías de estado, vea Estados de flujo de trabajo y categorías de estado.

Instrucciones de diseño del flujo de trabajo

El flujo de trabajo se define mediante la identificación, en primer lugar, de los estados y las transiciones válidas entre ellos. La sección de la definición wit especifica los estados válidos, las transiciones, las razones de las transiciones y las acciones opcionales que se realizarán cuando un miembro del equipo cambie el estado de un elemento WORKFLOW de trabajo.

En general, asocie cada estado a un rol de miembro del equipo y a una tarea que deba realizar una persona con ese rol para procesar el elemento de trabajo antes de cambiar su estado. Las transiciones definen las progresiones y regresiones válidas entre estados. Los motivos identifican el motivo por el que un miembro del equipo cambia un elemento de trabajo de un estado a otro. Además, las acciones admiten la automatización de la transición de un elemento de trabajo en un punto del flujo de trabajo.

Por ejemplo, el estado se establece en Nuevo cuando un evaluador abre un nuevo error que se basa en el proceso de Agile predeterminado. El desarrollador cambia el estado a Activo al corregir el error y, una vez corregido, el desarrollador cambia su estado a Resuelto y establece el valor del campo Motivo en Corregido. Después de comprobar la corrección, el evaluador cambia el estado del error a Cerrado y el campo Motivo cambia a Comprobado. Si el evaluador determina que el desarrollador no ha corregido el error, el evaluador cambiaría el estado del error a Activo y especificaría el motivo como No corregido o Error de prueba.

Al diseñar o modificar un flujo de trabajo, tenga en cuenta las siguientes instrucciones:

• Use el elemento para definir un estado único para cada rol de miembro del equipo que realizará STATE una acción específica en un elemento de trabajo. Cuantos más estados defina, más transiciones tendrá que definir. Independientemente de la secuencia en la que defina los estados, se muestran en orden alfanumérico en el menú desplegable del campo Estado.

  Si agrega un estado a un tipo de elemento de trabajo que aparece en las páginas del trabajo pendiente o del panel en el portal web, también debe asignar el estado a una categoría de estado. Para obtener más información, revise Estados de flujo de trabajo y categorías de estado.

• Use el TRANSITION elemento para definir una transición para cada progresión y regresión válidas de un estado a otro.

  Como mínimo, debe definir una transición para cada estado y la transición desde el estado null al estado inicial.

  Puede definir solo una transición de sin asignar (null) al estado inicial. Cuando guarda un nuevo elemento de trabajo, se asigna automáticamente al estado inicial.

  Cuando un miembro del equipo cambia el estado de un elemento de trabajo, ese cambio desencadena la transición y las acciones que defina para que se realicen para el estado y la transición seleccionados. Los usuarios pueden especificar solamente los estados que sean válidos según las transiciones que defina para el estado actual. Además, un ACTION elemento , que es un elemento secundario de , puede cambiar el estado de un elemento de TRANSITION trabajo.

• Para cada transición, se define un motivo predeterminado mediante el DEFAULTREASON elemento . Puede definir tantas razones opcionales como desee mediante el REASON elemento . Estos valores aparecen en el menú desplegable del campo Motivo.

• Puede especificar las reglas que se aplicarán cuando el elemento de trabajo cambie de estado, cuando se realice una transición, o cuando un usuario seleccione un motivo concreto. Muchas de estas reglas complementan las reglas condicionales que puede aplicar al definir los campos de la FIELDS sección bajo la WORKITEMTYPE definición. Para obtener más información, vea Actualizar campos durante un cambio de flujo de trabajo más adelante en este tema.

• Los nombres que asigne a los estados y motivos no distinguen mayúsculas y minúsculas.

  Los menús desplegables de los campos Estado y Motivo del formulario de elemento de trabajo o del editor de consultas muestran los valores asignados en la sección del tipo WORKFLOW de elemento de trabajo.

Ejemplo de código y diagrama de flujo de trabajo

En el ejemplo de código siguiente se muestra WORKFLOW para la definición de WIT de errores para la plantilla de proceso agile. Este ejemplo define tres estados y cinco transiciones. Los STATE elementos especifican los estados Activo, Resuelto y Cerrado. Se definen todas las combinaciones posibles de transiciones de progresión y regresión para los tres estados, excepto una. No se define la transición de Cerrado a Resuelto. Por lo tanto, los miembros del equipo no pueden resolver un elemento de trabajo de este tipo si se cierra el elemento de trabajo.

En este ejemplo no se enumera todos los elementos DEFAULTREASON de , , y REASONACTIONFIELD .

Diagrama de estado de flujo de trabajo de ejemplo: Agile 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>

Determinar el número y los tipos de estados

El número y los tipos de estados válidos se determinan según el número de estados lógicos distintos en los que desea que existan los elementos de trabajo de ese tipo. Además, si diferentes miembros del equipo realizan diferentes acciones, puede pensar en definir un estado basándose en un rol de miembro. Cada estado se corresponde con una acción que un miembro del equipo debe realizar en el elemento de trabajo para moverla hasta el siguiente estado. Para cada estado, debe definir las acciones específicas y los miembros del equipo que pueden realizar esas acciones.

En la tabla siguiente se proporciona un ejemplo de cuatro estados definidos para realizar un seguimiento del progreso de una característica, así como los usuarios válidos que deben realizar las acciones indicadas:

Definir transiciones

Controla los estados de destino y origen a los que los miembros del equipo pueden cambiar un elemento de trabajo si define las progresiones y regresiones de estado válidas. Si no define una transición de un estado a otro estado, los miembros del equipo no pueden cambiar un elemento de trabajo de un tipo determinado de un estado determinado a otro estado determinado.

La tabla siguiente define las transiciones válidas para cada uno de los cuatro estados que se describieron anteriormente en este tema, junto con el motivo predeterminado para cada uno.

Puede restringir quién puede realizar una transición de un estado a otro mediante los atributos paray no del elemento . Como se muestra en el siguiente ejemplo, los evaluadores pueden volver a abrir un error, pero no los desarrolladores.

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

Especificar los motivos

Cuando un miembro del equipo cambia el campo Estado, ese usuario puede conservar el motivo predeterminado para esa transición o especificar un motivo distinto si se definen opciones adicionales. Debe usar el elemento DEFAULTREASON para especificar uno y solo un motivo predeterminado. Debe especificar motivos adicionales solo si ayudan al equipo a realizar el seguimiento de los datos o a realizar informes sobre los mismos.

Por ejemplo, un desarrollador puede especificar uno de los siguientes motivos cuando resuelve un error: Corregido (valor predeterminado), Aplazado, Duplicado, Por diseño, No se puede reproducir u Obsoleto. Cada motivo especifica una acción concreta que debe realizar el evaluador en relación con el error.

El ejemplo siguiente muestra los elementos que definen los motivos por los que un miembro del equipo puede resolver un error:

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

Especificar acciones

En general, los miembros del equipo cambian el estado de un elemento de trabajo especificando un valor diferente para el campo Estado y, a continuación, guardando el elemento de trabajo. Sin embargo, también puede definir un elemento que cambie automáticamente el estado de un elemento de ACTION trabajo cuando se produzca esa transición. Como se muestra en el siguiente ejemplo, puede especificar que los elementos de trabajo de error deberían resolverse automáticamente si están asociados a archivos que un desarrollador protege en el control de versiones:

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

Puede usar el elemento para cambiar automáticamente el estado de los elementos de trabajo de un tipo determinado cuando se producen eventos en otra parte de la administración del ciclo de vida de la aplicación de Microsoft Visual Studio o fuera de Visual Studio Administración del ciclo de vida de la aplicación (por ejemplo, desde una herramienta que realiza un seguimiento de las ACTION llamadas). Para obtener más información, vea ACTION.

Actualizar un campo durante un cambio de flujo de trabajo

Puede definir reglas que actualizan campos cada vez que se produzcan los eventos siguientes:

• Asigne una regla de campo en cuando desee que la regla se aplique para todas las transiciones a y los motivos STATE para entrar en ese estado.

• Asigne una regla de campo en cuando desee que la regla se aplique para esa transición y todos los motivos TRANSITION para realizar esa transición.

• Asigne una regla de campo DEFAULTREASON en o cuando desee que las reglas se REASON apliquen solo por ese motivo específico.

  Si un campo siempre debe contener el mismo valor, defina la regla en el FIELD elemento que define ese campo. Para más información sobre el uso de reglas, consulte Reglas y evaluación de reglas.

  Debe intentar minimizar el número de condiciones que define para cualquier tipo de elemento de trabajo. Con cada regla condicional que agregue, se aumenta la complejidad del proceso de validación que se produce cada vez que un miembro del equipo guarda un elemento de trabajo. Los conjuntos de reglas complejas pueden aumentar el tiempo necesario para guardar el elemento de trabajo.

  Los ejemplos siguientes muestran algunas de las reglas que se aplican a los campos de sistema en la plantilla de proceso para MSF Agile Software Development.

Cambiar el valor de un campo cuando cambia el estado

Cuando el valor del campo Estado de un elemento de trabajo se establece en Activo y se guarda el elemento de trabajo, los valores de los campos Activado por y Asignado a se establecen automáticamente en el nombre del usuario actual. Ese usuario debe ser miembro del grupo Team Foundation Server usuarios válidos. El valor del campo Fecha activada también se establece automáticamente. El ejemplo siguiente muestra los elementos que aplican esta regla:

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

Borrar el valor de un campo cuando cambia el valor de otro campo

Cuando el valor del campo Estado de un elemento de trabajo se establece en Activo y se guarda el elemento de trabajo, los campos Fecha cerrada y Cerrado por se establecen automáticamente en NULL y se convierten en de solo lectura si se usa el elemento , como se muestra en el ejemplo siguiente.

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

Definir un campo en función del contenido de otro campo

Cuando el valor del campo Estado de un elemento de trabajo cambia a Resuelto y se guarda el elemento de trabajo, el valor del campo Motivo resuelto se establece en el valor especificado por el usuario en el campo Motivo. El ejemplo siguiente muestra los elementos que aplican esta regla:

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

Artículos relacionados

• Estados de flujo de trabajo y categorías de estado
• Personalización de la experiencia de seguimiento del trabajo
• Consulta por asignación, flujo de trabajo o cambios de panel Kanban
• Diseñar el formulario de elemento de trabajo
• Importar, exportar y administrar tipos de elemento de trabajo

Compatibilidad con herramientas

Puede admitir a los usuarios para visualizar el flujo de trabajo instalando la extensión State Model Visualization desde Visual Studio Marketplace.