learning-front

Nivel 12 · Cómo es el trabajo de verdad

Scrum y sus ceremonias

El marco que da ritmo a un equipo de producto: de dónde viene (el manifiesto ágil), sus pilares, los tres roles, los artefactos con sus compromisos, la user story (formato, INVEST, criterios y estimación) y las cuatro ceremonias, vistas en una semana real de trabajo.

Hasta aquí el curso te ha enseñado a construir y a llevar tu código a producción: sabes maquetar, programar, tipar, testear, montar una app de React y desplegarla. Eso es lo que hace un desarrollador. Pero en una empresa no programas en el vacío: programas dentro de un equipo, con un ritmo, unas reuniones y un vocabulario que nadie te explica el primer día y que se da por sabido. La primera semana en un trabajo, la mitad de lo que no entiendes no es técnico: es de proceso.

Este nivel va de eso. Y empieza por el marco que organiza ese ritmo en la mayoría de los equipos de producto: Scrum. La herramienta donde todo esto vive de verdad —el tablero, los tickets— es Jira, y es el siguiente capítulo; aquí montamos primero el modelo mental, porque sin entender el porqué la herramienta es solo botones.

Agile: el porqué antes que el cómo#

Antes de Scrum hubo una forma dominante de hacer software: planificarlo todo al principio, en un documento enorme, y ejecutarlo en fases largas y separadas —primero todo el análisis, luego todo el diseño, luego todo el desarrollo, al final todas las pruebas—. Se le llama “waterfall” (cascada), porque cada fase cae sobre la siguiente y no se vuelve atrás.

Imagina el Team Builder hecho así: seis meses especificando hasta el último detalle, seis meses construyéndolo, y al entregarlo descubres que los jugadores no querían un editor de equipos completo, querían sobre todo comparar winrates, que apenas era una nota al pie del documento. Has entregado exactamente lo pactado y, aun así, no sirve. Ese es el fallo de fondo: el plan se escribe cuando MENOS sabes del problema, y para cuando entregas, el mundo ha cambiado.

En 2001, un grupo de desarrolladores resumió una forma distinta de trabajar en el Manifiesto Ágil: cuatro frases que valoran una cosa por encima de otra, sin tirar la segunda.

  • Individuos e interacciones por encima de procesos y herramientas. La gente que habla resuelve más que un proceso perfecto en un papel.
  • Software funcionando por encima de documentación exhaustiva. La medida del progreso es lo que funciona, no lo que está escrito.
  • Colaboración con el cliente por encima de la negociación de un contrato. Trabajar con quien recibe el producto, no defenderte de él con un contrato.
  • Responder al cambio por encima de seguir un plan. Cuando aprendes algo nuevo, lo incorporas, no lo ignoras porque “no estaba en el plan”.

Fíjate en que no dice “la documentación no importa”: dice que, si tienes que elegir, eliges software que funciona. Esos cuatro valores se desarrollan en doce principios (entregar valor pronto y de forma continua, dar la bienvenida al cambio aunque llegue tarde, mantener un ritmo sostenible…), pero la idea es esa. Agile es la filosofía. Scrum es la forma concreta y más extendida de aplicarla.

Scrum: un marco, no una metodología#

Conviene decirlo claro porque se confunde: Scrum es un marco (un esqueleto con unas reglas mínimas), no una metodología cerrada que te diga cada paso. Te da unos roles, unos artefactos y unas ceremonias, y deja que tu equipo rellene el resto según su contexto. Por eso dos equipos “que hacen Scrum” pueden trabajar de forma muy distinta y los dos estar en lo cierto.

Debajo de Scrum hay una idea: el empirismo, decidir mirando lo que de verdad pasa en vez de lo que el plan predijo. Eso se sostiene en tres pilares:

  • Transparencia. El trabajo es visible para todos. Por eso hay un tablero: cualquiera ve en qué punto está cada cosa.
  • Inspección. Ese trabajo visible se revisa con frecuencia. Por eso hay ceremonias: momentos fijos para mirar dónde estamos.
  • Adaptación. Lo que se ve en la inspección se usa para ajustar el rumbo. Por eso un plan en Scrum no es sagrado: cambia con lo aprendido.

Los tres encadenan: sin trabajo visible no hay nada que inspeccionar, y sin inspección no puedes adaptarte. Si un equipo esconde cómo va, “hace Scrum” solo de nombre.

La idea central, en el día a día, es trocear el trabajo en ciclos cortos y repetidos llamados sprints. Un sprint dura un tiempo fijo —normalmente una o dos semanas— y al final de cada uno el equipo entrega algo que funciona de verdad. Cada sprint tiene un objetivo del sprint (sprint goal): una frase que dice para qué sirve este sprint (“que el jugador pueda filtrar el roster”), y que servirá de brújula cuando algo se tuerza a mitad de camino.

Que el sprint dure un tiempo fijo es un caso de timeboxing: acotar de antemano cuánto dura algo y respetarlo. Aplica también a las reuniones, y no es burocracia: un límite obliga a centrarse en lo importante y evita que todo se estire hasta llenar el día.

El sprint es el latido del equipo. Visto de lejos, el ritmo es este:

text
┌──────────────── SPRINT (1-2 semanas) ────────────────┐
│                                                       │
│  Planning ─▶ [ Daily · Daily · Daily · … ] ─▶ Review ─▶ Retro
│     ▲                  (cada día)                      │
│     │                                                  ▼
│     └────────────── y vuelve a empezar ───────────────┘

Cada pieza de ese diagrama tiene un nombre y un porqué. Vamos por partes: primero quién hace el trabajo (los roles), luego sobre qué trabajan (los artefactos) y por último cuándo se reúnen y para qué (las ceremonias).

Los tres roles#

Scrum define tres roles. No son cargos ni niveles salariales: son responsabilidades distintas, y cada una existe para que el equipo no dependa de una sola persona para todo.

Product Owner (PO). Es el dueño del qué y del porqué. Decide qué se construye y en qué orden, priorizando el backlog según el valor para el negocio y para el usuario, y habla con los stakeholders (negocio, clientes, soporte) para traer ese contexto al equipo. Una parte central de su trabajo es decir que no: a casi todo, para proteger lo importante. En el Team Builder, el PO mira los datos de uso y dice “este sprint, el filtro por rol antes que el modo oscuro, porque es lo que más piden los jugadores que arman equipos”. Lo que el PO no hace es decidir cómo se implementa: eso es del equipo.

Scrum Master. Facilita el proceso y quita impedimentos; es liderazgo de servicio (sirve al equipo, no manda sobre él). Si el equipo está bloqueado porque falta un acceso, porque otra área no responde o porque las reuniones se comen el día, el Scrum Master lo desatasca. Cuida que las ceremonias sirvan para algo y protege al equipo de interrupciones: cuando a mitad de sprint alguien de fuera intenta colar “una cosita rápida”, el Scrum Master es quien dice “lo miramos en el próximo planning”. Ojo con la trampa más común: no es el jefe. No reparte tareas ni manda. Si actúa como jefe, el equipo vuelve a esperar órdenes en vez de organizarse, y se pierde la autonomía que hacía útil a Scrum.

Equipo de desarrollo. Quienes construyen: tú. Es multidisciplinar (entre todos tienen lo necesario para entregar: front, back, diseño, tests) y se organiza solo: decide el cómo y quién hace qué, sin que nadie de fuera lo asigne. Suele ser pequeño (del orden de tres a nueve personas) para que la coordinación no se vuelva el trabajo. En el Team Builder, es el equipo quien decide hacer el filtro con botones accesibles en vez de un desplegable, porque encaja mejor con el resto de la interfaz.

Por encima de un equipo concreto a veces aparece un agile coach: un perfil que ayuda a VARIOS equipos a la vez a mejorar su forma de trabajar, a escala de organización. Lo verás nombrado, pero no es parte del día a día de un equipo como los tres anteriores: piensa en él como un Scrum Master de Scrum Masters.

Los artefactos y sus compromisos#

Los roles trabajan sobre tres cosas concretas, y cada una lleva asociado un “compromiso” que le da foco.

El product backlog es la lista priorizada de todo lo que el producto podría necesitar: features, arreglos, mejoras. Lo ordena el PO y nunca se termina —siempre hay más ideas que tiempo—. En el Team Builder serían entradas como “filtrar por rol”, “ordenar por winrate”, “guardar equipos favoritos”, de la más prioritaria a la menos. Su compromiso es el product goal: el objetivo grande hacia el que apunta todo el backlog (“ser la forma más rápida de armar un equipo competitivo”).

El sprint backlog es el subconjunto que el equipo elige y se compromete a hacer este sprint, más el plan para lograrlo. Es la diferencia entre “todo lo que podríamos hacer algún día” y “lo que nos comprometemos a entregar en las próximas dos semanas”. Su compromiso es el sprint goal que ya vimos. Confundir los dos backlogs lleva a comprometerse con la lista entera, y un equipo que se compromete con todo no se compromete con nada.

El incremento es lo que el equipo termina de verdad al final del sprint: software que funciona y que se podría entregar. No es “casi hecho” ni “hecho pero sin probar”: es hecho según el listón del equipo. Ese listón es su compromiso, la Definition of Done (DoD): el acuerdo compartido de qué significa “terminado” —por ejemplo, con tests, revisado por otra persona y desplegable—. La DoD aplica a TODO el trabajo por igual; no la confundas con los criterios de aceptación, que son específicos de cada historia (lo vemos ahora).

La unidad de trabajo: la user story#

El backlog no se escribe en lenguaje técnico, sino en user stories (historias de usuario): la unidad de trabajo de un equipo de producto. Una user story describe algo desde el valor que aporta a alguien, con un formato fijo:

text
Como [tipo de usuario]
quiero [hacer algo]
para [obtener un beneficio].

Para el filtro del Team Builder:

markdown
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.

Fíjate en lo que NO es: no dice “añade un desplegable que llame a tal función”. Una historia no es una especificación técnica, es una conversación pendiente sobre un problema del usuario. El cómo lo decide el equipo. Si escribes el cómo en la historia, anclas al equipo a una solución antes de entender el problema y le quitas una decisión que es suya.

Una buena historia es además una vertical slice (un corte vertical): entrega valor de punta a punta, por pequeño que sea, en vez de media feature que no sirve hasta que llega la otra mitad. “Filtrar por rol” es una vertical slice —el jugador ya puede usarlo entero—; “pintar los botones del filtro pero sin que filtren nada” no lo es, porque no aporta valor por sí sola. Cortar el trabajo en rodajas que funcionan permite entregar algo útil cada sprint y no acumular piezas a medias que solo valen juntas.

Hay una chuleta clásica para revisar si una historia está bien escrita, el acrónimo INVEST:

  • Independiente: se puede priorizar y entregar sola, sin quedar bloqueada esperando a otra. “Filtrar por rol” no necesita que antes exista “buscar por nombre”.
  • Negociable: es una conversación, no un contrato cerrado; los detalles se afinan con el equipo y el PO.
  • Valiosa: aporta valor a alguien. Si no se nota desde fuera, probablemente es una tarea técnica, no una historia.
  • Estimable: el equipo puede hacerse una idea de su tamaño. Si no hay forma de estimarla, es que falta entenderla o partirla.
  • Small (pequeña): cabe holgada en un sprint. Una historia que llena el sprint entero da miedo y casi nunca termina.
  • Testeable: se puede comprobar si está hecha, lo que nos lleva a los criterios.

Para saber cuándo una historia está hecha, lleva criterios de aceptación: condiciones verificables, no opiniones. Una forma habitual de escribirlos es el patrón “Dado / Cuando / Entonces”:

markdown
- Dado el roster completo, cuando activo el filtro "Tanque",
  entonces la lista muestra solo los héroes tanque.
- Dado un filtro activo, cuando lo desactivo,
  entonces vuelven a aparecer todos los héroes.
- Dado un rol sin héroes, cuando lo activo,
  entonces se muestra "No hay héroes de este rol".

“Que funcione bien” no es un criterio: no se puede comprobar. “Al activar Tanque solo se ven los tanques” sí. La diferencia parece pequeña, pero decide si el “done” es un hecho o una discusión.

Y para planificar, las historias se estiman en story points: un número que mide el esfuerzo de forma relativa (complejidad más incertidumbre), no en horas. ¿Por qué no horas? Porque las horas fingen una precisión que no existe —dos personas tardan distinto, y nadie acierta— mientras que casi todo el mundo coincide en “esta historia es más grande que aquella”. Se suele usar una escala que crece a saltos (1, 2, 3, 5, 8, 13: los números de Fibonacci), porque cuanto más grande es algo, menos sentido tiene afinar.

Una técnica habitual para estimar es el planning poker: cada persona del equipo elige a la vez una carta con su número y todas se revelan de golpe. Si alguien dice 2 y otro 13, no es que uno se equivoque: es que entienden la historia de forma distinta, y esa diferencia se habla antes de comprometerse. La estimación, además, no es para vigilar a nadie: con el tiempo, la suma de puntos que un equipo cierra de media por sprint es su velocidad (velocity), que sirve para que ESE equipo prevea cuánto cabe en el siguiente. No para compararse con otro equipo (sus puntos son otra escala) ni para presionar; si se usa así, la gente infla las estimaciones y el número deja de significar nada.

Las ceremonias#

Scrum tiene cuatro reuniones (ceremonias o eventos) con un propósito claro cada una, todas con su caja de tiempo.

Sprint planning abre el sprint. El equipo responde a dos preguntas: qué puede entregarse (elige historias del backlog priorizado por el PO, según su capacidad y su velocidad) y cómo lo hará (esboza el plan). Acuerda el objetivo del sprint y sale con el sprint backlog comprometido. Para que el planning sea ágil, las historias deben llegar ya entendidas y estimadas; de eso se encarga el refinement, que viene ahora. Ejemplo: el equipo del Team Builder coge “filtrar por rol” (3), “buscar por nombre” (2) y “ordenar por winrate” (3), fija como objetivo “que el jugador encuentre rápido al héroe que busca” y deja fuera “guardar favoritos” para el siguiente.

Daily (stand-up) es la reunión diaria, corta (unos 15 minutos). El equipo se sincroniza y saca a la luz los bloqueos para resolverlos rápido. La forma clásica son tres preguntas —qué hice ayer, qué haré hoy, qué me bloquea—, aunque lo que importa no es el guion sino el fin: que el equipo se coordine y los problemas salgan pronto. Ejemplo útil: “ayer terminé la UI del filtro; hoy enchufo la lógica; me bloquea que no sé si el dato de rol viene en mayúsculas o minúsculas de la API”. Eso es una daily que sirve. La trampa, que verás en el capítulo de la realidad, es que degenere en un parte de estado para el manager: cuando eso pasa, la gente informa de que “todo va bien” y los bloqueos de verdad se esconden.

Sprint review (la demo) cierra el sprint mostrando el incremento terminado a los stakeholders (las personas con interés en el producto: PO, negocio, a veces clientes) para recoger feedback. Se enseña lo hecho, lo que ya funciona, no maquetas ni promesas. Ejemplo: el equipo enseña el filtro funcionando con datos reales, alguien de negocio pregunta “¿y se puede combinar con la búsqueda?” y eso entra al backlog como idea para el próximo sprint. Si demostraras lo que aún no existe, generarías una sensación de avance falsa, y los demás ajustarían sus planes a algo que no está.

Retrospectiva es la reunión del equipo sobre cómo trabajó, no sobre el producto. Qué fue bien, qué fue mal y —lo importante— qué vamos a cambiar el próximo sprint. Hay formatos sencillos para guiarla, como “empezar / dejar de / seguir” (start / stop / continue). La clave es que salga con acciones concretas y con dueño: “a partir de ahora, los criterios de aceptación se escriben en el refinement, no en el planning” es una acción; “deberíamos comunicarnos mejor” no lo es. Una retro sin acciones que se cumplan es solo una queja colectiva, y el equipo deja de tomársela en serio.

Y una pieza más, que no es un evento de horario fijo sino un trabajo continuo: el refinement (refinamiento). Es preparar el backlog —aclarar historias, partir las demasiado grandes, estimarlas— para que lleguen al planning listas. Sin refinement, el planning se atasca intentando entender y trocear historias enormes sobre la marcha, se eterniza y el equipo acaba comprometiéndose con trabajo que no comprende.

Kanban, la otra forma#

Scrum no es la única opción. Kanban organiza el trabajo de otra manera: en vez de sprints, un flujo continuo de tareas visualizado en un tablero, donde se limita cuántas cosas pueden estar a la vez en curso (el límite de WIP). No hay compromiso de sprint ni objetivo de sprint; las tareas entran y salen según van llegando. Encaja mejor cuando el trabajo es impredecible —un equipo de soporte no puede “planificar” las incidencias de la semana— o cuando las tareas son pequeñas y constantes. Muchos equipos mezclan ideas de los dos (a eso se le llama a veces “Scrumban”). Lo importante por ahora: el marco es una herramienta para servir al equipo, no una religión que cumplir al pie de la letra.

Una semana en la vida del equipo#

Junta todo lo anterior y así se ve un sprint de una semana del equipo del Team Builder:

text
LUNES        Sprint planning. Se eligen las historias, se fija el
             objetivo del sprint y arranca el tablero.

MAR–VIE      Daily cada mañana (15 min): qué hice, qué haré, qué me
             bloquea. El trabajo avanza por el tablero.

MIÉRCOLES    Refinement (1 h): se preparan y estiman las historias
             del PRÓXIMO sprint, para que el lunes que viene el
             planning sea rápido.

VIERNES      Sprint review (demo): se enseña el incremento hecho a
             los stakeholders y se recoge feedback.
             Después, retrospectiva: qué mejorar, con acciones.
             El lunes vuelve a empezar.

No es un horario sagrado —cada equipo lo ajusta—, pero te da la forma: ceremonias que abren y cierran, dailies que sincronizan, refinement que prepara el futuro. Ese es el ritmo que vas a vivir.

Comprueba lo que sabes#

Pregunta 1 de 14

¿Qué problema del modelo waterfall (planificarlo todo al principio y entregar al final) viene a resolver el trabajo ágil?

Tu turno#

El ejercicio de este capítulo es un artefacto de empresa de verdad: escribir una user story como la dejarías en un ticket. No hay editor de código aquí; lo escribes tú y luego comparas con las tres soluciones, que muestran la misma historia subiendo de calidad. La distancia entre tu versión y cada tier es lo que el capítulo te está enseñando.

Ejercicio · hazlo en local

Tu primera user story

El Team Builder es el producto de tu equipo. Escribe una user story para una feature concreta (filtrar el roster por rol) con su formato, sus criterios de aceptación verificables y una estimación en story points justificada. Las soluciones muestran la misma historia en tres niveles de calidad. Haz la tuya primero y luego compara: ahí está el aprendizaje.

Paso 1: Una historia legible con la forma correcta

  • Usas el formato "Como [rol] quiero [acción] para [beneficio]".
  • Incluyes algún criterio de aceptación.
  • Le pones una estimación en story points.

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/scrum-y-ceremonias
# abre index.html en el navegador y edita solucion.js
Ver soluciones 
# Filtrar héroes por rol

Como usuario del Team Builder
quiero filtrar los héroes por su rol
para encontrar antes al que busco.

## Criterios de aceptación

- Se puede filtrar por rol.
- El filtro funciona bien.
- Es rápido.

## Estimación

5 puntos.

Por qué este nivel

  • Tiene la forma de una user story y se entiende, que ya es más de lo que se ve en muchos backlogs reales. El problema son los criterios: "que funcione bien" o "que sea rápido" no se pueden verificar, así que nadie sabe cuándo la historia está hecha de verdad.
  • Su consecuencia real: en la demo aparece el clásico "yo pensaba que esto también incluía X". Sin criterios verificables, el "done" es una opinión, la historia se reabre y el sprint que parecía cerrado no lo estaba. El tier "mejor" lo arregla haciendo cada criterio comprobable.