Su Template de datos para el ciclo de vida del desarrollo de software
Su Template de datos para el ciclo de vida del desarrollo de software
- Atributos recomendados para recopilar
- Actividades clave que conviene registrar
- Pautas para la extracción
Atributos del ciclo de vida del desarrollo de software
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
ActivityName
|
Nombre de un evento o una tarea concretos que tuvieron lugar durante el ciclo de vida del desarrollo de software. | ||
|
Descripción
El nombre de la actividad describe un paso del proceso de desarrollo, como 'Incidencia creada', 'Código enviado a la solicitud de incorporación', 'Solicitud de incorporación aprobada' o 'Implementación exitosa'. Estos eventos forman la secuencia de pasos del proceso completo de un elemento de desarrollo. Este atributo es fundamental para Process Mining, ya que se utiliza para construir el mapa del proceso. Analizar la secuencia, la frecuencia y la duración de estas actividades permite conocer el flujo real del proceso, identificar las rutas habituales, detectar desviaciones y localizar cuellos de botella.
Por qué es importante
Este atributo constituye la base del mapa del proceso 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 (por ejemplo, 'PushEvent' o 'PullRequestReviewEvent').
Ejemplos
Incidencia creadaSolicitud de incorporación abiertaCódigo enviado a la solicitud de incorporaciónRevisión solicitadaSolicitud de incorporación fusionada
|
|||
|
Elemento de desarrollo
DevelopmentItemId
|
Identificador único de una unidad de trabajo de desarrollo, como una función, una corrección de errores o una tarea. Se utiliza como identificador principal del caso. | ||
|
Descripción
El ID del elemento de desarrollo permite seguir un elemento de trabajo desde su creación hasta la implementación final. Vincula todas las actividades relacionadas, como la creación de ramas, las confirmaciones, las solicitudes de incorporación, las revisiones y las implementaciones, en una única instancia de proceso coherente. En el análisis, este ID se utiliza para calcular el tiempo de ciclo de principio a fin de una tarea de desarrollo. Permite reconstruir todo el recorrido de una función o una corrección de errores y analizar en detalle los cuellos de botella, los ciclos de retrabajo y las variaciones del proceso de cada elemento de trabajo.
Por qué es importante
Es la clave esencial para Process Mining: conecta todos los eventos de desarrollo relacionados en un único caso y permite visualizar y analizar con precisión el ciclo de vida del desarrollo de software de principio a fin.
Dónde obtenerlo
Suele ser el número de incidencia o de solicitud de incorporación de GitHub. Puede extraerse del campo 'number' de la carga útil de los eventos webhook o de las respuestas de la API relacionados con incidencias o solicitudes de incorporación.
Ejemplos
101PR-2345TASK-812
|
|||
|
Hora de inicio
EventTimestamp
|
Fecha y hora exactas en que tuvo lugar una actividad o un evento de desarrollo concretos. | ||
|
Descripción
Esta marca de tiempo señala el inicio 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 las diferencias de tiempo entre estas marcas permiten 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 demoras entre pasos y aporta los datos necesarios para el análisis de cuellos de botella y los Dashboards de supervisión del rendimiento.
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
Suele encontrarse 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, solicitudes de incorporación y confirmaciones.
Ejemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Hora de finalización
EndTimestamp
|
Fecha y hora exactas en que se completó una actividad o un evento de desarrollo concretos. | ||
|
Descripción
La marca de tiempo de finalización señala cuándo termina una actividad. Aunque muchos eventos de GitHub son instantáneos (por ejemplo, 'Incidencia creada'), algunas actividades tienen una duración medible (por ejemplo, la ejecución de una comprobación de CI). La diferencia entre la hora de finalización y la hora de inicio indica el tiempo de procesamiento de una actividad. Este atributo se utiliza para calcular la métrica 'ProcessingTime', esencial para comprender cuánto tiempo de trabajo activo se dedica a 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 con precisión los tiempos de procesamiento de las actividades y distinguir el tiempo de trabajo activo del tiempo de espera.
Dónde obtenerlo
Puede encontrarse como 'completed_at' en los objetos de ejecución de comprobaciones o deducirse de la marca de tiempo de un evento posterior que cierre lógicamente la actividad.
Ejemplos
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Prioridad
Priority
|
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, no es un campo nativo y suele gestionarse mediante etiquetas (por ejemplo, 'P1-Alta', 'P2-Media'). Para extraer esta información de forma fiable, se necesita un sistema de etiquetado coherente. Este atributo es esencial para el 'Análisis del flujo según la prioridad'. 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 comprobar la eficacia de la estrategia de priorización.
Dónde obtenerlo
Se obtiene de las etiquetas de GitHub aplicadas a incidencias o solicitudes de incorporación de cambios. Se necesita una convención estandarizada para las etiquetas de prioridad.
Ejemplos
AltaMediaBajaCrítico
|
|||
|
Repositorio
RepositoryName
|
Nombre del repositorio de código donde tiene lugar la actividad de desarrollo. | ||
|
Descripción
El repositorio funciona como identificador de un proyecto o producto y contiene todo el código, las incidencias y las solicitudes de incorporación de una aplicación o un componente concretos. Permite segmentar y comparar los procesos de desarrollo de distintos productos o equipos. En el análisis, este atributo permite filtrar y comparar el rendimiento de los procesos de 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 Dashboard «Rendimiento por proyecto y tipo».
Por qué es importante
Permite segmentar y comparar los procesos de desarrollo de distintos proyectos, productos o equipos, y facilita un análisis más específico.
Dónde obtenerlo
Está disponible en el objeto 'repository' de casi todas las cargas útiles de webhooks y API de GitHub. El campo concreto 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
|
Clasificación del elemento de trabajo de desarrollo, como una función, un error, una tarea o una épica. | ||
|
Descripción
Este atributo clasifica la naturaleza del trabajo. Por lo general, 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 el tiempo de ciclo previsto para corregir un error puede ser mucho menor que el de desarrollar una función nueva. Este atributo permite comparar distintos tipos de trabajo. Ayuda a analizar si las correcciones de errores se procesan más rápido que las funciones nuevas y a comprender cómo se asignan los recursos entre la deuda técnica y el nuevo desarrollo. Es una dimensión clave del Dashboard «Rendimiento por proyecto y tipo».
Por qué es importante
Clasifica los elementos de trabajo y permite comparar el rendimiento y analizar cómo avanzan por el proceso distintos tipos de trabajo, como los errores y las funciones.
Dónde obtenerlo
Suele obtenerse de las etiquetas aplicadas a incidencias o solicitudes de incorporación en GitHub. Requiere una convención de etiquetado coherente, como 'type:bug' o 'type:feature'.
Ejemplos
ErrorFunciónTareaDeuda técnica
|
|||
|
Usuario asignado
Assignee
|
Usuario o persona desarrolladora asignada para gestionar el elemento de desarrollo o una tarea concreta, como la revisión de una solicitud de incorporación. | ||
|
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 de una solicitud de incorporación o la persona revisora solicitada para una revisión de código. Registrar las asignaciones es clave para comprender la distribución de recursos y la carga de trabajo. Este atributo permite supervisar la carga de trabajo del equipo de desarrollo, identificar cuellos de botella relacionados con los recursos y analizar la eficiencia de los traspasos entre integrantes del equipo. Los Dashboards se pueden filtrar 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 del equipo de desarrollo, 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, solicitudes de incorporación y eventos de revisión de la API de GitHub.
Ejemplos
john.doejane.smithdev-team-lead
|
|||
|
Autor
Author
|
Usuario que creó la incidencia, la solicitud de incorporación de cambios o el commit. | ||
|
Descripción
El autor es quien 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 solicitud de incorporación de cambios es quien escribió el código. En el análisis, el autor permite conocer de dónde procede el trabajo. Por ejemplo, analizar quién informa de los errores puede revelar patrones relacionados con determinados equipos o funcionalidades. También se puede combinar con la persona asignada para analizar los patrones de traspaso.
Por qué es importante
Identifica a quien originó un elemento de trabajo o un cambio de código. Puede ser útil para analizar las fuentes de 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, solicitudes de incorporación de cambios y commits. El campo suele ser 'user.login'.
Ejemplos
sara.jonesmike.leeautomation-bot
|
|||
|
Entorno de implementación
DeploymentEnvironment
|
Entorno de destino de una implementación, como 'Staging' o 'Production'. | ||
|
Descripción
Este atributo especifica dónde se implementa el código. Hacer un seguimiento de las implementaciones en distintos entornos es clave para comprender todo el ciclo de vida, desde el desarrollo hasta la publicación en producción. Este atributo permite analizar el subproceso de implementación. Se puede utilizar para medir cuánto tarda el código en pasar de staging a producción y para hacer un seguimiento de la tasa de éxito de las implementaciones en distintos entornos. Es esencial para saber cuándo un elemento de desarrollo está realmente terminado y se ha entregado a los usuarios.
Por qué es importante
Distingue las publicaciones previas a producción de las de producción. Esto es fundamental para medir el verdadero tiempo de comercialización y analizar los patrones de implementación.
Dónde obtenerlo
Esta información se obtiene de la API de GitHub Deployments, que suelen activar los flujos de CI/CD u otros procesos automatizados.
Ejemplos
desarrollostagingproducción
|
|||
|
Es retrabajo
IsRework
|
Indicador booleano que es verdadero si una actividad representa un retroceso 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 revisión de una solicitud de incorporación de cambios recibe el estado 'Cambios solicitados' o cuando se vuelve a abrir una incidencia después de cerrarla. Se obtiene mediante el análisis de la secuencia de actividades. Este atributo es esencial para cuantificar el desperdicio y la ineficiencia. Contribuye directamente al Dashboard 'Ciclos de retrabajo y regresión' y al KPI '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, lo que facilita cuantificar, visualizar y analizar las causas de las ineficiencias del proceso.
Dónde obtenerlo
Este atributo se obtiene mediante cálculos. La lógica consiste en definir un flujo de proceso estándar y marcar las actividades que se desvían al volver a una etapa lógica anterior.
Ejemplos
truefalse
|
|||
|
Estado de la comprobación de CI
CiCheckStatus
|
Estado de una comprobación automatizada de integración continua (CI), como 'correcta' o 'fallida'. | ||
|
Descripción
Este atributo refleja el resultado de las compilaciones, pruebas y análisis automatizados que se ejecutan sobre los cambios de código de una solicitud de incorporación de cambios. 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. También respalda las actividades 'Comprobaciones de CI superadas' y 'Comprobaciones de CI fallidas', y permite analizar los retrasos causados por compilaciones fallidas.
Por qué es importante
Indica si se superan o fallan los controles de calidad automatizados y aporta 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 la API de GitHub Checks o Statuses.
Ejemplos
successfailurependingerror
|
|||
|
Estado de la revisión
ReviewState
|
Resultado de la revisión del código de una solicitud de incorporación de cambios, como 'Aprobado' o 'Cambios solicitados'. | ||
|
Descripción
Este atributo registra la decisión del revisor. Entre los estados habituales están 'APPROVED', que indica que el código está listo para integrarse, y 'CHANGES_REQUESTED', que indica que es necesario retrabajarlo. También puede haber otros estados, como 'COMMENTED' o 'PENDING'. Este atributo es fundamental 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. Además, permite identificar cuándo se devuelve un elemento de desarrollo para modificarlo y contribuye directamente al Dashboard 'Ciclos de retrabajo y regresión'.
Por qué es importante
Muestra 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 una solicitud de incorporación de cambios en la API de GitHub. Por ejemplo, en los datos de 'PullRequestReviewEvent'.
Ejemplos
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
Estado del elemento
State
|
Estado actual de una incidencia o solicitud de incorporación, como 'open', 'closed' o 'merged'. | ||
|
Descripción
Este atributo indica el estado general de un elemento de desarrollo. Las incidencias suelen tener los estados 'open' y 'closed'. Las solicitudes de incorporación pueden tener los estados 'open', 'closed' y 'merged'. Así se obtiene una instantánea del progreso del elemento. En el análisis, el estado permite distinguir el trabajo activo del completado. Es esencial para Dashboards como «Progreso del desarrollo activo», que supervisan el trabajo en curso. También se utiliza para definir el final de un proceso: por ejemplo, los estados 'merged' o 'closed' pueden indicar que un caso se ha completado.
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 útiles JSON de incidencias y solicitudes de incorporación de la API de GitHub.
Ejemplos
abiertacerradafusionada
|
|||
|
Etiquetas
Labels
|
Lista de etiquetas aplicadas a una incidencia o solicitud de incorporación de cambios para clasificarla. | ||
|
Descripción
Las etiquetas de GitHub ofrecen una forma flexible de añadir metadatos a las incidencias y solicitudes de incorporación de cambios. Pueden indicar la prioridad, el tipo de trabajo, los componentes, los equipos o el estado. La lista completa de etiquetas aporta un contexto amplio y no estructurado. Aunque atributos concretos, como la prioridad y el tipo, se obtienen de las etiquetas, conservar la lista completa puede resultar útil para análisis puntuales y para descubrir otros patrones del proceso. También permite filtrar y segmentar los casos de forma flexible según cualquier combinación de etiquetas.
Por qué es importante
Ofrece una fuente flexible y amplia de metadatos para clasificar los elementos de trabajo y permite realizar análisis dimensionales detallados y variados.
Dónde obtenerlo
Está disponible en el arreglo 'labels' de los datos JSON de incidencias y solicitudes de incorporación de cambios de la API de GitHub. Cada elemento del arreglo es un objeto con un campo 'name'.
Ejemplos
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Hash del commit
CommitHash
|
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. Funciona como un ID permanente de una versión concreta del código. Los commits son las unidades atómicas de cambio en el 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 que se realizó. Esto puede ser muy valioso para las auditorías, el cumplimiento o el análisis detallado de las causas raíz de incidentes en producción.
Por qué es importante
Vincula un paso del proceso con el cambio de código exacto con el máximo nivel de detalle y permite una trazabilidad completa para auditorías y depuración.
Dónde obtenerlo
Está disponible en los datos de los eventos push ('head_commit.id') o mediante la API de Commits para una solicitud de incorporación de cambios o una rama.
Ejemplos
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Nombre de la rama
BranchName
|
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 al código base principal. El nombre de la rama suele incluir información útil, como el número de la incidencia o una breve descripción del trabajo. Analizar los nombres de las ramas ayuda a comprender las estrategias de ramificación y el cumplimiento de las convenciones de desarrollo. También permite vincular commits de código concretos con un elemento de desarrollo y obtener 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 push, o en los objetos 'head' y 'base' de la respuesta de la API de una solicitud de incorporación de cambios.
Ejemplos
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Número de solicitud de incorporación de cambios
PullRequestNumber
|
Identificador único de una solicitud de incorporación de cambios asociada al elemento de desarrollo. | ||
|
Descripción
Una solicitud de incorporación de cambios (PR) propone integrar un conjunto de cambios de código en una rama concreta. El número de solicitud de incorporación de cambios vincula actividades de desarrollo, como las inserciones de código y las revisiones, con el elemento de desarrollo o la incidencia principal. Este ID es fundamental para hacer un seguimiento de la integración del código y del subproceso de revisión dentro del ciclo de vida general del desarrollo. Permite analizar en detalle el proceso de revisión del código, incluidos los tiempos de revisión, los ciclos de retrabajo detectados durante la revisión y las tasas de integración. Conecta la fase de planificación (incidencia) con la fase de implementación (PR).
Por qué es importante
Vincula las incidencias con los cambios de código y los procesos de revisión correspondientes. Así, permite analizar en detalle el ciclo de revisión del código 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
|
Usuario al que se solicitó revisar el código de una solicitud de incorporación de cambios. | ||
|
Descripción
Un revisor es un desarrollador o miembro del equipo encargado de inspeccionar los cambios de código de una solicitud de incorporación de cambios para comprobar su calidad, corrección y cumplimiento de los estándares. Una solicitud de incorporación de cambios 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 revisión y medir cuánto tardan los revisores en responder a las solicitudes. Es un componente clave para calcular el KPI 'Tiempo medio del ciclo de revisión del código'.
Por qué es importante
Identifica a las personas que participan en el control de calidad y 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 el arreglo 'requested_reviewers' o en el objeto 'user' de un evento de revisión de una solicitud de incorporación de cambios en la API de GitHub.
Ejemplos
alex.chenmaria.garciasenior-dev-team
|
|||
|
Sistema de origen
SourceSystem
|
Sistema del que se extrajeron los datos del proceso de desarrollo. | ||
|
Descripción
Este atributo identifica el origen de los datos de los eventos. En este proceso, el valor sería siempre 'GitHub'. En un entorno más complejo, donde las actividades de desarrollo abarcan varios sistemas (por ejemplo, Jira para la planificación, GitHub para el código y Jenkins para la implementación), este campo permite 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 abarcan distintas plataformas y aporta 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
Suele ser un valor estático que se añade durante el proceso de extracción, transformación y carga de datos (ETL) para identificar el origen de los registros.
Ejemplos
GitHubGitHub Enterprise
|
|||
|
Tiempo de ciclo de desarrollo
DevelopmentCycleTime
|
Tiempo total transcurrido desde la creación de un elemento de desarrollo hasta su implementación final o cierre. | ||
|
Descripción
Esta métrica se calcula por caso como la diferencia entre el primer evento (por ejemplo, 'Incidencia creada') y el último (por ejemplo, 'Implementación correcta' o 'Incidencia cerrada') de un elemento de desarrollo. Es uno de los KPI más importantes para medir la eficiencia general del proceso de desarrollo. Contribuye directamente al Dashboard 'Tiempo de ciclo general del desarrollo' y al KPI 'Tiempo medio del ciclo de desarrollo'. Reducir esta métrica suele ser uno de los principales objetivos de las iniciativas de mejora de procesos.
Por qué es importante
Representa el tiempo de comercialización de principio a fin de un elemento de desarrollo, por lo que es un KPI fundamental para medir la velocidad y la eficiencia generales del proceso.
Dónde obtenerlo
Se calcula por caso restando la marca de tiempo de la primera actividad de la marca de tiempo de la última.
Ejemplos
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Tiempo de espera en los traspasos
HandoffWaitingTime
|
Tiempo de inactividad calculado que un elemento de desarrollo pasa esperando entre actividades realizadas por distintas 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 cambia la persona responsable. Por ejemplo, el tiempo entre un evento 'Revisión solicitada' y un evento 'Cambios solicitados en la revisión' realizado por otro usuario. Es una métrica fundamental para identificar brechas de comunicación y problemas de coordinación. Contribuye al Dashboard 'Eficiencia de los traspasos críticos' y al KPI 'Tiempo medio de espera en los traspasos'. Los tiempos de espera prolongados en los puntos de traspaso suelen indicar limitaciones de recursos o procesos de notificación ineficientes.
Por qué es importante
Permite localizar retrasos causados por una coordinación deficiente o la falta de recursos durante los traspasos entre 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 los datos
LastDataUpdate
|
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. Aporta metadatos sobre la actualidad de los datos analizados. No debe confundirse con la marca de tiempo del evento, que registra cuándo ocurrió el evento de negocio. En el análisis, este campo es fundamental para saber si la vista del proceso está actualizada. Permite 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 se añade durante el proceso de extracción, transformación y carga de datos (ETL).
Ejemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
Actividades del ciclo de vida del desarrollo de software
| 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 solicitud de incorporación. Este evento se infiere del estado de las comprobaciones que notifican 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 en el proceso de entrega.
Dónde obtenerlo
Se infiere a partir de la API de GitHub Checks o la API de Statuses. Una ejecución de comprobación o una actualización de estado informa 'success' o 'completed' con una conclusión 'success'.
Capturar
Supervise la API de Checks para detectar una conclusión 'success' en los conjuntos de comprobaciones pertinentes.
Tipo de evento
inferred
|
|||
|
Incidencia cerrada
|
El elemento de desarrollo se considera terminado y la incidencia correspondiente se cierra formalmente. Esto puede ocurrir automáticamente al fusionar una solicitud de incorporación vinculada o de forma manual por parte de un integrante del equipo. | ||
|
Por qué es importante
Esta actividad marca el final definitivo del proceso para un elemento de desarrollo. Es fundamental para calcular los tiempos de ciclo de principio a fin.
Dónde obtenerlo
Es un evento explícito que se registra en el flujo de eventos de la API de GitHub Issues. El tipo de evento es 'closed'.
Capturar
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 función. Este evento se registra explícitamente cuando una persona crea una incidencia nueva en un repositorio de GitHub. | ||
|
Por qué es importante
Es la actividad inicial principal del proceso, esencial para medir el tiempo de ciclo total del desarrollo y comprender de dónde surge el trabajo.
Dónde obtenerlo
Es un evento explícito que se registra en el flujo de eventos de la API de GitHub Issues. El tipo de evento suele ser 'opened' para un número de incidencia determinado.
Capturar
Escuche el evento 'opened' de una incidencia mediante webhooks o consultas periódicas a la API.
Tipo de evento
explicit
|
|||
|
Solicitud de incorporación abierta
|
Indica que un primer bloque de código está listo para su revisión e integración. Una persona desarrolladora crea una solicitud de incorporación (PR) para proponer cambios desde su rama de función a una rama principal. GitHub registra este evento de forma explícita. | ||
|
Por qué es importante
Es un hito clave que marca el fin de la fase inicial de desarrollo y el comienzo del proceso de revisión e integración. Permite analizar por separado los tiempos de ciclo de desarrollo y de revisión.
Dónde obtenerlo
Se registra en el flujo de eventos de la API de GitHub Pull Request o mediante webhooks. La acción del evento es 'opened'.
Capturar
Escuche la acción 'opened' de una solicitud de incorporación mediante webhooks o consultas periódicas a la API.
Tipo de evento
explicit
|
|||
|
Solicitud de incorporación aprobada
|
Una persona revisora ha aprobado formalmente los cambios de una solicitud de incorporación, lo que indica que cumplen los estándares de calidad y funcionalidad. El evento se registra cuando la persona revisora envía su revisión con el estado 'approve'. | ||
|
Por qué es importante
Es un control de calidad clave y un hito importante antes de la fusión. El tiempo que transcurre desde la creación de la PR hasta alcanzar este estado es un KPI fundamental para medir la eficiencia del proceso de revisión.
Dónde obtenerlo
Se registra mediante la API de GitHub Pull Request o webhooks cuando se envía una revisión con el estado 'APPROVED'.
Capturar
Filtre los eventos de envío de revisiones de solicitudes de incorporación por el estado 'APPROVED'.
Tipo de evento
explicit
|
|||
|
Solicitud de incorporación fusionada
|
Los cambios de código aprobados en la solicitud de incorporación se integran oficialmente en la rama de destino, como main o develop. Esta acción final y explícita de la solicitud incorpora el código nuevo. | ||
|
Por qué es importante
Es un hito clave que representa la finalización del desarrollo y la revisión. Para muchos equipos, es el último paso antes de la implementación automatizada.
Dónde obtenerlo
Se registra en el flujo de eventos de la API de GitHub Pull Request o mediante webhooks. La acción del evento es 'closed' y el atributo 'merged' de la carga útil de la solicitud de incorporación tiene el valor true.
Capturar
Escuche la acción 'closed' de una solicitud de incorporación y compruebe si la marca 'merged' tiene el valor true.
Tipo de evento
explicit
|
|||
|
Cambios solicitados en la revisión
|
Una persona revisora ha terminado de revisar el código y ha determinado que es necesario modificarlo antes de aprobar la solicitud de incorporación. La persona revisora envía formalmente su revisión con el estado 'request_changes'. | ||
|
Por qué es importante
Este evento indica explícitamente un ciclo de retrabajo. Analizar su frecuencia ayuda a localizar problemas de calidad, requisitos poco claros o áreas en las que el equipo de desarrollo necesita formación.
Dónde obtenerlo
Se registra mediante la API de GitHub Pull Request o webhooks cuando se envía una revisión con el estado 'CHANGES_REQUESTED'.
Capturar
Filtre los eventos de envío de revisiones de solicitudes de incorporación por el estado 'CHANGES_REQUESTED'.
Tipo de evento
explicit
|
|||
|
Código enviado a la solicitud de incorporación
|
Representa una actualización del código enviado para revisión, ya sea como parte de la solicitud de incorporación inicial o en respuesta a la retroalimentación recibida durante la revisión. Este evento se registra cada vez que se envía una confirmación nueva a la rama asociada con una solicitud de incorporación abierta. | ||
|
Por qué es importante
Registrar estos eventos es fundamental para identificar ciclos de retrabajo. Si se envían varios cambios después de una revisión, significa que se solicitaron modificaciones que afectan al tiempo de ciclo total.
Dónde obtenerlo
Es un evento explícito en la cronología de la solicitud de incorporación, que suele aparecer como una confirmación añadida. Puede registrarse mediante el webhook 'push' o supervisando las confirmaciones asociadas con una PR.
Capturar
Registre los eventos 'push' en una rama asociada con una solicitud de incorporación 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 solicitud de incorporación. Se infiere de un estado de fallo notificado por un sistema como GitHub Actions. | ||
|
Por qué es importante
Esta actividad pone de relieve problemas técnicos de calidad que requieren la intervención del equipo de desarrollo y generan 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 a partir de la API de GitHub Checks o la API de Statuses. Una ejecución de comprobación o una actualización de estado informa 'failure' o 'completed' con una conclusión 'failure'.
Capturar
Supervise la API de Checks para detectar una conclusión 'failure' en los conjuntos de comprobaciones pertinentes.
Tipo de evento
inferred
|
|||
|
Implementación exitosa
|
Los cambios de código se han implementado correctamente en un entorno específico, como el de pruebas o el de producción. Este evento suele registrarse mediante la API de GitHub Deployments, a menudo a partir de una GitHub Action tras una fusión. | ||
|
Por qué es importante
Marca el paso del código del repositorio a un entorno activo. Registrar este evento es esencial para medir el tiempo de entrega completo, desde la idea hasta la producción.
Dónde obtenerlo
Se registra mediante la API de Deployments. Un servicio externo o una GitHub Action crea una implementación y luego actualiza su estado a 'success'.
Capturar
Supervise los eventos de estado de implementación mediante webhooks para detectar el estado 'success'.
Tipo de evento
inferred
|
|||
|
Incidencia reabierta
|
Se reactiva una incidencia que se había cerrado, normalmente porque la solución no fue suficiente o se detectó una regresión. Este evento explícito reinicia el ciclo de vida del elemento de desarrollo. | ||
|
Por qué es importante
Indica un ciclo de retrabajo importante y puede señalar un defecto que llegó a producción o una solución incompleta. Registrar su frecuencia es una medida clave de la calidad general del software.
Dónde obtenerlo
Es un evento explícito que se registra en el flujo de eventos de la API de GitHub Issues. El tipo de evento es 'reopened'.
Capturar
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 crea una rama nueva a partir del código base principal. Este evento explícito se registra cuando se envía una rama nueva al repositorio; a menudo, su nombre incluye el número de la incidencia. | ||
|
Por qué es importante
Indica el paso 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 cuánto tardan quienes desarrollan en empezar a trabajar y a detectar demoras iniciales en la lista de tareas pendientes.
Dónde obtenerlo
Se registra 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'.
Capturar
Procese los eventos webhook 'create' de las ramas nuevas y vincúlelos con una incidencia.
Tipo de evento
explicit
|
|||
|
Revisión solicitada
|
La persona autora de una solicitud de incorporación pide formalmente a integrantes o equipos concretos que revisen su código. Esta acción explícita en la interfaz o la API de GitHub envía notificaciones a 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 transcurrido hasta que se envía una revisión ayuda a medir la capacidad de respuesta de quienes revisan y a detectar posibles cuellos de botella.
Dónde obtenerlo
Se registra en el flujo de eventos de la API de GitHub Pull Request o mediante webhooks. La acción del evento es 'review_requested'.
Capturar
Escuche la acción 'review_requested' de una solicitud de incorporación.
Tipo de evento
explicit
|
|||
Guías de extracción
¿Todo listo para empezar?
Utilice este Template para preparar sus datos y empezar a optimizar el ciclo de vida del desarrollo de software. Detecte ineficiencias y consiga entregas más rápidas y fluidas desde hoy.
Impulse su SDLC: detecte ineficiencias al instante
Reduzca el tiempo de ciclo un 30 % y agilice el desarrollo en GitHub.
No se requiere tarjeta de crédito. La configuración lleva solo unos minutos.