Antes de empezar. El backend persistente ya está publicado y has trabajado transacciones en Servidor. Hoy priorizarás la evolución del mismo producto para el segundo trimestre.
Se explica
25 minutos · explicación y demostración
El producto de septiembre continúa en el segundo trimestre. Ya tiene CRUD, relaciones y persistencia; ahora debe evolucionar según necesidades concretas. La sesión no consiste en buscar otro tema ni en volver a justificar desde cero el elegido.
Una mejora describe un problema observado y el resultado que permitiría resolverlo. «Añadir JWT» es una solución técnica; «cada persona solo modifica sus reservas» expresa la necesidad que después guiará identidad y permisos.
Reutilizaremos las incidencias, decisiones y comentarios reunidos durante el trimestre. Compararemos valor, esfuerzo y dependencias para elegir un incremento viable. La autenticación se implementará cuando llegue la UD9 de Servidor; hoy se puede describir quién necesita hacer qué sin saber aún configurar Spring Security.
Se trabaja
140 minutos · trabajo guiado sobre el producto compartido
Bloque A · Observar el producto actual
Abre la versión persistente publicada y pide a otra persona que realice un recorrido del contrato. Anota dónde duda, qué dato necesita y qué acción no puede completar. Distingue un fallo reproducible de una petición de mejora. Guarda los hallazgos en el tablero actual, indicando la versión observada.
Bloque B · Proponer tres mejoras del mismo dominio
En la propuesta de evolución escribe tres candidatas con necesidad, persona afectada, comportamiento actual y criterio de aceptación. Ejemplo: en préstamos, impedir que un socio cierre el préstamo de otro. Conserva las entidades del producto y señala qué relación o regla cambia; no añadas tablas únicamente para aumentar el número.
Bloque C · Ordenar por dependencias
Para cada candidata anota qué requiere de Servidor: filtros/paginación (29–30), cliente (33–34), identidad/permisos (35–40), integración externa (41–44). Marca una mejora principal y deja las demás en backlog. Divide la principal en cambios revisables: contrato, implementación, prueba y despliegue. El trabajo de implementación enlaza con las issues de Servidor.
Bloque D · Contrastar y decidir
La persona revisora intenta reproducir la necesidad y comprobar el criterio sin conocer la solución. Si el criterio dice «mejorar», concreta un resultado observable. Actualiza la ficha con la decisión y lo que queda fuera. No cambies de repositorio ni de autoría/equipo respecto a Servidor.
Bloque E · Preparar el cierre común
Enlaza la propuesta de evolución desde el registro de la sesión y desde la release candidata del primer trimestre. Comprueba que los defectos que impiden la entrega siguen siendo prioritarios frente a las mejoras futuras. Prepara los enlaces a producto, PR, CI y versión para la defensa conjunta de la próxima semana.
Cierre
15 minutos · comprobación del resultado
Al terminar la sesión: Tienes una mejora priorizada, su necesidad justificada y sus dependencias identificadas. Explica qué conserva del producto actual y qué cambio observable aportará.