Sistema de Seguimiento

Guía completa sobre clasificación de issues, origen de datos y normativa del equipo

Índice de Contenidos

DEFINICIONES
BUENAS PRÁCTICAS
OBLIGATORIO

SECCIÓN 1: DEFINICIONES

Conceptos fundamentales del sistema de clasificación

Clasificación de Issues

El sistema clasifica automáticamente cada issue en una de las siguientes categorías:

PLANIFICADO

Definición:

Issues que fueron planificadas con anterioridad en la base de datos de JiraPlanner. Representan trabajo que el equipo sabía que tenía que hacer antes de empezar la release.

Características:
  • Existe en la BD Jira-Planner-v2
  • Tiene planned_hours definidas
  • Fue creada ANTES de la release
  • Representa intención previa
Ejemplo:
III-1234 - "Implementar login con OAuth2"
Planificada en JiraPlanner con 8h antes de la release 1.2.0

EMERGENTE

Definición:

Issues que NO fueron planificadas pero se determinaron como necesarias durante la release. Cambios legítimos por necesidades del negocio o bugs críticos.

Criterio C1:
  • NO existe en JiraPlanner
  • Tiene FixVersion = Release
  • Alguien decidió que era necesaria
  • Trabajo adicional legítimo
Ejemplo:
III-5678 - "Bug crítico: validación emails"
NO planificada, pero marcada con FixVersion = 1.2.0

RUIDO / IMPROVISACIÓN

Definición:

Issues con imputaciones de horas en el rango de fechas, pero que NO tienen FixVersion de la release. Trabajo improvisado o desviaciones del plan.

Criterio C2:
  • NO existe en JiraPlanner
  • NO tiene FixVersion = Release
  • Tiene worklogs en las fechas
  • Trabajo improvisado
Ejemplo:
III-9999 - "Soporte técnico cliente X"
5 horas imputadas pero sin FixVersion = 1.2.0
ALERTA: El ruido indica descontrol. Minimizarlo es crucial.

ANCESTRO

Definición:

Issues que aparecen solo para mantener la jerarquía (Epic ? Story ? Subtask), pero que NO son ni Planificadas, ni Emergentes, ni Ruido.

Características:
  • NO está en JiraPlanner
  • NO tiene FixVersion = Release
  • NO tiene worklogs en el rango
  • Es PADRE de otra issue relevante
Ejemplo:
III-100 - "Epic: Refactorización auth"
NO está en la release, pero una de sus stories SÍ

Origen de los Datos

El sistema combina datos de TRES fuentes:

1. JiraPlanner
(Planificación Interna)

Base de datos: Jira-Planner-v2 (PostgreSQL)

Datos que aporta:
  • Epics, Stories, Subtasks planificadas
  • Horas Planificadas (planned_hours)
  • Asignaciones de equipo
  • Releases y proyectos
Tablas:
project
release
epic
story
subtask
2. Jira API
(Datos Reales)

Conexión: Jira Cloud
aspiresoftwarespanish.atlassian.net

Datos que aporta:
  • Horas Estimadas (timeoriginalestimate)
  • Horas Imputadas (timespent)
  • FixVersion
  • Worklogs (quién, cuándo, cuánto)
  • Target Start/End
  • Estado, asignado, etc.
Endpoints:
GET /issue/{key}
POST /search/jql
GET /issue/{key}/worklog
3. CoreTracker
(BD Unificada)

Base de datos: CoreTracker (PostgreSQL)

Función:
  • Combina JiraPlanner + Jira API
  • Almacena clasificación
  • Consultas rápidas
  • Histórico de sincronizaciones
Tabla principal:
issue (unificada)
Se sincroniza al cargar Comparador o con botón "Sincronizar Todo"

Criterios de Clasificación

Criterio C1 - Emergentes (FixVersion)
Objetivo:

Detectar issues NO planificadas pero necesarias para la release

Lógica:
IF issue.FixVersion == Release.KeyJira
  AND issue NOT IN JiraPlanner
THEN
  Clasificar como EMERGENTE
JQL:
project = "III" AND fixVersion = "1.2.0"
Criterio C2 - Ruido (Worklogs)
Objetivo:

Detectar issues con tiempo imputado pero sin FixVersion de la release

Lógica:
IF worklogDate BETWEEN Release.StartDate AND EndDate
  AND worklogAuthor IN Release.Users
  AND (FixVersion != Release OR NULL)
  AND issue NOT IN JiraPlanner
THEN
  Clasificar como RUIDO
Prioridad C2 > C1: Si cumple ambos criterios, C2 tiene prioridad

SECCIÓN 2: BUENAS PRÁCTICAS

Recomendaciones para un seguimiento exitoso

Campos Importantes en Jira

Campo Jira Nombre Técnico Descripción Importancia Por qué es importante
FixVersion fixVersions Release a la que pertenece CRÍTICO Sin esto NO se detecta C1
Original Estimate timeoriginalestimate Horas estimadas CRÍTICO Columna "H. Est."
Time Spent timespent Horas imputadas (worklogs) CRÍTICO Columna "H. Imp."
Target Start customfield_10022 Fecha objetivo inicio IMPORTANTE Columna "Inicio"
Target End customfield_10023 Fecha objetivo fin IMPORTANTE Columna "Fin"
Epic Link customfield_10014 Epic al que pertenece OPCIONAL Mantiene jerarquía
HACER (DO)
  • Asignar FixVersion correcta antes de trabajar
  • Completar Original Estimate en cada issue
  • Imputar horas SOLO en issues de la release actual
  • Informar Target Start/End
  • Actualizar estados diariamente
  • Consultar con PO antes de tomar issues fuera del plan
NO HACER (DON'T)
  • NUNCA imputar sin FixVersion
  • NUNCA trabajar sin Original Estimate
  • No imputar en issues de otras releases sin avisar
  • No crear issues sin asignar a release específica
  • No dejar issues huérfanas (sin Epic Link o Parent)
  • No trabajar en issues no planificadas sin autorización

SECCIÓN 3: NORMATIVA OBLIGATORIA DEL EQUIPO

Reglas estrictas que DEBEN cumplirse

PROHIBIDO IMPUTAR SIN:

1. Horas Estimadas

Original Estimate

Sin estimación ? NO imputar

2. FixVersion Asignada

fixVersions

Sin release ? NO imputar

3. Fechas Definidas

Target Start / End

Sin timeline ? Poca visibilidad

Consecuencias de NO seguir la normativa
  • El trabajo aparecerá como RUIDO en el sistema
  • Product Owner NO sabrá qué está pasando
  • Las métricas de planificación serán INCORRECTAS
  • Se pierde VISIBILIDAD y CONTROL sobre la release
  • Los stakeholders NO tendrán información FIABLE
Responsabilidad de Product Owner

Product Owner debe saber en cada momento:

  • Qué trabajo está planificado y comprometido
  • Qué trabajo emergente ha surgido y por qué
  • Qué ruido está distrayendo al equipo
  • Si el equipo va a cumplir con los plazos
En un entorno deslocalizado y remoto:
La disciplina en Jira es la ÚNICA forma de que Product Owner tenga visibilidad real. No hay "pasar por la mesa". Todo debe estar en Jira, bien clasificado y actualizado.
Colaboración Solicitada al Equipo
Por favor, equipo:
  • Ayúdanos a mantener la visibilidad rellenando correctamente los campos
  • Consultad con PO antes de tomar issues fuera del plan
  • Imputad horas SOLO en issues con FixVersion, Original Estimate, Target Start y Target End
  • Actualizad estados diariamente
  • Comunicad bloqueadores en cuanto surjan
Trabajando juntos conseguiremos:
  • Releases más predecibles
  • Mejor comunicación
  • Menos sorpresas
  • Métricas fiables
Volver al Dashboard