Parte III. El Sprint con IA
Descubrir y entregar a la vez
Dual track: por qué las specs no son una cascada
Seis semanas sin hablar con un socio
GymApp nunca había entregado tan rápido. En seis semanas habían salido once mejoras: el aviso de plazas, el filtro de clases, el historial de entrenamientos, el modo oscuro. Héctor abría cada Sprint Review con una diapositiva llena de cosas terminadas.
Celia hizo la pregunta incómoda en la Retrospectiva: ¿cuándo fue la última vez que alguien habló con un socio? Nadie se acordaba. Las mejoras salían de las reseñas de las tiendas, de peticiones de los centros y de ideas del propio equipo. Todas razonables. Ninguna comprobada antes de construirla.
Ramón, que estaba de invitado, añadió otra cosa. Desde que el equipo escribía specs para los agentes, alguien del comité le había preguntado si habían vuelto a la cascada: primero el documento, luego el código.
La objeción tiene sentido
El miedo es razonable. Si todo empieza por una spec, parece que hemos vuelto a las fases: primero se analiza, luego se construye. Y la cascada fracasó por algo: cuando terminabas de construir, descubrías que algunas cosas analizadas no eran ciertas.
Pero lo que hace cascada a una cascada no es que haya un documento antes del código. Es el tamaño del lote y la dirección del aprendizaje. Un documento de cien páginas que se escribe una vez y se entrega a otro equipo es cascada. Una spec de media página, de un solo elemento, escrita la semana antes de construirlo y corregida con lo que se aprendió en el Sprint anterior, no lo es.
Dos carriles, un equipo
El dual track ordena esto. Lo describió Desirée Sy en 2007, a partir de su trabajo de diseño en Alias (hoy Autodesk), y lo popularizó Marty Cagan. Son dos carriles de trabajo en el mismo equipo y en el mismo Sprint:
- El carril de descubrimiento decide qué merece la pena construir. Habla con usuarios, prueba prototipos, mira datos y convierte ideas en hipótesis con evidencia.
- El carril de ejecución construye lo que ya está validado, con calidad y listo para producción.
No son dos equipos. Son las mismas personas con distinto peso en cada carril: el Product Owner y el diseño pesan más en descubrimiento; los desarrolladores y los agentes, en ejecución. Pero los desarrolladores participan en descubrimiento, porque saben qué es caro y qué es fácil, y el Product Owner participa en ejecución, porque decide qué está listo para salir.
La spec como punto de paso
La spec es la frontera entre carriles. Un elemento pasa de descubrimiento a ejecución cuando tiene su spec: pequeña, de un solo elemento, con la evidencia que justifica construirlo y con ejemplos que permiten comprobarlo.
Y el aprendizaje vuelve en sentido contrario. Lo que se descubre al construir (que un caso no estaba previsto, que algo es más caro de lo que parecía) vuelve al carril de descubrimiento y cambia las siguientes specs. Esa vuelta es lo que la cascada no tenía.
Con IA, un carril se come al otro
Con IA, el carril de ejecución corre tanto que puede comerse al otro. Si construir algo cuesta una tarde, parece absurdo dedicar una semana a comprobar si hace falta. Es justo al revés: cuanto más barato es construir, más cosas se construyen sin comprobar, y más caro sale el conjunto.
Por eso el descubrimiento necesita capacidad reservada. No "cuando haya tiempo", porque con IA nunca hay tiempo: siempre hay algo más que entregar.
Cómo se ve en el Sprint
- En el tablero, dos zonas: lo que se está descubriendo y lo que se está construyendo, con un límite de trabajo en curso en cada una.
- El refinamiento es la frontera entre el descubrimiento y la ejecución: ahí se traslada a una spec aquellas características con un riesgo bajo a nivel de negocio, técnico y funcional.
- La Sprint Review mira los dos carriles: lo que se ha entregado y lo que se ha aprendido, incluidas las ideas que se han descartado.
- El Sprint Goal puede ser de cualquiera de los dos: entregar algo o resolver una duda importante.
GymApp decidió reservar dos días por Sprint de Celia y Héctor, y medio día de un desarrollador, para el carril de descubrimiento. La primera pregunta que tenía que contestar era la que llevaba meses en el aire: ¿qué hacen los socios que se dan de baja?
En resumen
Las specs no son una cascada si son pequeñas, frecuentes y el aprendizaje vuelve hacia atrás. Dos carriles en el mismo equipo y el mismo Sprint: descubrimiento decide qué merece la pena; ejecución construye lo validado. Con IA, hay que proteger el primero.
Pruébalo esta semana
Reserva una parte fija del próximo Sprint para descubrir, aunque sea pequeña, y escribe qué pregunta tiene que contestar. En la Review, cuenta lo que habéis aprendido con el mismo detalle que lo que habéis entregado.
Si en tu empresa alguien sigue viendo las specs como una cascada, el artículo ¿Spec-Driven Development es waterfall? responde con más detalle según el tipo de aplicación.