Cómo se usan los estados de flujo de trabajo y las categorías de estado en los backlogs y paneles

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

Todos los flujos de trabajo constan de estados, transiciones y motivos. Los flujos de trabajo se definen para un tipo de elemento de trabajo (WIT). Una transición admite el movimiento hacia delante y hacia atrás entre dos estados. Cuando se agrega un estado personalizado, el sistema agrega automáticamente las transiciones del estado personalizado a todos los demás estados heredados (excepto quitado).

Cada estado pertenece a una categoría de estado (anteriormente denominada metaestado). Las categorías de estado admiten el trabajo pendiente de la herramienta Agile y las vistas de placa.

Estados de flujo de trabajo

Los estados de flujo de trabajo definen cómo progresa un elemento de trabajo tras su creación hasta su cierre. Por ejemplo, los cuatro estados principales definidos para el caso de usuario (proceso agile) definen una progresión de cuatro estados, de Nuevo, Activo, Resuelto, a Cerrado. (El estado Quitado admite la eliminación de un elemento de trabajo para que no aparezca en el trabajo pendiente; para obtener más información, vea Mover, cambiar o eliminar elementos de trabajo).

Las progresión y regresiones naturales del caso de usuario, el elemento de trabajo pendiente del producto y los WIT de requisitos son los que se muestran.

Estados de flujo de trabajo: caso de usuario, proceso agile

Estados de flujo de trabajo de caso de usuario, proceso agile

Categorías de estado

Las categorías de estado determinan cómo las herramientas de planeamiento de Agile y los widgets de panel seleccionados tratan cada estado de flujo de trabajo. Las categorías de estado usadas por los backlogs, paneles y widgets son Proposed, In Progress y Complete.

Este es el modo en que los estados heredados predeterminados se asignan a las categorías de estado de los tres procesos del sistema más los WIT de administración de casos de prueba. Los estados de flujo de trabajo de Caso de prueba, Diseño de pruebas y Conjunto de pruebas son los mismos en los cuatro procesos del sistema.

Nota:

El proceso Básico está disponible cuando se agrega un proyecto a Azure DevOps Services o Azure DevOps Server 2019 Update 1. Para implementaciones locales anteriores, elija Agile, Scrum o proceso de CMMI.

Categorías

WIT de seguimiento de trabajo

WiT de seguimiento de pruebas

Propuesta: Se asigna a los estados asociados a los elementos de trabajo recién agregados para que aparezcan en el trabajo pendiente. La primera columna de los paneles Kanban y paneles de tareas se asigna a una categoría de estado Propuesto.

Tareas

Diseño (caso de prueba)

En curso: Se asigna a los estados que representan el trabajo activo. Los elementos de trabajo asignados a estados asignados a esta categoría aparecen en el trabajo pendiente (a menos que decida ocultarlos) y conste de las columnas centrales de los paneles Kanban.

En curso

Activo (plan de prueba) en planeamiento (conjunto de pruebas) en curso (conjunto de pruebas) listo (caso de prueba)

Resuelto: Se ha implementado la asignación a los estados que representan una solución, pero aún no se han comprobado. Por lo general, estos estados se aplican a los WIT de errores. Los elementos de trabajo en estado Resuelto aparecen en el trabajo pendiente de forma predeterminada. Las herramientas de Agile tratan la categoría de estado Resuelto exactamente igual que la categoría de estado En curso.

N/D

N/D

Completado: Se asigna a los estados que representan el trabajo que ha finalizado. Los elementos de trabajo cuyo estado está en esta categoría no aparecen en el trabajo pendiente y aparecen en la última columna del panel Kanban. No se pueden modificar los estados de esta categoría ni se pueden agregar estados a esta categoría.

Listo

Cerrado (caso de prueba) completado (conjunto de pruebas) inactivo (plan de pruebas)

Se ha quitado: Se asigna al estado Quitado. Los elementos de trabajo en un estado asignado a la categoría Quitado se ocultan de las experiencias de trabajo pendiente y placa.

N/D

N/D

Nota:

Los elementos de trabajo completados o cerrados no se muestran en los trabajos pendientes y paneles una vez que la fecha de cambio es mayor que un año de antigüedad. Todavía puede enumerar estos elementos mediante una consulta. Si desea que se muestren en un trabajo pendiente o placa, puede realizar un cambio menor en ellos que restablezca el reloj.

Campos Activated By/Date y Resolved By/Date

El sistema actualiza estos campos(Activadopor , Fechaactivada , Resueltopor y Fecharesuelta) cuando se produce un cambio en función de los estados de categoría de flujo de trabajo correspondientes. Cuando el estado del flujo de trabajo cambia a una categoría de estado Propuesto, se actualizan Activated By y Activated Date. Cuando el estado del flujo de trabajo cambia a una categoría de estado Resuelto, se actualizan Resolved By (Resuelto por) y Resolved Date (Fecha resuelta).

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

Nota:

La lógica que rige los campos descritos aquí se aplica a Azure DevOps Services, Azure DevOps Server 2020.1 updatey versiones posteriores.

Dado que estos campos hacen referencia a las categorías de estado de flujo de trabajo, se hace referencia a los estados de flujo de trabajo personalizados que agregue al actualizar los campos. Para más información sobre la personalizació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 cualquier estado de categoría distinto del establecido. Por ejemplo, si actualiza un elemento de trabajo de Nuevo a Fijo ,se actualizan los campos Resolved By/Resolved Date (Fecha resuelta por/Resuelta). Sin embargo, si actualiza desde Fijo y Listo para pruebas (quese encuentran en el mismo estado de categoría), los campos Resolved By/Resolved Date no se actualizan.
  • Al realizar la transición hacia atrás, como pasar de un estado Resuelto a Activo, el sistema borra los valores de los campos Resolved By/Resolved Date . Si ha pasado de Activo a Nuevo,el sistema borra los valores de los campos Activated By/Activated Date (Fecha activada por/Activado).
  • No cambie manualmente los valores de estos campos. Son campos del sistema que se rigen por reglas del sistema. Cualquier valor que intente establecer se escribirá en exceso.

Cuándo agregar un estado frente a una columna Kanban

Las columnas States y Kanban se usan para realizar un seguimiento del estado del trabajo. Los estados de flujo de trabajo se comparten entre un proyecto, mientras que las columnas Kanban se comparten dentro de un equipo. Solo los administradores de la colección de proyectos pueden agregar estados personalizados, mientras que los administradores del equipo pueden agregar columnas Kanban.

Agregue estados personalizados cuando desee que todos los equipos realicen un seguimiento del estado según el flujo de trabajo empresarial adoptado por la organización. Al personalizar el proceso, se personalizan automáticamente los proyectos y wi-fi que hacen referencia a ese proceso.

Además, al agregar estados personalizados para admitir esos estados de flujo de trabajo de los que varios equipos desean realizar un seguimiento, se evita la confusión que puede surgir cuando el equipo crea una consulta basada en una columna Kanban. Dado que cada equipo puede personalizar las columnas del panel Kanban y las calles, es posible que los valores asignados a los elementos de trabajo que aparecen en paneles diferentes no sean los mismos. La principal forma de resolver este problema es mantener la propiedad única de los elementos de trabajo por ruta de acceso de área de equipo. Otra solución es formalizar las columnas mediante la adición de estados personalizados, que se pueden compartir entre equipos.

Finalización automática de elementos de trabajo con solicitudes de extracción

Al vincular un elemento de trabajo a una solicitud de extracción (PR), puede completar automáticamente esos elementos de trabajo al completar la solicitud de solicitud de cambio. Para obtener información sobre cómo hacerlo, consulte Autocompletar elementos de trabajo con solicitudes de extracción.