Su Template de datos del ciclo de vida del desarrollo de software

Azure DevOps
Su Template de datos del ciclo de vida del desarrollo de software

Su Template de datos del ciclo de vida del desarrollo de software

Este Template ofrece una guía clara para preparar los datos del ciclo de vida del desarrollo de software para Process Mining. Describe los atributos de datos esenciales que debe recopilar, las actividades clave que conviene seguir y ofrece instrucciones prácticas para extraer esta información de Azure DevOps. Utilice este recurso para estructurar correctamente los datos y obtener análisis útiles que permitan optimizar los procesos.
  • Atributos recomendados para recopilar
  • Actividades clave que conviene seguir en el ciclo de vida del desarrollo de software
  • Instrucciones detalladas para extraer datos de Azure DevOps
¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Atributos del ciclo de vida del desarrollo de software

Estos son los campos de datos recomendados para incluir en el registro de eventos y realizar un análisis y una optimización completos del ciclo de vida del desarrollo de software.
5 Obligatorio 7 Recomendado 6 Opcional
Nombre Descripción
Elemento de desarrollo
DevelopmentItem
Identificador único de una unidad de trabajo, como una funcionalidad, un error o una historia de usuario, que sirve como identificador del caso en el proceso.
Descripción

El elemento de desarrollo representa una unidad de trabajo concreta que se sigue en Azure DevOps. Cada elemento, identificado por un ID único, es el objeto central en torno al cual giran todas las actividades del proceso, desde su creación y planificación hasta el desarrollo, las pruebas y la implementación.

En el análisis de Process Mining, este atributo es fundamental para relacionar todos los eventos vinculados en un único recorrido del caso. Permite reconstruir el ciclo de vida completo de cada elemento de trabajo y analizar sus tiempos de ciclo, desviaciones del proceso y ciclos de retrabajo.

Por qué es importante

Es el identificador principal que conecta todos los pasos del proceso en un caso coherente y permite analizar de principio a fin el ciclo de vida de desarrollo de software.

Dónde obtenerlo

Corresponde al campo ID de un elemento de trabajo en Azure DevOps Boards. Está disponible a través de la API REST de Azure DevOps para el seguimiento de elementos de trabajo.

Ejemplos
10234102351023610237
Hora del evento
EventTime
Marca de tiempo precisa que indica cuándo ocurrió una actividad o un evento específico de un elemento de desarrollo.
Descripción

La hora del evento registra la fecha y la hora de cada actividad del ciclo de desarrollo. Esta marca de tiempo es el dato temporal fundamental para ordenar cronológicamente los eventos y calcular el tiempo transcurrido entre ellos.

En el análisis, este atributo es esencial para calcular todas las métricas basadas en el tiempo, incluidos los tiempos de ciclo, de procesamiento y de espera. Permite crear un Registro de eventos ordenado cronológicamente, requisito para cualquier análisis de Process Mining. Se utiliza para diagnosticar retrasos, medir el rendimiento frente a los SLA y seguir las tendencias a lo largo del tiempo.

Por qué es importante

Esta marca de tiempo establece el orden cronológico de los eventos, algo esencial para calcular todos los KPI basados en la duración y comprender el flujo del proceso y sus cuellos de botella.

Dónde obtenerlo

Es la fecha de cambio asociada a cada actualización del historial de un elemento de trabajo. En el caso de eventos externos, como compilaciones o implementaciones, corresponde a la marca de tiempo de finalización del evento.

Ejemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Nombre de la actividad
ActivityName
Nombre del evento o la tarea específicos que tuvieron lugar en un momento determinado del ciclo de desarrollo de un elemento de trabajo.
Descripción

El nombre de la actividad describe un paso o hito específico del proceso, como Desarrollo iniciado, Solicitud de incorporación de cambios creada o Implementado en producción. Estas actividades se derivan de cambios en el estado del elemento de trabajo, de eventos vinculados, como compilaciones o solicitudes de incorporación de cambios, o de eventos personalizados.

Este atributo es esencial para crear el mapa del proceso, que representa visualmente el flujo de trabajo. Permite analizar la secuencia de eventos, identificar las rutas habituales, detectar cuellos de botella entre actividades específicas y analizar la frecuencia de cada paso.

Por qué es importante

Define los pasos del proceso y constituye la base del mapa del proceso, lo que permite analizar el flujo de trabajo, los cuellos de botella y las desviaciones.

Dónde obtenerlo

Por lo general, se obtiene de los cambios en el campo de estado de un elemento de trabajo o de eventos vinculados, como compilaciones, confirmaciones y solicitudes de incorporación de cambios. El historial del elemento de trabajo proporciona los datos sin procesar de estos eventos.

Ejemplos
Desarrollo iniciadoSolicitud de incorporación de cambios completadaPruebas de control de calidad fallidasImplementado en producciónElemento de trabajo cerrado
Sistema de origen
SourceSystem
Sistema del que se extrajeron los datos del proceso, en este caso, Azure DevOps.
Descripción

Este atributo identifica el sistema de origen de los datos. Es especialmente útil cuando se combinan datos de varios sistemas para obtener una visión más amplia del proceso. En este modelo, el valor es siempre Azure DevOps.

Aunque en un análisis de un solo sistema pueda parecer un dato fijo, aporta contexto esencial sobre el origen de los datos, algo clave para la gobernanza de datos, la resolución de problemas y futuras integraciones con otros sistemas, como ServiceNow o SAP.

Por qué es importante

Aporta contexto esencial sobre el origen de los datos, importante para la gobernanza de datos, la validación y el análisis de procesos que abarcan varios sistemas.

Dónde obtenerlo

Es un valor estático que debe añadirse durante la extracción y transformación de los datos para identificar el conjunto de datos.

Ejemplos
Azure DevOps
Última actualización de los datos
LastDataUpdate
Marca de tiempo que indica cuándo se actualizaron por última vez los datos de este proceso desde el sistema de origen.
Descripción

Este atributo registra cuándo se extrajo y actualizó por última vez el conjunto de datos desde Azure DevOps. Indica con claridad la antigüedad de los datos y el periodo que abarca el análisis.

En cualquier análisis de procesos, conocer la actualidad de los datos es fundamental para tomar decisiones informadas. Esta marca de tiempo permite saber si se consulta información en tiempo real o una instantánea histórica, lo que influye en la pertinencia de las conclusiones.

Por qué es importante

Indica la actualidad de los datos para que los análisis y las decisiones se basen en un periodo claramente definido.

Dónde obtenerlo

Es una marca de tiempo de metadatos que se genera y almacena durante el proceso de extracción, transformación y carga (ETL) de los datos.

Ejemplos
2024-05-20T08:00:00Z
Asignado a
AssignedTo
Usuario o miembro del equipo al que está asignado actualmente el elemento de desarrollo.
Descripción

Este atributo identifica a la persona responsable del elemento de trabajo en una etapa determinada del proceso. La asignación puede cambiar varias veces durante el ciclo de vida del elemento, por ejemplo, de una persona desarrolladora a una persona encargada de las pruebas y, después, a quien gestiona los lanzamientos.

Analizar los datos por persona asignada es fundamental para el Dashboard de visión general de la carga de trabajo de desarrollo y pruebas. Ayuda a comprender cómo se distribuyen los recursos, identificar a quienes tienen una carga excesiva y analizar las diferencias de rendimiento entre personas o equipos.

Por qué es importante

Permite analizar los recursos, comprender cómo se distribuye la carga de trabajo, identificar cuellos de botella relacionados con recursos específicos y gestionar la capacidad del equipo.

Dónde obtenerlo

Corresponde al campo Asignado a de un elemento de trabajo en Azure DevOps. El valor se obtiene del historial del elemento de trabajo para cada evento.

Ejemplos
jane.doe@example.comjohn.smith@example.comsin asignar
Es retrabajo
IsRework
Indicador booleano que señala si un elemento de desarrollo ha vuelto a una etapa anterior de su ciclo de vida.
Descripción

Este indicador se establece en verdadero si un elemento de trabajo entra en un ciclo de retrabajo, por ejemplo, si pasa de «Pruebas de control de calidad completadas» a «Desarrollo iniciado». Se calcula analizando la secuencia de actividades de un caso y detectando avances no lineales.

Este atributo es esencial para el Dashboard de frecuencia de retrabajo y repetición de pruebas, así como para el KPI de frecuencia de ciclos de retrabajo. Permite filtrar y cuantificar el retrabajo fácilmente, lo que ayuda a localizar problemas de calidad, brechas de comunicación o pruebas insuficientes que generan ineficiencias.

Por qué es importante

Identifica y cuantifica directamente el retrabajo, lo que ayuda a detectar problemas de calidad e ineficiencias del proceso que prolongan el tiempo de ciclo.

Dónde obtenerlo

Es un atributo calculado a partir del análisis de la secuencia de actividades de cada caso en el registro de eventos.

Ejemplos
truefalse
Estado
State
Estado actual del elemento de desarrollo en su flujo de trabajo, como «Nuevo», «Activo», «Resuelto» o «Cerrado».
Descripción

El atributo Estado representa el estado formal de un elemento de trabajo en un momento determinado, según lo define la plantilla de proceso del proyecto. Las transiciones entre estos estados son la fuente principal para generar las actividades del registro de eventos.

Aunque el atributo «Actividad» suele describir con más detalle un cambio de estado, el atributo «Estado» sin procesar resulta útil para filtrar y analizar los datos. Permite saber cuánto tiempo permanecen los elementos en determinados estados y es fundamental para crear el Dashboard de duración por etapa y analizar los traspasos.

Por qué es importante

Indica el estado del elemento de trabajo en su ciclo de vida, un dato fundamental para comprender el flujo del proceso y calcular el tiempo que permanece en las distintas etapas.

Dónde obtenerlo

Corresponde al campo «State» de un elemento de trabajo en Azure DevOps.

Ejemplos
NuevoActivoEn control de calidadResueltoCerrado
Hora de finalización
EndTime
Marca de tiempo que indica cuándo terminó una actividad. Se utiliza para calcular su tiempo de procesamiento.
Descripción

La hora de finalización marca el término de una actividad. En muchos registros de eventos, la hora de inicio de la actividad siguiente sirve como hora de finalización de la anterior. Sin embargo, contar con una hora de finalización específica permite calcular con mayor precisión tanto el tiempo de procesamiento de la actividad como el tiempo de inactividad entre actividades.

Este atributo es fundamental para calcular el KPI de tiempo de procesamiento y realizar un análisis detallado de Bottleneck. Permite distinguir entre el tiempo dedicado a trabajar activamente en una tarea y el tiempo de espera hasta que comienza el siguiente paso, algo clave para el Dashboard de análisis de traspasos entre etapas.

Por qué es importante

Permite calcular con precisión los tiempos de procesamiento de las actividades y los tiempos de inactividad, algo fundamental para analizar cuellos de botella y mejorar la eficiencia.

Dónde obtenerlo

A menudo se calcula a partir de otros datos. Puede corresponder a la hora de inicio del evento siguiente del mismo caso o registrarse explícitamente si el sistema de origen captura las horas de inicio y finalización de las tareas.

Ejemplos
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Nombre del equipo
TeamName
Nombre del equipo de desarrollo responsable del elemento de trabajo.
Descripción

El nombre del equipo identifica al equipo concreto al que se asigna un elemento de trabajo. En Azure DevOps, el trabajo suele organizarse por equipos, que pueden formar parte de un proyecto más amplio.

Este atributo permite segmentar el análisis de procesos por equipo. Resulta muy útil para comparar procesos y resultados entre equipos, identificar buenas prácticas en los equipos con mejor rendimiento y detectar dónde pueden necesitar apoyo o mejoras en el proceso.

Por qué es importante

Permite comparar distintos equipos, detectar diferencias de rendimiento y compartir buenas prácticas en toda la organización.

Dónde obtenerlo

A menudo se obtiene de «Area Path» del elemento de trabajo, ya que los equipos suelen estar asociados a rutas de área específicas en Azure DevOps.

Ejemplos
Equipo PhoenixEscuadrón OmegaNúcleo de plataformaEquipo de frontend
Prioridad
Priority
Clasificación numérica o descriptiva de la importancia del elemento de desarrollo en relación con otros elementos.
Descripción

La prioridad indica la importancia de un elemento de trabajo para la planificación. Una prioridad más alta significa que conviene atender el elemento antes que otros de menor prioridad. Los valores suelen ser numéricos, por ejemplo, 1, 2, 3 y 4, donde 1 es la prioridad más alta.

Este atributo es esencial para el Dashboard de rendimiento y tiempo de ciclo por prioridad. Analizar los datos con este atributo permite determinar si el sistema de priorización funciona: los elementos de alta prioridad deberían avanzar por el proceso más rápido que los de baja prioridad.

Por qué es importante

Permite analizar si el proceso acelera eficazmente la atención de los elementos de alta prioridad, algo clave para evaluar el éxito de las estrategias de priorización.

Dónde obtenerlo

Corresponde al campo «Priority» de un elemento de trabajo en Azure DevOps.

Ejemplos
1234
Tipo de elemento de trabajo
WorkItemType
Clasificación del elemento de desarrollo, como error, funcionalidad, historia de usuario o tarea.
Descripción

El tipo de elemento de trabajo clasifica la naturaleza del trabajo realizado. Los distintos tipos suelen seguir rutas de proceso diferentes y tener expectativas de rendimiento o SLA distintos. Por ejemplo, un error puede seguir una ruta más rápida que una funcionalidad.

Este atributo es esencial para realizar análisis comparativos. Permite filtrar el mapa del proceso o los KPI por tipo de trabajo y comprobar si ciertos procesos son más eficientes para los errores que para las funcionalidades, o seguir las tendencias históricas del tiempo de ciclo en distintas categorías de trabajo.

Por qué es importante

Permite segmentar el análisis del proceso y comparar los flujos de trabajo y el rendimiento de distintas categorías, como errores y funcionalidades.

Dónde obtenerlo

Corresponde al campo Tipo de elemento de trabajo de un elemento de trabajo en Azure DevOps.

Ejemplos
ErrorFuncionalidadHistoria de usuarioTask
Gravedad
Severity
Indica el impacto de un error o problema en el sistema o en las personas usuarias finales.
Descripción

La gravedad permite clasificar el impacto de un error, desde fallos críticos del sistema hasta problemas estéticos menores. Se diferencia de la prioridad, que determina el orden de trabajo. Un error de gravedad alta puede tener una prioridad baja si existe una solución alternativa sencilla.

Este atributo aporta otra dimensión al análisis, especialmente para el Dashboard de rendimiento y tiempo de ciclo por prioridad. Permite responder preguntas como «¿Estamos corrigiendo primero los errores más críticos?» y comprender el nivel de riesgo del trabajo en curso.

Por qué es importante

Ayuda a clasificar los elementos de trabajo según su impacto en el negocio y permite analizar la eficacia con que el equipo aborda los problemas de mayor impacto.

Dónde obtenerlo

Corresponde al campo «Severity» de un elemento de trabajo, normalmente de tipo error, en Azure DevOps.

Ejemplos
1 - Crítico2 - Alto3 - Medio4 - Bajo
ID de solicitud de incorporación de cambios
PullRequestId
Identificador de una solicitud de incorporación de cambios vinculada al elemento de desarrollo.
Descripción

Este atributo vincula un elemento de trabajo con una solicitud de incorporación de cambios concreta, el mecanismo para enviar y revisar cambios en el código. Un elemento de trabajo puede estar asociado a varias solicitudes de incorporación de cambios.

El ID de la solicitud de incorporación de cambios permite analizar con más detalle la revisión y la integración del código. Puede utilizarse para medir el tiempo desde que se crea la solicitud hasta que se completa, y para analizar con qué frecuencia se rechazan las solicitudes o requieren cambios importantes. Esto puede indicar problemas de calidad del código o requisitos poco claros.

Por qué es importante

Vincula el trabajo de desarrollo con actividades concretas de revisión del código y permite analizar en detalle la integración del código y el proceso de aseguramiento de la calidad.

Dónde obtenerlo

Esta información se encuentra en la sección «Links» o «Development» de un elemento de trabajo en Azure DevOps.

Ejemplos
452145334589
Nombre del proyecto
ProjectName
Nombre del proyecto de Azure DevOps al que pertenece el elemento de desarrollo.
Descripción

Este atributo identifica el proyecto concreto de la organización de Azure DevOps donde se encuentra el elemento de trabajo. Aporta contexto general, sobre todo en organizaciones con muchos proyectos.

El nombre del proyecto es una dimensión clave para filtrar y comparar. El Dashboard de tendencias históricas del tiempo de ciclo permite segmentar el análisis por proyecto y descubrir si algunos son más o menos eficientes que otros, o si las mejoras de proceso en un proyecto han tenido un efecto positivo.

Por qué es importante

Ofrece una agrupación general para el análisis y permite comparar el rendimiento y las tendencias entre distintos proyectos.

Dónde obtenerlo

Corresponde al campo «Team Project» de un elemento de trabajo en Azure DevOps.

Ejemplos
Plataforma de comercio electrónicoRelanzamiento de la aplicación móvilModernización del almacén de datos
Ruta de iteración
IterationPath
Sprint o periodo de desarrollo al que se asigna el elemento de trabajo.
Descripción

La ruta de iteración, o sprint, representa un periodo de desarrollo con una duración definida. Los elementos de trabajo se asignan a una iteración para completarse dentro de ese periodo.

El análisis por ruta de iteración permite comprender el rendimiento del proceso sprint a sprint. Puede utilizarse para seguir la evolución del tiempo de ciclo entre sprints, analizar el trabajo pendiente que se arrastra de un sprint a otro y evaluar la previsibilidad de la planificación.

Por qué es importante

Permite analizar el trabajo por sprint, evaluar el rendimiento a lo largo del tiempo y mejorar las prácticas ágiles.

Dónde obtenerlo

Corresponde al campo «Iteration Path» de un elemento de trabajo en Azure DevOps.

Ejemplos
Plataforma de comercio electrónico\Sprint 12Plataforma de comercio electrónico\Sprint 13Relanzamiento de la aplicación móvil\Fase 2\Sprint 4
Tiempo de espera de aprobación
ApprovalWaitingTime
Tiempo que un elemento de desarrollo espera una aprobación después de que se haya enviado la solicitud.
Descripción

Esta métrica mide la duración de los periodos de espera en los que un elemento de trabajo queda pendiente de aprobación. Un ejemplo claro es el tiempo entre «UAT iniciado» y «UAT aprobado». Se calcula midiendo el intervalo entre estas dos actividades para un caso determinado.

Este atributo calculado es compatible con el Dashboard de análisis del tiempo de espera de aprobación y su KPI correspondiente. Al identificar estas demoras concretas, los equipos pueden mejorar la comunicación y la toma de decisiones para reducir el tiempo de inactividad y acelerar el ciclo de vida completo.

Por qué es importante

Mide específicamente las demoras causadas por la espera de decisiones o aprobaciones y señala oportunidades para mejorar la comunicación y la toma de decisiones.

Dónde obtenerlo

Se calcula identificando en el registro de eventos las actividades concretas que marcan el inicio y el fin de la aprobación (por ejemplo, «UAT iniciado» y «UAT aprobado») y calculando la diferencia de tiempo.

Ejemplos
3 días y 2 horas1 día, 8 horas y 30 minutos4 horas
Tiempo de traspaso entre etapas
StageHandoffTime
Tiempo de inactividad entre la finalización de una etapa principal y el inicio de la siguiente.
Descripción

El tiempo de traspaso entre etapas mide la espera entre etapas consecutivas del proceso; por ejemplo, el tiempo entre «Desarrollo completado» y «Pruebas de control de calidad iniciadas». Se calcula identificando estas transiciones clave y midiendo el intervalo entre el final de la primera actividad y el inicio de la segunda.

Esta métrica es el eje del Dashboard de duración por etapa y análisis de traspasos. Aislar y medir el tiempo de traspaso es fundamental para detectar cuellos de botella ocultos en los que el trabajo permanece inactivo, a menudo por falta de recursos, demoras en la comunicación o procesos ineficientes.

Por qué es importante

Cuantifica las esperas entre etapas del proceso y pone al descubierto cuellos de botella y demoras ocultos que no forman parte del trabajo activo.

Dónde obtenerlo

Es un atributo calculado. Para obtenerlo, se identifican pares de actividades consecutivas que representan un traspaso y se calcula la diferencia de tiempo entre ellas.

Ejemplos
2 horas y 15 minutos1 día y 4 horas30 minutos
Obligatorio Recomendado Opcional

Actividades del ciclo de vida del desarrollo de software

Estos son los pasos e hitos clave del proceso que debe registrar en el registro de eventos para descubrir el proceso con precisión e identificar cuellos de botella.
7 Recomendado 8 Opcional
Actividad Descripción
Desarrollo iniciado
Esta actividad indica que una persona desarrolladora ha comenzado a trabajar activamente en el elemento. Se infiere cuando el estado del elemento de trabajo cambia a Activo, En curso o Comprometido.
Por qué es importante

Marca el inicio de la fase de desarrollo activo. Analizar el tiempo transcurrido entre Creado y Desarrollo iniciado permite conocer cuánto tiempo permanecen los elementos en la cola del backlog.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia de Nuevo o Aprobado a En curso.

Capturar

Se infiere cuando el campo de estado cambia a Activo o En curso.

Tipo de evento inferred
Elemento de trabajo creado
Esta actividad marca el inicio del ciclo de desarrollo y corresponde a la creación de un elemento de trabajo, como una historia de usuario, un error o una tarea. Se registra explícitamente cuando se guarda un nuevo registro en Azure DevOps Boards.
Por qué es importante

Este es el evento de inicio principal del proceso. Es esencial para medir el tiempo de ciclo de desarrollo de principio a fin y comprender de dónde surge el trabajo.

Dónde obtenerlo

Este evento se obtiene de la fecha de creación del propio elemento de trabajo. La tabla del historial del elemento también registra esta transición de estado inicial.

Capturar

Se obtiene del campo de fecha de creación del elemento de trabajo.

Tipo de evento explicit
Implementado en producción
Marca la implementación satisfactoria en el entorno de producción del código asociado al elemento de trabajo. Este evento explícito se obtiene de los registros de lanzamiento de Azure Pipelines.
Por qué es importante

Es un hito crítico que representa la entrega de valor. Sirve como punto final para calcular el tiempo de entrega y el tiempo de ciclo.

Dónde obtenerlo

Se obtiene de los datos de la canalización de lanzamiento de Azure Pipelines, en concreto del evento de finalización de una implementación en una etapa de producción vinculada al elemento de trabajo.

Capturar

Se obtiene del evento de finalización de una implementación de la canalización de lanzamiento.

Tipo de evento explicit
Pruebas de control de calidad iniciadas
Representa el inicio de la fase formal de pruebas de control de calidad. Se infiere cuando el estado de un elemento de trabajo cambia a En control de calidad, En pruebas o un valor similar.
Por qué es importante

Marca el comienzo del ciclo de control de calidad. Analizar la duración de esta fase es fundamental para comprender los cuellos de botella y la eficiencia de las pruebas.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo al detectar que el campo System.State cambia a En control de calidad o a otro estado designado para las pruebas.

Capturar

Se infiere cuando el campo de estado cambia a En control de calidad o En pruebas.

Tipo de evento inferred
Solicitud de incorporación de cambios completada
Representa la finalización satisfactoria de una revisión de código: se aprueba la solicitud de incorporación de cambios y el código se integra en la rama de destino. Este evento se registra explícitamente en Azure Repos.
Por qué es importante

Marca el final de la fase de revisión del código, que suele ser un cuello de botella. Analizar el tiempo entre la creación y la finalización de la solicitud de incorporación de cambios permite evaluar la eficiencia del ciclo de revisión.

Dónde obtenerlo

Se obtiene del evento de finalización o integración de una solicitud de incorporación de cambios en Azure Repos vinculada a un elemento de trabajo.

Capturar

Se obtiene del evento de integración de una solicitud de incorporación de cambios vinculada a un elemento de trabajo.

Tipo de evento explicit
Solicitud de incorporación de cambios creada
Indica que la persona desarrolladora terminó la codificación inicial y envió los cambios para su revisión mediante una solicitud de incorporación de cambios. Este evento vincula el elemento de trabajo con un cambio de código específico en Azure Repos.
Por qué es importante

Este es un traspaso clave entre el desarrollo y la revisión del código. Su seguimiento permite medir la duración de la codificación y saber cuándo el código está listo para la revisión por pares.

Dónde obtenerlo

Se obtiene de los datos de Azure Repos al vincular el evento de creación de la solicitud de incorporación de cambios con el elemento de trabajo correspondiente. A menudo, la persona desarrolladora establece este vínculo explícitamente.

Capturar

Se obtiene del evento de creación de una solicitud de incorporación de cambios en Azure Repos vinculada a un elemento de trabajo.

Tipo de evento explicit
UAT aprobada
Esta actividad indica que las partes interesadas del negocio aprobaron los cambios tras las pruebas de aceptación del usuario. Por lo general, se infiere cuando el estado cambia de En UAT a UAT aprobada o Listo para lanzamiento.
Por qué es importante

Es un hito de aprobación crítico que confirma que el elemento de trabajo cumple los requisitos del negocio y está listo para implementarse en producción.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo al detectar que el campo System.State cambia de un estado de UAT a uno aprobado o listo para el lanzamiento.

Capturar

Se infiere cuando el campo de estado cambia de En UAT a Listo para lanzamiento.

Tipo de evento inferred
Compilación correcta
Esta actividad confirma que el código fuente, incluidos los cambios nuevos, se compiló y empaquetó correctamente mediante una canalización de compilación. Azure Pipelines registra este evento explícitamente.
Por qué es importante

Es un control de calidad crítico que garantiza que el código nuevo se integre correctamente sin interrumpir la compilación. Los errores en esta etapa pueden indicar problemas de integración.

Dónde obtenerlo

Se obtiene de los eventos de finalización de compilaciones de Azure Pipelines. La compilación debe vincularse al elemento de trabajo, ya sea directamente o mediante la solicitud de incorporación de cambios correspondiente.

Capturar

Se obtiene del evento de finalización de una compilación de Azure Pipelines.

Tipo de evento explicit
Desarrollo completado
Indica que finalizaron las actividades de desarrollo y las pruebas unitarias, y que el elemento está listo para las pruebas formales. Por lo general, se infiere cuando el estado del elemento de trabajo cambia a Resuelto o Listo para pruebas.
Por qué es importante

Marca un traspaso importante del equipo de desarrollo al equipo de control de calidad. Medir el tiempo hasta el inicio de las pruebas de control de calidad ayuda a identificar retrasos en el traspaso.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia a un valor como Resuelto o a un estado personalizado que indica que está listo para el control de calidad.

Capturar

Se infiere cuando el campo de estado cambia a Resuelto.

Tipo de evento inferred
Elemento de trabajo aprobado
Representa la aprobación formal de un elemento de trabajo y confirma que está bien definido y listo para desarrollarse. Por lo general, se infiere cuando el campo de estado cambia a un valor como Aprobado o Listo para desarrollo.
Por qué es importante

El seguimiento de las aprobaciones permite analizar el tiempo transcurrido entre la presentación de una idea y el compromiso de desarrollarla. También pone de manifiesto posibles retrasos en la planificación y la depuración del backlog.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo al detectar que el campo System.State cambia a Aprobado o a un estado personalizado similar.

Capturar

Se infiere cuando el campo de estado cambia a Aprobado.

Tipo de evento inferred
Elemento de trabajo cancelado
Indica que el elemento de trabajo se canceló y no se completará ni se implementará. Se registra cuando el estado cambia a Eliminado, Cancelado o a un estado similar.
Por qué es importante

Representa un final alternativo no satisfactorio del proceso. Analizar los elementos cancelados puede revelar problemas de planificación, priorización o definición de requisitos.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia a un estado terminal de la categoría Eliminado.

Capturar

Se infiere cuando el campo de estado cambia a Eliminado o Cancelado.

Tipo de evento inferred
Elemento de trabajo cerrado
Representa el cierre definitivo del elemento de trabajo tras la implementación y cualquier validación posterior. Se registra cuando el estado cambia a Cerrado o Hecho.
Por qué es importante

Esta actividad marca la finalización satisfactoria de todo el proceso para un elemento de trabajo. Es el punto final definitivo de su ciclo de vida.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia a Cerrado o a un estado terminal similar de la categoría Completado.

Capturar

Se infiere cuando el campo de estado cambia a Cerrado.

Tipo de evento inferred
Pruebas de control de calidad completadas
Marca la finalización satisfactoria de la fase de control de calidad. Se infiere cuando el estado del elemento de trabajo cambia de uno de pruebas a otro como Listo para UAT o Aprobado por control de calidad.
Por qué es importante

Es un control de calidad clave que indica que el elemento está listo para las pruebas de aceptación del usuario o para su lanzamiento. Los retrasos posteriores pueden señalar cuellos de botella en las pruebas de aceptación o en la planificación del lanzamiento.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia de En control de calidad a un estado posterior como Listo para UAT o Hecho.

Capturar

Se infiere cuando el campo de estado cambia de En control de calidad a Listo para UAT.

Tipo de evento inferred
Pruebas de control de calidad fallidas
Indica que el elemento de trabajo no superó las pruebas de control de calidad y vuelve a desarrollo. Se registra cuando el estado cambia de uno de pruebas a En curso o Activo.
Por qué es importante

Esta actividad es esencial para identificar ciclos de retrabajo. Si ocurre con frecuencia, puede señalar problemas de calidad del código, requisitos o procesos de prueba.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo al detectar una transición de un estado como En control de calidad a otro como Activo o En curso.

Capturar

Se infiere cuando el campo de estado cambia de En control de calidad a Activo.

Tipo de evento inferred
UAT iniciada
Representa el inicio de las pruebas de aceptación del usuario (UAT), en las que las partes interesadas del negocio validan la funcionalidad. Por lo general, se infiere cuando el estado cambia a En UAT o a un estado similar.
Por qué es importante

Mide el inicio de la validación final antes del lanzamiento. Para optimizar el proceso, es fundamental analizar la duración de las UAT y los tiempos de espera de aprobación.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State se actualiza a un estado personalizado que representa las UAT, como En UAT.

Capturar

Se infiere cuando el campo de estado cambia a En UAT.

Tipo de evento inferred
Recomendado Opcional

Guías de extracción

Cómo obtener los datos de Azure DevOps

¿Listo para empezar?

Empiece hoy mismo a optimizar el ciclo de vida del desarrollo de software. Este Template es el primer paso para obtener información valiosa sobre sus procesos.

¡Optimice hoy mismo el ciclo de vida del desarrollo de software en Azure DevOps!

Reduzca el tiempo de ciclo un 30 % y elimine los cuellos de botella del flujo de trabajo de desarrollo de software.

Comience la prueba gratuita

No se requiere tarjeta de crédito. Empiece en unos minutos.