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

  • Artículo

Azure DevOps Server 2022: Azure DevOps Server 2019

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 lógica y la regresión 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 Motivo. Para más información, consulte Acerca de los procesos y las plantillas de proceso.

Flujo de trabajo para elemento de trabajo pendiente de producto (plantilla de proceso de Scrum)

Flujo de trabajo de elementos de trabajo pendiente de productos, proceso Scrum

Nota:

En este artículo se describe cómo personalizar un estado de flujo de trabajo. Si, en su lugar, desea cambiar el estado asignado a un elemento de trabajo específico, consulte uno de los siguientes artículos: Panel Kanban, Seguimiento del trabajo en curso o Panel de tareas, Actualizar estado de la tarea. También puede realizar una actualización masiva del estado para muchos elementos de trabajo.

Para obtener información sobre los flujos de trabajo de canalización de compilación, consulte Introducción a CI/CD.

Actualización de la definición XML de un tipo de elemento de trabajo

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

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 agile. Estas WIT pertenecen a las categorías Requisito o Tarea. Para más información sobre las categorías de los estados, consulte Estados de flujo de trabajo y categorías de estado.

Directrices de diseño de flujo de trabajo

Para definir el flujo de trabajo, primero identifique los estados y las transiciones válidas entre ellos. La WORKFLOW sección de la definición de 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 de trabajo.

En general, asociará cada estado con un rol de miembro del equipo y una tarea que una persona de ese rol debe realizar 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 por qué un miembro del equipo cambia un elemento de trabajo de un estado a otro y 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 basado en el proceso ágil 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 determinó 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.

A medida que diseña o modifica un flujo de trabajo, tenga en cuenta las siguientes directrices:

  • Use el STATE elemento para definir un estado único para cada rol miembro del equipo que realizará una acción específica en un elemento de trabajo. Cuantos más estados defina, más transiciones debe 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 más información, consulte 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 del estado null al estado inicial.

    Solo puede definir una transición de unssigned (null) al estado inicial. Al guardar 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 se definen para el estado seleccionado y la transición. Los usuarios solo pueden especificar los estados que son válidos en función de las transiciones que defina para el estado actual. Además, un ACTION elemento , que es un elemento secundario de TRANSITION, puede cambiar el estado de un elemento de 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 reglas que se aplicarán cuando el elemento de trabajo cambie el estado, cuando realice la transición o cuando un usuario seleccione un motivo específico. Muchas de estas reglas complementan las reglas condicionales que puede aplicar al definir los campos de la sección en la FIELDSWORKITEMTYPE 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 los motivos no distinguen mayúsculas de minúsculas.

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

Diagrama de flujo de trabajo y ejemplo de código

En el ejemplo de código siguiente se muestra el para WORKFLOW la definición de WIT de errores para la plantilla de proceso agile. En este ejemplo se definen tres estados y cinco transiciones. Los STATE elementos especifican los estados Activo, Resuelto y Cerrado. Todas las combinaciones posibles para las transiciones de progresión y regresión se definen para los tres estados, excepto uno. 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 enumeran todos los elementos de DEFAULTREASON, REASON, ACTIONy FIELD.

Diagrama de estado de flujo de trabajo de ejemplo: Agile Bug WIT

Estados de flujo de trabajo de errores, plantilla de proceso de Agile

<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

Determina el número y los tipos de estados válidos en función del 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 considerar la posibilidad de definir un estado basado en un rol de miembro. Cada estado corresponde a una acción que un miembro del equipo debe realizar en el elemento de trabajo para moverlo al 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 y los usuarios válidos que deben realizar las acciones indicadas:

Estado Usuario válido Action to perform
Propuesto Jefe de proyecto Cualquier persona puede crear un elemento de trabajo de características. Sin embargo, solo los administradores de proyectos pueden aprobar o desaprobar el elemento de trabajo. Si un administrador de proyectos aprueba una característica, el administrador de proyectos cambia el estado del elemento de trabajo a Activo; de lo contrario, un miembro del equipo lo cierra.
Activas Jefe de desarrollo El responsable de desarrollo supervisa el desarrollo de la característica. Cuando se completa la característica, el cliente potencial de desarrollo cambia el estado del elemento de trabajo de la característica a Revisar.
Revisar Jefe de proyecto El administrador de proyectos revisa la característica que el equipo implementó y cambia el estado del elemento de trabajo a Cerrado si la implementación es satisfactoria.
Cerrada Jefe de proyecto No se espera que se produzca ninguna acción adicional en los elementos de trabajo que están cerrados. Estos elementos permanecen en la base de datos con fines de archivado e informes.

Nota:

Todos los estados aparecen en orden alfabético en la lista del formulario para un elemento de trabajo de un tipo determinado, independientemente de la secuencia en la que se especifiquen.

Definición de transiciones

Puede controlar los estados hacia y desde 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.

En la tabla siguiente se definen las transiciones válidas para cada uno de los cuatro estados descritos anteriormente en este tema, junto con el motivo predeterminado de cada uno.

Estado Transición al estado Motivo predeterminado
Propuesto Activo (progresión) Aprobado para el desarrollo
Cerrado (progresión) Sin homologar
Activas Revisión (progresión) Criterios de aceptación cumplidos
Revisar Cerrado (progresión) Característica completa
Activo (regresión) No cumple los requisitos
Cerrada Propuesto (regresión) Reconsiderar la aprobación
Activo (regresión) Cerrado en error

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

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

Especificar las razones

Cuando un miembro del equipo cambia el campo Estado, ese usuario puede conservar el motivo predeterminado de esa transición o especificar otro motivo si define opciones adicionales. Debe usar el DEFAULTREASON elemento para especificar una y solo una razón predeterminada. Solo debe especificar razones adicionales si ayudan al equipo a realizar un seguimiento o informar de los datos.

Por ejemplo, un desarrollador puede especificar uno de los siguientes motivos cuando resuelve un error: Corregido (predeterminado), Diferido, Duplicado, Como diseñado, No se puede reproducir o Obsoleto. Cada motivo especifica una acción determinada para que el evaluador realice con respecto al error.

Nota:

Todos los motivos aparecen en orden alfabético en la lista del formulario de trabajo para los elementos de trabajo de un tipo determinado, independientemente de la secuencia en la que especifique los REASON elementos.

En el ejemplo siguiente se muestran los elementos que definen los motivos por los que un miembro del equipo podría 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 ACTION elemento que cambie automáticamente el estado de un elemento de trabajo cuando se produzca esa transición. Como se muestra en el ejemplo siguiente, puede especificar que los elementos de trabajo de errores se deben resolver automáticamente si están asociados a archivos que un desarrollador comprueba en el control de versiones:

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

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

Actualizar un campo durante un cambio de flujo de trabajo

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

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

  • Asigne una regla de campo en TRANSITION cuando desee que la regla se aplique a esa transición y todas las razones para realizar esa transición.

  • Asigne una regla de campo en DEFAULTREASON o REASON cuando desee que las reglas solo se apliquen 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 defina para cualquier tipo de elemento de trabajo. Con cada regla condicional que agregue, aumentará 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 complejos pueden aumentar el tiempo necesario para guardar el elemento de trabajo.

    En los ejemplos siguientes se muestran algunas de las reglas que se aplican a los campos del sistema en la plantilla de proceso para el desarrollo de software ágil de MSF.

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 Activated By y Assigned To se establecen automáticamente en el nombre del usuario actual. Ese usuario debe ser miembro del grupo Usuarios válidos de Team Foundation Server. El valor del campo Fecha activada también se establece automáticamente. En el ejemplo siguiente se muestran 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 solo lectura si se usa el EMPTY 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 basado en el 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 . En el ejemplo siguiente se muestran 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>

Compatibilidad con herramientas

Puede admitir a los usuarios para visualizar el flujo de trabajo instalando la extensión Visualización de modelos de estado desde Visual Studio Marketplace.