Decidir con lo que mostró el sprint

Lo que mostró el piloto

En la Review del Sprint 1, tres clubes (Robótica, Teatro y Debate) usaron la app durante una semana. Camila volvió a la Retro con esto anotado, y con el backlog tal como estaba antes del piloto: 1) Notificar a Bienestar de cada reserva (8 puntos), 2) Calendario visual con colores (8 puntos), 3) Reservas semanales (5 puntos).

Backlog vivo: evidencia vs. opinión

Un ítem del backlog es una apuesta: "creemos que esto le sirve a este usuario". Cada sprint trae datos que confirman o desmienten esa apuesta. La disciplina es distinguir lo que alguien observó de lo que alguien supone, y dejar que lo primero pese más al ordenar.

Con esa lectura, el backlog de Camila queda así. Nada se borró: lo que bajó sigue visible, con la razón anotada, por si más adelante llega evidencia a favor.

¿Cuántos puntos entran al Sprint 2?

El backlog ya está reordenado. Ahora toca el Planning del Sprint 2. En el Sprint 1 el equipo planificó 24 puntos (seis historias) y terminó 15 (cuatro historias que cumplen la Definition of Done). Las otras dos, de 5 y 4 puntos, quedaron "casi listas": con el código escrito, pero sin pruebas ni revisión. Bienestar espera la app completa dentro de cuatro sprints más.

Velocidad y pronóstico

La velocidad (velocity) es la cantidad de puntos de historias terminadas en un sprint. Solo cuenta lo que cumple la Definition of Done: una historia con la mitad del trabajo hecho suma cero. Con la velocidad de los últimos sprints, el equipo pronostica cuánto comprometer y cuándo llegaría al final del backlog.

Para saber si la fecha es realista se divide lo que falta por la velocidad. Con 60 puntos restantes en el backlog y 15 por sprint, el equipo necesita 4 sprints. Si Bienestar quiere la app en 3, la conversación correcta es de alcance ("¿qué sale de la lista?"), no de horas extra.

"¿Y si lo ordenamos con un Repository?"

La historia que encabeza el Sprint 2 es "reservas semanales": un club pide el mismo salón y horario durante varias semanas. Si alguna de esas semanas choca con otra reserva, no se crea ninguna. Hoy la lógica de reservas arma sus consultas SQL directo, en seis lugares de reservas.js. Valentina propone un Repository. Mateo duda: "¿no es meterle ingeniería de más a algo que funciona?"

import { db } from "./db.js";

export function reservarSemanal({ club, espacioId, inicio, fin, semanas }) {
  const existentes = db
    .prepare("SELECT inicio, fin FROM reservas WHERE espacio_id = ?")
    .all(espacioId);            // ← la consulta vive dentro de la regla
  // ...regla: revisar choques semana por semana...
  db.prepare("INSERT INTO reservas ...").run(/* ... */);
}

Repository: el bibliotecario de tus datos

Pensalo como una biblioteca. Vos le pedís al bibliotecario "dame los libros del estante 3" y "guardá este libro". No te importa si el catálogo es un fichero de papel o una computadora: él sabe cómo, y vos solo hacés el pedido. Un Repository es ese bibliotecario: el resto del programa le pide reservas y él se ocupa de dónde y cómo se guardan.

El "contrato" son solo dos pedidos. JavaScript no tiene interfaces: el equipo lo escribe y lo respeta.

La versión más simple posible del bibliotecario es una lista dentro de la memoria. Son ocho líneas y sirve para las pruebas:

export class ReservasEnMemoria {
  #datos = [];                                   // una lista, nada más
  delEspacio(espacioId) {
    return this.#datos.filter((r) => r.espacioId === espacioId);
  }
  guardar(reserva) {
    this.#datos.push(reserva);
  }
}

export class ReservasSqlite {
  constructor(db) {
    this.db = db;
    db.exec(`CREATE TABLE IF NOT EXISTS reservas (
      id INTEGER PRIMARY KEY, club TEXT, espacio_id INTEGER, inicio INTEGER, fin INTEGER)`);
  }
  delEspacio(espacioId) {
    return this.db
      .prepare("SELECT club, espacio_id AS espacioId, inicio, fin FROM reservas WHERE espacio_id = ?")
      .all(espacioId);
  }
  guardar(r) {
    this.db
      .prepare("INSERT INTO reservas (club, espacio_id, inicio, fin) VALUES (?, ?, ?, ?)")
      .run(r.club, r.espacioId, r.inicio, r.fin);
  }
}

¿De dónde saca el servicio su repositorio?

Valentina ya tiene los dos repositorios. Falta escribir ReservasService, la clase con la regla de "reservas semanales". Ahora hay que decidir cómo consigue el repositorio que va a usar.

Inyección de dependencias: que se lo pasen

Es una idea sencilla: en vez de que un objeto cree lo que necesita, se lo pasan desde afuera. Como cuando el cajero no fabrica su propia caja registradora: se la dan al empezar el turno. No requiere ningún framework; alcanza con un parámetro del constructor.

Así queda el servicio completo para la regla "no reservar un horario ocupado". Son pocas líneas y no menciona SQLite en ningún lado:

export class ReservasService {
  constructor(repo) {
    this.repo = repo;                  // ← llega de afuera
  }

  reservar(nueva) {
    const ocupado = this.repo
      .delEspacio(nueva.espacioId)
      .some((r) => hayChoque(r, nueva));
    if (ocupado) return false;
    this.repo.guardar(nueva);
    return true;
  }
}

Y quien decide cuál bibliotecario usar es un solo lugar, el main.js (la raíz de composición). Las pruebas hacen la misma elección, pero con el de memoria:

// main.js — la app real
const servicio = new ReservasService(new ReservasSqlite(db));

// en una prueba
const servicio = new ReservasService(new ReservasEnMemoria());

test("no deja reservar un horario ocupado", () => {
  const servicio = new ReservasService(new ReservasEnMemoria());

  assert.equal(servicio.reservar({ espacioId: 1, inicio: 10, fin: 12 }), true);
  assert.equal(servicio.reservar({ espacioId: 1, inicio: 11, fin: 13 }), false);  // choca
  assert.equal(servicio.reservar({ espacioId: 1, inicio: 12, fin: 14 }), true);   // contigua: no choca
});

const SEMANA = 7 * 24 * 60 * 60 * 1000;

reservarSemanal({ club, espacioId, inicio, fin, semanas }) {
  const nuevas = [];
  for (let i = 0; i < semanas; i++) {
    const r = { club, espacioId, inicio: inicio + i * SEMANA, fin: fin + i * SEMANA };
    const choque = this.repo.delEspacio(espacioId).some((x) => hayChoque(x, r));
    if (choque) return { ok: false, semana: i + 1 };
    nuevas.push(r);
  }
  nuevas.forEach((r) => this.repo.guardar(r));   // recién acá se guarda: todo o nada
  return { ok: true, creadas: nuevas.length };
}

"Hagamos lo mismo con los clubes"

Mateo, ya convencido, quiere aplicar el patrón a listarClubes(), la función que llena el desplegable de clubes. Es un único SELECT, se llama desde un solo lugar, no tiene ninguna regla de negocio y nunca causó una prueba fallida.

Cuándo ayuda y cuándo estorba

Un patrón de diseño no es un objetivo: es una herramienta para un dolor concreto. Un Repository con inyección de dependencias cuesta algo (más archivos, dos implementaciones que mantener, un salto más para leer el código), y ese costo tiene que quedar compensado por algo visible. La misma lógica de la primera mitad de la guía: decidir con evidencia, no con costumbre.

Actividades de repaso

Un repaso integrador de lo que acabás de recorrer. Cada actividad se corrige al instante; tu progreso se guarda automáticamente en este navegador.

🎯 Reto Final: tu backlog y tu patrón

Ahora con el proyecto real de tu equipo. Escribí, en no más de un párrafo por punto: 1) una evidencia concreta del último sprint (de uso, de la Retro o de tus números) que justifique mover un ítem de lugar en tu backlog, y qué ítem bajaría por falta de evidencia, 2) tu velocidad de los sprints que llevás y cuántos puntos vas a comprometer en el próximo, 3) un lugar de tu código donde un Repository con inyección ayudaría y otro donde estorbaría, con la señal que usaste para decidir.

Cheat Sheet

¿Sabías que...?