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

La hora de inicio del evento marca la fecha y hora exactas en las que comenzó una actividad. Proporciona el orden cronológico de todos los eventos de un mismo caso, algo esencial para reconstruir el flujo del proceso con precisión.

Las marcas de tiempo son la base de todos los análisis de Process Mining basados en el tiempo. Se utilizan para calcular indicadores clave de rendimiento como tiempos de ciclo, tiempos de espera y tiempos de procesamiento entre actividades. Analizar las marcas de tiempo ayuda a localizar cuellos de botella, medir la eficiencia del proceso y comprender la duración de las distintas etapas del ciclo de vida del desarrollo. Por ejemplo, el tiempo entre «Code Submitted for Review» y «Code Review Completed» puede revelar retrasos en el proceso de revisión.

Esta marca de tiempo es esencial para ordenar correctamente los eventos y calcular todas las métricas basadas en el tiempo, como el tiempo de ciclo y los cuellos de botella.

Está disponible en registros de eventos, pistas de auditoría o tablas de historial que registran los cambios de los elementos de trabajo de desarrollo.

El ID del elemento de desarrollo es la clave principal que identifica de forma única cada instancia de caso durante todo el ciclo de vida del desarrollo de software. Cada ID representa una pieza de trabajo distinta, como una historia de usuario, una tarea o una corrección de bug, desde su creación hasta su resolución o despliegue final.

En el análisis de Process Mining, este atributo es esencial para reconstruir el recorrido completo de cada elemento de trabajo. Permite a la herramienta vincular todas las actividades relacionadas, como «Development Started», «Code Review Completed» y «Deployed to Production», en un flujo de proceso coherente. Analizar el ciclo de vida de cada elemento de desarrollo ayuda a identificar variaciones, retrasos y bucles de retrabajo asociados a piezas de trabajo específicas.

Este es el identificador de caso fundamental necesario para rastrear el ciclo de vida completo de cada elemento de trabajo de desarrollo, desde el principio hasta el final.

Normalmente se encuentra en las tablas principales de elementos de trabajo o seguimiento de incidencias de un sistema de gestión del desarrollo de software.

El nombre de la actividad describe un paso específico o un cambio de estado en el proceso de desarrollo. Estas actividades forman los nodos del mapa de procesos y representan hitos clave como «Item Approved for Development», «Code Submitted for Review» o «QA Testing Completed».

Este atributo es fundamental para visualizar el flujo del proceso y comprender la secuencia de eventos. Al analizar las distintas actividades, los equipos pueden identificar las rutas más habituales, descubrir desviaciones del proceso y medir el tiempo empleado en cada etapa. Constituye la base del análisis de cuellos de botella, la detección de retrabajo y la comprobación de conformidad con respecto a un modelo de proceso objetivo.

Define los pasos del proceso y permite visualizar y analizar el Workflow de desarrollo.

A menudo se deriva de registros de cambios de estado, flujos de eventos o tablas de historial de auditoría asociadas a los elementos de trabajo de desarrollo.

El atributo Sistema de origen identifica la aplicación o plataforma de origen en la que se registraron los datos del ciclo de vida del desarrollo. Es especialmente útil en entornos donde se utilizan varias herramientas de desarrollo, por ejemplo, Jira para el seguimiento de incidencias y GitLab para la gestión del código fuente.

En el análisis, especificar el sistema de origen ayuda a validar los datos y proporciona contexto sobre los datos del proceso. Permite comparar procesos gestionados en distintos sistemas y garantiza que la interpretación de los datos sea correcta, ya que los nombres de los campos y las convenciones de proceso pueden variar entre sistemas. También puede utilizarse para filtrar el análisis y centrarse en el conjunto de datos de una herramienta específica.

Proporciona contexto sobre el origen de los datos, algo fundamental para validarlos y realizar análisis que involucren varios sistemas integrados.

Normalmente es un valor estático que se añade durante la extracción de datos para identificar el origen de los registros.

El atributo Last Data Update registra la fecha y hora en que los datos se extrajeron o actualizaron por última vez desde el sistema de origen. Esto proporciona una indicación clara de la actualidad y relevancia de los datos.

Esta información es fundamental para garantizar que los análisis y los Dashboards se basen en información actualizada. Las partes interesadas pueden comprobar de un vistazo hasta qué punto está actualizada la vista del proceso, lo que genera confianza en las conclusiones obtenidas. Es un elemento de metadatos clave para gestionar las canalizaciones de datos y programar las actualizaciones de datos.

Indica la actualidad de los datos y garantiza que el análisis sea oportuno y relevante para la toma de decisiones.

Normalmente, este valor lo genera y almacena la canalización de extracción, transformación y carga de datos (ETL).

Este atributo identifica a la persona o el grupo responsable de completar el paso actual o el elemento de trabajo en su conjunto. La asignación puede cambiar varias veces durante el ciclo de vida, lo que refleja las transferencias entre distintos roles, como desarrollo, pruebas de QA y revisión.

Analizar el atributo Asignado a es fundamental para comprender la carga de trabajo del equipo, la eficiencia de las transferencias y los patrones de colaboración. Permite filtrar el mapa de procesos para ver el trabajo de una persona o un equipo específicos y ayuda a identificar cuellos de botella relacionados con determinados recursos. El análisis de redes sociales basado en las transferencias entre personas asignadas puede revelar carencias de comunicación o estructuras de colaboración excesivamente complejas.

Permite analizar la carga de trabajo de los recursos, la frecuencia de las transferencias y los patrones de colaboración, lo que ayuda a optimizar la eficiencia del equipo.

Se encuentra en el registro del elemento de trabajo o de la incidencia, normalmente en el historial o registro de auditoría del elemento.

El estado del elemento de desarrollo representa la situación de un elemento de trabajo en un momento determinado. Mientras que el nombre de la actividad captura el evento de cambio de estado, este atributo captura el estado en sí. Puede ser útil para analizar la situación del trabajo en el momento en que tuvo lugar un evento.

Este atributo suele utilizarse para crear el nombre de la actividad, pero también puede aportar contexto adicional. Por ejemplo, analizar el campo de estado permite estudiar cuánto tiempo permanecen los elementos en un estado concreto, como «Blocked» o «Waiting for Review». Comprender el tiempo empleado en estados improductivos es fundamental para identificar retrasos sistémicos y mejorar la eficiencia del flujo.

Permite analizar el tiempo empleado en distintos estados y ayuda a identificar retrasos y el tiempo dedicado a estados que no aportan valor, como «Blocked».

Está disponible como campo principal del registro del elemento de trabajo o de la incidencia y se registra en su historial.

La hora de finalización del evento marca la conclusión de una actividad. Aunque muchos pasos del proceso se registran como eventos instantáneos, con horas de inicio y finalización idénticas, algunas actividades tienen una duración medible. Por ejemplo, una actividad de «Code Review» puede tener una hora de inicio y otra de finalización distintas.

Este atributo es esencial para calcular el tiempo de procesamiento activo de tareas específicas y distinguirlo del tiempo de inactividad o espera. Al comparar la duración entre la hora de inicio y la hora de finalización del evento, los analistas pueden medir el esfuerzo dedicado a actividades que aportan valor. Esto permite analizar con mayor detalle el uso de los recursos y ayuda a identificar qué tareas consumen más tiempo de trabajo activo.

Permite calcular el tiempo de procesamiento activo de cada actividad, separarlo del tiempo de espera y obtener una visión más clara del esfuerzo realizado.

Puede encontrarse en los registros de eventos o derivarse tomando la marca de tiempo de la siguiente actividad de la secuencia para el mismo elemento de trabajo.

Este atributo identifica al equipo, squad o grupo específico responsable de entregar el elemento de desarrollo. En las organizaciones grandes, el trabajo suele distribuirse entre varios equipos especializados, como «Frontend», «Backend», «Mobile» o «Platform».

Analizar por nombre del equipo permite comparar el rendimiento y compartir buenas prácticas entre equipos. Ayuda a responder preguntas como «¿Qué equipo tiene el tiempo de ciclo más corto?» o «¿Un equipo sufre más retrabajo que los demás?». Este análisis puede revelar diferencias en los Workflows, las competencias o la disponibilidad de recursos que afectan al rendimiento general de la entrega y ofrecen oportunidades de mejora específicas del proceso.

Permite comparar el rendimiento de distintos equipos, identificar buenas prácticas y detectar áreas de mejora.

A menudo está asociado a la persona asignada o aparece como campo directo en el registro del proyecto o del elemento de trabajo.

El nombre del proyecto proporciona contexto al agrupar los elementos de trabajo que pertenecen a un producto, iniciativa o base de código específicos. Las prácticas de desarrollo y los tiempos de ciclo pueden variar considerablemente entre proyectos, por ejemplo, entre un sistema heredado y una aplicación nueva desarrollada desde cero.

Este atributo permite agregar y comparar los procesos de desarrollo a alto nivel en distintas áreas de la organización. Al filtrar el análisis por proyecto, las personas responsables pueden evaluar la salud y la eficiencia de cada iniciativa de desarrollo. También es esencial para comprender cómo se relaciona el rendimiento del proceso con el contexto específico y el entorno técnico de un proyecto.

Permite segmentar el análisis del proceso por producto o iniciativa y revela diferencias de rendimiento relacionadas con el contexto del proyecto.

Es un campo estándar del registro del elemento de trabajo o de la incidencia, o el nombre del repositorio en sistemas como Git.

El atributo Prioridad indica la urgencia empresarial o técnica de un elemento de trabajo. Normalmente se establece con valores como «High», «Medium» o «Low» y ayuda a los equipos a decidir en qué trabajar a continuación.

En Process Mining, la prioridad es una dimensión de análisis muy útil. Permite comprobar si los elementos de alta prioridad se procesan realmente más rápido que los de baja prioridad. Comparar los tiempos de ciclo entre distintos niveles de prioridad puede revelar si el proceso respeta las prioridades del negocio. Si los elementos de alta prioridad se retrasan con frecuencia, puede indicar problemas de planificación, asignación de recursos o diseño del Workflow.

Ayuda a comprobar si el trabajo de alta prioridad avanza más rápido por el proceso e identifica cuellos de botella que afectan de forma desproporcionada a los elementos críticos.

Es un campo estándar del registro del elemento de trabajo o de la incidencia en la mayoría de los sistemas de gestión del desarrollo.

Este atributo categoriza la naturaleza del trabajo realizado. Los distintos tipos de elementos de trabajo suelen seguir rutas de proceso diferentes y tener expectativas de rendimiento distintas. Por ejemplo, un «Bug» puede requerir un proceso rápido de hotfix, mientras que una «Feature» sigue un ciclo estándar de desarrollo y pruebas.

Con este atributo, los analistas pueden comparar los flujos de proceso y el rendimiento de distintos tipos de trabajo. Esto ayuda a responder preguntas como «¿Nuestro proceso de corrección de bugs es más rápido que el proceso de desarrollo de funcionalidades?» o «¿Los elementos de deuda técnica sufren más retrabajo?». Es una dimensión fundamental para segmentar los datos y obtener conclusiones más específicas y útiles.

Permite comparar los procesos y el rendimiento de distintas categorías de trabajo y revela ineficiencias específicas de determinados tipos de desarrollo.

Es un campo estándar del registro del elemento de trabajo o de la incidencia en la mayoría de los sistemas de gestión del desarrollo.

El atributo Creador identifica a la persona que inició el elemento de trabajo. Puede ser una persona responsable de producto que crea una historia de usuario, alguien de QA que registra un bug o una persona de atención al cliente que notifica una incidencia de un cliente.

Analizar quién crea los elementos de trabajo puede proporcionar información sobre el origen del trabajo. Por ejemplo, un volumen elevado de bugs notificados por personas usuarias finales podría indicar problemas de calidad en versiones recientes. También puede utilizarse para analizar la claridad y la calidad de los requisitos iniciales al relacionar la persona creadora con el retrabajo o los retrasos posteriores.

Ayuda a identificar quién origina el trabajo y permite analizar las fuentes de demanda, bugs o solicitudes de funcionalidades.

Un campo estándar como «Reporter» o «Author» en el registro de creación inicial de un elemento de trabajo.

La gravedad se diferencia de la prioridad: mide el impacto técnico de una incidencia, mientras que la prioridad mide la urgencia de corregirla. Por ejemplo, un error tipográfico en una página que se visita poco puede tener una gravedad y una prioridad bajas, mientras que un problema crítico de corrupción de datos tendría una gravedad y una prioridad altas.

Este atributo es fundamental para analizar la calidad, especialmente al analizar los procesos de corrección de bugs. Permite a los equipos evaluar si están resolviendo primero las incidencias más graves. Al analizar el tiempo de ciclo de los distintos niveles de gravedad, las organizaciones pueden garantizar que los problemas críticos del sistema se resuelvan rápidamente para minimizar el impacto en los clientes.

Permite analizar la eficacia con la que el equipo aborda las incidencias según su impacto técnico y garantiza que los problemas críticos se resuelvan con rapidez.

Es un campo estándar, especialmente para elementos de trabajo de tipo «Bug» o «Incident», en los sistemas de gestión del desarrollo.

El indicador de retrabajo es un atributo booleano o categórico derivado que marca los eventos que forman parte de un ciclo de retrabajo. Normalmente se identifica cuando el flujo del proceso retrocede, por ejemplo, de «QA Testing» a «Development in Progress», o cuando tienen lugar actividades específicas de retrabajo, como «Rework Identified in QA».

Este atributo es muy valioso para analizar la calidad y la eficiencia. Permite calcular directamente las tasas de retrabajo y destaca las partes del proceso que generan más retrabajo. Al filtrar las actividades de retrabajo, los equipos pueden realizar un análisis de causa raíz para comprender por qué los problemas de calidad no se detectan antes. Reducir el retrabajo es una palanca clave para mejorar tanto la velocidad de desarrollo como la calidad del producto.

Cuantifica directamente el retrabajo, lo que permite a los equipos medir su frecuencia, analizar sus causas y realizar un seguimiento de las mejoras de calidad a lo largo del tiempo.

Normalmente se deriva durante la transformación de datos mediante la identificación de bucles hacia atrás en el flujo del proceso o de nombres de actividades específicos relacionados con fallos.

El atributo Versión planificada vincula un elemento de desarrollo con un calendario de entrega o una versión específicos. Suele utilizarse en la planificación de versiones para agrupar funcionalidades y correcciones destinadas a un despliegue coordinado.

Analizar por versión planificada ayuda a evaluar la previsibilidad y fiabilidad del proceso de lanzamiento. Permite realizar un seguimiento de las entregas a tiempo al comparar la versión planificada con la fecha de despliegue real. Además, ayuda a gestionar el alcance y a comprender el flujo del trabajo destinado a una versión concreta, destacando posibles riesgos o retrasos que podrían afectar al calendario de entrega.

Conecta el trabajo de desarrollo con los calendarios de entrega y permite analizar las tasas de entrega a tiempo y la previsibilidad de las versiones.

Un campo estándar como «Fix Version», «Target Release» o «Iteration Path» en herramientas de planificación ágil y desarrollo.