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

Puede cambiar el flujo de trabajo de un tipo de elemento de trabajo (WIT) para que admita sus procesos de negocio y de equipo. Los tipos de elemento de trabajo admiten el seguimiento de todos los tipos de trabajo (requisitos, tareas, defectos de código) para admitir el desarrollo de software mediante Team Foundation Server (TFS).

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.

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

Para información general sobre los estados de flujo de trabajo predeterminados admitidos en las plantillas de proceso predeterminadas que proporciona TFS, vea Trabajar con artefactos de proyecto de equipo y elegir una plantilla de proceso. Para información sobre el flujo de trabajo de definición de compilación, vea Personalizar la plantilla de proceso de compilación.

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 WORKFLOW de la definición de tipo de elemento de trabajo especifica los estados válidos, las transiciones, los motivos para las transiciones y las acciones opcionales que se ejecutarán cuando un miembro del equipo cambie el estado de un elemento 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 basado en la plantilla de proceso predeterminada de Agile que Team Foundation Server (TFS) proporciona. 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 a 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 corrigió el error, el evaluador cambiará el estado del error a Activo y especificará el motivo como Sin corregir o Prueba no superada.

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

• Use el elemento STATE para definir un estado único para cada rol de miembro del equipo que vaya a realizar 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 se definen los estados, se enumeran 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 de trabajo pendiente o panel de Team Web Access, también debe asignar el estado a un metaestado. Consulta Referencia de elemento XML de la configuración del proceso.

• Use el elemento TRANSITION 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 elemento ACTION, que es un elemento secundario de TRANSITION, puede cambiar el estado de un elemento de trabajo.

• Para cada transición, defina un motivo predeterminado mediante el elemento DEFAULTREASON. Puede definir tantos motivos opcionales como desee con el elemento REASON. Estos valores aparecen en el menú desplegable del campo Razón.

• 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 se pueden aplicar al definir los campos de la sección FIELDS bajo la definición WORKITEMTYPE. Para más información, vea Actualizar un campo 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 WORKFLOW del tipo de elemento de trabajo.

Ejemplo de código y diagrama de flujo de trabajo

El siguiente ejemplo de código muestra el elemento WORKFLOW para la definición del tipo de elemento de trabajo Error de la plantilla de proceso de Agile. Este ejemplo define tres estados y cinco transiciones. Los elementos STATE 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 muestran todos los elementos para DEFAULTREASON, REASON, ACTION y FIELD.

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

Diagrama de estado de flujo de trabajo de ejemplo: tipo de elemento de trabajo Error de Agile

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 for y not del elemento TRANSITION. 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 solamente 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 luego guardando el elemento de trabajo. Sin embargo, también puede definir un elemento ACTION que cambie automáticamente el estado de un elemento de 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 ACTION para cambiar automáticamente el estado de los elementos de trabajo de un tipo determinado cuando los eventos se producen en algún lugar de Microsoft Visual Studio Application Lifecycle Management o fuera de Visual Studio Application Lifecycle Management (por ejemplo, en una herramienta que realice el seguimiento de las llamadas). Para obtener más información, consulta Automatizar las asignaciones de campo en función del estado, la transición o el motivo.

Actualizar un campo durante un cambio de flujo de trabajo

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

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

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

• Asignar una regla de campo en DEFAULTREASON o REASON cuando desee que las reglas solo se apliquen para ese motivo concreto.

Si un campo debe contener siempre el mismo valor, se define la regla en el elemento FIELD que define ese campo. Para más información sobre el uso de reglas, vea Aplicar reglas a un campo de elemento de trabajo.

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

Cambiar el valor de un campo cuando cambia el estado

Cuando se establece el valor del campo Estado para un elemento de trabajo 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 Usuarios válidos de Team Foundation Server. El valor del campo Fecha de activación 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 de cierre y Cerrado por se establecen automáticamente en null y se convierten en campos de solo lectura si usa el elemento EMPTY, 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 el elemento de trabajo se guarda, el valor del campo Motivo de resolución 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>

Preguntas y respuestas

P: ¿Existe una herramienta para cambiar el flujo de trabajo o para ver los diagramas del estado de flujo de trabajo?

R: Sí. Puede cambiar el flujo de trabajo o ver el diagrama de estado de flujo de trabajo que se está definiendo mediante el Editor de procesos, una herramienta avanzada para Visual Studio. Para más información, vea la siguiente página del sitio web de Microsoft: Herramientas avanzadas de Team Foundation Server.

P: ¿Dónde puedo obtener información general de los elementos XML de definición del tipo de elemento de trabajo?

R: Vea Referencia de todos los elementos WITD de XML.