Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
servicios de Azure DevOps
Nota:
Esta característica solo está disponible en Azure DevOps Services. Azure DevOps Server no se admite.
Actualiza automáticamente el estado de un elemento de trabajo según el estado de las tareas secundarias. Por ejemplo, cuando una tarea secundaria se mueve a un estado activo (como Active o In Progress), el elemento de trabajo primario también se mueve a un estado activo. Cuando todas las tareas secundarias alcanzan un estado completado (como Closed o Done), el elemento de trabajo primario se cierra automáticamente.
Importante
Las reglas de automatización de elementos de trabajo solo se aplican al flujo de trabajo de su equipo en el backlog y los tableros. Otros equipos del proyecto pueden establecer sus propias reglas independientes.
Nota:
Las reglas usan categorías de estado , no nombres de estado específicos, por lo que funcionan de forma coherente en todas las plantillas de proceso (Agile, Scrum, CMMI). Por ejemplo, una regla que cierra el elemento primario cuando se completan todos los elementos secundarios se aplica independientemente de si el proceso llama a ese estado Closed, Doneo Resolved.
Establezca reglas en el nivel de trabajo pendiente del equipo. Estas reglas se aplican a todos los elementos de trabajo en ese nivel específico. Puede establecer estas reglas de forma independiente para cada nivel de trabajo pendiente, incluidas historias, características y epopeyas. Por ejemplo, puedes automatizar el cierre de casos de usuarios, pero mantener abiertas las características y épicas.
Tip
Puede utilizar la inteligencia artificial para ayudar con esta tarea más adelante en este artículo, o consulte Habilitar la asistencia de IA con Azure DevOps MCP Server para comenzar.
Requisitos previos
| Categoría | Requisitos |
|---|---|
| Proyecto | Un proyecto de Azure DevOps. |
| Niveles de acceso | Básico o superior. Los usuarios con acceso Stakeholder no tienen acceso a la navegación de Boards ni a la configuración del equipo. |
| Permisos | Para configurar reglas de automatización de elementos de trabajo para tu equipo: el rol de Administrador de Equipo o miembro del grupo Administradores de Proyectos. |
Establecer reglas
Establezca reglas de equipo para cada nivel de trabajo pendiente.
Nota:
- Requisito de ámbito de equipo: las reglas de automatización se desencadenan solo cuando los elementos de trabajo pertenecen al mismo equipo. Cerrar una tarea en un equipo o proyecto diferente no actualiza automáticamente el estado del elemento primario.
- Limitación de la interfaz: las reglas de automatización de estado del elemento de trabajo solo funcionan cuando se actualizan los elementos a través de paneles, trabajos pendientes o vistas sprint. Estas reglas no se desencadenan al actualizar estados de elementos de trabajo desde resultados de consulta o formularios de elementos de trabajo.
- Reactivación: las reglas no se desencadenan cuando un elemento secundario se mueve de un estado completado a un estado activo. Este comportamiento es por diseño.
Inicie sesión en el proyecto (
https://dev.azure.com/{Your_Organization}/{Your_Project}).Selecciona Paneles>Trabajos pendientes>
Configurar opciones del equipo.
Seleccione Reglas.
Seleccione una o varias reglas para aplicar en este nivel de trabajo pendiente y, a continuación, seleccione Guardar.
Están disponibles las siguientes reglas:
Rule Cuando se activa Actualizar el estado primario a Activo cuando un estado secundario está activo Cuando cualquier elemento secundario se mueve a una categoría de estado activa Actualizar el estado del elemento principal a Resuelto cuando todos los estados de los elementos secundarios sean Resueltos o Completados Cuando todos los elementos secundarios alcanzan una categoría de estado resuelta o completada Actualizar el estado principal a Cerrado cuando todos los estados secundarios estén Cerrados o Completados Cuando todos los elementos secundarios pasan a una categoría de estado cerrada o completada Las reglas solo se aplican a las transiciones de estado futuras. Los elementos de trabajo existentes no se actualizan retroactivamente al habilitar reglas.
Para aplicar reglas en otros niveles de trabajo pendiente (como Características o Epopeyas), abra el trabajo pendiente de cada nivel, seleccione Configurar reglas de configuración> de equipo y repita estos pasos. Cada nivel de trabajo pendiente tiene su propia configuración de regla independiente.
Deshabilitar reglas
Para deshabilitar una regla, vaya a Configurar reglas de configuración> de equipo, desactive las casillas aplicables y seleccione Guardar. El cambio surte efecto inmediatamente para futuras transiciones de estado.
Comprobación de que las reglas funcionan
Para confirmar que las reglas están activas, actualiza el estado de un elemento hijo en tu trabajo pendiente o en tu tablero y comprueba que el elemento principal se actualice automáticamente. Si el elemento principal no se actualiza, confirma que ambos elementos estén asignados al mismo equipo y que estás actualizando desde Boards, Backlogs o Sprints (no desde el resultado de una consulta o el formulario de un elemento de trabajo).
Reglas aplicadas al tablero de sprint
Estas reglas también se aplican cuando actualizas elementos secundarios en el tablero de sprint.
Reglas aplicadas en el nivel del backlog de historias de usuario
En el ejemplo siguiente se muestran las reglas aplicadas al nivel de trabajo pendiente de casos de usuarios.
Reglas aplicadas a varios niveles de trabajo pendiente sincronizados
En el ejemplo siguiente se muestran las reglas aplicadas a varios niveles de trabajo pendiente sincronizados.
Use la IA para automatizar las transiciones de estado de los elementos de trabajo
Puede usar la asistencia de IA a través del servidor MCP de Azure DevOps para ayudarle a configurar y solucionar problemas de reglas de automatización de elementos de trabajo. Aquí tiene algunas indicaciones de ejemplo que puede usar:
| tarea | Mensaje de ejemplo |
|---|---|
| Descripción de las categorías de estado | "Explicar cómo funcionan las categorías de estado en Azure Boards y cómo se asignan a mi plantilla de proceso ágil" |
| Descripción de las categorías de estado | "¿Cuál es la diferencia entre las categorías de estado y los nombres de estado en Azure Boards?" |
| Configuración de reglas del plan | "¿Qué niveles de trabajo pendiente de nuestro proyecto deben tener habilitadas las reglas de automatización y qué debe hacer cada regla?" |
| Configuración de reglas del plan | "¿Qué reglas de automatización se recomienda para un equipo que use la plantilla de proceso de Scrum?" |
| Solucionar problemas de reglas | Nuestras historias de usuario padre no se cierran cuando cerramos todas las tareas hijas; ¿qué debo revisar? |
| Solucionar problemas de reglas | "¿Por qué funcionan las reglas de automatización para un equipo de nuestro proyecto, pero no para otro?" |
| Análisis de estados de elementos de trabajo | "Revise el estado actual de los elementos de trabajo en nuestro sprint e identifique los elementos primarios que no coinciden con los estados de sus elementos secundarios" |
| Análisis de estados de elementos de trabajo | Muéstrame qué funcionalidades principales todavía tienen historias hijas activas y cuáles deberían estar ya cerradas |
Nota:
Estas indicaciones funcionan mejor cuando se proporciona contexto sobre la plantilla de proceso del equipo y la configuración del trabajo pendiente. Cuanto más específico sea, mejor será la sugerencia.
Preguntas más frecuentes sobre las reglas de automatización de elementos de trabajo
¿Por qué los elementos de trabajo cambian de estado automáticamente?
Si los elementos de trabajo cambian de estado inesperadamente, es probable que el equipo habilite las reglas de automatización. Vaya a Configurar la configuración del equipo>Reglas para revisar y ajustar las reglas activas.
¿Por qué no se desencadenan reglas al reactivar un elemento secundario?
Las reglas no se activan cuando un elemento secundario pasa de un estado completado a un estado activo. Este comportamiento es por diseño para evitar que las reglas deshagan cierres intencionados.
¿Por qué no funcionan las reglas de automatización para los elementos de un equipo o proyecto diferente?
Las reglas solo se activan cuando los elementos de trabajo principal y secundario pertenecen al mismo equipo. Los cambios de estado entre equipos y entre proyectos no activan las reglas de automatización.
Para preguntas adicionales, incluida si puede establecer reglas por tipo de elemento de trabajo y cómo automatizar casos de usuario sin afectar a las características, consulte las preguntas más frecuentes sobre las reglas de Automatización.