Acerca de los estados de flujo de trabajo en trabajos pendientes y paneles

Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Los flujos de trabajo son fundamentales para la forma en que Azure Boards realiza un seguimiento de los elementos de trabajo. Cada tipo de elemento de trabajo tiene su propio flujo de trabajo que define estados, transiciones y motivos. Las transiciones mueven los elementos de trabajo hacia delante y hacia atrás entre estados. Al agregar un estado personalizado, Azure DevOps agrega transiciones predeterminadas basadas en reglas de proceso.

Azure Boards usa categorías de estado para aplicar el comportamiento del flujo de trabajo de forma coherente en trabajos pendientes, paneles y widgets. En este artículo se explica cómo los estados se corresponden con categorías y cómo esta correspondencia afecta a la visibilidad de los elementos, las columnas del tablero y el comportamiento de los informes.

Estados de flujo de trabajo

Los estados de flujo de trabajo definen cómo se mueve un elemento de trabajo de la creación al cierre. En el proceso ágil, un caso de usuario suele pasar por Nuevo, Activo, Resuelto y Cerrado. Para quitar un elemento de trabajo de la lista de trabajo pendiente, use el estado Eliminado. Para más información, vea Movimiento, cambio o eliminación de elementos de trabajo.

En el diagrama siguiente se muestran las rutas típicas de progresión y regresión para los tipos comunes de elementos de trabajo: caso de usuario (Agile), problema (Básico), elemento de trabajo pendiente de producto (Scrum) y requisito (CMMI).

Estados de flujo de trabajo: casos de usuario, proceso de Agile

Diagrama que muestra los estados de los flujos de trabajo de la Historia de Usuario para el proceso ágil.

Estados de categoría

Las categorías de estado normalizan cómo las herramientas de planeamiento ágil y los widgets de panel interpretan los estados de flujo de trabajo. Teams asigna estados de flujo de trabajo a estos estados de categoría: Propuesto, En curso, Resuelto y Completado.

En la tabla siguiente se muestra cómo los estados heredados predeterminados se corresponden con los estados de categoría en cada uno de los cuatro procesos del sistema, incluidos los tipos de elementos de trabajo de Plan de prueba. Los flujos de trabajo de casos de prueba, de diseño de pruebas y de conjuntos de pruebas utilizan las mismas asignaciones en los cuatro procesos.

Categories

Seguimiento del trabajo

Seguimiento de pruebas

Propuesta: Use esta categoría para los estados de elementos de trabajo recién agregados. Los elementos aparecen en el trabajo pendiente y la primera columna de paneles y paneles de tareas se asigna a Propuesto.

New

Diseño (caso de prueba)

En curso: Use esta categoría para los estados de trabajo activos. Los elementos aparecen en el backlog (a menos que estén ocultos) y se corresponden con las columnas centrales del tablero.

Activo (Error, Epopeya, Característica, Caso de usuario)

Activo (Plan de pruebas); En planificación (Conjunto de pruebas); En curso (Conjunto de pruebas); Listo (caso de prueba)

Resuelto: Use esta categoría para los estados en los que se implementa una solución pero aún no se ha comprobado (normalmente para errores). Los elementos resueltos aparecen en el trabajo pendiente de forma predeterminada, se pueden incluir en gráficos de agotamiento y comportarse como En curso en muchas herramientas.

Resuelto (error)

n/a

Completado: Use esta categoría para estados de trabajo terminados. Los elementos no aparecen en la lista de tareas pendientes y se corresponden con la última columna del tablero. Cada tipo de elemento de trabajo solo puede tener un estado asignado a esta categoría.

Cerrado (Error, Epopeya, Característica, Caso de usuario)

Cerrado (caso de prueba); Completado (Conjunto de pruebas); Inactivo (plan de prueba)

Eliminado: use esta categoría con el estado Eliminado para ocultar elementos de las experiencias de trabajo pendiente y panel.

Quitado (Epopeya, Característica, Caso de usuario)

n/a

Donde aparecen los tipos de elementos de trabajo

Use la tabla siguiente como referencia rápida para donde aparece cada categoría de tipo de elemento de trabajo.

Categoría de tipo de elemento de trabajo Aparece en
Requirement Solo placa del producto
Feature Solo tablero de la cartera de características
Epic Solo para el tablero de cartera de Epic
Custom Solo panel de portafolio personalizado

Tip

Mapea cada estado del flujo de trabajo a una columna del tablero. Si un estado no está asignado, no aparece en el panel.

Note

  • Los trabajos pendientes y los paneles ocultan los elementos de trabajo completados o cerrados cuando su fecha modificada es superior a 183 días (aproximadamente seis meses).
  • Para buscar elementos ocultos, ejecute una consulta.
  • Mostrar de nuevo un elemento en un backlog o panel realizando una actualización menor para actualizar la Fecha de cambio.

Note

  • Los trabajos pendientes y los paneles ocultan los elementos de trabajo completados o cerrados cuando su fecha modificada es anterior a un año.
  • Para buscar elementos ocultos, ejecute una consulta.
  • Mostrar de nuevo un elemento en un backlog o panel realizando una actualización menor para actualizar la Fecha de cambio.

Campos Activado por/Fecha y Resuelto por/Fecha

El sistema actualiza estos campos( Activado por, Fecha activada, Resuelta por y Fecha resuelta) en función de los cambios de estado de categoría de flujo de trabajo:

  • Cuando el estado del flujo de trabajo cambia a una categoría En curso , el sistema actualiza Activated By y Activated Date.
  • Cuando el estado del flujo de trabajo cambia a una categoría Resuelto, el sistema actualiza Resuelto por y Fecha de resolución.

Para obtener más información sobre cómo se asignan los estados de flujo de trabajo a las categorías de estado, consulte Cómo se usan los estados de flujo de trabajo y las categorías de estado en trabajos pendientes y paneles.

Note

Esta lógica se aplica a Azure DevOps Services, Azure DevOps Server 2020.1 y versiones posteriores.

Dado que estos campos hacen referencia a categorías de estado de flujo de trabajo, los estados de flujo de trabajo personalizados que agregue también desencadenan actualizaciones de campos. Para obtener más información, consulte Personalización del flujo de trabajo de un proceso.

Notas adicionales

  • Los campos se actualizan cada vez que un elemento de trabajo se mueve desde un estado de categoría distinto del que se establece. Por ejemplo, si traslada un elemento de trabajo de Nuevo a Fijo, los campos Resuelto por/Fecha de resolución se actualizan. Si se mueve de Fixed a Ready for Testing (que se encuentra en el mismo estado de categoría), los campos Resueltos por fecha resuelta no se actualizan.
  • Al retroceder, como desde un estado Resuelto a un estado Activo, el sistema borra los campos Resuelto Por/Fecha de Resolución. Si se mueve de Activo a Nuevo, el sistema borra los campos Activated By/Activated Date .
  • No cambie manualmente estos valores de campo. Estos campos son campos del sistema regidos por reglas del sistema y Azure DevOps sobrescribe los valores manuales.

Cuándo agregar un Estado frente a una columna

Use los estados y columnas juntos para realizar un seguimiento del estado del trabajo, pero use cada uno para un ámbito diferente:

  • Estado: Lógica de flujo de trabajo a nivel de proyecto compartida entre equipos.
  • Columna: visualización del tablero a nivel de equipo.

Los usuarios con permisos de edición de procesos (normalmente Project administradores de recopilación o editores de procesos delegados) pueden agregar estados personalizados. Los administradores del equipo y los administradores de Project pueden agregar columnas de panel.

Agregue estados personalizados cuando los equipos necesiten una definición de flujo de trabajo compartida para consultas, informes y coherencia entre equipos. Los estados personalizados se propagan a los tipos de elementos de trabajo que hacen referencia al proceso.

Agregue o ajuste las columnas cuando un equipo necesita una vista específica del panel de trabajo sin cambiar el flujo de trabajo compartido.

Para evitar confusiones, mantenga la propiedad del elemento de trabajo alineada con las rutas de acceso del área de equipo o normalice los flujos de trabajo compartidos con estados personalizados cuando varios equipos sigan el mismo proceso.

Completar automáticamente los elementos de trabajo con solicitudes de incorporación de cambios

Al vincular un elemento de trabajo a una solicitud de incorporación de cambios (PR), Azure DevOps puede completar automáticamente el elemento de trabajo vinculado cuando se complete la solicitud de incorporación de cambios. Para obtener más información, consulta Automatización de la finalización de elementos de trabajo con PR.

Automatización de transiciones de estado de elementos de trabajo

Azure DevOps puede actualizar automáticamente el estado de un elemento de trabajo primario en función del estado de sus tareas secundarias. Para obtener más información, consulte Automatización de las transiciones de estado del elemento de trabajo.

Contenido relacionado

Modelo de proceso de herencia

Modelo de proceso XML local

Widgets de panel

  • Last updated on