Diseñar el flujo de trabajo

El flujo de trabajo de un tipo de elemento de trabajo se diseña con el propósito de admitir procesos empresariales y de equipo específicos.El flujo de trabajo determina la progresión lógica de tareas que se realizarán y quién las realizará.El flujo de trabajo se define identificando primero los estados y las transiciones válidas entre ellos.La sección WORKFLOW de la definición del tipo de elemento de trabajo define los estados válidos, las transiciones, los motivos de las transiciones y las acciones opcionales que se realizarán cuando un miembro del equipo cambie el estado de un elemento de trabajo.Para obtener más información acerca de las definiciones de tipos, vea Referencia de todos los elementos XML WITD.

En general, cada estado se asocia a un rol de miembro del equipo y a una tarea que una persona con 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 los estados.Los motivos identifican por qué un miembro del equipo cambia un elemento de trabajo de un estado a otro, y las acciones permiten la automatización de la transición de un elemento de trabajo en un punto del flujo de trabajo.

Importante
Si agrega un estado a un tipo de elemento de trabajo que aparece en las páginas de trabajo pendiente o del comité en Team Web Access, también debe asignar el estado a un metastate.Vea Personalizar las páginas de panel y de trabajo pendiente mediante la configuración del proceso.

Por ejemplo, el estado está establecido en Nueva cuando un evaluador abre un nuevo error basada en la plantilla predeterminada de proceso de MSF que Team Foundation Server (TFS) proporciona.El desarrollador cambia el estado Activa a corregir el error, y corregido una vez, el desarrollador cambia su estado a Resuelto y establezca el motivo en Corregido.Después de comprobar la corrección, el evaluador cambia el estado del error a Cerrado y el campo motivo a Comprobado.Si el evaluador determinase que el desarrollador no ha corregido el error, cambiaría el estado del error a Activa y especificar el Motivo como Sin corregir o Prueba no superada.

[!NOTA]

Puede crear y modificar las definiciones de tipos de elemento de trabajo y otros objetos para realizar el seguimiento de los elementos de trabajo mediante Process Editor, una herramienta avanzada para Visual Studio.No se ofrece soporte técnico para esta herramienta.Para obtener más información, vea la siguiente página en el sitio Web de Microsoft: Herramientas avanzadas de Team Foundation Server.

En este tema

• Instrucciones de diseño del flujo de trabajo

• Diagrama del flujo de trabajo y ejemplo de código

• Determinar el número y los tipos de estados

• Definir las transiciones

  • Especificar los motivos

  • Especificar las acciones

• Actualizar un campo cuando cambia el estado

  • Definir un campo cuando cambia el estado

  • Borrar el valor de un campo

  • Definir un campo a partir del contenido de otro campo

• Ver el diagrama de estados de flujo de trabajo

Instrucciones de diseño del flujo de trabajo

Cuando se diseña o modifica un flujo de trabajo, se deben tener en cuenta las siguientes instrucciones:

• Al usar el elemento STATE, se define un estado único para cada rol de miembro del equipo que vaya a realizar una acción concreta con un elemento de trabajo.Cuantos más estados se definen, más transiciones habrá que definir.Se enumeran por orden alfanumérico en la lista Estado sin tener en cuenta la secuencia con la que se definen los estados.

• Para definir una transición para cada progresión y regresión válida de un estado a otro se usa el elemento TRANSITION.

• Como mínimo, se debe definir una transición para cada estado, y la transición del estado nulo al estado inicial.

• Para cada transición, se debe definir un motivo predeterminado mediante el elemento DEFAULTREASON.Puede definir tantos motivos opcionales como desee mediante el elemento REASON.

• Los menús desplegables para los campos de estado y motivo dentro del elemento de trabajo o presentación del editor de consultas que los valores asignaban en la sección de WORKFLOW del tipo de elemento de trabajo.

• Solo se puede definir una transición del estado sin asignar (nulo) al estado inicial.Al guardar un nuevo elemento de trabajo, se le asigna automáticamente el estado inicial.

• Cuando un miembro del equipo cambia el estado de un elemento de trabajo, ese cambio activa la transición y las acciones que se han definido para que se realicen para el estado seleccionado y la transición.Los usuarios pueden especificar solo los estados que son válidos en función de las transiciones que definan 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.

• Se pueden definir para cualquier campo reglas condicionales, que se aplicarán cuando el elemento de trabajo cambie de estado o experimente 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 en la sección FIELDS bajo la definición WORKITEMTYPE.Para obtener más información, vea Actualizar los campos cuando cambia un estado, más adelante en este mismo tema.

• Debería intentar minimizar el número de condiciones que define para cualquier tipo de elemento de trabajo.Con cada regla condicional que se agrega, 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 complejos pueden aumentar el tiempo necesario para guardar el elemento de trabajo.

• Los nombres que se asignan a los estados y motivos no hacen distinción entre mayúsculas y minúsculas.

Volver al principio

Diagrama del flujo de trabajo y ejemplo de código

En la siguiente tabla se muestra la sección WORKFLOW de la definición de un tipo de elemento de trabajo que realiza el seguimiento de defectos de código y el diagrama de estados de flujo de trabajo que define.En este ejemplo se definen tres estados, seis transiciones y nueve motivos.Los elementos STATE especifican los estados Activo, Resuelto y Cerrado.Se definen todas las posibles combinaciones de transiciones de progresión y regresión para los tres estados menos uno.No se define la transición de Cerrado a Resuelto.Por consiguiente, los miembros del equipo no pueden resolver ningún elemento de trabajo de este tipo si se cierra el elemento de trabajo.

[!NOTA]

En el ejemplo no se muestran 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" /> </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>

Diagrama de estados de flujo de trabajo de ejemplo

Determinar el número y los tipos de estados

Determina el número y los tipos de estados válidos según el número de estados lógicos distintos en los que se desea que existan los elementos de trabajo de ese tipo.Por otra parte, si distintos miembros del equipo realizan acciones diferentes, puede considerar la definición de un estado basado en el rol de un miembro.Cada estado se corresponde con una acción que un miembro del equipo debe realizar en el elemento de trabajo para moverlo al estado siguiente.Para cada estado, debería definir las acciones concretas y los miembros del equipo que pueden realizar esas acciones.

La siguiente tabla proporciona un ejemplo de cuatro estados definidos para realizar el seguimiento del progreso de una característica y los usuarios válidos que deben realizar las acciones indicadas:

Estado	Usuario válido	Acción por realizar
Propuesto	Jefe de proyecto	Cualquiera puede crear un elemento de trabajo de característica.Sin embargo, solo los jefes de proyecto pueden aprobar o desaprobar el elemento de trabajo.Si un jefe de proyecto aprueba una característica, el jefe de proyecto cambia el estado del elemento de trabajo a Activo; de lo contrario, un miembro del equipo lo cierra.
Activo	Responsable de desarrollo	El responsable de desarrollo supervisa el desarrollo de la característica.Cuando se completa la característica, el responsable de desarrollo cambia el estado del elemento de trabajo de característica a Revisión.
Revisión	Jefe de proyecto	El jefe de proyecto revisa la característica que el equipo implementó y cambia el estado del elemento de trabajo a Cerrado si la implementación es satisfactoria.
Cerrado	Jefe de proyecto	No se espera ninguna acción adicional en los elementos de trabajo cerrados.Estos elementos permanecen en la base de datos para archivarlos y generar informes.

[!NOTA]

Todos los estados aparecen ordenados alfabéticamente en el formulario para un elemento de trabajo de un tipo determinado, sin tener en cuenta la secuencia en la que se especifican.

Volver al principio

Definir las transiciones

Los estados entre los que los miembros del equipo pueden cambiar un elemento de trabajo se pueden controlar si se definen progresiones y regresiones de estado válidas.Si no se define una transición de un estado a otro, los miembros del equipo no pueden cambiar un elemento de trabajo de un tipo determinado de un estado a otro estado determinado.

En la siguiente tabla 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 a estado	Motivo predeterminado
Propuesto	Activo (progresión)	Aprobado para desarrollo
	Cerrado (progresión)	No aprobado
Activo	Revisión (progresión)	Criterios de aceptación cumplidos
Revisión	Cerrado (progresión)	Característica completa
	Activo (regresión)	No cumple los requisitos
Cerrado	Propuesto (regresión)	Reconsiderar para aprobación
	Activo (regresión)	Cerrado por error

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 reabrir un error, pero no así los desarrolladores.

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

Volver al principio

Especificar los motivos

Cuando un miembro del equipo cambia el campo de estado, ese usuario puede mantener el motivo predeterminado de la transición o especificar un motivo diferente si se definen otras opciones.Debe utilizar el elemento DEFAULTREASON para especificar un único motivo predeterminado.Debería especificar otros motivos adicionales si ello ayudará al equipo a realizar el seguimiento de los datos o a generar informes con los mismos.

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

[!NOTA]

Todos los motivos se enumeran por orden alfabético en el formulario de trabajo para los elementos de trabajo de un tipo determinado, sin tener en cuenta la secuencia en la que se especifican los elementos REASON.

En el siguiente ejemplo se muestran los elementos que definen los motivos por los cuales 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>

Volver al principio

Especificar las acciones

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

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

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

Volver al principio

Actualizar un campo

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

• Asigne una regla de campo bajo STATE si desea que la regla se aplique a todas las transiciones a un estado y los motivos para llegar a ese estado.

• Asigne una regla de campo bajo TRANSITION si desea que la regla se aplique a esa transición y todos los motivos para realizar esa transición.

• Asigne una regla de campo bajo DEFAULTREASON o REASON si desea que las reglas solo se apliquen a ese motivo concreto.

Si un campo siempre debe contener el mismo valor, la regla se define bajo el elemento FIELD que define ese campo.Para obtener más información, vea Establecer las condiciones de un campo de elemento de trabajo.

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

• Cambiar el valor de un campo cuando cambia el estado

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

• Definir un campo a partir del contenido de otro campo

Volver al principio

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 Valid Users.El valor del campo Fecha de activación también se establece automáticamente.En el siguiente ejemplo 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>

Volver al principio

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 pasan a ser de solo lectura si se 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>

Volver al principio

Definir un campo a partir 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 de resolución se establece en el valor que el usuario especificó en el campo Motivo.En el siguiente ejemplo 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>

Volver al principio

Ver el diagrama de estados de flujo de trabajo

Puede ver el diagrama de estados de flujo de trabajo que se está definiendo mediante process editor, una herramienta avanzada para Visual Studio.No se ofrece soporte técnico para esta herramienta.Para obtener más información, vea la siguiente página en el sitio Web de Microsoft: Herramientas avanzadas de Team Foundation Server.

Volver al principio

Vea también

Otros recursos

Definir y personalizar el flujo de trabajo de elementos de trabajo