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 hoja de ruta clara para preparar los datos de su ciclo de vida del desarrollo de software para Process Mining. Describe los atributos de datos esenciales que debe recopilar, las actividades clave que debe seguir y proporciona orientación práctica para extraer esta información específicamente de Azure DevOps. Aproveche este recurso para asegurarse de que sus datos estén perfectamente estructurados y permitan realizar análisis útiles y optimizar el proceso.
  • Atributos recomendados para recopilar
  • Actividades clave que debe seguir en su SDLC
  • Guía detallada para extraer datos de Azure DevOps
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos del ciclo de vida del desarrollo de software

Estos son los campos de datos recomendados para incluir en su registro de eventos y obtener 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
El identificador único de una unidad de trabajo, como una funcionalidad, un error o una historia de usuario, que sirve como identificador del caso para el proceso.
Descripción

El elemento de desarrollo representa una unidad de trabajo diferenciada que se supervisa en Azure DevOps. Cada elemento, identificado mediante su ID único, es el objeto central en torno al cual giran todas las actividades del proceso, desde la creación y la 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 asociados en un único caso. Permite reconstruir el ciclo de vida completo de cada elemento de trabajo y analizar los tiempos de ciclo, las desviaciones del proceso y los ciclos de retrabajo de cada elemento.

Por qué es importante

Es el identificador principal que conecta todos los pasos del proceso en un caso coherente y hace posible el análisis integral del ciclo de vida del desarrollo de software.

Dónde obtenerlo

Corresponde al campo «ID» de un elemento de trabajo en Azure DevOps Boards. Está disponible mediante la API REST de Azure DevOps para el seguimiento de elementos de trabajo.

Ejemplos
10234102351023610237
Hora del evento
EventTime
La marca de tiempo exacta que indica cuándo tuvo lugar 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 vida de desarrollo. Esta marca de tiempo es el elemento temporal fundamental para ordenar cronológicamente los eventos y calcular las duraciones 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, los tiempos de procesamiento y los tiempos de espera. Permite crear un registro de eventos ordenado cronológicamente, que es la entrada necesaria para cualquier análisis de Process Mining. Se utiliza para diagnosticar demoras, medir el rendimiento frente a los SLA y seguir las tendencias a lo largo del tiempo.

Por qué es importante

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

Dónde obtenerlo

Es la «Changed Date» asociada a cada actualización del historial de un elemento de trabajo. Para eventos externos, como compilaciones o implementaciones, es 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
El nombre del evento o la tarea específicos que tuvieron lugar en un momento determinado del ciclo de vida de desarrollo de un elemento de trabajo.
Descripción

El nombre de la actividad describe un paso o hito específico del proceso, como «Development Started», «Pull Request Created» o «Deployed to Production». Estas actividades se derivan de cambios en el estado del elemento de trabajo, de eventos vinculados como compilaciones o Pull Requests, o de eventos personalizados.

Este atributo es esencial para construir el mapa del proceso, que representa visualmente el Workflow. Permite a los analistas comprender la secuencia de eventos, identificar rutas habituales, descubrir cuellos de botella entre actividades específicas y analizar la frecuencia de cada paso.

Por qué es importante

Define los pasos del proceso, forma la estructura del mapa del proceso y permite analizar el Workflow, los cuellos de botella y las desviaciones.

Dónde obtenerlo

Normalmente se deriva de los cambios en el campo «State» de un elemento de trabajo o de eventos vinculados, como compilaciones, commits y Pull Requests. El historial del elemento de trabajo proporciona los datos sin procesar de estos eventos.

Ejemplos
Desarrollo iniciadoPull Request completadoPruebas de QA fallidasImplementado en producciónElemento de trabajo cerrado
Sistema de origen
SourceSystem
El sistema del que se extrajeron los datos del proceso, que en este caso es Azure DevOps.
Descripción

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

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

Por qué es importante

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

Dónde obtenerlo

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

Ejemplos
Azure DevOps
Última actualización de datos
LastDataUpdate
La marca de tiempo que indica la última vez que se actualizaron 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. Proporciona una indicación clara de la actualidad de los datos y del periodo que abarca el análisis.

En cualquier análisis de procesos, conocer la antigüedad de los datos es fundamental para tomar decisiones informadas. Esta marca de tiempo ayuda a comprender si se está consultando información en tiempo real o una instantánea histórica, lo que afecta a la relevancia de los resultados.

Por qué es importante

Informa sobre la actualidad de los datos y garantiza que los análisis y las decisiones se basen en un periodo de tiempo conocido.

Dónde obtenerlo

Es una marca de tiempo de metadatos generada y almacenada durante el proceso de extracción, transformación y carga (ETL) de datos.

Ejemplos
2024-05-20T08:00:00Z
Asignado a
AssignedTo
El 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 un desarrollador a un tester y después a un responsable de lanzamientos.

Analizar por «Assigned To» es fundamental para el Dashboard Developer and Tester Workload Overview. Ayuda a comprender la asignación de recursos, identificar miembros del equipo sobrecargados y analizar las diferencias de rendimiento entre personas o equipos.

Por qué es importante

Permite realizar análisis basados en los recursos, comprender la distribución de la carga de trabajo, identificar cuellos de botella específicos de los recursos y gestionar la capacidad del equipo.

Dónde obtenerlo

Corresponde al campo «Assigned To» de un elemento de trabajo en Azure DevOps. El valor se captura del historial del elemento de trabajo para cada evento.

Ejemplos
jane.doe@example.comjohn.smith@example.comSin asignar
Es retrabajo
IsRework
Un 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 true si un elemento de trabajo presenta un ciclo de retrabajo, por ejemplo, al pasar de «QA Testing Completed» a «Development Started». Se calcula analizando la secuencia de actividades de un caso y detectando progresiones no lineales.

Este atributo es esencial para el Dashboard Rework and Retesting Frequency y el KPI Rework Loop Frequency. Permite filtrar y cuantificar fácilmente el retrabajo, ayudando a localizar problemas de calidad, deficiencias de comunicación o pruebas insuficientes que generan ineficiencias.

Por qué es importante

Identifica y cuantifica directamente el retrabajo, ayudando a poner de relieve problemas de calidad e ineficiencias del proceso que prolongan los tiempos de ciclo.

Dónde obtenerlo

Es un atributo calculado que se obtiene mediante el análisis de la secuencia de actividades del registro de eventos de cada caso.

Ejemplos
truefalse
Estado
State
El estado actual del elemento de desarrollo dentro de su Workflow, como «New», «Active», «Resolved» o «Closed».
Descripción

El atributo State representa el estado formal de un elemento de trabajo en cualquier momento, 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 «Activity» suele ser una versión más descriptiva de un cambio de estado, el atributo sin procesar «State» resulta útil para filtrar y analizar. Ayuda a comprender cuánto tiempo pasan los elementos en determinados estados y es fundamental para crear el Dashboard Stage Duration y analizar las transferencias.

Por qué es importante

Indica el estado del elemento de trabajo en el ciclo de vida, algo fundamental para comprender el flujo del proceso y calcular el tiempo empleado 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
La marca de tiempo que indica cuándo se completó una actividad. Se utiliza para calcular el tiempo de procesamiento de una actividad.
Descripción

La hora de finalización marca la conclusión 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, disponer de una hora de finalización diferenciada 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 ProcessingTime y realizar un análisis detallado de cuellos de botella. Ayuda a diferenciar el tiempo dedicado activamente a una tarea del tiempo de espera hasta que comienza el paso siguiente, algo clave para el Dashboard Stage Handoff Analysis.

Por qué es importante

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

Dónde obtenerlo

A menudo se deriva. Puede ser la hora de inicio del evento posterior 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
El nombre del equipo de desarrollo responsable del elemento de trabajo.
Descripción

El nombre del equipo identifica al equipo específico al que está asignado un elemento de trabajo. En Azure DevOps, el trabajo suele organizarse por equipos, que pueden ser subconjuntos de un proyecto más amplio.

Este atributo permite segmentar el análisis del proceso por equipo. Es muy útil para comparar procesos y rendimiento entre equipos, identificar buenas prácticas en los equipos de alto rendimiento y detectar áreas en las que determinados equipos pueden necesitar apoyo o mejoras de proceso.

Por qué es importante

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

Dónde obtenerlo

A menudo se deriva de «Area Path» de un 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 la plataformaEquipo de frontend
Prioridad
Priority
La 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 programación de un elemento de trabajo. Una prioridad más alta sugiere que el elemento debe atenderse antes que los elementos de menor prioridad. Los valores habituales son numéricos, como 1, 2, 3 y 4, donde 1 es la prioridad más alta.

Este atributo es esencial para el Dashboard Priority-Based Throughput & Cycle Time. Analizar los datos con este atributo ayuda a determinar si el sistema de priorización es eficaz, es decir, si los elementos de alta prioridad avanzan realmente más rápido por el proceso que los de baja prioridad.

Por qué es importante

Permite analizar si el proceso acelera eficazmente 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
La clasificación del elemento de desarrollo, como Bug, Feature, User Story o Task.
Descripción

El tipo de elemento de trabajo categoriza 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 «Bug» puede seguir una ruta acelerada en comparación con una «Feature».

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

Por qué es importante

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

Dónde obtenerlo

Corresponde al campo «Work Item Type» de un elemento de trabajo en Azure DevOps.

Ejemplos
ErrorFuncionalidadHistoria de usuarioTarea
Gravedad
Severity
Indica el impacto de un error o problema en el sistema o en los usuarios finales.
Descripción

La gravedad se utiliza para 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 del trabajo. Un error de alta gravedad puede tener baja prioridad si existe una solución alternativa disponible.

Este atributo aporta otra dimensión al análisis, especialmente para el Dashboard Priority-Based Throughput & Cycle Time. Permite investigar cuestiones como «¿Estamos corrigiendo primero los errores más críticos?» y ayuda a comprender el perfil de riesgo del trabajo procesado.

Por qué es importante

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

Dónde obtenerlo

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

Ejemplos
1 - Crítica2 - Alta3 - Media4 - Baja
ID de Pull Request
PullRequestId
El identificador de una Pull Request vinculada al elemento de desarrollo.
Descripción

Este atributo vincula un elemento de trabajo con una Pull Request específica, que es el mecanismo para enviar y revisar cambios de código. Un mismo elemento de trabajo puede estar asociado a varias Pull Requests.

Disponer del ID de Pull Request permite analizar con mayor detalle la revisión y la integración del código dentro del ciclo de vida. Puede utilizarse para medir el tiempo desde la creación hasta la finalización de una Pull Request y analizar con qué frecuencia se rechazan o requieren cambios importantes, lo que puede indicar problemas de calidad del código o requisitos poco claros.

Por qué es importante

Conecta el trabajo de desarrollo con actividades específicas de revisión de código y permite analizar en detalle el proceso de integración del código y 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
El nombre del proyecto de Azure DevOps al que pertenece el elemento de desarrollo.
Descripción

Este atributo identifica el proyecto específico de la organización de Azure DevOps en el que se encuentra el elemento de trabajo. Proporciona un contexto de alto nivel, especialmente en organizaciones con muchos proyectos.

Project Name es una dimensión crítica para filtrar y comparar. Es compatible con el Dashboard Historical Cycle Time Trends, ya que permite segmentar el análisis por proyecto y revelar si determinados proyectos son más o menos eficientes que otros, o si las mejoras de proceso aplicadas en un proyecto han tenido un impacto positivo.

Por qué es importante

Proporciona una agrupación de alto nivel 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
El sprint de desarrollo o periodo acotado al que está asignado el elemento de trabajo.
Descripción

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

Analizar por ruta de iteración ayuda a comprender el rendimiento del proceso sprint a sprint. Puede utilizarse para comprobar si los tiempos de ciclo mejoran en sprints sucesivos, analizar el trabajo trasladado y evaluar la previsibilidad de la planificación de sprints.

Por qué es importante

Permite realizar análisis basados en sprints, ayudar a los equipos a evaluar su rendimiento a lo largo del tiempo y mejorar sus 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
El tiempo que un elemento de desarrollo permanece a la espera de una aprobación después de realizarse una solicitud.
Descripción

Esta métrica mide la duración de periodos de espera específicos en los que un elemento de trabajo está pendiente de aprobación. Un ejemplo claro es el tiempo entre «UAT Started» y «UAT Approved». Se calcula midiendo el tiempo entre estas dos actividades específicas para un caso determinado.

Este atributo calculado respalda directamente el Dashboard Approval Waiting Time Analysis y el KPI correspondiente. Al aislar estas demoras concretas, los equipos pueden mejorar los procesos de comunicación y 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 pone de relieve oportunidades para mejorar la comunicación y la toma de decisiones.

Dónde obtenerlo

Se calcula localizando en el registro de eventos las actividades específicas de inicio y finalización de la aprobación, por ejemplo, «UAT Started» y «UAT Approved», y calculando la diferencia de tiempo.

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

Stage Handoff Time mide el periodo de espera entre etapas consecutivas del proceso, por ejemplo, el tiempo entre «Development Completed» y «QA Testing Started». 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 foco del Dashboard Stage Duration and Handoff Analysis. Aislar y medir el tiempo de transferencia es fundamental para identificar cuellos de botella ocultos en los que el trabajo permanece inactivo, a menudo por falta de disponibilidad de recursos, demoras de comunicación o procesos ineficientes.

Por qué es importante

Cuantifica los tiempos de espera entre etapas del proceso y expone directamente cuellos de botella ocultos y demoras que no forman parte del trabajo activo.

Dónde obtenerlo

Es un atributo calculado. Requiere identificar pares de actividades consecutivas que representen una transferencia y calcular después la diferencia de tiempo entre ellas.

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

Actividades del ciclo de vida del desarrollo de software

Estos son los pasos clave y los hitos del proceso que debe capturar en su 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 un desarrollador ha comenzado a trabajar activamente en el elemento. Se captura al inferir un cambio en el estado del elemento de trabajo a "Active", "In Progress" o "Committed".
Por qué es importante

Marca el inicio de la fase de desarrollo activo. Analizar el tiempo desde "Created" hasta "Development Started" revela los tiempos de espera en la cola del backlog.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia de un estado "New" o "Approved" a un estado "In Progress".

Recopilar

Se infiere cuando el campo State cambia a "Active" o "In Progress".

Tipo de evento inferred
Elemento de trabajo creado
Esta actividad marca el inicio del ciclo de vida de desarrollo y representa la creación de un nuevo elemento de trabajo, como un User Story, Bug o Task. 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 integral del desarrollo y comprender las fuentes iniciales del trabajo.

Dónde obtenerlo

Este evento se captura a partir de la "Created Date" del propio elemento de trabajo. La tabla de historial del elemento de trabajo también registra esta transición de estado inicial.

Recopilar

Se captura del campo "Created Date" 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. Es un evento explícito capturado 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 lead time y el cycle time.

Dónde obtenerlo

Capturado de los datos del pipeline de lanzamiento de Azure Pipelines, específicamente del evento de finalización de una implementación en una etapa «Production» vinculada al elemento de trabajo.

Recopilar

Capturado de un evento de finalización de implementación del pipeline de lanzamiento.

Tipo de evento explicit
Pruebas de QA iniciadas
Representa el inicio de la fase formal de pruebas de aseguramiento de la calidad. Esta actividad se infiere cuando el estado de un elemento de trabajo cambia a "In QA", "Testing" o un valor similar.
Por qué es importante

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

Dónde obtenerlo

Inferido del historial del elemento de trabajo mediante el seguimiento de un cambio en el campo System.State a «In QA» u otro estado de pruebas designado.

Recopilar

Inferido del cambio del campo State a «In QA» o «Testing».

Tipo de evento inferred
Pull Request completado
Representa la finalización satisfactoria de una revisión de código: el pull request se aprueba y el código se fusiona con 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 de código, que suele ser un cuello de botella. Analizar el tiempo entre la creación y la finalización del PR revela la eficiencia del ciclo de revisión.

Dónde obtenerlo

Se captura del evento de finalización o fusión de un pull request en Azure Repos vinculado a un elemento de trabajo.

Recopilar

Se captura del evento de fusión del pull request vinculado a un elemento de trabajo.

Tipo de evento explicit
Pull Request creado
Indica que el desarrollador ha completado la codificación inicial y ha enviado los cambios para su revisión mediante un pull request. Este evento vincula el elemento de trabajo con un cambio de código específico en Azure Repos.
Por qué es importante

Esta es una transferencia clave de desarrollo a revisión de código. Su seguimiento ayuda a medir la duración de la codificación e identificar cuándo el código está listo para la revisión por pares.

Dónde obtenerlo

Se captura de los datos de Azure Repos al vincular el evento de creación del pull request con el elemento de trabajo asociado. A menudo, el desarrollador crea este vínculo explícitamente.

Recopilar

Se captura del evento de creación de un pull request de Azure Repos vinculado a un elemento de trabajo.

Tipo de evento explicit
UAT aprobada
Esta actividad indica que las partes interesadas del negocio han aprobado los cambios después de las pruebas de aceptación del usuario. Normalmente se infiere a partir de un cambio de estado de «In UAT» a «UAT Approved» o «Ready for Release».
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 su implementación en producción.

Dónde obtenerlo

Inferido del historial del elemento de trabajo al detectar un cambio en el campo System.State desde un estado de UAT a un estado aprobado o listo para el lanzamiento.

Recopilar

Inferido del cambio del campo State de «In UAT» a «Ready for Release».

Tipo de evento inferred
Compilación correcta
Esta actividad confirma que el código fuente, incluidos los nuevos cambios, se ha compilado y empaquetado correctamente mediante un canal de compilación. Es un evento explícito registrado por Azure Pipelines.
Por qué es importante

Actúa como un control de calidad crítico y garantiza que el código nuevo se integre correctamente sin romper la compilación. Los fallos en esta etapa pueden indicar problemas de integración.

Dónde obtenerlo

Se captura 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 el pull request asociado.

Recopilar

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

Tipo de evento explicit
Desarrollo completado
Indica que se han completado todas las actividades de desarrollo y pruebas unitarias, y que el elemento está listo para las pruebas formales. Normalmente se infiere a partir de un cambio de estado del elemento de trabajo a "Resolved" o "Ready for Test".
Por qué es importante

Marca una transferencia importante del equipo de desarrollo al equipo de QA. Medir el tiempo hasta "QA Testing Started" ayuda a identificar retrasos en la transferencia.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo cuando el campo System.State cambia a un valor como "Resolved" o a un estado personalizado que indique que está listo para QA.

Recopilar

Se infiere cuando el campo State cambia a "Resolved".

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 el desarrollo. Normalmente se infiere a partir de un cambio en el campo "State" a un valor como "Approved" o "Ready for Dev".
Por qué es importante

El seguimiento de las aprobaciones ayuda a analizar el tiempo transcurrido entre el envío de una idea y el compromiso de desarrollo. También pone de manifiesto posibles retrasos en las fases de planificación y depuración del backlog.

Dónde obtenerlo

Se infiere del historial del elemento de trabajo al detectar un cambio del campo System.State a "Approved" o a un estado personalizado similar.

Recopilar

Se infiere cuando el campo State cambia a "Approved".

Tipo de evento inferred
Elemento de trabajo cancelado
Indica que el elemento de trabajo se ha cancelado y no se completará ni se implementará. Se captura mediante un cambio de estado a «Removed», «Cancelled» o un estado similar.
Por qué es importante

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

Dónde obtenerlo

Inferido del historial del elemento de trabajo cuando el campo System.State cambia a un estado terminal de la categoría «Removed».

Recopilar

Inferido del cambio del campo State a «Removed» o «Cancelled».

Tipo de evento inferred
Elemento de trabajo cerrado
Representa el cierre definitivo del elemento de trabajo después de la implementación y de cualquier validación posterior. Se captura mediante un cambio de estado a «Closed» o «Done».
Por qué es importante

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

Dónde obtenerlo

Inferido del historial del elemento de trabajo cuando el campo System.State cambia a «Closed» o a un estado terminal similar de la categoría «Completed».

Recopilar

Inferido del cambio del campo State a «Closed».

Tipo de evento inferred
Pruebas de QA completadas
Marca la finalización satisfactoria de la fase de aseguramiento de la calidad. Se infiere cuando el estado del elemento de trabajo cambia de un estado de pruebas a otro como «Ready for UAT» o «QA Approved».
Por qué es importante

Es un punto de control de calidad clave que indica que el elemento está listo para las pruebas de aceptación del usuario o para su lanzamiento. Las demoras posteriores pueden indicar cuellos de botella en UAT o en la planificación del lanzamiento.

Dónde obtenerlo

Inferido del historial del elemento de trabajo cuando el campo System.State cambia de «In QA» a un estado posterior como «Ready for UAT» o «Done».

Recopilar

Inferido del cambio del campo State de «In QA» a «Ready for UAT».

Tipo de evento inferred
Pruebas de QA fallidas
Indica que el elemento de trabajo no ha superado las pruebas de aseguramiento de la calidad y vuelve a desarrollo. Se captura mediante un cambio de estado desde un estado de pruebas a «In Progress» o «Active».
Por qué es importante

Esta actividad es esencial para identificar ciclos de retrabajo. Una alta frecuencia de este evento apunta a problemas de calidad del código, requisitos o procesos de pruebas.

Dónde obtenerlo

Inferido del historial del elemento de trabajo al detectar una transición desde un estado como «In QA» a otro como «Active» o «In Progress».

Recopilar

Inferido del cambio del campo State de «In QA» a «Active».

Tipo de evento inferred
UAT iniciada
Representa el inicio de las pruebas de aceptación del usuario, en las que las partes interesadas del negocio validan la funcionalidad. Normalmente se infiere a partir de un cambio de estado a «In UAT» o a un estado similar.
Por qué es importante

Mide el inicio de la validación final antes del lanzamiento. Es fundamental analizar la duración de UAT y los tiempos de espera para la aprobación a fin de optimizar el proceso.

Dónde obtenerlo

Inferido del historial del elemento de trabajo cuando el campo System.State se actualiza a un estado personalizado que representa UAT, como «In UAT».

Recopilar

Inferido del cambio del campo State a «In UAT».

Tipo de evento inferred
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Azure DevOps

¿Listo para comenzar?

Comience hoy mismo su camino hacia la optimización del ciclo de vida del desarrollo de software. Este Template es el primer paso para descubrir información valiosa sobre su proceso.

Optimice su SDLC en Azure DevOps. ¡Comience hoy!

Reduzca el tiempo de ciclo un 30 % y elimine los cuellos de botella de su Workflow de SDLC.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Comience en cuestión de minutos.