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

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

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

Esta plantilla ofrece una guía completa para recopilar y preparar los datos de su ciclo de vida de desarrollo de software desde GitHub. Incluye los atributos recomendados, las actividades esenciales que debe supervisar y orientación práctica para extraer los datos. Utilice este recurso para crear un registro de eventos preciso que le permita analizar y optimizar el proceso de forma eficaz.
  • Atributos recomendados para recopilar
  • Actividades clave que debe supervisar
  • Guía de extracción
¿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 completo del ciclo de vida del desarrollo de software y descubrir el proceso.
3 Obligatorio 5 Recomendado 15 Opcional
Nombre Descripción
Actividad
ActivityName
El nombre de un evento o una tarea específicos que tuvieron lugar dentro del Software Development Lifecycle.
Descripción

El nombre de la actividad describe un paso individual del proceso de desarrollo, como 'Incidencia creada', 'Código enviado a la PR', 'Pull Request aprobada' o 'Despliegue exitoso'. Estos eventos forman la secuencia de pasos que constituye el proceso de extremo a extremo de un elemento de desarrollo.

Este atributo es fundamental para el Process Mining, ya que se utiliza para construir el mapa de procesos. Analizar la secuencia, la frecuencia y la duración de estas actividades revela el flujo real del proceso, identifica las rutas habituales, destaca las desviaciones y localiza los cuellos de botella.

Por qué es importante

Este atributo constituye la base del mapa de procesos y permite visualizar y analizar la secuencia de eventos del ciclo de vida del desarrollo.

Dónde obtenerlo

Se obtiene del campo 'action' de las cargas útiles de eventos webhook, por ejemplo, 'opened' o 'closed' para una incidencia, o del propio tipo de evento, como 'PushEvent' o 'PullRequestReviewEvent'.

Ejemplos
Incidencia creadaPull Request abiertaCódigo enviado a la PRRevisión solicitadaPull Request fusionada
Elemento de desarrollo
DevelopmentItemId
El identificador único de una unidad individual de trabajo de desarrollo, como una funcionalidad, una corrección de errores o una tarea. Sirve como identificador principal del caso.
Descripción

El ID del elemento de desarrollo realiza el seguimiento de un elemento de trabajo desde su creación hasta el despliegue final. Vincula todas las actividades asociadas, como la creación de ramas, los commits, las pull requests, las revisiones y los despliegues, en una única instancia de proceso coherente.

En el análisis, este ID se utiliza para calcular el tiempo de ciclo de extremo a extremo de una tarea de desarrollo. Permite reconstruir todo el recorrido de una funcionalidad o una corrección de errores, lo que facilita un análisis detallado de los cuellos de botella, los ciclos de retrabajo y las variaciones del proceso en cada elemento de trabajo.

Por qué es importante

Es la clave esencial para el Process Mining, ya que conecta todos los eventos de desarrollo relacionados en un único caso y permite visualizar y analizar con precisión el Software Development Lifecycle de extremo a extremo.

Dónde obtenerlo

Normalmente es el número de incidencia o el número de pull request de GitHub. Puede extraerse del campo 'number' de la carga útil de eventos webhook o de las respuestas de la API relacionadas con incidencias o pull requests.

Ejemplos
101PR-2345TASK-812
Hora de inicio
EventTimestamp
La fecha y hora exactas en que tuvo lugar una actividad o un evento de desarrollo específicos.
Descripción

Esta marca de tiempo señala el comienzo de una actividad. Es fundamental para ordenar cronológicamente los eventos y reconstruir el flujo del proceso de cada elemento de desarrollo. La secuencia y la diferencia de tiempo entre estas marcas se utilizan para analizar el rendimiento del proceso.

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 identificar retrasos entre pasos y proporciona los datos necesarios para el análisis de cuellos de botella y la supervisión del rendimiento mediante Dashboards.

Por qué es importante

Esta marca de tiempo es fundamental para ordenar correctamente los eventos y calcular todas las métricas de rendimiento, como los tiempos de ciclo y la duración de los cuellos de botella.

Dónde obtenerlo

Normalmente aparece en los campos 'created_at' o 'updated_at' de las cargas útiles JSON de las API y los webhooks de GitHub para distintos objetos, como incidencias, pull requests y commits.

Ejemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Hora de finalización
EndTimestamp
La fecha y hora exactas en que se completó una actividad o un evento de desarrollo específicos.
Descripción

La marca de tiempo de finalización señala que una actividad ha terminado. Aunque muchos eventos de GitHub son instantáneos, como 'Incidencia creada', algunas actividades tienen una duración medible, como la ejecución de una comprobación de CI. La diferencia entre la hora de finalización y la hora de inicio proporciona el tiempo de procesamiento de una actividad.

Este atributo se utiliza para calcular la métrica 'ProcessingTime', fundamental para comprender cuánto esfuerzo activo se dedica a distintas tareas, como las revisiones de código o las comprobaciones automatizadas. Analizar los tiempos de procesamiento ayuda a identificar actividades ineficientes que consumen demasiado tiempo.

Por qué es importante

Permite calcular tiempos de procesamiento precisos para las actividades y ayuda a distinguir entre el tiempo de trabajo activo y el tiempo de espera inactivo.

Dónde obtenerlo

Puede encontrarse como 'completed_at' en los objetos de ejecución de comprobaciones o derivarse de la marca de tiempo de un evento posterior que concluya lógicamente la actividad.

Ejemplos
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Persona usuaria asignada
Assignee
La persona usuaria o desarrolladora asignada para gestionar el elemento de desarrollo o una tarea específica, como la revisión de una pull request.
Descripción

Este atributo identifica a la persona responsable del trabajo en una etapa determinada. Puede ser la persona asignada a una incidencia, la autora o el autor de una solicitud de incorporación de cambios, o la persona revisora solicitada para una revisión de código. Hacer un seguimiento de la persona asignada es fundamental para comprender la asignación de recursos y la carga de trabajo.

Este atributo se utiliza en el análisis para supervisar la carga de trabajo de desarrollo, identificar cuellos de botella de recursos y analizar la eficiencia de las transferencias entre distintos miembros del equipo. Los Dashboards pueden filtrarse por persona asignada para evaluar el rendimiento individual o del equipo y garantizar una distribución equilibrada del trabajo.

Por qué es importante

Es fundamental para analizar la carga de trabajo de las personas desarrolladoras, el rendimiento del equipo y la eficiencia de los traspasos entre sus integrantes.

Dónde obtenerlo

Está disponible en el objeto 'assignee' o 'user' de las cargas útiles JSON de incidencias, pull requests y eventos de revisión de la API de GitHub.

Ejemplos
john.doejane.smithdev-team-lead
Prioridad
Priority
El nivel de prioridad asignado a un elemento de desarrollo, como «High», «Medium» o «Low».
Descripción

La prioridad indica la urgencia o importancia empresarial de un elemento de trabajo. En GitHub, la prioridad no es un campo nativo y normalmente se gestiona mediante etiquetas, como «P1-High» y «P2-Medium». Para extraer esta información de forma fiable, se necesita un esquema de etiquetado coherente.

Este atributo es esencial para el «Priority-Based Flow Analysis». Permite comprobar si los elementos de alta prioridad se procesan realmente más rápido que los de baja prioridad y medir la variación del tiempo de ciclo según la prioridad. También ayuda a evaluar la eficacia del proceso de priorización.

Por qué es importante

Permite analizar si los elementos de alta prioridad se procesan más rápido que los de menor prioridad y validar así la eficacia de la estrategia de priorización.

Dónde obtenerlo

Se obtiene de las etiquetas de GitHub aplicadas a incidencias o pull requests. Requiere una convención estandarizada para las etiquetas de prioridad.

Ejemplos
AltaMediaBajaCrítica
Repositorio
RepositoryName
El nombre del repositorio de código donde tiene lugar la actividad de desarrollo.
Descripción

El repositorio actúa como identificador del proyecto o producto y contiene todo el código, las incidencias y las pull requests de una aplicación o componente específicos. Permite segmentar y comparar los procesos de desarrollo entre distintos productos o equipos.

En el análisis, este atributo permite filtrar y comparar el rendimiento del proceso entre distintos proyectos. Ayuda a responder preguntas como «¿Qué proyecto tiene el tiempo de ciclo más largo?» o «¿Cómo se compara el proceso de corrección de errores del Proyecto A con el del Proyecto B?». Es esencial para el panel «Throughput by Project and Type».

Por qué es importante

Permite segmentar y comparar los procesos de desarrollo entre distintos proyectos, productos o equipos, lo que facilita un análisis más específico.

Dónde obtenerlo

Está disponible en el objeto 'repository' de prácticamente todas las cargas útiles de webhooks y API de GitHub. El campo específico suele ser 'repository.full_name' o 'repository.name'.

Ejemplos
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Tipo de elemento de desarrollo
DevelopmentItemType
La clasificación del elemento de trabajo de desarrollo, como funcionalidad, error, tarea o epic.
Descripción

Este atributo categoriza la naturaleza del trabajo realizado. Normalmente, esta información se gestiona mediante etiquetas o plantillas de incidencias específicas en GitHub. Comprender el tipo de trabajo es fundamental para establecer expectativas de rendimiento adecuadas, ya que una corrección de errores puede tener un tiempo de ciclo esperado mucho menor que una nueva funcionalidad.

Este atributo permite comparar distintos tipos de trabajo. Ayuda a analizar si las correcciones de errores se procesan más rápido que las nuevas funcionalidades o a comprender la asignación de recursos entre la deuda técnica y el desarrollo nuevo. Es una dimensión clave del panel «Throughput by Project and Type».

Por qué es importante

Clasifica los elementos de trabajo, lo que permite comparar el rendimiento y analizar cómo fluyen por el proceso los distintos tipos de trabajo, como errores y funcionalidades.

Dónde obtenerlo

Normalmente se obtiene de las etiquetas de GitHub aplicadas a incidencias o pull requests. Requiere una convención de etiquetado coherente, como «type:bug» y «type:feature».

Ejemplos
ErrorFuncionalidadTareaDeuda técnica
Autor
Author
El usuario que creó la incidencia, la pull request o el commit.
Descripción

El autor es la persona que origina un artefacto concreto del proceso de desarrollo. Por ejemplo, el autor de una incidencia es quien informó del error o solicitó la funcionalidad. El autor de una pull request es la persona desarrolladora que escribió el código.

En el análisis, el autor puede utilizarse para comprender el origen del trabajo. Por ejemplo, analizar a los autores de los informes de errores puede revelar patrones relacionados con determinados equipos o funcionalidades. También puede combinarse con la persona asignada para analizar los patrones de transferencia.

Por qué es importante

Identifica a la persona que originó un elemento de trabajo o un cambio de código, lo que puede resultar útil para analizar el origen del retrabajo, los informes de errores o las solicitudes de funcionalidades.

Dónde obtenerlo

Está disponible en el objeto «user» dentro del objeto principal de las respuestas de la API para incidencias, pull requests y commits. El campo suele ser «user.login».

Ejemplos
sara.jonesmike.leeautomation-bot
Entorno de despliegue
DeploymentEnvironment
El entorno de destino de un despliegue, como «Staging» o «Production».
Descripción

Este atributo especifica dónde se despliega el código. Realizar un seguimiento de los despliegues en distintos entornos es clave para comprender todo el ciclo de vida, desde el desarrollo hasta la publicación en producción.

Permite analizar el subproceso de despliegue. Puede utilizarse para medir el tiempo necesario para promover el código de staging a producción y realizar un seguimiento de la tasa de éxito de los despliegues en distintos entornos. Es esencial para saber cuándo un elemento de desarrollo está realmente «done» y se ha entregado a las personas usuarias.

Por qué es importante

Distingue entre las publicaciones previas a producción y las publicaciones en producción, algo fundamental para medir el verdadero «time-to-market» y analizar los patrones de despliegue.

Dónde obtenerlo

Esta información se obtiene de la API de GitHub Deployments, que suele activarse mediante flujos de CI/CD u otros procesos automatizados.

Ejemplos
desarrollopreproducciónproducción
Es retrabajo
IsRework
Un indicador booleano que es verdadero si una actividad representa una regresión a una etapa anterior del proceso.
Descripción

Este indicador se establece como verdadero cuando un elemento de desarrollo retrocede en el proceso, por ejemplo, cuando una pull request recibe una revisión «Changes Requested» o cuando una incidencia se vuelve a abrir después de cerrarse. Se obtiene mediante el análisis de la secuencia de actividades.

Este atributo es esencial para cuantificar el desperdicio y la ineficiencia. Es compatible directamente con el panel «Rework and Regression Loops» y el KPI «Rework Rate». Al filtrar por «IsRework = true», las personas analistas pueden aislar e investigar las causas del retrabajo.

Por qué es importante

Marca explícitamente las actividades que constituyen retrabajo, lo que facilita cuantificar, visualizar y analizar las causas de las ineficiencias del proceso.

Dónde obtenerlo

Es un atributo derivado. La lógica consiste en definir un flujo de proceso estándar y marcar después cualquier actividad que se desvíe al regresar a una etapa lógica anterior.

Ejemplos
truefalse
Estado de la comprobación de CI
CiCheckStatus
El estado de una comprobación automatizada de Integración Continua (CI), como «passed» o «failed».
Descripción

Este atributo refleja el resultado de las compilaciones, pruebas y exploraciones automatizadas que se ejecutan sobre los cambios de código de una pull request. Las comprobaciones de CI son un control de calidad fundamental en los flujos de trabajo de desarrollo actuales.

Analizar este atributo ayuda a comprender la eficacia de las pruebas automatizadas. Una tasa elevada de fallos puede indicar problemas de estabilidad del código, del conjunto de pruebas o del entorno de desarrollo. Es compatible con las actividades «CI Checks Passed» y «CI Checks Failed», y ayuda a analizar los retrasos causados por compilaciones fallidas.

Por qué es importante

Indica si los controles de calidad automatizados se han superado o han fallado, y ofrece información sobre la calidad del código y la eficacia del flujo de CI.

Dónde obtenerlo

Se obtiene del campo «state» o «conclusion» de los objetos de ejecución de comprobaciones o de estado mediante las API de GitHub Checks o Statuses.

Ejemplos
éxitofallopendienteerror
Estado de la revisión
ReviewState
El resultado de una revisión de código de una pull request, como «Approved» o «Changes Requested».
Descripción

Este atributo recoge la decisión tomada por un revisor. Entre los estados habituales se encuentran «APPROVED», que indica que el código está listo para fusionarse, y «CHANGES_REQUESTED», que indica que es necesario realizar retrabajo. También pueden aparecer otros estados, como «COMMENTED» o «PENDING».

Es un atributo crítico para analizar el retrabajo y la calidad. Una frecuencia elevada de eventos «CHANGES_REQUESTED» puede indicar problemas en la calidad inicial del código o requisitos poco claros. Es compatible directamente con el panel «Rework and Regression Loops», ya que identifica cuándo se devuelve un elemento de desarrollo para modificarlo.

Por qué es importante

Indica directamente los ciclos de retrabajo y los controles de calidad del proceso de revisión del código, lo que ayuda a localizar las fuentes de ineficiencia y los problemas de calidad.

Dónde obtenerlo

Está disponible en el campo «state» de un objeto de revisión de pull request de la API de GitHub, por ejemplo, en una carga «PullRequestReviewEvent».

Ejemplos
APROBADOCAMBIOS SOLICITADOSCOMENTADO
Estado del elemento
State
El estado actual de una incidencia o pull request, como «open», «closed» o «merged».
Descripción

Este atributo indica el estado general de un elemento de desarrollo. En el caso de las incidencias, los estados habituales son 'open' y 'closed'. En el caso de las solicitudes de incorporación de cambios, los estados incluyen 'open', 'closed' y 'merged'. Esto proporciona una instantánea del progreso del elemento.

En el análisis, el estado se utiliza para distinguir el trabajo activo del trabajo completado. Es esencial para Dashboards como 'Active Development Progress', que supervisan el trabajo en curso. También se utiliza para definir el final de un proceso. Por ejemplo, un estado 'merged' o 'closed' puede indicar la finalización de un caso.

Por qué es importante

Indica claramente si un elemento de trabajo está en curso o se ha completado, algo fundamental para analizar el ciclo de vida y supervisar el trabajo activo.

Dónde obtenerlo

Está disponible directamente en el campo «state» de las cargas JSON de incidencias y pull requests de la API de GitHub.

Ejemplos
abiertocerradofusionado
Etiquetas
Labels
Una lista de etiquetas aplicadas a una incidencia o pull request para clasificarla.
Descripción

Las etiquetas de GitHub ofrecen una forma flexible de añadir metadatos a las incidencias y pull requests. Pueden utilizarse para indicar la prioridad, el tipo de trabajo, los componentes, los equipos o el estado. La lista sin procesar de etiquetas proporciona un contexto amplio y no estructurado.

Aunque atributos concretos, como Prioridad y Tipo, se derivan de las etiquetas, conservar la lista completa puede resultar útil para análisis ad hoc y para descubrir otros patrones del proceso. Permite filtrar y segmentar los casos con flexibilidad según cualquier combinación de etiquetas.

Por qué es importante

Proporciona una fuente flexible y completa de metadatos para clasificar los elementos de trabajo, lo que permite realizar análisis dimensionales profundos y variados.

Dónde obtenerlo

Está disponible como la matriz «labels» de la carga JSON de incidencias y pull requests de la API de GitHub. Cada elemento de la matriz es un objeto con un campo «name».

Ejemplos
error, interfaz de usuario, alta-prioridadfuncionalidad, backend, necesita-documentacióndeuda-técnica, refactorización
Hash del commit
CommitHash
El identificador único (SHA) de un commit de código concreto.
Descripción

El hash de un commit es un hash SHA-1 de 40 caracteres que identifica de forma única un commit en Git. Actúa como ID permanente de una versión concreta del código. Los commits son las unidades atómicas de cambio del proceso de desarrollo.

Aunque ofrece un nivel de detalle muy alto, el hash del commit proporciona la máxima trazabilidad. Permite vincular un evento del proceso directamente con el cambio de código exacto realizado. Esto puede resultar muy valioso para auditorías, cumplimiento o análisis detallados de la causa raíz de incidentes en producción.

Por qué es importante

Proporciona el vínculo más detallado entre un paso del proceso y el cambio de código exacto, lo que permite una trazabilidad completa para auditorías y depuración.

Dónde obtenerlo

Está disponible en las cargas de eventos de envío («head_commit.id») o mediante la API de Commits para una pull request o una rama.

Ejemplos
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nombre de la rama
BranchName
El nombre de la rama de Git en la que se realizaron los cambios de código del elemento de desarrollo.
Descripción

Una rama es una línea de desarrollo independiente que se crea para trabajar en una nueva funcionalidad o corregir un error sin afectar a la base de código principal. El nombre de la rama suele contener información útil, como el número de la incidencia o una breve descripción del trabajo.

Analizar los nombres de las ramas puede ayudar a comprender las estrategias de ramificación y el cumplimiento de las convenciones de desarrollo. También facilita vincular commits de código concretos con un elemento de desarrollo y ofrece una visión completa de la actividad de programación.

Por qué es importante

Aporta contexto sobre la línea de desarrollo concreta y ayuda a aplicar y analizar las estrategias de ramificación y las convenciones de nomenclatura.

Dónde obtenerlo

Está disponible en el campo «ref» de los eventos de envío, o en los objetos «head» y «base» de la respuesta de la API de una pull request.

Ejemplos
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Número de pull request
PullRequestNumber
El identificador único de una pull request asociada al elemento de desarrollo.
Descripción

Una pull request (PR) es una propuesta para fusionar un conjunto de cambios de código en una rama concreta. El número de pull request vincula actividades de desarrollo, como los envíos de código y las revisiones, con el elemento de desarrollo principal o la incidencia.

Este ID es fundamental para realizar el seguimiento de la integración y la revisión del código dentro del ciclo de vida general del desarrollo. Permite analizar en detalle el proceso de revisión, incluidos los tiempos de revisión, los ciclos de retrabajo identificados durante la revisión y las tasas de fusión. Conecta la fase de planificación, representada por la incidencia, con la fase de implementación, representada por la PR.

Por qué es importante

Vincula las incidencias con los cambios de código y los procesos de revisión concretos, lo que permite analizar en detalle el ciclo de revisión y su impacto en el tiempo total de entrega.

Dónde obtenerlo

Está disponible en el campo «number» del objeto «pull_request» en muchas respuestas de la API de GitHub, o como identificador principal de la API de Pull Requests.

Ejemplos
12345678910
Revisor
Reviewer
El usuario al que se solicitó realizar una revisión de código en una pull request.
Descripción

Un revisor es una persona desarrolladora o integrante del equipo asignada para inspeccionar los cambios de código de una pull request y comprobar su calidad, corrección y cumplimiento de los estándares. Una pull request puede tener varios revisores.

Este atributo es esencial para analizar el proceso de revisión del código. Ayuda a identificar cuellos de botella relacionados con revisores concretos, comprender cómo se distribuye la carga de trabajo de revisión y medir el tiempo que tardan los revisores en responder a las solicitudes. Es un componente clave para calcular el KPI «Average Code Review Cycle Time».

Por qué es importante

Identifica a las personas que participan en el proceso de aseguramiento de la calidad, lo que permite analizar la carga de trabajo de revisión, los retrasos y la eficiencia general de las revisiones de código.

Dónde obtenerlo

Está disponible en la matriz «requested_reviewers» o en el objeto «user» de un evento de revisión de pull request procedente de la API de GitHub.

Ejemplos
alex.chenmaria.garciasenior-dev-team
Sistema de origen
SourceSystem
El sistema del que se extrajeron los datos del proceso de desarrollo.
Descripción

Este atributo identifica el origen de los datos de eventos. En este proceso, el valor sería siempre 'GitHub'. En un entorno más complejo, donde las actividades de desarrollo abarcan varios sistemas, como Jira para la planificación, GitHub para el código y Jenkins para el despliegue, este campo se utiliza para distinguir el origen de cada evento.

En el análisis, ayuda a rastrear los datos hasta su origen para validarlos y resolver problemas. También permite analizar procesos que atraviesan distintas plataformas y proporciona un contexto claro para cada actividad.

Por qué es importante

Identifica el origen de los datos, algo esencial para validarlos y analizar procesos que pueden abarcar varios sistemas integrados.

Dónde obtenerlo

Normalmente es un valor estático que se añade durante el proceso de extracción, transformación y carga (ETL) de datos para etiquetar el origen de los registros.

Ejemplos
GitHubGitHub Enterprise
Tiempo de ciclo de desarrollo
DevelopmentCycleTime
El tiempo total transcurrido desde la creación de un elemento de desarrollo hasta su despliegue final o cierre.
Descripción

Es una métrica a nivel de caso que se calcula como la diferencia de tiempo entre el primer evento, como «Issue Created», y el evento final, como «Deployment Succeeded» o «Issue Closed», de un único elemento de desarrollo.

Es uno de los KPI más importantes para medir la eficiencia general del proceso de desarrollo. Es compatible directamente con el panel «Overall Development Cycle Time» y el KPI «Average Development Cycle Time». Reducir esta métrica suele ser uno de los objetivos principales de las iniciativas de mejora de procesos.

Por qué es importante

Representa el «time-to-market» integral de un elemento de desarrollo, por lo que es un KPI crítico para medir la velocidad y la eficiencia generales del proceso.

Dónde obtenerlo

Se calcula a nivel de caso restando la marca de tiempo de la primera actividad de la marca de tiempo de la última actividad.

Ejemplos
P5DT6H30MP14DT12HP1DT2H
Tiempo de espera por transferencia
HandoffWaitingTime
El tiempo de inactividad calculado que un elemento de desarrollo pasa esperando entre actividades realizadas por personas diferentes.
Descripción

Esta métrica mide el tiempo entre la finalización de una actividad y el inicio de la siguiente, pero solo cuando cambia la persona responsable. Por ejemplo, el tiempo entre un evento «Review Requested» y un evento «Changes Requested in Review» realizado por otra persona usuaria.

Es una métrica crítica para identificar carencias de comunicación y problemas de coordinación. Es compatible con el panel «Critical Handoff Efficiency» y el KPI «Average Handoff Waiting Time». Los tiempos de espera elevados en los puntos de transferencia suelen indicar limitaciones de recursos o procesos de notificación ineficientes.

Por qué es importante

Localiza los retrasos causados por una coordinación deficiente o por la falta de disponibilidad de recursos durante las transferencias entre distintos equipos o roles, que suelen ser fuentes importantes de ineficiencia.

Dónde obtenerlo

Se calcula identificando actividades consecutivas en las que cambia el atributo «Assignee» o «User» y midiendo después el intervalo de tiempo entre ellas.

Ejemplos
PT1H15MP2DT4HPT25M
Última actualización de datos
LastDataUpdate
La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen.
Descripción

Este atributo registra la fecha y hora de la extracción o actualización de datos más reciente. Proporciona metadatos sobre la actualidad de los datos analizados. Se diferencia de la marca de tiempo del evento, que registra cuándo ocurrió el evento empresarial.

En el análisis, este campo es fundamental para comprender la actualidad de la vista del proceso. Ayuda a saber si se están consultando datos en tiempo real o una instantánea de un momento concreto, algo importante para los Dashboards operativos y la supervisión.

Por qué es importante

Indica la actualidad de los datos, un aspecto fundamental para garantizar que los análisis y los Dashboards se basen en información actualizada.

Dónde obtenerlo

Esta marca de tiempo se genera y añade durante el proceso de extracción, transformación y carga (ETL) de datos.

Ejemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
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.
6 Recomendado 7 Opcional
Actividad Descripción
Comprobaciones de CI superadas
Representa la finalización exitosa de comprobaciones automatizadas, como compilaciones, pruebas unitarias o análisis estático, ejecutadas sobre el código de una pull request. Este evento se infiere a partir del estado de las comprobaciones notificadas por sistemas como GitHub Actions.
Por qué es importante

Este control de calidad automatizado es fundamental para garantizar la estabilidad del código. Los fallos o los tiempos de ejecución prolongados pueden convertirse en cuellos de botella importantes del flujo de entrega.

Dónde obtenerlo

Se infiere de la API Checks o la API Statuses de GitHub. Una ejecución de comprobación o una actualización de estado informa de 'success' o de 'completed' con una conclusión 'success'.

Recopilar

Supervise la API Checks para detectar una conclusión 'success' en las suites de comprobaciones pertinentes.

Tipo de evento inferred
Incidencia cerrada
El elemento de desarrollo se considera completado y la incidencia correspondiente se cierra formalmente. Esto puede ocurrir automáticamente cuando se fusiona una pull request vinculada o de forma manual por parte de una persona del equipo.
Por qué es importante

Esta actividad representa el final definitivo del proceso para un elemento de desarrollo. Es fundamental para calcular los tiempos de ciclo de extremo a extremo.

Dónde obtenerlo

Es un evento explícito capturado del flujo de eventos de la API de GitHub Issues. El tipo de evento es 'closed'.

Recopilar

Escuche el evento 'closed' de una incidencia mediante webhooks o consultas periódicas a la API.

Tipo de evento explicit
Incidencia creada
Marca el inicio del ciclo de vida de un elemento de desarrollo y representa la creación formal de una tarea, un error o una solicitud de funcionalidad. Este evento se captura explícitamente cuando una persona usuaria crea una nueva incidencia en un repositorio de GitHub.
Por qué es importante

Esta es la actividad inicial principal del proceso, esencial para medir el tiempo total del ciclo de desarrollo y comprender las fuentes iniciales del trabajo.

Dónde obtenerlo

Es un evento explícito capturado del flujo de eventos de la API de GitHub Issues. El tipo de evento suele ser 'opened' para un número de incidencia determinado.

Recopilar

Escuche el evento 'opened' de una incidencia mediante webhooks o consultas periódicas a la API.

Tipo de evento explicit
Pull Request abierta
Indica que un primer bloque de código está listo para su revisión e integración. Una persona desarrolladora crea una pull request (PR) para proponer cambios desde su rama de funcionalidad a una rama principal. Es un evento explícito de GitHub.
Por qué es importante

Este es un hito crítico que marca el final de la fase inicial de desarrollo y el comienzo del flujo de revisión e integración. Es clave para analizar por separado los tiempos de desarrollo y de revisión.

Dónde obtenerlo

Se captura del flujo de eventos de la API de Pull Requests de GitHub o mediante webhooks. La acción del evento es 'opened'.

Recopilar

Escuche la acción 'opened' de una pull request mediante webhooks o consultas periódicas a la API.

Tipo de evento explicit
Pull Request aprobada
Una persona revisora ha aprobado formalmente los cambios de una pull request, lo que indica que cumple los estándares de calidad y funcionalidad. Se captura cuando la persona revisora envía su revisión con el estado 'approve'.
Por qué es importante

Este es un control de calidad clave y un hito importante antes de la fusión. El tiempo necesario para alcanzar este estado desde la creación de la PR es un KPI crítico de la eficiencia del proceso de revisión.

Dónde obtenerlo

Se captura de la API de Pull Requests de GitHub o mediante webhooks cuando se envía una revisión con el estado 'APPROVED'.

Recopilar

Filtre los eventos de envío de revisiones de pull requests por el estado 'APPROVED'.

Tipo de evento explicit
Pull Request fusionada
Los cambios de código aprobados de la pull request se integran oficialmente en la rama de destino, como main o develop. Es una acción final explícita sobre una pull request que incorpora el código nuevo.
Por qué es importante

Este es un hito crítico que representa la finalización del desarrollo y la revisión. Para muchos equipos, es el último paso antes del despliegue automatizado.

Dónde obtenerlo

Se captura del flujo de eventos de la API de Pull Requests de GitHub o mediante webhooks. La acción del evento es 'closed' y el atributo 'merged' de la carga útil de la pull request es true.

Recopilar

Escuche la acción 'closed' de una pull request y compruebe si el indicador 'merged' es true.

Tipo de evento explicit
Cambios solicitados en la revisión
Una persona revisora ha completado la revisión del código y ha determinado que es necesario realizar modificaciones antes de aprobar la pull request. La persona revisora envía formalmente su revisión con el estado 'request_changes'.
Por qué es importante

Este evento señala explícitamente un ciclo de retrabajo. Analizar su frecuencia ayuda a localizar problemas de calidad, requisitos poco claros o áreas en las que se necesita formación para las personas desarrolladoras.

Dónde obtenerlo

Se captura de la API de Pull Requests de GitHub o mediante webhooks cuando se envía una revisión con el estado 'CHANGES_REQUESTED'.

Recopilar

Filtre los eventos de envío de revisiones de pull requests por el estado 'CHANGES_REQUESTED'.

Tipo de evento explicit
Código enviado a la PR
Representa una actualización del código enviado para revisión, ya sea como parte de la PR inicial o en respuesta a los comentarios de revisión. Este evento se captura cada vez que se envía un nuevo commit a la rama asociada con una pull request abierta.
Por qué es importante

El seguimiento de estos eventos es fundamental para identificar ciclos de retrabajo. Varios envíos después de una revisión indican que fueron necesarios cambios, lo que afecta al tiempo total del ciclo.

Dónde obtenerlo

Es un evento explícito en la cronología de la pull request, que suele aparecer como un commit añadido. Puede capturarse mediante el webhook 'push' o supervisando los commits asociados a una PR.

Recopilar

Realice el seguimiento de los eventos 'push' en una rama asociada con una pull request abierta.

Tipo de evento explicit
Comprobaciones de CI fallidas
Representa el fallo de una comprobación automatizada, como un error de compilación o una prueba unitaria fallida, ejecutada sobre el código de una pull request. Se infiere a partir de un estado de fallo notificado por un sistema como GitHub Actions.
Por qué es importante

Esta actividad destaca problemas técnicos de calidad que requieren la intervención de una persona desarrolladora y crean un ciclo de retrabajo. Analizar la frecuencia de los fallos puede orientar mejoras en las pruebas locales o en la calidad del código.

Dónde obtenerlo

Se infiere de la API Checks o la API Statuses de GitHub. Una ejecución de comprobación o una actualización de estado informa de 'failure' o de 'completed' con una conclusión 'failure'.

Recopilar

Supervise la API Checks para detectar una conclusión 'failure' en las suites de comprobaciones pertinentes.

Tipo de evento inferred
Despliegue exitoso
Los cambios de código se han desplegado correctamente en un entorno específico, como staging o producción. Este evento suele capturarse mediante la API Deployments de GitHub, a menudo activada por una GitHub Action después de una fusión.
Por qué es importante

Marca la transición del código desde el repositorio hasta un entorno activo. Su seguimiento es esencial para medir el lead time completo, desde la idea hasta producción.

Dónde obtenerlo

Se captura mediante la API Deployments. Un servicio externo o una GitHub Action crea un despliegue y después actualiza su estado a 'success'.

Recopilar

Supervise los eventos de estado del despliegue mediante webhooks para detectar el estado 'success'.

Tipo de evento inferred
Incidencia reabierta
Una incidencia cerrada anteriormente se reactiva, normalmente porque la corrección fue insuficiente o se detectó una regresión. Es un evento explícito que reinicia el ciclo de vida del elemento de desarrollo.
Por qué es importante

Esto señala un ciclo de retrabajo importante e indica un posible defecto que llegó a producción o una corrección incompleta. Hacer un seguimiento de su frecuencia es una medida clave de la calidad general del software.

Dónde obtenerlo

Es un evento explícito capturado del flujo de eventos de la API de GitHub Issues. El tipo de evento es 'reopened'.

Recopilar

Escuche el evento 'reopened' de una incidencia mediante webhooks o consultas periódicas a la API.

Tipo de evento explicit
Rama creada
Representa el inicio del trabajo de desarrollo activo de una incidencia, cuando una persona desarrolladora crea una nueva rama a partir de la base de código principal. Es un evento explícito que se captura cuando se envía una nueva rama al repositorio, cuyo nombre suele contener el número de la incidencia.
Por qué es importante

Indica la transición de la planificación a la programación activa. Medir el tiempo entre la creación de la incidencia y este evento ayuda a analizar el tiempo de asignación al desarrollo y los retrasos iniciales del backlog.

Dónde obtenerlo

Se captura mediante la API Git de GitHub o webhooks que escuchan eventos 'create' de tipo 'branch'. A menudo es necesario vincular el nombre de la rama con una incidencia mediante convenciones de nomenclatura, como 'feature/issue-123'.

Recopilar

Analice los eventos webhook 'create' de nuevas ramas y asócielos con una incidencia.

Tipo de evento explicit
Revisión solicitada
La persona autora de una pull request solicita formalmente a determinadas personas o equipos que revisen su código. Es una acción explícita en la interfaz o la API de GitHub que activa notificaciones para las personas revisoras solicitadas.
Por qué es importante

Esta actividad marca el inicio oficial del traspaso al proceso de revisión de código. El tiempo entre este evento y el envío de una revisión ayuda a medir la capacidad de respuesta de las personas revisoras y los posibles cuellos de botella.

Dónde obtenerlo

Se captura del flujo de eventos de la API de Pull Requests de GitHub o mediante webhooks. La acción del evento es 'review_requested'.

Recopilar

Escuche la acción 'review_requested' de una pull request.

Tipo de evento explicit
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de GitHub

¿Listo para comenzar?

Utilice esta plantilla para preparar sus datos y comenzar a optimizar su ciclo de vida de desarrollo de software. Descubra las ineficiencias y consiga entregas más rápidas y fluidas desde hoy.

Impulse su SDLC: localice las ineficiencias al instante

Reduzca el tiempo de ciclo un 30 % y agilice su proceso de desarrollo en GitHub.

Iniciar la prueba gratuita

No necesita tarjeta de crédito; la configuración tarda solo unos minutos.