Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

GitHub
Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

Esta plantilla proporciona una guía completa para recopilar y preparar sus datos del Ciclo de Vida de Desarrollo de Software de GitHub. Encontrará atributos recomendados para incluir, actividades esenciales a rastrear y orientación práctica para la extracción de datos. Utilice este recurso para construir un registro de eventos preciso para un análisis y optimización de procesos efectivos.
  • Atributos recomendados para recopilar
  • Actividades clave para el seguimiento
  • Guía de Extracción
¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Atributos del Ciclo de Vida de Desarrollo de Software

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis exhaustivo del Ciclo de Vida de Desarrollo de Software y el descubrimiento de procesos.
3 Requerido 5 Recomendado 16 Opcional
Nombre Descripción
Actividad
ActivityName
El nombre de un evento o tarea específica que ocurrió dentro del ciclo de vida de desarrollo de software.
Descripción

El Nombre de la Actividad describe un solo paso en el proceso de desarrollo, como 'Incidencia Creada', 'Código Subido a PR', 'Pull Request Aprobada' o 'Despliegue Exitoso'. Estos eventos forman la secuencia de pasos que constituyen el proceso de extremo a extremo para 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, frecuencia y duración de estas actividades revela el flujo de proceso real, identifica rutas comunes, destaca desviaciones y señala cuellos de botella.

Por qué es importante

Este atributo forma la columna vertebral del mapa de procesos, permitiendo la visualización y el análisis de la secuencia de eventos en el ciclo de vida de desarrollo.

Dónde obtener

Derivado del campo 'action' de los payloads de eventos de webhook (p. ej., 'opened', 'closed' para un issue) o del propio tipo de evento (p. ej., 'PushEvent', 'PullRequestReviewEvent').

Ejemplos
Incidencia CreadaPull Request abiertaCódigo Empujado a PRRevisión solicitadaPull Request fusionada
Elemento de Desarrollo
DevelopmentItemId
El identificador único para una sola unidad de trabajo de desarrollo, como una característica, corrección de errores o tarea. Esto sirve como el identificador principal del caso.
Descripción

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

En el análisis, este ID se utiliza para calcular el tiempo de ciclo de extremo a extremo de una tarea de desarrollo. Permite la reconstrucción de todo el recorrido de una característica o corrección de error, posibilitando un análisis detallado de cuellos de botella, bucles de retrabajo y variaciones de proceso para elementos de trabajo individuales.

Por qué es importante

Es la clave esencial para el process mining, conectando todos los eventos de desarrollo relacionados en un solo caso para visualizar y analizar con precisión el ciclo de vida completo de desarrollo de software.

Dónde obtener

Este es típicamente el Número de Incidencia o Número de Pull Request de GitHub. Se puede extraer del campo 'number' en la carga útil de los eventos de webhook relacionados con incidencias o pull requests o las respuestas de la API.

Ejemplos
101PR-2345TASK-812
Hora de Inicio
EventTimestamp
La fecha y hora exactas en que ocurrió una actividad o evento de desarrollo específico.
Descripción

Esta marca de tiempo marca el inicio de una actividad. Es crucial para ordenar los eventos cronológicamente y reconstruir el flujo del proceso para cada elemento de desarrollo. La secuencia y la diferencia de tiempo entre estas marcas de tiempo 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, incluyendo tiempos de ciclo, tiempos de procesamiento y tiempos de espera. Permite la identificación de retrasos entre pasos y proporciona los datos necesarios para el análisis de cuellos de botella y los dashboards de monitoreo de rendimiento.

Por qué es importante

Esta marca de tiempo es crítica para ordenar los eventos correctamente y calcular todas las métricas de rendimiento, como tiempos de ciclo y duraciones de cuellos de botella.

Dónde obtener

Típicamente se encuentra como campos 'created_at' o 'updated_at' en las cargas útiles JSON de las APIs y webhooks de GitHub para varios 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 evento de desarrollo específico.
Descripción

La marca de tiempo final marca la finalización de una actividad. Aunque muchos eventos en GitHub son instantáneos (por ejemplo, 'Issue Created'), algunas actividades tienen una duración medible (por ejemplo, una verificación de CI en ejecución). La diferencia entre el tiempo final y el tiempo inicial produce el tiempo de procesamiento de una actividad.

Este atributo se utiliza para calcular la métrica 'ProcessingTime', que es vital para comprender cuánto esfuerzo activo se dedica a diferentes tareas, como revisiones de código o verificaciones automatizadas. El análisis de los tiempos de procesamiento ayuda a identificar actividades ineficientes que consumen demasiado tiempo.

Por qué es importante

Permite el cálculo de tiempos de procesamiento precisos para las actividades, ayudando a distinguir entre el tiempo de trabajo activo y el tiempo de espera ocioso.

Dónde obtener

Se puede encontrar como 'completed_at' en objetos de ejecución de verificación o derivarse de la marca de tiempo de un evento subsiguiente que concluye lógicamente.

Ejemplos
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Prioridad
Priority
El nivel de prioridad asignado a un elemento de desarrollo, como 'Alta', 'Media' o 'Baja'.
Descripción

La prioridad indica la urgencia o importancia comercial de un elemento de trabajo. En GitHub, la prioridad no es un campo nativo y generalmente se gestiona mediante etiquetas (por ejemplo, 'P1-High', 'P2-Medium'). Se requiere un esquema de etiquetado coherente para extraer esta información de manera fiable.

Este atributo es esencial para el 'Análisis de flujo basado en prioridad'. Permite a los analistas verificar si los elementos de alta prioridad se procesan realmente más rápido que los de baja prioridad y medir la varianza del tiempo de ciclo en función de la prioridad. 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 baja prioridad, validando la efectividad de la estrategia de priorización.

Dónde obtener

Derivado de las etiquetas de GitHub aplicadas a issues o pull requests. Requiere una convención estandarizada para las etiquetas de prioridad.

Ejemplos
AltoMedioBajoCrítico
Repositorio
RepositoryName
El nombre del repositorio de código donde se está llevando a cabo la actividad de desarrollo.
Descripción

El repositorio actúa como un identificador de proyecto o producto, conteniendo todo el código, incidencias y pull requests para una aplicación o componente específico. Proporciona una forma de segmentar y comparar los procesos de desarrollo entre diferentes productos o equipos.

En el análisis, este atributo permite filtrar y comparar el rendimiento del proceso entre diferentes 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 en el Proyecto A con el Proyecto B?'. Es esencial para el dashboard 'Rendimiento por proyecto y tipo'.

Por qué es importante

Permite la segmentación y comparación de procesos de desarrollo entre diferentes proyectos, productos o equipos, posibilitando un análisis más focalizado.

Dónde obtener

Disponible en el objeto 'repository' en casi todos los payloads de webhooks y API de GitHub. El campo específico es típicamente '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 una característica, error, tarea o épica.
Descripción

Este atributo categoriza la naturaleza del trabajo que se está realizando. Esta información se gestiona típicamente a través de etiquetas o plantillas de incidencias específicas dentro de GitHub. Comprender el tipo de trabajo es crucial para establecer expectativas de rendimiento adecuadas, ya que una corrección de errores podría tener un tiempo de ciclo esperado mucho más corto que una nueva característica.

Este atributo permite el análisis comparativo entre diferentes tipos de trabajo. Ayuda a analizar si las correcciones de errores se procesan más rápido que las nuevas características, o a comprender la asignación de recursos para la deuda técnica frente al nuevo desarrollo. Es una dimensión clave en el dashboard 'Rendimiento por proyecto y tipo'.

Por qué es importante

Categoriza los elementos de trabajo, permitiendo comparaciones de rendimiento y el análisis de cómo diferentes tipos de trabajo (p. ej., errores vs. características) fluyen a través del proceso.

Dónde obtener

Típicamente derivado de las etiquetas de GitHub aplicadas a incidencias o pull requests. Requiere una convención de etiquetado coherente (por ejemplo, 'type:bug', 'type:feature').

Ejemplos
`Bug`CaracterísticaTaskDeuda técnica
Usuario Asignado
Assignee
El usuario o desarrollador asignado para manejar el elemento de desarrollo o una tarea específica, como una revisión de pull request.
Descripción

Este atributo identifica al individuo responsable del trabajo en una etapa determinada. Podría ser el asignado de una incidencia, el autor de una pull request o el revisor solicitado para una revisión de código. El seguimiento del asignado es clave para comprender la asignación de recursos y la carga de trabajo.

Este atributo se utiliza en el análisis para monitorear la carga de trabajo del desarrollador, identificar cuellos de botella de recursos y analizar la eficiencia de las transferencias entre diferentes miembros del equipo. Los dashboards se pueden filtrar por asignado para evaluar el rendimiento individual o del equipo y asegurar una distribución equilibrada del trabajo.

Por qué es importante

Crucial para analizar la carga de trabajo del desarrollador, el rendimiento del equipo y la eficiencia de las transferencias entre diferentes miembros del equipo.

Dónde obtener

Disponible en el objeto 'assignee' o 'user' dentro de los payloads JSON para issues, pull requests y eventos de revisión de la API de GitHub.

Ejemplos
john.doejane.smithdev-team-lead
¿Es Retrabajo?
IsRework
Una bandera booleana que es verdadera si una actividad representa una regresión a una etapa de proceso anterior.
Descripción

Esta bandera se establece en verdadero cuando un elemento de desarrollo retrocede en el proceso, por ejemplo, cuando una pull request recibe una revisión de 'Changes Requested', o cuando una incidencia se reabre después de haber sido cerrada. Se deriva analizando la secuencia de actividades.

Este atributo es esencial para cuantificar el desperdicio y la ineficiencia. Apoya directamente el dashboard de 'Bucles de Retrabajo y Regresión' y el KPI de 'Tasa de Retrabajo'. Al filtrar por 'IsRework = true', los analistas pueden aislar e investigar las causas del retrabajo.

Por qué es importante

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

Dónde obtener

Este es un atributo derivado. La lógica implica definir un flujo de proceso estándar y luego marcar cualquier actividad que se desvíe al regresar a una etapa lógica anterior.

Ejemplos
truefalse
Autor
Author
El usuario que creó la incidencia, pull request o commit.
Descripción

El autor es el originador de un artefacto específico en el proceso de desarrollo. Por ejemplo, el autor de una incidencia es la persona que informó el error o solicitó la característica. El autor de una pull request es el desarrollador que escribió el código.

En el análisis, el autor puede utilizarse para comprender las fuentes de trabajo. Por ejemplo, analizar los autores de los informes de errores podría revelar patrones relacionados con equipos o características específicas. También puede utilizarse junto con el asignado para analizar patrones de transferencia.

Por qué es importante

Identifica al originador de un elemento de trabajo o cambio de código, lo cual puede ser útil para analizar las fuentes de retrabajo, informes de errores o solicitudes de características.

Dónde obtener

Disponible en el objeto 'user' dentro del objeto principal de las respuestas de la API para issues, pull requests y commits. El campo es típicamente 'user.login'.

Ejemplos
sara.jonesmike.leeautomation-bot
Entorno de Despliegue
DeploymentEnvironment
El entorno objetivo para un despliegue, como 'Staging' o 'Producción'.
Descripción

Este atributo especifica dónde se está desplegando el código. El seguimiento de los despliegues a diferentes entornos es clave para comprender el ciclo de vida completo, desde el desarrollo hasta el lanzamiento a producción.

Este atributo permite analizar el subproceso de despliegue. Se puede utilizar para medir el tiempo que lleva promover el código de staging a producción y para rastrear la tasa de éxito de los despliegues a diferentes entornos. Es esencial para saber cuándo un elemento de desarrollo está verdaderamente 'terminado' y entregado a los usuarios.

Por qué es importante

Distingue entre lanzamientos de preproducción y producción, lo cual es crítico para medir el verdadero 'time-to-market' y analizar los patrones de despliegue.

Dónde obtener

Esta información se obtiene de la API de despliegues de GitHub, que a menudo se activa por pipelines de CI/CD u otra automatización.

Ejemplos
developmentstagingproducción
Estado de revisión
ReviewState
El resultado de una revisión de código en una pull request, como 'Approved' o 'Changes Requested'.
Descripción

Este atributo captura la decisión tomada por un revisor. Los estados comunes incluyen 'APPROVED', que indica que el código está listo para fusionarse, y 'CHANGES_REQUESTED', que indica que se requiere retrabajo. Otros estados pueden incluir 'COMMENTED' o 'PENDING'.

Este es un atributo crítico para analizar el retrabajo y la calidad. Una alta frecuencia de eventos 'CHANGES_REQUESTED' puede indicar problemas con la calidad inicial del código o requisitos poco claros. Apoya directamente el dashboard de 'Bucles de Retrabajo y Regresión' al identificar cuándo un elemento de desarrollo es enviado de vuelta para modificación.

Por qué es importante

Indica directamente los bucles de retrabajo y las puertas de calidad dentro del proceso de revisión de código, ayudando a identificar las fuentes de ineficiencia y los problemas de calidad.

Dónde obtener

Disponible como el campo 'state' dentro de un objeto de revisión de pull request de la API de GitHub. Por ejemplo, en un payload 'PullRequestReviewEvent'.

Ejemplos
APROBADOCHANGES_REQUESTEDCOMMENTED
Estado de Verificación de CI
CiCheckStatus
El estado de una verificación de Integración Continua (CI) automatizada, como 'passed' o 'failed'.
Descripción

Este atributo refleja el resultado de las compilaciones, pruebas y escaneos automatizados que se ejecutan contra los cambios de código en una pull request. Las verificaciones de CI son un punto de control de calidad crítico en los flujos de trabajo de desarrollo modernos.

Analizar este atributo ayuda a comprender la eficacia de las pruebas automatizadas. Una alta tasa de fallos podría indicar problemas con la estabilidad del código, la suite de pruebas o el entorno de desarrollo. Soporta las actividades 'CI Checks Passed' y 'CI Checks Failed' y ayuda a analizar los retrasos causados por compilaciones rotas.

Por qué es importante

Indica el éxito o fracaso de las puertas de calidad automatizadas, proporcionando información sobre la calidad del código y la efectividad del pipeline de CI.

Dónde obtener

Obtenido del campo 'state' o 'conclusion' de los objetos de ejecución de verificación o estado a través de la API de GitHub Checks o Statuses.

Ejemplos
éxitofailurependienteerror
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 de alto nivel de un elemento de desarrollo. Para las incidencias, los estados típicos son 'open' y 'closed'. Para las pull requests, 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 identificar el trabajo activo frente al completado. Es esencial para dashboards como 'Progreso de desarrollo activo' que monitorean el trabajo en curso. También se utiliza para definir el final de un proceso, por ejemplo, un estado de 'merged' o 'closed' podría significar la finalización de un caso.

Por qué es importante

Proporciona una indicación clara de si un elemento de trabajo está actualmente en curso o completado, lo cual es fundamental para el análisis del ciclo de vida y el monitoreo del trabajo activo.

Dónde obtener

Directamente disponible como el campo 'state' en los payloads JSON para issues y pull requests de la API de GitHub.

Ejemplos
abiertocerradofusionado
Etiquetas
Labels
Una lista de etiquetas o rótulos aplicados a un issue o pull request para su categorización.
Descripción

Las etiquetas en GitHub son una forma flexible de añadir metadatos a los issues y pull requests. Pueden utilizarse para indicar prioridad, tipo de trabajo, componentes, equipos o estado. La lista bruta de etiquetas proporciona un contexto rico y no estructurado.

Aunque atributos específicos como Prioridad y Tipo se derivan de las etiquetas, mantener la lista completa puede ser útil para análisis ad-hoc y para descubrir otros patrones de proceso. Permite un filtrado y segmentación flexibles de los casos basados en cualquier combinación de etiquetas.

Por qué es importante

Proporciona una fuente de metadatos flexible y rica para categorizar elementos de trabajo, permitiendo un análisis dimensional profundo y variado.

Dónde obtener

Disponible como el array 'labels' en el payload JSON para issues y pull requests de la API de GitHub. Cada elemento del array es un objeto con un campo 'name'.

Ejemplos
bug, ui, alta prioridadfeature, backend, necesita-documentacióntech-debt, refactor
Hash de Commit
CommitHash
El identificador único (SHA) para un commit de código específico.
Descripción

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

Aunque es altamente granular, el hash de commit proporciona el nivel máximo de trazabilidad. Permite a los analistas vincular un evento de proceso directamente al cambio de código exacto que se realizó. Esto puede ser invaluable para auditorías, cumplimiento o un análisis detallado de la causa raíz de incidentes en producción.

Por qué es importante

Proporciona el enlace más granular entre un paso del proceso y el cambio de código exacto, permitiendo una trazabilidad completa para auditorías y depuración.

Dónde obtener

Disponible en los payloads de eventos push ('head_commit.id') o a través de la API de Commits para un pull request o rama.

Ejemplos
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nombre de la Rama
BranchName
El nombre de la rama de Git donde se realizaron los cambios de código para el elemento de desarrollo.
Descripción

Una rama es una línea de desarrollo independiente, creada para trabajar en una nueva característica o corrección de error sin afectar el código base principal. El nombre de la rama a menudo contiene información útil, como el número de issue o una breve descripción del trabajo.

Analizar los nombres de las ramas puede ayudar a comprender las estrategias de ramificación y la adherencia a las convenciones de desarrollo. También ayuda a vincular commits de código específicos a un elemento de desarrollo, proporcionando una imagen completa de la actividad de codificación.

Por qué es importante

Proporciona contexto sobre la línea específica de desarrollo y ayuda a aplicar y analizar estrategias de ramificación y convenciones de nomenclatura.

Dónde obtener

Disponible en el campo 'ref' para eventos push, o en los objetos 'head' y 'base' dentro de una respuesta de la API de pull request.

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

Un pull request (PR) es una propuesta para fusionar un conjunto de cambios de código en una rama específica. El número de Pull Request vincula las actividades de desarrollo, como los pushes de código y las revisiones, al elemento de desarrollo o issue principal.

Este ID es crucial para rastrear el subproceso de integración y revisión de código dentro del ciclo de vida de desarrollo más amplio. Permite un análisis detallado del proceso de revisión de código, incluyendo 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 (issue) con la fase de implementación (PR).

Por qué es importante

Vincula los issues a los cambios de código específicos y a los procesos de revisión, permitiendo un análisis detallado del ciclo de revisión de código y su impacto en el tiempo total de entrega.

Dónde obtener

Disponible como el campo 'number' dentro del objeto 'pull_request' en muchas respuestas de la API de GitHub, o como el identificador principal de la API de Pull Requests.

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

Un revisor es un desarrollador o miembro del equipo asignado para inspeccionar los cambios de código en un pull request en cuanto a calidad, corrección y adherencia a los estándares. Un pull request puede tener múltiples revisores.

Este atributo es esencial para analizar el proceso de revisión de código. Ayuda a identificar cuellos de botella relacionados con revisores específicos, comprender la distribución de 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 de 'Tiempo de Ciclo Promedio de Revisión de Código'.

Por qué es importante

Identifica a los individuos involucrados en el proceso de aseguramiento de calidad, permitiendo el análisis de las cargas de trabajo de revisión, los retrasos y la eficiencia general de las revisiones de código.

Dónde obtener

Disponible en el array 'requested_reviewers' o el objeto 'user' de un evento de revisión de pull request de la API de GitHub.

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

Este atributo identifica el origen de los datos del evento. Para este proceso, el valor sería consistentemente 'GitHub'. En un entorno más complejo donde las actividades de desarrollo abarcan múltiples sistemas (por ejemplo, Jira para planificación, GitHub para código, Jenkins para despliegue), este campo se utiliza para distinguir la fuente de cada evento.

En el análisis, ayuda a rastrear los datos hasta su origen para su validación y resolución de problemas. También permite analizar procesos que cruzan diferentes plataformas, proporcionando un contexto claro para cada actividad.

Por qué es importante

Identifica el origen de los datos, lo cual es esencial para la validación de datos y para analizar procesos que pueden abarcar múltiples sistemas integrados.

Dónde obtener

Este es típicamente un valor estático añadido durante el proceso de extracción, transformación y carga de datos (ETL) para etiquetar la fuente 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

Esta es una métrica a nivel de caso calculada como la diferencia de tiempo entre el primer evento (por ejemplo, 'Issue Created') y el evento final (por ejemplo, 'Deployment Succeeded' o 'Issue Closed') para un solo elemento de desarrollo.

Este es uno de los KPI más importantes para medir la eficiencia general del proceso de desarrollo. Apoya directamente el dashboard 'Tiempo de ciclo de desarrollo general' y el KPI 'Tiempo de ciclo de desarrollo promedio'. Reducir esta métrica es a menudo un objetivo principal de las iniciativas de mejora de procesos.

Por qué es importante

Representa el 'time-to-market' de extremo a extremo para un elemento de desarrollo, convirtiéndolo en un KPI crítico para medir la velocidad y eficiencia general del proceso.

Dónde obtener

Calculado 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 de Transferencia
HandoffWaitingTime
El tiempo de inactividad calculado que un elemento de desarrollo pasa esperando entre actividades realizadas por diferentes personas.
Descripción

Esta métrica mide el tiempo entre la finalización de una actividad y el inicio de la siguiente, pero solo cuando la persona responsable cambia. Por ejemplo, el tiempo entre un evento de 'Revisión Solicitada' y un evento de 'Cambios Solicitados en Revisión' por un usuario diferente.

Esta es una métrica crítica para identificar brechas de comunicación y problemas de coordinación. Apoya el dashboard de 'Eficiencia de Transferencia Crítica' y el KPI 'Tiempo Promedio de Espera en Transferencia'. Los altos tiempos de espera en los puntos de transferencia suelen ser un signo de limitaciones de recursos o procesos de notificación ineficientes.

Por qué es importante

Identifica los retrasos causados por una mala coordinación o la falta de disponibilidad de recursos durante las transferencias entre diferentes equipos o roles, que a menudo son las principales fuentes de ineficiencia.

Dónde obtener

Calculado identificando actividades secuenciales donde el atributo 'Assignee' o 'User' cambia, y luego midiendo el lapso de tiempo entre ellas.

Ejemplos
PT1H15MP2DT4HPT25M
Tiempo de Procesamiento
ProcessingTime
La duración calculada de una actividad, que representa el tiempo de trabajo activo.
Descripción

El tiempo de procesamiento es el tiempo transcurrido entre el inicio y el final de una actividad. Se calcula como 'EndTimestamp' menos 'EventTimestamp'. Esta métrica mide cuánto tiempo se tarda en completar una tarea, excluyendo cualquier tiempo de espera para que la tarea comience.

Analizar el tiempo de procesamiento ayuda a identificar qué actividades son las que consumen más tiempo en términos de esfuerzo activo. Esto es diferente del tiempo de ciclo, que incluye el tiempo de espera. Por ejemplo, una revisión de código podría tener un tiempo de ciclo largo pero un tiempo de procesamiento corto, lo que indica que el revisor está ocupado y la PR está esperando en una cola.

Por qué es importante

Mide la duración del trabajo activo, ayudando a distinguir entre el tiempo dedicado a una tarea y el tiempo de espera, lo cual es clave para mejoras específicas de eficiencia.

Dónde obtener

Calculado restando el 'EventTimestamp' del 'EndTimestamp' para un solo registro de actividad.

Ejemplos
PT5M15SPT2H30MP1DT12H
Última actualización de datos
LastDataUpdate
El timestamp 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 frescura de los datos que se están analizando. Esto es distinto de la marca de tiempo del evento, que registra cuándo ocurrió el evento de negocio.

En el análisis, este campo es crucial para comprender la puntualidad de la vista del proceso. Ayuda a los usuarios a saber si están viendo datos en tiempo real o una instantánea de un momento específico, lo cual es importante para los dashboards operativos y el monitoreo.

Por qué es importante

Indica la frescura de los datos, lo cual es crítico para garantizar que los análisis y los dashboards se basen en información actualizada.

Dónde obtener

Este timestamp se genera y se 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
Requerido Recomendado Opcional

Actividades del Ciclo de Vida de Desarrollo de Software

Estos son los pasos clave del proceso y los hitos a registrar en tu registro de eventos para un descubrimiento preciso del proceso y la identificación de cuellos de botella.
6 Recomendado 7 Opcional
Actividad Descripción
Incidencia Cerrada
El elemento de desarrollo se considera completo y la incidencia correspondiente se cierra formalmente. Esto puede ocurrir automáticamente cuando se fusiona una pull request vinculada o ser realizado manualmente por un miembro del equipo.
Por qué es importante

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

Dónde obtener

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

Capturar

Escuche el evento 'closed' en una incidencia a través de webhooks o sondeo de API.

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

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

Dónde obtener

Este es un evento explícito capturado del flujo de eventos de la API de incidencias de GitHub. El tipo de evento es típicamente 'opened' para un número de incidencia dado.

Capturar

Escuche el evento 'opened' en una incidencia a través de webhooks o sondeo de API.

Tipo de evento explicit
Pull Request abierta
Significa que un bloque inicial de código está listo para revisión e integración. Un desarrollador crea una pull request (PR) para proponer cambios desde su rama de característica a una rama principal. Este es un evento explícito en GitHub.
Por qué es importante

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

Dónde obtener

Capturado del flujo de eventos de la API de Pull Request de GitHub o webhooks. La acción del evento es 'opened'.

Capturar

Escuche la acción 'opened' para una pull request a través de webhooks o sondeo de API.

Tipo de evento explicit
Pull Request aprobada
Un revisor ha aprobado formalmente los cambios en un pull request, indicando que cumple con los estándares de calidad y funcionales. Esto se captura cuando un revisor envía su revisión con un estado de 'approve'.
Por qué es importante

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

Dónde obtener

Capturado de la API de Pull Request de GitHub o webhooks cuando se envía una revisión con el estado 'APPROVED'.

Capturar

Filtre los eventos de envío de revisión de pull request para 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. Esta es una acción explícita y final en una pull request que incorpora el nuevo código.
Por qué es importante

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

Dónde obtener

Capturado del flujo de eventos de la API de Pull Request de GitHub o webhooks. La acción del evento es 'closed' y el atributo 'merged' del payload del pull request es verdadero.

Capturar

Escuche la acción 'closed' en una pull request y verifique si el indicador 'merged' es verdadero.

Tipo de evento explicit
Verificaciones de CI Pasadas
Representa la finalización exitosa de las verificaciones automatizadas, como compilaciones, pruebas unitarias o análisis estático, ejecutadas sobre el código en una pull request. Este evento se infiere del estado de las verificaciones reportado por sistemas como GitHub Actions.
Por qué es importante

Este punto de control de calidad automatizado es crucial para garantizar la estabilidad del código. Los fallos o los largos tiempos de ejecución pueden ser cuellos de botella significativos en el pipeline de entrega.

Dónde obtener

Inferido de la API de Checks de GitHub o la API de Statuses. Una ejecución de verificación o actualización de estado reporta un 'success' o 'completed' con una conclusión de 'success'.

Capturar

Monitorice la API de Checks para una conclusión de 'success' en las suites de verificación relevantes.

Tipo de evento inferred
Cambios Solicitados en Revisión
Un revisor ha completado su revisión de código y ha determinado que son necesarias modificaciones antes de que el pull request pueda ser aprobado. El revisor envía formalmente su revisión con un estado de 'request_changes'.
Por qué es importante

Este evento señala explícitamente un bucle de retrabajo. El análisis de su frecuencia ayuda a identificar problemas de calidad, requisitos poco claros o áreas para la capacitación de desarrolladores.

Dónde obtener

Capturado de la API de Pull Request de GitHub o webhooks cuando se envía una revisión con el estado 'CHANGES_REQUESTED'.

Capturar

Filtre los eventos de envío de revisión de pull request para el estado 'CHANGES_REQUESTED'.

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

El seguimiento de estos eventos es crucial para identificar bucles de retrabajo. Múltiples pushes después de una revisión indican que se requirieron cambios, afectando el tiempo de ciclo general.

Dónde obtener

Este es un evento explícito en la línea de tiempo de la pull request, a menudo etiquetado como un commit añadido. Se puede capturar del webhook 'push' o monitoreando los commits asociados con una PR.

Capturar

Rastree los eventos 'push' en una rama asociada con una pull request abierta.

Tipo de evento explicit
Despliegue Exitoso
Los cambios de código se han desplegado con éxito en un entorno específico, como staging o producción. Este evento se captura típicamente a través de la API de despliegues de GitHub, a menudo activado por una GitHub Action después de una fusión.
Por qué es importante

Marca la transición del código del repositorio a un entorno en vivo. El seguimiento de esto es esencial para medir el tiempo de entrega completo, desde la idea hasta la producción.

Dónde obtener

Capturado a través de la API de Deployments. Un servicio externo o GitHub Action crea un despliegue y luego actualiza su estado a 'success'.

Capturar

Monitorice los eventos de estado de despliegue a través de webhooks para un estado de 'success'.

Tipo de evento inferred
Issue Reabierto
Un issue previamente cerrado se reactiva, típicamente porque la solución fue insuficiente o se encontró una regresión. Este es un evento explícito que reinicia el ciclo de vida del elemento de desarrollo.
Por qué es importante

Esto señala un bucle de retrabajo significativo, indicando una potencial 'fuga de defectos en producción' o una corrección incompleta. El seguimiento de su frecuencia es una medida clave de la calidad general del software.

Dónde obtener

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

Capturar

Escuche el evento 'reopened' en una incidencia a través de webhooks o sondeo de API.

Tipo de evento explicit
Rama Creada
Representa el inicio del trabajo de desarrollo activo para una incidencia, donde un desarrollador crea una nueva rama desde la base de código principal. Este es un evento explícito capturado cuando se sube una nueva rama al repositorio, a menudo conteniendo el número de incidencia en su nombre.
Por qué es importante

Indica la transición de la planificación a la codificación activa. Medir el tiempo entre la creación del issue y este evento ayuda a analizar el tiempo de inicio del desarrollador y los retrasos iniciales del backlog.

Dónde obtener

Capturado a través de la API Git de GitHub o webhooks que escuchan eventos 'create' de tipo 'branch'. A menudo es necesario vincular el nombre de la rama a un issue mediante convenciones de nomenclatura, como 'feature/issue-123'.

Capturar

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

Tipo de evento explicit
Revisión solicitada
El autor de una pull request solicita formalmente a miembros o equipos específicos que revisen su código. Esta es una acción explícita dentro de la interfaz de usuario o la API de GitHub que activa notificaciones a los revisores solicitados.
Por qué es importante

Esta actividad marca el inicio oficial de la transferencia al proceso de revisión de código. El tiempo entre esto y el envío de una revisión ayuda a medir la capacidad de respuesta del revisor y los posibles cuellos de botella.

Dónde obtener

Capturado del flujo de eventos de la API de Pull Request de GitHub o webhooks. La acción del evento es 'review_requested'.

Capturar

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

Tipo de evento explicit
Verificaciones de CI Fallidas
Representa el fallo de una verificación automatizada, como un error de compilación o una prueba unitaria fallida, ejecutada sobre el código en una pull request. Esto se infiere de un estado de fallo reportado por un sistema como GitHub Actions.
Por qué es importante

Esta actividad destaca problemas de calidad técnica que requieren la intervención del desarrollador, creando un bucle de retrabajo. El análisis de la frecuencia de fallos puede orientar mejoras en las pruebas locales o la calidad del código.

Dónde obtener

Inferido de la API de Checks de GitHub o la API de Statuses. Una ejecución de verificación o actualización de estado reporta un 'failure' o 'completed' con una conclusión de 'failure'.

Capturar

Monitorice la API de Checks para una conclusión de 'failure' en las suites de verificación relevantes.

Tipo de evento inferred
Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de GitHub