Su Template de datos del ciclo de vida del desarrollo de software
Su Template de datos del ciclo de vida del desarrollo de software
- Atributos recomendados para recopilar
- Actividades clave que debe seguir en su SDLC
- Guía detallada para extraer datos de Azure DevOps
Atributos del ciclo de vida del desarrollo de software
| 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
|
|||
Actividades del ciclo de vida del desarrollo de software
| 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
|
|||
Guías de extracción
¿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.
No necesita tarjeta de crédito. Comience en cuestión de minutos.