Su Template de datos del ciclo de vida de desarrollo de software
Su Template de datos del ciclo de vida de desarrollo de software
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía para extraer datos de Jira Software
Atributos del ciclo de vida del desarrollo de software
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
Activity
|
El nombre de un evento específico o de un cambio de estado que tuvo lugar durante el ciclo de vida de desarrollo de un elemento. | ||
|
Descripción
Este atributo representa un paso o hito diferenciado del proceso de desarrollo de software. Estas actividades se derivan de cambios en el campo de estado de la incidencia de Jira u otros eventos relevantes, como confirmaciones de código o revisiones. En Process Mining, la secuencia de estas actividades forma el mapa del proceso. Analizarlas ayuda a identificar el flujo del proceso, medir la duración de etapas concretas y detectar desviaciones del Workflow estándar, como ciclos de retrabajo o controles de calidad omitidos.
Por qué es importante
Las actividades definen los pasos del proceso y su secuencia es esencial para visualizar el flujo del proceso, identificar cuellos de botella y analizar las variaciones del proceso.
Dónde obtenerlo
Normalmente se deriva de las transiciones del campo «status» en el historial o registro de cambios de la incidencia de Jira. También puede enriquecerse con datos de herramientas de desarrollo conectadas.
Ejemplos
Desarrollo iniciadoRevisión de código realizadaPruebas de QA completadasImplementado en producción
|
|||
|
Elemento de desarrollo
DevelopmentItem
|
El identificador único de una unidad de trabajo individual, como una historia, un error o una tarea, dentro de Jira Software. | ||
|
Descripción
El elemento de desarrollo actúa como identificador principal del caso y representa una unidad de trabajo diferenciada, como una funcionalidad, una corrección de errores o una tarea. Vincula todas las actividades de ese elemento específico, desde la concepción y la planificación iniciales hasta el desarrollo, las pruebas y la implementación. En Jira, normalmente corresponde a la clave de la incidencia, por ejemplo, «PROJ-123». Analizar este atributo permite seguir el ciclo de vida completo de cada elemento de trabajo, de extremo a extremo. Es la base para crear mapas de procesos, calcular tiempos de ciclo e identificar variaciones en la forma en que los distintos elementos avanzan por el proceso de desarrollo.
Por qué es importante
Esta es la clave esencial para vincular todas las actividades de desarrollo relacionadas y hacer posible el seguimiento de un único elemento de trabajo desde el inicio hasta el final.
Dónde obtenerlo
Este es el campo estándar «key» de una incidencia en el objeto de la API Jira Software Issue.
Ejemplos
PROJ-101CORE-5432API-789
|
|||
|
Hora del evento
EventTime
|
La fecha y hora exactas en las que tuvo lugar una actividad o evento de desarrollo específico. | ||
|
Descripción
La hora del evento es la marca de tiempo que registra cuándo tuvo lugar una actividad. Constituye la base temporal de todos los análisis de Process Mining, ya que proporciona el orden cronológico de los eventos de cada caso. Este atributo es fundamental para calcular todas las métricas basadas en el tiempo, incluidos los tiempos de ciclo, los tiempos de procesamiento y los tiempos de espera entre actividades. Permite analizar el rendimiento del proceso a lo largo del tiempo y ayuda a identificar cuándo y dónde se producen retrasos en el ciclo de vida del desarrollo.
Por qué es importante
Esta marca de tiempo es fundamental para ordenar correctamente los eventos y calcular todas las métricas basadas en la duración, que son clave para comprender la eficiencia del proceso e identificar retrasos.
Dónde obtenerlo
Corresponde a la marca de tiempo «created» de cada entrada del registro de cambios o historial de una incidencia.
Ejemplos
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
|
|||
|
Sistema de origen
SourceSystem
|
El sistema del que se extrajeron los datos del ciclo de vida del desarrollo. | ||
|
Descripción
Este atributo identifica el origen de los datos. En este proceso, será siempre «Jira Software», pero resulta útil para distinguir los datos cuando se combinan varios sistemas de origen en un análisis más amplio. En un entorno de TI más amplio, especificar el sistema de origen garantiza la trazabilidad de los datos y ayuda a gestionar su calidad y las tareas de integración entre distintas plataformas.
Por qué es importante
Proporciona una procedencia clara de los datos, algo crucial al integrar datos de varios sistemas o para fines de gobierno y auditoría de datos.
Dónde obtenerlo
Es un valor estático que debe añadirse durante el proceso de extracción y transformación de datos.
Ejemplos
Jira Software
|
|||
|
Última actualización de datos
LastDataUpdate
|
La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este proceso desde el sistema de origen. | ||
|
Descripción
Este atributo registra la fecha y hora de la extracción de datos más reciente desde Jira Software. Proporciona contexto sobre la actualidad de los datos analizados. Conocer la hora de la última actualización es importante para comprender la vigencia de la información del proceso. Ayuda a analistas y usuarios de negocio a confirmar que están consultando datos actuales e indica el punto de corte de los eventos incluidos en el análisis.
Por qué es importante
Indica la actualidad de los datos, un aspecto esencial para garantizar que los análisis y los Dashboards reflejen el estado más reciente del proceso.
Dónde obtenerlo
Esta marca de tiempo se genera y registra al final del proceso de extracción, transformación y carga (ETL) de datos.
Ejemplos
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
|
|||
|
Estado del elemento
ItemStatus
|
El estado actual del elemento de desarrollo dentro de su Workflow. | ||
|
Descripción
Este atributo refleja la etapa específica del elemento de desarrollo en un momento determinado, como «In Progress», «In Review» o «Done». La secuencia de cambios de estado a lo largo del tiempo es la que genera las actividades para Process Mining. Mientras que el atributo «Activity» representa el evento de cambio, «ItemStatus» proporciona el estado del elemento. Es útil como dimensión de filtrado y análisis, ya que permite ver cuántos elementos se encuentran actualmente en un estado concreto o analizar las características de los elementos que permanecen mucho tiempo en un estado determinado.
Por qué es importante
Proporciona una instantánea de la posición de un elemento en su ciclo de vida, algo esencial para el análisis basado en estados y para comprender el estado actual del trabajo en curso.
Dónde obtenerlo
Es el campo «status» dentro del objeto «fields» de la respuesta de la API Jira Issue.
Ejemplos
To DoIn ProgressIn ReviewDone
|
|||
|
Nombre del equipo
TeamName
|
El equipo de desarrollo responsable del elemento de trabajo. | ||
|
Descripción
Representa el equipo ágil o de funcionalidades específico asignado al elemento de desarrollo. En Jira, suele implementarse como un campo personalizado o puede derivarse de otra información, como el proyecto o un componente específico. Este atributo es fundamental para analizar el rendimiento por equipo. Permite filtrar los Dashboards para mostrar métricas como el tiempo de ciclo, la tasa de retrabajo y el rendimiento de equipos individuales. Esto es crucial para los Dashboards "Eficiencia de los traspasos entre fases" y "Carga de trabajo de desarrollo y progreso de los elementos".
Por qué es importante
Permite medir y comparar el rendimiento de distintos equipos de desarrollo, identificar los equipos con mejor rendimiento y compartir buenas prácticas.
Dónde obtenerlo
Normalmente es un campo personalizado de Jira. Consulte con su administrador de Jira para identificar el nombre específico del campo, que podría ser «Team», «Squad» o similar.
Ejemplos
Equipo PhoenixServicios centralesUI/UX Avengers
|
|||
|
Nombre del proyecto
ProjectName
|
El nombre del proyecto de Jira al que pertenece el elemento de desarrollo. | ||
|
Descripción
En Jira, todos los elementos de trabajo se organizan en proyectos. El nombre del proyecto proporciona un contexto general y suele corresponder a un producto, equipo o iniciativa específicos. Este atributo es una dimensión eficaz para filtrar y comparar. Permite analizar y comparar el proceso del ciclo de vida del desarrollo de software entre distintos proyectos o productos. Así se puede descubrir qué proyectos son más eficientes, cuáles presentan más retrabajo y si los distintos equipos siguen variantes diferentes del proceso.
Por qué es importante
Permite segmentar el análisis del proceso por proyecto, producto o equipo, comparar el rendimiento e identificar las mejores prácticas.
Dónde obtenerlo
Es el campo «project» dentro del objeto «fields» de la respuesta de la API Jira Issue.
Ejemplos
Desarrollo de aplicaciones móvilesPlataforma centralCiencia de datos
|
|||
|
Prioridad del elemento
ItemPriority
|
El nivel de prioridad asignado al elemento de desarrollo, que indica su urgencia. | ||
|
Descripción
La prioridad del elemento define la importancia o urgencia relativa de un elemento de trabajo. Jira proporciona un campo estándar «priority» con niveles configurables como Highest, High, Medium y Low. Analizar la prioridad es crucial para comprobar la conformidad e identificar cuellos de botella en elementos críticos. Por ejemplo, el Dashboard «Priority Item Conformance Check» utiliza este atributo para verificar si los elementos de alta prioridad se aceleran como se espera o si quedan atascados en las mismas colas que los elementos de baja prioridad.
Por qué es importante
Ayuda a analizar si los elementos de alta prioridad se procesan más rápido que los de baja prioridad y si siguen una ruta más ágil, garantizando el cumplimiento de los SLA.
Dónde obtenerlo
Es el campo «priority» dentro del objeto «fields» de la respuesta de la API Jira Issue.
Ejemplos
MáximaAltaMediaBaja
|
|||
|
Responsable asignado
Assignee
|
El usuario asignado actualmente para gestionar el elemento de desarrollo. | ||
|
Descripción
El responsable asignado es la persona responsable del elemento de trabajo en su etapa actual. En Jira, es un campo estándar que cambia cuando el elemento pasa entre distintas personas y equipos. Analizar el responsable asignado es clave para comprender la asignación de recursos, la distribución de la carga de trabajo y los puntos de transferencia. Ayuda a responder preguntas como qué desarrolladores o equipos participan en etapas concretas, quién constituye un cuello de botella y cómo se distribuye el trabajo en la organización.
Por qué es importante
Identifica al usuario o recurso responsable de una actividad, lo que permite analizar la carga de trabajo, gestionar recursos y comprender las transferencias entre personas.
Dónde obtenerlo
Es el campo «assignee» dentro del objeto «fields» de la respuesta de la API Jira Issue.
Ejemplos
Alice SmithBob JohnsonSin asignar
|
|||
|
Tipo de elemento
ItemType
|
La clasificación del elemento de desarrollo, como Bug, Story, Task o Epic. | ||
|
Descripción
El tipo de elemento categoriza la naturaleza del trabajo realizado. Jira utiliza un campo estándar «issuetype» para distinguir entre diferentes tipos de elementos de trabajo, que a menudo tienen Workflows propios. Este atributo es esencial para el análisis comparativo. Permite filtrar el proceso por tipos de trabajo específicos, por ejemplo, para comparar el ciclo de vida de un «Bug» con el de una «Story». Así se puede identificar si ciertos tipos de trabajo son más propensos a sufrir retrasos, retrabajo o desviaciones del proceso estándar.
Por qué es importante
Permite segmentar el análisis del proceso para comparar cómo se gestionan distintos tipos de trabajo, como errores frente a nuevas funcionalidades, y dónde difieren sus procesos.
Dónde obtenerlo
Es el campo «issuetype» dentro del objeto «fields» de la respuesta de la API Jira Issue.
Ejemplos
HistoriaErrorTareaÉpica
|
|||
|
Componente
Component
|
Una subsección o área funcional de un proyecto a la que pertenece el elemento. | ||
|
Descripción
En Jira, los componentes se utilizan para agrupar incidencias de un proyecto en partes más pequeñas y manejables. Pueden representar un área funcional, como «Autenticación de usuarios»; una capa técnica, como «Backend API»; o un módulo, como «Informes». El análisis por componente ofrece una visión más detallada del proceso de desarrollo. Puede ayudar a identificar si determinadas partes de la aplicación generan más errores, tienen ciclos de desarrollo más largos o requieren más retrabajo, lo que apunta a áreas de deuda técnica o complejidad.
Por qué es importante
Permite segmentar el proceso por áreas funcionales o técnicas del producto, ayudando a determinar qué componentes son fuente de retrasos o problemas de calidad.
Dónde obtenerlo
Es el campo estándar «components» dentro del objeto «fields» de la respuesta de la Jira Issue API.
Ejemplos
Interfaz de usuarioBase de datosAPI GatewayAutenticación
|
|||
|
Es retrabajo
IsRework
|
Un indicador que señala si una actividad forma parte de un bucle de retrabajo. | ||
|
Descripción
Este atributo booleano es verdadero si una actividad representa un retroceso en el proceso, como volver a «Desarrollo iniciado» después de no superar las pruebas de QA. Se determina analizando la secuencia de actividades de un caso. Identificar el retrabajo es fundamental para mejorar la eficiencia y la calidad del proceso. Este atributo respalda directamente el KPI «Tasa de actividades de retrabajo» y el panel «Frecuencia y rutas de los bucles de retrabajo». Permite cuantificar el esfuerzo desperdiciado y localizar las causas raíz de los problemas de calidad que generan retrabajo.
Por qué es importante
Identifica explícitamente las actividades que forman parte de bucles de retrabajo ineficientes, lo que permite medir y analizar con precisión el desperdicio del proceso y los problemas de calidad.
Dónde obtenerlo
Es un atributo calculado. Requiere definir el flujo de proceso esperado y marcar después cualquier actividad que se desvíe al volver a una fase anterior.
Ejemplos
truefalse
|
|||
|
Hora de finalización del evento
EventEndTime
|
La marca de tiempo en la que se completó una actividad o cambió un estado. | ||
|
Descripción
Este atributo marca la hora de finalización de una actividad. Es la marca de tiempo de la actividad siguiente en la secuencia de un caso determinado. Mientras que 'EventTime' (StartTime) marca el inicio de una actividad, EventEndTime marca su finalización. La diferencia entre ambas marcas de tiempo es el tiempo de procesamiento de esa actividad. Esto es fundamental para calcular el KPI "Tiempo medio de procesamiento de una etapa" y crear Dashboards que analicen la duración de las actividades.
Por qué es importante
Define el punto final de una actividad y permite calcular la duración de cada paso del proceso, algo esencial para analizar cuellos de botella.
Dónde obtenerlo
Es un atributo derivado. Para un evento determinado, su hora de finalización es la hora de inicio del evento posterior del mismo caso.
Ejemplos
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
|
|||
|
Informador
Reporter
|
El usuario que creó o notificó originalmente el elemento de desarrollo. | ||
|
Descripción
El informador es la persona que creó la incidencia en Jira. Puede ser un desarrollador, un especialista de QA, un responsable de producto o incluso un cliente mediante una integración con un centro de servicios. Analizar al informador puede proporcionar información sobre el origen del trabajo. Por ejemplo, puede analizarse si los errores notificados por el equipo de QA tienen un ciclo de vida diferente al de los notificados por los clientes. También puede ayudar a comprender los patrones de comunicación y el flujo de información al inicio del proceso.
Por qué es importante
Identifica el origen del elemento de trabajo y permite analizar patrones según quién crea las tareas o notifica los errores.
Dónde obtenerlo
Es el campo «reporter» dentro del objeto «fields» de la respuesta de la API Jira Issue.
Ejemplos
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Nombre del Sprint
SprintName
|
El nombre del Sprint ágil al que está asignado el elemento de desarrollo. | ||
|
Descripción
Para los equipos que utilizan Scrum, el Sprint es un periodo de tiempo definido durante el cual se completa un conjunto de trabajos. Este atributo registra el nombre o identificador del Sprint al que pertenece un elemento. El análisis por Sprint es fundamental para el Process Mining centrado en metodologías ágiles. Ayuda a evaluar el rendimiento de cada Sprint, comprender el trabajo pendiente que pasa al siguiente Sprint y realizar un seguimiento del progreso respecto a los objetivos del Sprint. Proporciona un contexto temporal más específico que los intervalos de fechas generales.
Por qué es importante
Proporciona un contexto esencial para los equipos ágiles y permite analizar la eficiencia y el rendimiento del proceso Sprint por Sprint.
Dónde obtenerlo
Esta información suele almacenarse en un campo personalizado «Sprint», gestionado por Jira Software (Agile). Los datos están disponibles mediante la Issue API.
Ejemplos
Sprint 1 de PROJSprint 3 del cuarto trimestre de 2023Sprint 2 del PI de noviembre
|
|||
|
Resolución del elemento
ItemResolution
|
El resultado final o motivo por el que se cierra un elemento de desarrollo. | ||
|
Descripción
Resolution explica por qué un elemento pasó a un estado cerrado. Aunque el estado pueda ser «Closed», la resolución podría ser «Done», «Won't Do», «Duplicate» o «Cannot Reproduce». Esto proporciona un contexto esencial sobre el resultado del trabajo. Analizar la resolución ayuda a diferenciar el trabajo completado correctamente de los elementos cancelados o rechazados. Esto es importante para el análisis de calidad y para comprender el rendimiento real del trabajo valioso frente al esfuerzo dedicado a elementos que finalmente se descartaron.
Por qué es importante
Distingue entre los elementos completados correctamente y los cerrados por otros motivos, algo fundamental para realizar análisis precisos de productividad y calidad.
Dónde obtenerlo
Es el campo «resolution» dentro del objeto «fields» de la respuesta de la API Jira Issue. Normalmente solo se completa cuando una incidencia se cierra.
Ejemplos
DoneWon't DoDuplicadoNo se puede reproducir
|
|||
|
Tiempo de ciclo total
CycleTime
|
La duración total de extremo a extremo de un elemento de desarrollo. | ||
|
Descripción
El tiempo de ciclo mide el tiempo total transcurrido desde la creación de un elemento de desarrollo hasta su resolución final, como el despliegue en producción. Se calcula a nivel de caso como la diferencia entre la marca de tiempo del primer evento y la del último. Es un KPI principal para medir la velocidad y la eficiencia generales del proceso. El KPI «Tiempo medio de ciclo de extremo a extremo» y el panel «Análisis general del tiempo de ciclo del SDLC» se basan directamente en este cálculo. Reducir el tiempo de ciclo suele ser un objetivo clave de las iniciativas de mejora de procesos.
Por qué es importante
Mide la velocidad de extremo a extremo del proceso de desarrollo y proporciona un indicador clave del rendimiento general y de la velocidad de entrega.
Dónde obtenerlo
Es un atributo calculado a nivel de caso. Corresponde a la marca de tiempo del último evento menos la marca de tiempo del primero para un «DevelopmentItem» determinado.
Ejemplos
12096002592000604800
|
|||
|
Tiempo de espera de la transferencia
HandoffWaitTime
|
El tiempo de inactividad entre dos actividades consecutivas. | ||
|
Descripción
Esta métrica calcula el tiempo de espera o de cola entre la finalización de una actividad y el inicio de la siguiente. Representa el tiempo durante el que el trabajo permanece inactivo a la espera de que alguien lo retome. Es una métrica fundamental para el KPI «Tiempo medio de espera de la transferencia» y el panel «Eficiencia de la transferencia entre fases». Los tiempos elevados de transferencia suelen indicar problemas de coordinación, limitaciones de recursos o una comunicación ineficiente entre equipos, por ejemplo, entre desarrollo y QA. Minimizar este tiempo de inactividad es una palanca clave para reducir el tiempo de ciclo general.
Por qué es importante
Pone de relieve el tiempo de inactividad o de cola del proceso, expone ineficiencias en las transferencias entre equipos o personas y revela problemas de coordinación.
Dónde obtenerlo
Es una métrica calculada. Corresponde a la hora de inicio de una actividad menos la hora de finalización de la actividad anterior del mismo caso.
Ejemplos
017280043200
|
|||
|
Versión de corrección
FixVersion
|
La versión de software en la que el elemento de desarrollo se resolvió y publicó realmente. | ||
|
Descripción
La «Fix Version» de Jira indica la release que contiene el trabajo completado de un elemento. Marca el resultado concreto del esfuerzo de desarrollo. Este atributo proporciona el contexto real de la release, que puede compararse con «PlannedReleaseVersion» para analizar el rendimiento de las entregas. También se utiliza para agrupar todos los elementos entregados en una release específica y obtener una visión consolidada de lo realizado.
Por qué es importante
Confirma en qué release se incluyó un trabajo y proporciona la referencia definitiva para analizar las releases y realizar un seguimiento de las funcionalidades entregadas.
Dónde obtenerlo
Corresponde al campo «fixVersions» de la respuesta de la Jira Issue API.
Ejemplos
Corrección urgente v2.1.1Versión principal v3.0.0v2.2.0
|
|||
|
Versión planificada
PlannedReleaseVersion
|
La versión de software o release de destino en la que está previsto desplegar el elemento. | ||
|
Descripción
Este atributo, que suele corresponder al campo «Affects Version/s» de Jira, indica la release prevista para una funcionalidad o corrección. Sirve como fecha límite u objetivo para completar el trabajo. Es un atributo fundamental para el KPI «Tasa de entregas de releases a tiempo». Al comparar la fecha de despliegue real con la fecha de release planificada asociada a esta versión, puede medir el cumplimiento del calendario y la previsibilidad de su proceso de releases.
Por qué es importante
Define la fecha de entrega o release objetivo, lo que permite calcular las tasas de entrega a tiempo y analizar el cumplimiento del calendario.
Dónde obtenerlo
Corresponde a los campos «versions» o «fixVersions» de la Jira Issue API. El campo específico utilizado para la planificación puede variar.
Ejemplos
Versión 2.1Versión del primer trimestre de 2024Lanzamiento del proyecto Phoenix
|
|||
Actividades del ciclo de vida del desarrollo de software
| Actividad | Descripción | ||
|---|---|---|---|
|
Desarrollo iniciado
|
Representa el momento en que un desarrollador comienza a trabajar activamente en el elemento de desarrollo. Casi siempre se captura infiriendo un cambio de estado dentro del Workflow de Jira, por ejemplo, cuando el estado de la incidencia cambia a «In Progress». | ||
|
Por qué es importante
Este es un hito crucial para medir el tiempo de desarrollo activo. Ayuda a distinguir entre el tiempo de espera y el trabajo que aporta valor, una métrica clave para identificar cuellos de botella.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo en la que el campo «status» cambia por primera vez a «In Progress», «In Development» o un estado activo similar.
Recopilar
Marca de tiempo del cambio de estado a «In Progress».
Tipo de evento
inferred
|
|||
|
Elemento de desarrollo creado
|
Esto marca el inicio del ciclo de vida, cuando un nuevo elemento de desarrollo, como una historia, un error o una tarea, se registra formalmente en Jira. El sistema captura explícitamente este evento con una marca de tiempo de creación para cada incidencia. | ||
|
Por qué es importante
Esta actividad constituye el inicio definitivo del proceso, algo esencial para calcular los tiempos de ciclo de extremo a extremo y realizar un seguimiento del volumen total de trabajo entrante.
Dónde obtenerlo
Este es un evento fundamental para cada incidencia de Jira. La marca de tiempo de creación se almacena en el campo «created» del registro de la incidencia, al que se puede acceder mediante la API de Jira.
Recopilar
El campo de marca de tiempo «created» del objeto Jira Issue.
Tipo de evento
explicit
|
|||
|
Implementado en producción
|
Este evento marca el momento en que los cambios de código asociados al elemento de desarrollo están activos en el entorno de producción. Puede inferirse a partir de un cambio de estado final a «Done» o «Released», o capturarse mediante un evento explícito de una herramienta de CI/CD integrada. | ||
|
Por qué es importante
Este es el principal punto final de éxito del proceso. Es esencial para calcular el tiempo total de ciclo de extremo a extremo y medir la frecuencia de implementación y el rendimiento.
Dónde obtenerlo
Puede inferirse a partir del registro de cambios de la incidencia de Jira cuando el estado cambia a «Released» o «Done». Para obtener mayor precisión, puede capturarse a partir de eventos de implementación enviados por herramientas de CI/CD como Jenkins o Bamboo, o mediante la función Deployments de Jira.
Recopilar
Marca de tiempo del cambio de estado a «Done» o «Released».
Tipo de evento
inferred
|
|||
|
Pruebas de QA completadas
|
Indica que el elemento de desarrollo ha superado correctamente todas las comprobaciones de aseguramiento de la calidad y está listo para la siguiente etapa, como las pruebas de aceptación del usuario o la versión. Se infiere a partir de un cambio de estado que lo saca del estado principal de pruebas. | ||
|
Por qué es importante
Esto marca la finalización de un control de calidad importante. Analizar la duración de la fase de QA ayuda a optimizar los procesos de pruebas y la asignación de recursos.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo en la que el campo «status» pasa de «In QA» a un estado posterior como «Ready for UAT» o «Ready for Release».
Recopilar
Marca de tiempo del cambio de estado de «In QA» a «Ready for UAT».
Tipo de evento
inferred
|
|||
|
Pruebas de QA iniciadas
|
Este evento marca el inicio de la fase formal de pruebas de aseguramiento de la calidad para el elemento de desarrollo. Se infiere a partir de un cambio de estado en Jira cuando la incidencia pasa a un estado como «In QA», «In Testing» o «Ready for Testing». | ||
|
Por qué es importante
Este es un hito clave que inicia el ciclo de validación de calidad. Medir el tiempo desde «Development Completed» hasta este punto permite detectar retrasos en las transferencias entre los equipos de desarrollo y QA.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo en la que el campo «status» cambia a un estado de pruebas de QA designado, como «In QA».
Recopilar
Marca de tiempo del cambio de estado a «In QA» o «In Testing».
Tipo de evento
inferred
|
|||
|
UAT aprobada
|
Representa la finalización satisfactoria de las pruebas de aceptación del usuario e indica que las partes interesadas han aprobado la versión. Se infiere a partir de un cambio de estado de «In UAT» a un estado como «Ready for Release» o «Done». | ||
|
Por qué es importante
Este hito confirma la aceptación por parte del negocio y autoriza el elemento para su implementación en producción. Es un control crítico para garantizar que el trabajo entregado cumple las expectativas de los usuarios.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo del cambio de estado de «In UAT» al siguiente estado del Workflow, lo que indica la aprobación.
Recopilar
Marca de tiempo del cambio de estado de «In UAT» a «Ready for Release».
Tipo de evento
inferred
|
|||
|
Desarrollo completado
|
Esta actividad indica que el desarrollador ha terminado de programar y que el elemento está listo para la siguiente etapa, como la revisión de código o las pruebas. Se infiere a partir de un cambio de estado en Jira, como pasar de «In Progress» a «In Review» o «Ready for QA». | ||
|
Por qué es importante
Esto marca el final de la fase principal de desarrollo y permite analizar la duración de la programación y la eficiencia de las transferencias al equipo de aseguramiento de la calidad.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira, capturando la marca de tiempo en la que el campo «status» cambia de un estado de desarrollo activo a un estado posterior como «In Review» o «Ready for QA».
Recopilar
Marca de tiempo del cambio de estado de «In Progress» a «In Review» o «Ready for QA».
Tipo de evento
inferred
|
|||
|
Elemento de desarrollo cancelado
|
Representa la finalización de un elemento de desarrollo antes de completarlo. Se infiere a partir de un cambio de estado a un estado terminal como «Canceled», «Rejected» o «Won't Do», y suele ir acompañado de una resolución específica. | ||
|
Por qué es importante
Esta actividad registra los resultados no satisfactorios del proceso. Analizar por qué se cancelan los elementos puede revelar problemas de planificación, priorización o definición de requisitos.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo en la que el «status» de la incidencia cambia a «Canceled» o «Won't Do» y se establece la resolución correspondiente.
Recopilar
Marca de tiempo del cambio de estado a «Canceled», «Rejected» o «Won't Do».
Tipo de evento
inferred
|
|||
|
Elemento de desarrollo cerrado
|
Esta es la acción administrativa final, que confirma que no se espera ningún trabajo adicional sobre el elemento. A menudo se infiere a partir de un cambio de estado a «Closed» y de la asignación de un valor al campo «Resolution». | ||
|
Por qué es importante
Representa el final absoluto del recorrido de un elemento. Compararlo con «Deployed to Production» puede revelar retrasos administrativos o periodos de supervisión posteriores a la implementación.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo en la que el campo «status» cambia a «Closed» y se establece una resolución.
Recopilar
Marca de tiempo del cambio de estado a «Closed».
Tipo de evento
inferred
|
|||
|
Elemento listo para desarrollo
|
Indica que un elemento de desarrollo se ha especificado, revisado y priorizado por completo, por lo que está listo para que un desarrollador comience a trabajar en él. Normalmente se infiere a partir de un cambio de estado en el Workflow, como pasar de «Backlog» a «To Do» o «Ready for Dev». | ||
|
Por qué es importante
Realizar un seguimiento de este punto ayuda a medir la preparación del backlog y el tiempo que los elementos esperan antes de que comience el desarrollo. Permite separar el tiempo de planificación y perfeccionamiento del tiempo de desarrollo activo.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Busque una marca de tiempo en la que el campo «status» cambie a un valor como «Ready for Dev», «To Do» o «Selected for Development».
Recopilar
Marca de tiempo del cambio de estado a un estado de preparación previo al desarrollo.
Tipo de evento
inferred
|
|||
|
Preparado para la versión
|
Indica que el elemento de desarrollo ha superado todas las comprobaciones y se ha incluido en una versión específica del software, a la espera de su implementación. A menudo se infiere cuando el estado de una incidencia cambia a «Ready for Release» o cuando se completa el campo «Fix Version». | ||
|
Por qué es importante
Esta actividad ayuda a realizar un seguimiento de la preparación de la versión y del tiempo que los elementos esperan una ventana de implementación una vez completado todo el trabajo de desarrollo y pruebas.
Dónde obtenerlo
Normalmente se infiere a partir del registro de cambios de la incidencia de Jira como un cambio de estado a «Ready for Release». Como alternativa, puede inferirse a partir de la marca de tiempo en la que se establece el campo «Fix Version/s».
Recopilar
Marca de tiempo del cambio de estado a «Ready for Release» o del momento en que se completa «Fix Version».
Tipo de evento
inferred
|
|||
|
Pruebas de QA fallidas
|
Indica que el equipo de QA ha encontrado un defecto, por lo que el elemento de desarrollo se devuelve a los desarrolladores para su retrabajo. Se infiere a partir de una transición de estado hacia atrás, por ejemplo, de «In QA» a «In Progress» o «To Do». | ||
|
Por qué es importante
Esta actividad es crucial para identificar ciclos de retrabajo. Realizar un seguimiento de su frecuencia ayuda a cuantificar el coste de la mala calidad y a señalar áreas de mejora en el desarrollo o en los requisitos.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Se captura cuando el campo «status» pasa de un estado de pruebas, por ejemplo «In QA», a un estado de desarrollo anterior, como «In Progress».
Recopilar
Marca de tiempo del cambio de un estado de pruebas a un estado de desarrollo.
Tipo de evento
inferred
|
|||
|
Revisión de código realizada
|
Indica que un compañero o responsable ha revisado el código en cuanto a calidad, estándares y funcionalidad. Puede inferirse a partir de un cambio de estado, como pasar de «In Review» a «Ready for QA», o capturarse explícitamente desde herramientas de desarrollo integradas. | ||
|
Por qué es importante
Esta actividad es un control de calidad crítico. Analizar su duración y sus resultados, como el retrabajo, ayuda a mejorar la calidad del código y a reducir los errores detectados más adelante en el proceso.
Dónde obtenerlo
Normalmente se infiere a partir del registro de cambios de la incidencia de Jira cuando el estado sale de «Code Review». También puede ser un evento explícito si se integran herramientas de repositorio de código como Bitbucket o GitHub.
Recopilar
Marca de tiempo del cambio de estado de «In Review» al siguiente estado.
Tipo de evento
inferred
|
|||
|
UAT iniciada
|
Marca el inicio de las pruebas de aceptación del usuario, en las que las partes interesadas del negocio o los usuarios finales validan la nueva funcionalidad. Se infiere a partir de un cambio de estado en Jira a un estado como «In UAT» o «User Acceptance Testing». | ||
|
Por qué es importante
Esta actividad registra el inicio de la fase final de validación antes de la versión. Analizar su duración es clave para comprender y reducir los retrasos causados por la disponibilidad de las partes interesadas o por los ciclos de comentarios.
Dónde obtenerlo
Se infiere a partir del registro de cambios de la incidencia de Jira. Es la marca de tiempo en la que el campo «status» se actualiza a «In UAT» o a un estado designado similar.
Recopilar
Marca de tiempo del cambio de estado a «In UAT».
Tipo de evento
inferred
|
|||
Guías de extracción
¿Listo para comenzar?
Comience hoy mismo a optimizar su ciclo de vida de desarrollo de software preparando sus datos con esta plantilla. Descubra información que le permita acelerar las entregas y mejorar la calidad.
Optimice su SDLC en Jira Software. ¡Comience hoy!
Localice las ineficiencias y reduzca un 30 % el tiempo de ciclo de su SDLC.
No necesita tarjeta de crédito. Comience a optimizar en cuestión de minutos.