Saltar al contenido

Guía

Jira y gestión del trabajo

Jira hace casi cualquier cosa que le pidas, y ese es el problema: sin criterio acabas con un proceso pesado que la gente esquiva. La configuración es una decisión de equipo, no de administrador.

Última actualización:

Ilustración abstracta de un tablero Kanban con columnas y tarjetas en curso

Jira es una herramienta muy configurable de seguimiento de trabajo. Bien usada, da visibilidad de qué está en curso y dónde se atasca. Mal usada, se convierte en burocracia que se rellena para cumplir y que no refleja la realidad.

Estructura: proyectos, épicas, incidencias

  • Un proyecto de Jira por producto o por equipo estable, no por cada iniciativa temporal.
  • Épicas para agrupar trabajo con un objetivo común y una duración de semanas.
  • Incidencias (historias, tareas, *bugs*) que quepan en unos pocos días. Si algo no cabe en un *sprint*, todavía no está listo para empezarse.

Flujos de estado

El flujo por defecto (Por hacer → En curso → Hecho) es suficiente para la mayoría de equipos. Añade un estado solo cuando represente una espera real que quieras medir —«En revisión», «Bloqueado»— y no solo un matiz. Cada estado de más es una transición más que alguien tiene que recordar hacer.

Métricas que sirven y métricas que engañan

La métrica más útil suele ser el tiempo de ciclo: cuánto tarda una incidencia desde que se empieza hasta que se termina. Si sube, algo se está atascando y se ve en el tablero. La velocidad (puntos por *sprint*) sirve para planificar dentro de un mismo equipo, pero no para comparar equipos ni como objetivo: en cuanto se convierte en meta, se infla la estimación.

Integración con Git y CI

Conecta Jira con el repositorio para que las ramas y las *pull requests* enlacen con su incidencia y el estado avance solo al fusionar. Reduce el trabajo manual de mover tarjetas y hace que el tablero refleje la realidad sin esfuerzo.

Preguntas frecuentes

Lo que suelen preguntarnos

¿Scrum o Kanban en Jira?

Kanban si el trabajo llega de forma continua y priorizas sobre la marcha (soporte, mantenimiento). Scrum si planificáis por iteraciones con un compromiso por sprint. Jira soporta los dos; la elección es de proceso.

¿Cuántos campos personalizados conviene tener?

Los mínimos. Cada campo obligatorio es fricción en cada incidencia. Si un dato no se consulta para tomar una decisión, no debería ser obligatorio.

¿Sirve la estimación en puntos de historia?

Sirve para conversar sobre el tamaño y detectar cuando algo no se entiende bien. No sirve como medida de productividad ni para comparar personas o equipos.

¿Se puede usar Jira sin caer en la burocracia?

Sí, si la configuración la decide el equipo y se revisa cada pocos meses para quitar lo que no se usa. El problema casi nunca es Jira, es acumular reglas y no retirar ninguna.

Siguiente paso

Media hora bien invertida

Cuéntanos el problema en una llamada corta. Salimos con una primera orientación de por dónde iría y qué implicaría, sin compromiso y sin presentación comercial.