Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software
Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de Extracción
Atributos del Ciclo de Vida de Desarrollo de Software
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
Activity
|
El nombre del paso de proceso o evento específico que ocurrió, como '`Issue` Creada' o '`Merge Request` Fusionado'. | ||
|
Descripción
El atributo Actividad captura los eventos distintos que le ocurren a un Elemento de Desarrollo. Estos no se almacenan como un único campo en GitLab, sino que se derivan de varias acciones y campos de Este atributo es fundamental para construir el mapa de procesos, visualizar el
Por qué es importante
Define los pasos en el mapa de procesos, permitiendo la visualización y el análisis del
Dónde obtener
Se deriva de los tipos de eventos y cambios de estado en el flujo de datos de GitLab, o interpretando campos de marca de tiempo como 'created_at', 'merged_at' y 'closed_at' en incidencias y merge requests.
Ejemplos
Incidencia CreadaDesarrollo Iniciado`Merge Request` Fusionado`Pipeline` FallidoDesplegado a Producción
|
|||
|
Elemento de Desarrollo
DevelopmentItem
|
El identificador único para una unidad de trabajo, como una característica, corrección de `bug` o tarea, que sirve como identificador principal del caso. | ||
|
Descripción
El Elemento de Desarrollo representa una pieza de trabajo única y rastreable que fluye a través del ciclo de vida de desarrollo de software. Conecta todas las actividades relacionadas, desde la creación hasta el despliegue final, en un caso coherente. En GitLab, esto se representa típicamente por el ID interno ( Analizar por Elemento de Desarrollo permite la medición del tiempo de ciclo de principio a fin, la identificación de cuellos de botella y la verificación de la conformidad del proceso. Constituye la base para comprender con qué eficiencia se entrega el trabajo desde el concepto hasta la producción.
Por qué es importante
Este es el identificador de caso esencial que vincula todos los eventos del proceso, haciendo posible trazar el ciclo de vida completo de cualquier elemento de trabajo dado.
Dónde obtener
Este es típicamente el
Ejemplos
1024512PRJ-2345
|
|||
|
Hora de Inicio
StartTime
|
El timestamp que indica cuándo comenzó una *actividad* o un *evento*. | ||
|
Descripción
Esta marca de tiempo es el elemento temporal central en el
Por qué es importante
Este atributo proporciona la secuencia cronológica de eventos, que es esencial para calcular todas las métricas basadas en el tiempo y comprender el flujo del proceso.
Dónde obtener
Se extrae de varios campos de marca de tiempo en GitLab, como 'created_at', 'updated_at' o 'closed_at' en incidencias, y 'merged_at' en merge requests.
Ejemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Asignado
Assignee
|
El usuario asignado a la `issue` o `merge request` en el momento del evento. | ||
|
Descripción
El Responsable ( Analizar por Responsable es fundamental para el
Por qué es importante
Rastrea quién realizó el trabajo, permitiendo el análisis de la carga de trabajo, la eficiencia en la asignación de recursos y la identificación de retrasos causados por los traspasos.
Dónde obtener
Obtenido de los campos 'assignee.username' o 'assignees' en las respuestas de la
Ejemplos
jdoeasmithr.williams
|
|||
|
Hora de Finalización
EndTime
|
La marca de tiempo que indica cuándo se completó una actividad o evento. | ||
|
Descripción
El EndTime indica la fecha y hora exactas en que finalizó una actividad. En eventos instantáneos de GitLab, como 'Issue Created', coincide con el StartTime. En actividades con duración propia, como 'Code Review', representa el momento de finalización (por ejemplo, cuando se da la última aprobación). Este atributo es indispensable para calcular con precisión cuánto dura cada actividad (Processing Time). Además, facilita el análisis de cuellos de botella al permitir diferenciar el tiempo de trabajo activo del tiempo de espera entre tareas.
Por qué es importante
Permite el cálculo de duraciones precisas de actividad (
Dónde obtener
Para eventos atómicos, esto es lo mismo que
Ejemplos
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Nombre del Proyecto
ProjectName
|
El nombre del proyecto de GitLab al que pertenece el elemento de desarrollo. | ||
|
Descripción
Este atributo identifica el repositorio de código o proyecto específico donde se está realizando el trabajo. En GitLab, cada Analizar por Nombre del Proyecto permite comparaciones de rendimiento entre diferentes productos, componentes o servicios. Puede ayudar a identificar si ciertos proyectos tienen procesos de
Por qué es importante
Permite segmentar el análisis de procesos por producto, aplicación o componente, facilitando los esfuerzos de mejora dirigidos.
Dónde obtener
Obtenido de los campos 'name' o 'path_with_namespace' en la
Ejemplos
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Severidad
Severity
|
El nivel de severidad del elemento de desarrollo, típicamente para `bugs` o incidentes. | ||
|
Descripción
La Severidad indica el impacto de un Este atributo es esencial para el
Por qué es importante
Ayuda a priorizar el trabajo y a analizar si los elementos de alta severidad se gestionan más rápido. El seguimiento de los cambios apoya el
Dónde obtener
Derivado de las 'etiquetas' aplicadas a un Issue de GitLab. Se requiere un mapeo para interpretar etiquetas como 'S1', 'S2' como niveles de severidad.
Ejemplos
1 - Crítico2 - Alta3 - Medio4 - Baja
|
|||
|
Tipo de Elemento de Desarrollo
DevelopmentItemType
|
La clasificación del elemento de desarrollo, como 'Funcionalidad', 'Error' (`Bug`), 'Tarea' o 'Mantenimiento'. | ||
|
Descripción
Este atributo categoriza la naturaleza del trabajo que se realiza. En GitLab, esto se implementa comúnmente usando Analizar por Tipo de Elemento de Desarrollo permite comparar los flujos de proceso y los tiempos de ciclo para diferentes tipos de trabajo. Por ejemplo, se puede analizar si los
Por qué es importante
Segmentar el proceso por tipo de trabajo ayuda a identificar si ciertos tipos de trabajo son más propensos a retrasos, retrabajos o desviaciones.
Dónde obtener
Normalmente se deriva de las 'etiquetas' aplicadas a una Incidencia de GitLab. Se requiere una lógica de asignación para traducir etiquetas específicas a tipos estandarizados.
Ejemplos
Característica`Bug`TaskDeuda Técnica
|
|||
|
¿Es Retrabajo?
IsRework
|
Un indicador booleano que señala si una actividad forma parte de un ciclo de reelaboración. | ||
|
Descripción
Este atributo calculado marca las actividades que representan un paso hacia atrás en el proceso, como volver al desarrollo después de que las pruebas ya hayan comenzado. La lógica para esta bandera típicamente implica detectar secuencias específicas de actividades, por ejemplo, un evento 'Development Started' ocurriendo después de un evento ' Este atributo alimenta directamente el
Por qué es importante
Marca y cuantifica directamente el retrabajo, lo que facilita el análisis de las causas y el impacto de las ineficiencias del proceso y los problemas de calidad.
Dónde obtener
Calculado por la herramienta de Process Mining mediante el análisis de la secuencia de actividades de cada caso e identificando patrones que indican reprocesos.
Ejemplos
truefalse
|
|||
|
Estado del `Merge Request`
MergeRequestStatus
|
El estado del `merge request` asociado con el evento, como 'Opened', 'Merged' o 'Closed'. | ||
|
Descripción
Este atributo captura el estado de un Seguir el estado del
Por qué es importante
Proporciona visibilidad del proceso de revisión de código y fusión, que a menudo es un cuello de botella crítico en el
Dónde obtener
Obtenido del campo 'state' en la respuesta de la
Ejemplos
openedmergedcerradolocked
|
|||
|
Estado del `Pipeline`
PipelineStatus
|
El estado de la ejecución del `CI/CD pipeline`, como 'Success', 'Failed' o 'Running'. | ||
|
Descripción
Este atributo indica el resultado de una ejecución de Estos datos son esenciales para el
Por qué es importante
Registra el éxito y el fracaso de las compilaciones y pruebas automatizadas, revelando los ciclos de retrabajo y los problemas relacionados con la calidad del código o la automatización de pruebas.
Dónde obtener
Obtenido del campo 'status' en la respuesta de la
Ejemplos
successfallidorunningcancelado
|
|||
|
Estado del Elemento de Desarrollo
DevelopmentItemStatus
|
El estado del elemento de desarrollo en el momento del evento, como 'Abierto', 'En Progreso' o 'Cerrado'. | ||
|
Descripción
Este atributo refleja el estado del elemento de trabajo principal, típicamente una Seguir los cambios de estado es crucial para comprender el ciclo de vida del caso. Ayuda a identificar cuánto tiempo pasan los elementos en cada estado y puede usarse para filtrar el trabajo activo o completado en
Por qué es importante
Proporciona una instantánea del estado del caso, lo que permite analizar el tiempo dedicado a diversas etapas y filtrar el trabajo en curso frente al completado.
Dónde obtener
El estado principal proviene del campo 'state' de una
Ejemplos
openedcerradoEn ProgresoEn Revisión
|
|||
|
Nombre del Equipo
TeamName
|
El equipo de desarrollo asociado con el proyecto o el responsable (`assignee`). | ||
|
Descripción
El Nombre del Equipo representa el grupo o escuadrón responsable del elemento de desarrollo. Esta información típicamente no es un campo estándar en GitLab y a menudo se deriva de las convenciones de nomenclatura del proyecto, las estructuras de grupo, o mapeando los responsables ( Este atributo se utiliza para analizar el rendimiento del proceso a nivel de equipo. Ayuda a comparar la eficiencia, la carga de trabajo y la adhesión al proceso en diferentes equipos, apoyando
Por qué es importante
Permite el análisis de rendimiento y la comparación de procesos entre diferentes equipos, ayudando a identificar
Dónde obtener
A menudo se deriva mapeando el Nombre del Proyecto o el Responsable a una estructura de equipo definida fuera de GitLab, o se infiere de las jerarquías de grupos de GitLab.
Ejemplos
Frontend-AlphaServicios de BackendPlatform-Infra
|
|||
|
Rama de Destino
TargetBranch
|
El nombre de la rama de destino para un `merge request`. | ||
|
Descripción
La Rama de Destino ( Analizar por Rama de Destino puede revelar diferentes comportamientos de proceso para el código que se fusiona en diferentes destinos. Por ejemplo, las fusiones en 'main' pueden tener un proceso de aprobación más riguroso y tiempos de ciclo más largos que las fusiones en una rama de características. También puede ayudar a distinguir los despliegues de producción de otros tipos de integración de código.
Por qué es importante
Ayuda a diferenciar entre varios
Dónde obtener
Obtenido del campo 'target_branch' en la respuesta de la
Ejemplos
maindesarrollorelease/v2.1.0hotfix/user-auth-bug
|
|||
|
Source System
SourceSystem
|
Identifica el sistema del cual se obtuvieron los datos. | ||
|
Descripción
Este atributo especifica el origen de los datos del proceso. Para este modelo de datos, el valor será consistentemente 'GitLab'. Incluir este atributo es crucial en entornos donde los datos del proceso pueden combinarse de múltiples sistemas, como Jira para la planificación y GitLab para la ejecución. Permite filtrar, segmentar y ayuda a mantener la trazabilidad de los datos.
Por qué es importante
Aporta total claridad sobre el origen de los datos, algo fundamental para la gobernanza y para la integración de información proveniente de múltiples sistemas corporativos.
Dónde obtener
Este es un valor estático, 'GitLab', añadido durante el proceso de transformación de datos.
Ejemplos
GitLab
|
|||
|
Tiempo de Ciclo
CycleTime
|
El tiempo total transcurrido desde la primera actividad hasta la última actividad para un elemento de desarrollo. | ||
|
Descripción
El Cycle Time (tiempo de ciclo) es una métrica que mide la duración total de un caso. Normalmente se calcula como la diferencia de tiempo entre el primer evento (por ejemplo, 'Issue Created') y el último ('Deployed to Production') para un mismo ítem de desarrollo. Es un KPI fundamental para medir la eficiencia global del proceso. Se utiliza como métrica principal en dashboards como 'SDLC End-to-End Cycle Time' para monitorizar mejoras y detectar casos excesivamente largos que puedan revelar fallos sistémicos.
Por qué es importante
Este es un
Dónde obtener
Calculado por la herramienta de Process Mining restando el StartTime mínimo al StartTime máximo para cada CaseId único.
Ejemplos
10 días 4 horas23 horas 15 minutos35 días
|
|||
|
Tiempo de Espera en la Entrega
HandoffWaitTime
|
`Tiempo` de inactividad calculado entre dos actividades consecutivas realizadas por diferentes asignados. | ||
|
Descripción
Esta métrica calcula la duración de la brecha entre la finalización de una actividad y el inicio de la siguiente, específicamente cuando cambia el responsable ( Esta es la métrica clave para el
Por qué es importante
Cuantifica el tiempo de inactividad durante los traspasos entre diferentes personas o equipos, revelando retrasos ocultos y cuellos de botella en la comunicación.
Dónde obtener
Calculado por la herramienta de Process Mining. Requiere el análisis de eventos consecutivos dentro de un caso para verificar si el 'Assignee' ha cambiado y, posteriormente, calcular la diferencia de tiempo.
Ejemplos
1 día 2 horas15 minutos8 horas
|
|||
|
Tiempo de Procesamiento
ProcessingTime
|
La duración de una sola actividad, calculada como la diferencia entre su hora de finalización y su hora de inicio. | ||
|
Descripción
El tiempo de procesamiento mide el tiempo de trabajo activo para una actividad específica, distinto del tiempo de espera entre actividades. Se calcula como Esta métrica es crucial para el Análisis de Cuellos de Botella Específicos de la Etapa. Al agregar los tiempos de procesamiento de las actividades dentro de una etapa, como la Revisión de Código, los analistas pueden determinar exactamente cuánto tiempo se dedica activamente a realizar el trabajo, ayudando a identificar pasos de proceso ineficientes.
Por qué es importante
Mide la duración de las actividades individuales, ayudando a distinguir el tiempo de trabajo activo del tiempo de espera inactivo para un análisis preciso de los cuellos de botella.
Dónde obtener
Calculado por la herramienta de Process Mining como la diferencia entre el EndTime y el StartTime de una actividad.
Ejemplos
2 horas 30 minutos0 minutos3 días 8 horas
|
|||
|
Título del Hito
MilestoneTitle
|
El título del `milestone` o `sprint` al que se asigna el elemento de desarrollo. | ||
|
Descripción
Un Este
Por qué es importante
Vincula el trabajo de desarrollo a ciclos de planificación como
Dónde obtener
Obtenido del campo 'milestone.title' en las respuestas de la
Ejemplos
Lanzamiento Q4-2023`Sprint` 23.11Fase 1: `MVP`
|
|||
|
Última actualización de datos
LastDataUpdate
|
La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este evento desde el sistema de origen. | ||
|
Descripción
Este atributo registra la fecha y hora en que los datos del evento fueron extraídos o actualizados por última vez en el conjunto de datos de Esta información es vital para comprender la actualidad de los datos y validar la puntualidad del análisis del proceso. Ayuda a los usuarios a confiar en que los
Por qué es importante
Proporciona transparencia sobre la actualidad de los datos, asegurando que los usuarios sepan cuán actualizada está el análisis del proceso.
Dónde obtener
Esta marca de tiempo (
Ejemplos
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Versión de Lanzamiento
ReleaseVersion
|
La etiqueta de versión de software planificada o real asociada con el despliegue. | ||
|
Descripción
Este atributo identifica el lanzamiento de software específico del que forma parte un elemento de desarrollo. En GitLab, esto se puede asociar a través de un Esto es esencial para el
Por qué es importante
Conecta los elementos de desarrollo a un lanzamiento de software específico, lo cual es crucial para rastrear el progreso del lanzamiento y la adherencia al cronograma.
Dónde obtener
Esto se puede obtener de GitLab Releases, el nombre de una etiqueta
Ejemplos
v1.2.0v3.0.0-beta2023.4.1
|
|||
Actividades del Ciclo de Vida de Desarrollo de Software
| Actividad | Descripción | ||
|---|---|---|---|
|
`Merge Request` Creado
|
Indica que el trabajo de desarrollo inicial está completo y el código está listo para revisión e integración. Este es un evento explícito y central en el `workflow` de GitLab, capturado cuando un desarrollador abre un nuevo `merge request` (`MR`). | ||
|
Por qué es importante
Este es un
Dónde obtener
Este es un evento explícito capturado de la marca de tiempo
Capturar
Utilice el timestamp 'created_at' de la
Tipo de evento
explicit
|
|||
|
`Merge Request` Fusionado
|
Esta actividad significa la finalización exitosa del proceso de revisión e integración de código. Es un evento explícito que ocurre cuando un usuario fusiona la rama del `merge request` en la rama de destino. | ||
|
Por qué es importante
Este es un
Dónde obtener
Este es un evento explícito capturado de la marca de tiempo
Capturar
Utilice el timestamp 'merged_at' de la
Tipo de evento
explicit
|
|||
|
Desplegado a Producción
|
Esta actividad marca el despliegue exitoso del código al entorno de producción en vivo, haciéndolo disponible para los usuarios finales. Esto se captura cuando una tarea específica de 'deploy to production' en un `CI/CD pipeline` de GitLab se completa exitosamente. | ||
|
Por qué es importante
Este es el evento final principal para el proceso, lo que significa que se ha entregado valor. Es esencial para medir el tiempo de ciclo
Dónde obtener
Capturado del
Capturar
Utilice el timestamp 'finished_at' del trabajo de CI de despliegue a producción exitoso.
Tipo de evento
explicit
|
|||
|
Incidencia Creada
|
Esta actividad marca el comienzo del ciclo de vida de desarrollo, representando la creación de un nuevo elemento de trabajo, como una característica, `bug` o tarea. Se captura explícitamente cuando un usuario crea una nueva `issue` en GitLab, lo que registra la marca de tiempo de creación. | ||
|
Por qué es importante
Este es el evento de inicio principal para el proceso de principio a fin. Analizar el tiempo desde la creación de la
Dónde obtener
Este es un evento explícito capturado de la marca de tiempo
Capturar
Utilice el timestamp 'created_at' de la incidencia.
Tipo de evento
explicit
|
|||
|
`Pipeline` Fallido
|
Esta actividad ocurre cuando la ejecución de un `CI/CD pipeline` falla en cualquier etapa, como un error de `build` o una prueba fallida. GitLab registra explícitamente el estado final de cada `pipeline`, haciendo que los fallos sean fáciles de identificar. | ||
|
Por qué es importante
Los fallos del
Dónde obtener
Identificado por un estado 'fallido' en un registro de
Capturar
Filtre los registros de
Tipo de evento
explicit
|
|||
|
`Pipeline` Iniciado
|
Representa la iniciación de un `CI/CD pipeline` automatizado, que típicamente ejecuta `builds`, pruebas y escaneos de seguridad. GitLab crea explícitamente un registro de `pipeline` con una marca de tiempo de inicio cada vez que se activa un `pipeline`, por ejemplo, por un `commit` o la creación de un `MR`. | ||
|
Por qué es importante
El seguimiento de las ejecuciones de
Dónde obtener
Se captura desde la marca de tiempo 'created_at' o 'started_at' de un registro de pipeline en la tabla 'ci_pipelines' o a través de la API de Pipelines.
Capturar
Utilice el timestamp del registro de ejecución de la pipeline asociado a la rama del MR.
Tipo de evento
explicit
|
|||
|
Aprobación Añadida
|
Representa una aprobación formal de los cambios de código en un `merge request` por parte de un revisor. Este es un evento explícito capturado por GitLab cuando un usuario hace clic en el botón 'Aprobar'. | ||
|
Por qué es importante
Las aprobaciones son puertas de calidad clave. Su seguimiento ayuda a analizar el
Dónde obtener
Capturado de los
Capturar
Utilice el timestamp del
Tipo de evento
explicit
|
|||
|
Desarrollo Iniciado
|
Esta actividad significa el inicio del trabajo de codificación activo en la `issue`. Esto se infiere típicamente del primer `commit` de código enviado (`pushed`) a una rama asociada con la `issue`, ya que GitLab no tiene un botón explícito de 'start development'. | ||
|
Por qué es importante
Identifica el inicio exacto del trabajo de desarrollo que agrega valor, lo que permite una medición precisa de la fase de codificación pura y la separa del tiempo de planificación o espera.
Dónde obtener
Se infiere al encontrar la marca de tiempo del primer
Capturar
Encuentre la marca de tiempo del primer
Tipo de evento
inferred
|
|||
|
Despliegue Iniciado
|
Representa el inicio del proceso para liberar código a un entorno específico, como `staging` o `production`. En GitLab, esto corresponde al inicio de una tarea 'deploy' dentro de un `CI/CD pipeline`. | ||
|
Por qué es importante
El seguimiento del inicio del despliegue ayuda a aislar la duración de la fase de despliegue. Es crucial para medir y optimizar el
Dónde obtener
Capturado del
Capturar
Utilice el timestamp 'started_at' del
Tipo de evento
explicit
|
|||
|
Incidencia Asignada
|
Representa la asignación de una `issue` a un desarrollador o equipo específico, indicando que se ha establecido la propiedad del trabajo. Este es un evento explícito registrado por GitLab cada vez que se rellena o cambia el campo `assignee` de una `issue`. | ||
|
Por qué es importante
El seguimiento de las asignaciones es crucial para analizar la asignación de recursos, la carga de trabajo del equipo y los tiempos de traspaso (
Dónde obtener
Se obtiene de las notas de sistema de la incidencia en GitLab, las cuales registran cuándo se añade o cambia un 'assignee'. La marca de tiempo del evento queda registrada en dicha nota.
Capturar
Extraiga los eventos de cambio de asignado ('assignee changed') de las notas de sistema de la incidencia.
Tipo de evento
explicit
|
|||
|
Incidencia Cerrada
|
Representa el cierre administrativo final del elemento de trabajo, típicamente después de que sus cambios han sido desplegados y verificados. Este es un evento explícito capturado cuando un usuario cierra la `issue` en GitLab. | ||
|
Por qué es importante
Cerrar una incidencia suele marcar el fin definitivo de todo el trabajo relacionado. Al comparar este momento con el tiempo de despliegue, se pueden detectar retrasos en la validación posterior al despliegue o en trámites administrativos.
Dónde obtener
Este es un evento explícito capturado de la marca de tiempo
Capturar
Utilice el timestamp 'closed_at' de la incidencia.
Tipo de evento
explicit
|
|||
|
Revisión de Código Iniciada
|
Marca el inicio del proceso de revisión por pares para un `merge request`. Este evento se infiere de la primera acción relacionada con la revisión, como el primer comentario o hilo publicado por alguien que no sea el autor. | ||
|
Por qué es importante
Medir el tiempo desde la creación del
Dónde obtener
Se infiere de la marca de tiempo del primer comentario o hilo de revisión en el
Capturar
Encuentre la marca de tiempo del primer comentario de usuario en un
Tipo de evento
inferred
|
|||