learning-front

Nivel 12 · Cómo es el trabajo de verdad

La suite Atlassian: Jira y Confluence

La herramienta donde vive el marco de Scrum: Jira (tipos de issue, la anatomía de un ticket, el tablero con su flujo de estados y el ciclo de vida de una tarea) y Confluence (la memoria del equipo), más filtros, JQL y dashboards.

El capítulo anterior te dio el modelo mental de Scrum: los roles, los artefactos, las ceremonias y la user story como unidad de trabajo. Pero todo eso no vive en tu cabeza ni en una pizarra: vive en una herramienta donde el equipo ve el trabajo, lo mueve y lo comenta. La más extendida es Jira, de la empresa Atlassian, junto a su hermana Confluence.

Hay alternativas —Linear, Azure DevOps, GitHub Projects, Trello—, y el concepto es el mismo en todas; si entiendes Jira, las demás te resultan familiares. Por eso lo usamos de ejemplo: es el estándar que más te vas a encontrar, y el que da nombre a media jerga de oficina (“ábreme un ticket”, “está en el sprint”, “lo muevo a review”).

Jira: el centro de operaciones del equipo#

Jira organiza el trabajo de un equipo en torno a unas pocas piezas: un proyecto (el contenedor de todo, p. ej. “Team Builder”), los issues o tickets (cada unidad de trabajo), el backlog (la lista priorizada de tickets pendientes), el tablero (la vista donde se mueven) y los sprints (los ciclos del capítulo anterior, aquí de verdad).

La idea clave es esta: en Scrum, el backlog era un concepto. En Jira, ese backlog es una lista real de tickets que puedes reordenar arrastrando, comentar, estimar, etiquetar y enlazar entre sí. Lo que era una idea en una pizarra pasa a ser el sitio donde el equipo trabaja cada día y donde cualquiera —tú, el PO, el manager— ve en qué punto está cada cosa sin tener que preguntar.

Los tipos de issue#

No todo el trabajo es igual, así que un ticket tiene un tipo. Los que verás a diario:

  • Epic. Un contenedor grande: un objetivo que no cabe en un solo sprint, como “Filtros y búsqueda del roster”. Se entrega partiéndolo en historias.
  • Story (historia). Una unidad de valor para el usuario, en formato de user story: “filtrar el roster por rol”. Es la pieza con la que más vas a trabajar.
  • Task (tarea). Trabajo técnico sin cara de usuario directa: “actualizar las dependencias”, “configurar el linter en CI”. Necesario, pero no es una feature.
  • Bug. Un defecto en algo que ya existe: “el winrate se calcula mal en el roster”. Arregla lo roto, no añade valor nuevo.
  • Subtask (subtarea). El trozo más pequeño: una división técnica DENTRO de una story, como “la UI del filtro” y “la lógica más sus tests”.

¿Y qué aporta distinguirlos, más allá de ponerle una etiqueta a cada cosa? Que el tipo ordena y deja medir. Si tu tablero se llena de bugs sprint tras sprint, esa es una señal de calidad que se ve precisamente porque cada cosa lleva su tipo. Y la jerarquía da contexto: una story siempre puede mirar a su epic para saber a qué objetivo grande sirve.

text
EPIC  Filtros y búsqueda del roster
 │
 ├── STORY  Filtrar por rol
 │    ├── SUBTASK  UI de los botones de filtro
 │    └── SUBTASK  Lógica de filtrado + tests
 │
 ├── STORY  Buscar por nombre
 │
 └── STORY  Ordenar por winrate

El epic agrupa stories relacionadas y deja ver cuánto se ha avanzado hacia el objetivo. Sin epics, esas historias quedarían sueltas en el backlog, y es fácil entregar tres y olvidar la cuarta que hacía que el conjunto sirviera de algo.

El ticket por dentro#

El ticket es la unidad que se mueve por el tablero, y tiene bastantes más campos de los que parece. Estos son los que de verdad usas:

  • Clave y título. La clave es el identificador corto (p. ej. TB-42); por él se referencia el ticket en commits, PRs y conversaciones.
  • Tipo. Story, bug, task, subtask (los de arriba).
  • Descripción. Para una story, la del formato “Como… quiero… para…”.
  • Criterios de aceptación. Las condiciones verificables que dicen cuándo está hecho.
  • Estimación. Normalmente en story points.
  • Estado. En qué columna del tablero está ahora.
  • Asignado (assignee). Quién lo está trabajando. Si está vacío, nadie es su dueño.
  • Reporter. Quién lo creó (a menudo el PO, o quien encontró el bug). No es lo mismo que el assignee: el reporter da el contexto, el assignee responde del avance.
  • Etiquetas (labels) y componentes. Para clasificar y filtrar (frontend, roster…).
  • Sprint y epic. A qué sprint pertenece y bajo qué epic cuelga.
  • Issues enlazados. Relaciones con otros tickets: “bloquea a”, “está bloqueado por”, “se relaciona con”.
  • Comentarios y actividad. El hilo de conversación del ticket y su historial de cambios.

Así se ve un ticket completo del Team Builder:

markdown
TB-42 · Story · Epic: Filtros y búsqueda del roster

Título: Filtrar el roster por rol
Estado: In Progress      Prioridad: Alta
Asignado a: tú           Reporter: Marta (PO)
Estimación: 3 puntos     Sprint: Sprint 14
Labels: frontend, roster
Bloquea a: TB-43 (Combinar filtros)

Descripción
Como jugador que arma un equipo
quiero filtrar el roster por rol (tanque, daño o soporte)
para ver solo los héroes de la posición que me falta por cubrir.

Criterios de aceptación
- Hay tres filtros: Tanque, Daño y Soporte.
- Al activar un rol, la lista muestra solo los héroes de ese rol.
- Si un rol no tiene héroes, se muestra "No hay héroes de este rol".

Subtasks
- [x] UI de los botones de filtro
- [ ] Lógica de filtrado + tests

Comentarios
— Marta (PO): ¿los filtros son excluyentes o se pueden combinar?
— tú: excluyentes en esta historia; combinarlos es TB-43.

Fíjate en dos cosas. La primera: el comentario resuelve una duda en el propio ticket, no en un chat que se pierde; dentro de un mes, quien lea TB-42 entiende por qué los filtros no se combinan. La segunda: el ticket NO clava la implementación técnica. El cómo lo decide el equipo al planificar, igual que con la user story. Un ticket que ya trae la solución impuesta convierte una conversación en un dictado.

El tablero por dentro#

El tablero (board) es la vista de columnas por las que avanzan los tickets, de “sin empezar” a “hecho”. Cada columna corresponde a un estado del flujo de trabajo del equipo: el conjunto de estados posibles y las transiciones permitidas entre ellos. Un flujo típico de un equipo de front:

text
TABLERO DEL SPRINT — Team Builder            (límite WIP en In Progress: 3)
┌──────────────┬──────────────────┬──────────────┬──────────────┐
│    To Do     │ In Progress (2/3)│  In Review   │     Done     │
├──────────────┼──────────────────┼──────────────┼──────────────┤
│ TB-43        │ TB-42            │ TB-39        │ TB-38        │
│ Combinar     │ Filtrar por rol  │ Ordenar por  │ Cargar       │
│ filtros · 5  │ · 3              │ winrate · 3  │ roster · 5   │
│              │ TB-45            │              │ TB-37        │
│ TB-44        │ Bug: winrate mal │              │ Maquetar     │
│ Buscar · 2   │ calculado · 2    │              │ carta · 3    │
└──────────────┴──────────────────┴──────────────┴──────────────┘

Cada equipo adapta su flujo: unos añaden “QA”, otros “Bloqueado”. Hay un par de ideas que conviene tener claras:

  • In Review ≠ Done. “In Review” significa que el trabajo está hecho pero espera la revisión de un compañero (el code review, o la validación del Pull Request que viste en Git). Hasta que se revisa y se aprueba, no está cerrado.
  • El límite de WIP. Ese “(2/3)” de la columna In Progress es un tope: no se pueden tener más de tres tickets a la vez en curso. Cuando está lleno, la regla es “termina algo antes de empezar más”.
  • Las swimlanes. En tableros con mucho trabajo, las filas (swimlanes) agrupan los tickets por un criterio —por persona, por epic, por prioridad— para poder leerlos.

¿Y de qué sirve verlo así, en vez de una lista? El tablero hace visible el flujo y los atascos. Si “In Progress” está hasta arriba y “Done” vacío, el equipo ha empezado muchas cosas y no termina ninguna (justo lo que el límite de WIP previene). Si un ticket lleva tres días en “In Review”, hay un bloqueo silencioso —alguien acabó y nadie revisa— que frena la entrega. Nadie tiene que contarlo: se ve.

El ciclo de un ticket, de la idea al cierre#

Junta el ticket, el tablero y las ceremonias del capítulo anterior, y un ticket recorre esto:

text
TB-42 "Filtrar por rol", de la idea al cierre

Backlog ─▶ Refinement ─▶ Planning ─▶ In Progress ─▶ In Review ─▶ Done ─▶ Demo
  el PO     se aclara     entra al    lo programas   PR abierto,  mergeado  se enseña
  lo crea   y se estima   sprint y    + tests        un compañero          en la
            (3 pts)       se asigna                  lo revisa             review

El PO crea el ticket en el backlog. En el refinement se aclara y se estima. En el planning entra al sprint y alguien lo coge. Pasa a In Progress mientras se programa, con su PR. Al terminar va a In Review, donde un compañero lo revisa; cuando se aprueba y se mergea, pasa a Done. Y en la review del sprint se enseña funcionando. Cada columna del tablero es una parada de ese viaje, y cada ceremonia del capítulo anterior actúa sobre él en su momento. El tablero no es burocracia: es ese viaje hecho visible.

Sprints en Jira#

En Jira, el sprint del capítulo anterior es algo concreto: seleccionas del backlog las historias del sprint, las pones en el sprint y le das a “iniciar sprint”. A partir de ahí, el tablero muestra solo ese trabajo. Al acabar, “cierras el sprint” y lo que no se terminó vuelve al backlog para repriorizar.

Jira da además un par de gráficos para la inspección de la que hablábamos en Scrum:

  • El burndown: cuánto trabajo queda día a día. Si la línea baja a buen ritmo, el sprint va encarrilado; si se queda plana y se desploma el último día, casi todo se cerró al final —señal de tickets demasiado grandes o atascos en revisión—.
  • La velocidad (velocity): cuántos puntos cierra el equipo de media por sprint, para que ESE equipo prevea cuánto cabe en el siguiente. Como ya viste, no es para comparar equipos ni para presionar.

No tienes que ser un experto en estos gráficos; sí saber leerlos cuando aparezcan en una review o una retro.

Confluence: la memoria del equipo#

Jira guarda el trabajo; Confluence guarda el conocimiento. Es el wiki del equipo, organizado en spaces (uno por equipo o proyecto) y páginas en árbol. Lo que vive ahí:

  • Specs y PRDs: la descripción de una feature o de un producto antes de partirlo en tickets.
  • Decision logs (o ADRs): las decisiones importantes y su porqué.
  • Runbooks: recetas paso a paso para operaciones o incidencias (“cómo desplegar”, “qué hacer si se cae el login”).
  • Actas: notas de reuniones, resultados de retros.

Y se integra con Jira: puedes enlazar tickets dentro de una página, o incrustar una lista de issues que se actualiza sola. Una página de decision log del Team Builder se vería así:

markdown
# Decisión: filtrar en cliente, no en servidor

Estado: Aceptada · Fecha: 2026-06-12 · Autor: equipo Roster

## Contexto
El roster completo (unos 40 héroes) ya se carga entero en el cliente.

## Decisión
Filtrar y buscar en el cliente, sin llamadas nuevas al servidor.

## Alternativas consideradas
- Filtrar en el servidor: más llamadas y latencia para un dataset tan pequeño.

## Consecuencias
- El filtrado responde al instante.
- Si el roster creciera a miles de héroes, habría que reconsiderarlo.

La regla práctica: si es algo que se mueve por el tablero, va a Jira; si es algo que el equipo querrá consultar dentro de seis meses, va a Confluence. ¿Y qué pasa si no tienes un sitio así? El conocimiento vive en la cabeza de quien estaba ese día. Cuando esa persona se va de vacaciones —o de la empresa—, el equipo se queda sin saber por qué se hizo algo, y acaba rehaciendo debates ya cerrados o deshaciendo decisiones sin conocer su motivo. Por eso una decisión escrita, con su porqué y sus alternativas, vale más que diez mensajes de chat.

Buscar y ver: filtros, JQL y dashboards#

Cuando hay cientos de tickets, hace falta buscarlos. Jira tiene filtros visuales y, por debajo, JQL (Jira Query Language): un lenguaje para filtrar por cualquier campo. No hace falta dominarlo para empezar, pero un par de consultas te ahorran el día. Por ejemplo, “todo lo mío que no esté cerrado”:

text
assignee = currentUser() AND status != "Done"

Con esas búsquedas se montan dashboards: pantallas configurables que reúnen métricas y vistas de un vistazo —tickets abiertos, burndown del sprint, bugs por prioridad— sin tener que abrir mil tickets. Es lo que mira un equipo (o su manager) para ver el estado general.

Jira tiene mucho más —automatizaciones, informes, whiteboards—, pero nada de eso es lo que te hace productivo el primer día. Eso es escribir buenos tickets, moverlos por el tablero y leerlo bien. El resto se aprende cuando de verdad lo necesitas.

Comprueba lo que sabes#

Pregunta 1 de 12

En la jerarquía de Jira, ¿cómo se relacionan epic, story y subtask?

Tu turno#

El artefacto de este capítulo es el trabajo real de preparar el backlog: coger un epic y partirlo en historias trabajables, y escribir uno de sus tickets como lo dejarías en Jira. Hazlo tú y luego compara con las tres soluciones, que suben de calidad cuidando la granularidad y los criterios.

Ejercicio · hazlo en local

Descompón un epic y escribe su ticket

El PO ha creado el epic "Filtros y búsqueda del roster" en el Team Builder. Descomponlo en user stories del tamaño adecuado y escribe un ticket completo de una de ellas, como lo dejarías en Jira. Las soluciones muestran el desglose en tres niveles de calidad. Hazlo tú primero y compara: ahí está el aprendizaje.

Paso 1: El epic partido y un ticket con lo básico

  • Divides el epic en varias historias.
  • Escribes un ticket con título, descripción y estado.
  • El ticket lleva algún criterio de aceptación.

Cómo hacerlo en local

Clona el repositorio del curso, entra en la carpeta del ejercicio y abre el index.html en tu navegador. Toda tu solución va en solucion.js. 

git clone <repo>
cd exercises/nivel-12/suite-atlassian
# abre index.html en el navegador y edita solucion.js
Ver soluciones 
# Epic: Filtros y búsqueda del roster

## Historias

- Filtrar por rol.
- Buscar héroes y ordenarlos y que se vea bien en móvil.
- Limpiar filtros.

## Ticket de ejemplo

**Título:** Filtrar por rol

**Descripción:** El usuario quiere filtrar los héroes por rol.

**Criterios de aceptación:**

- Que se pueda filtrar por rol.
- Que vaya rápido.

**Estado:** To Do

Por qué este nivel

  • El epic está partido y el ticket tiene la forma de un ticket, que es el punto de partida. Pero una de las historias ("buscar y ordenar y que se vea en móvil") mete tres cosas distintas en una: es demasiado grande y mezcla temas, así que no cabe limpia en un sprint ni se puede estimar bien.
  • Y los criterios del ticket ("que vaya rápido") no se pueden comprobar. ¿La consecuencia? Nadie sabe cuándo la historia está hecha, y la historia-cajón-de-sastre se arrastra de sprint en sprint porque siempre le falta "una de las tres cosas". El tier "mejor" corta cada historia en una vertical slice.