Sprint 0: el kickoff de EventoUAB
Antes de escribir una sola línea de código, tu equipo tiene que decidir cómo va a trabajar, no solo qué va a construir. Esta guía recorre las primeras decisiones reales de un proyecto de Ingeniería de Software: elegir entre un proceso secuencial o uno iterativo, definir la visión y el alcance del producto, acordar reglas de equipo y armar el primer Product Backlog — todavía crudo, a propósito.
👁 — vistas · Ing. Roy Carrasco, Facultad de Ingeniería de Sistemas · UAB
Vas a acompañar el kickoff de EventoUAB — la app que te encargó Bienestar Estudiantil de la UAB para reservar los espacios donde los clubes hacen sus eventos. En cada decisión podés probar primero un camino equivocado, ver su consecuencia sin ninguna penalidad, y recién después se desbloquea el correcto.
El mismo encargo, dos caminos posibles
Bienestar Estudiantil te dio el encargo en una reunión de 20 minutos: "necesitamos una forma de reservar los espacios para eventos de club, ahora todo se coordina por WhatsApp y se duplican reservas todo el tiempo." Nada más. Ninguna otra especificación. Tu equipo de cuatro personas, recién formado, tiene que decidir cómo arranca.
Antes de elegir lenguaje o framework, el equipo tiene que elegir un proceso: ¿planificar todo antes de construir, o construir un poco y aprender sobre la marcha?
¿Cómo arranca tu equipo el Sprint 0?
Sin ponerse de acuerdo primero en qué problema resuelven y para quién, cada integrante termina construyendo una parte distinta de una app distinta. No hay una sola pieza que puedan mostrar junta al final de dos semanas. Probá con otra opción.
Pedir la especificación completa por escrito asume que hoy ya se sabe todo lo que la app va a necesitar. Bienestar Estudiantil tampoco lo sabe todavía — ni siquiera si prefiere reservar por franja horaria o por día completo. Ese documento va a quedar desactualizado la primera semana. Probá con otra opción.
Exacto. En Sprint 0 no se escribe código: se define el problema, el usuario y un primer recorte chico y mostrable. Seguí leyendo ↓
Cascada vs. Iterativo: por qué el orden importa
Un proceso secuencial (cascada) analiza, diseña, construye, prueba y entrega una sola vez, de punta a punta. Un proceso iterativo recorre los mismos pasos, pero en ciclos cortos que se repiten — cada ciclo entrega algo real y trae de vuelta lo que el usuario opinó.
| Aspecto | Cascada (secuencial) | Iterativo (Scrum) |
|---|---|---|
| Orden del trabajo | Analizar → Diseñar → Construir → Probar → Entregar, una sola vez | Los mismos pasos, repetidos en ciclos cortos (sprints) |
| Cuándo llega el feedback del usuario | Al final, cuando ya está casi todo construido | Cada pocas semanas, sobre un incremento real y usable |
| Costo de un requisito mal entendido | Alto: se descubre tarde, con gran parte del sistema ya construido sobre ese supuesto | Bajo: se descubre en el primer o segundo incremento, antes de construir el resto |
| Cuándo sí conviene | Problema ya bien entendido y estable (ej. construir un puente) | Problema que se termina de entender construyendo — la mayoría del software |
Cada sprint tiene un objetivo claro (Sprint Goal) y un compromiso concreto. La diferencia con cascada no es la ausencia de plan, sino que el plan se revisa cada pocas semanas contra algo real, en vez de una sola vez al principio.
¿Este comportamiento es típico de Cascada o de Iterativo?
Antes de escribir código: ¿para quién es esto?
El equipo quedó entusiasmado con la idea. Uno de tus compañeros ya quiere abrir el editor y empezar a programar la pantalla de login. Pero todavía nadie se puso de acuerdo en quién usa la app todos los días: ¿el estudiante que organiza el evento, cualquier estudiante, o el personal de Bienestar Estudiantil?
¿Qué hace el equipo antes de escribir la primera línea de código?
20 minutos de reunión alcanzan para el encargo, no para saber quién es el usuario real. ¿Reserva el club completo o cada estudiante? ¿Puede cancelar? Sin esa definición, cada integrante programa una suposición distinta. Probá con otra opción.
Construir "todo lo que se les ocurre" antes de validar nada es la misma trampa de la cascada, solo que sin documento: se invierte tiempo en funciones que capaz nadie pidió, y recién se pregunta cuando ya está construido. Probá con otra opción.
Exacto. Esa hoja es la Visión del Producto — no reemplaza al código, lo enfoca. Seguí leyendo ↓
La Visión del Producto en cuatro preguntas
La Visión del Producto no es un documento largo: son cuatro respuestas cortas que todo el equipo puede repetir de memoria. Sirve para que, en la semana 6, nadie tenga que adivinar por qué se está construyendo esto.
| Pregunta | Qué responde | EventoUAB |
|---|---|---|
| Problema | ¿Qué está roto hoy? | Las reservas de espacios para eventos de club se coordinan por WhatsApp y se duplican. |
| Usuario principal | ¿Quién decide si esto sirve? | El estudiante responsable de un club que necesita reservar un espacio. |
| Propuesta de valor | ¿Qué gana ese usuario que hoy no tiene? | Ver en un solo lugar qué espacios están libres y reservar sin esperar respuesta de nadie. |
| Alcance inicial | ¿Qué NO entra todavía? | Pagos, reportes para la decana y notificaciones push quedan para más adelante. |
No es solo "qué va a tener la app": es también, explícitamente, qué queda afuera del primer incremento. Eso es lo que en la próxima guía se traduce en la regla "el Sprint 1 debe ser pequeño".
1. El equipo anota que, por ahora, la app no va a manejar pagos ni reportes. Eso responde .
2. El equipo escribe: "hoy las reservas se duplican porque se coordinan por WhatsApp". Eso responde .
3. El equipo decide que quien usa la app todos los días es el estudiante responsable del club, no el personal de Bienestar Estudiantil. Eso responde .
4. El equipo resume que la app le ahorra al estudiante la espera de una respuesta por WhatsApp. Eso responde .
"Nos conocemos hace dos años, no hace falta un documento"
Con la visión definida, queda organizar cómo va a trabajar el equipo día a día: cuándo se reúnen, cómo se revisan los cambios de cada uno, qué pasa si alguien no llega a tiempo. Un compañero dice: "nos conocemos hace dos años, no hace falta poner reglas por escrito."
¿Qué conviene hacer con las reglas de trabajo del equipo?
Conocerse bien ayuda a llevarse bien, pero no reemplaza acordar reglas operativas: quién revisa un PR, hasta qué hora se puede pedir ayuda, qué pasa si alguien no entrega. Sin eso, el primer conflicto se resuelve improvisando, justo cuando más presión hay. Probá con otra opción.
Un Working Agreement copiado no refleja los horarios ni los acuerdos reales de este equipo — la próxima vez que alguien lo necesite, va a decir algo que el equipo nunca discutió de verdad. Probá con otra opción.
Exacto. No hace falta que sea largo: cinco o seis acuerdos concretos alcanzan, y sirven para señalar el primer choque sin que se vuelva personal. Seguí leyendo ↓
Scrum en 15 minutos
Scrum organiza el trabajo en sprints: ciclos cortos que terminan con algo usable. En un equipo de curso, alguien suele asumir el rol de Product Owner y otro el de Scrum Master, aunque todos programen — lo importante es que las tres preguntas de abajo tengan siempre un responsable claro.
| Rol | Pregunta que responde |
|---|---|
| Product Owner | ¿Qué construimos, y qué va primero? |
| Scrum Master | ¿Estamos trabajando bien como equipo? |
| Desarrolladores | ¿Cómo lo construimos y cuánto entra en el sprint? |
| Pieza | Qué es |
|---|---|
| Sprint Planning | Se define el objetivo del sprint y qué historias entran. |
| Daily Scrum | Minutos diarios del equipo para sincronizarse. |
| Sprint Review | Se muestra el incremento a los interesados y se recoge feedback. |
| Sprint Retrospective | El equipo revisa cómo trabajó y qué mejorar para el próximo sprint. |
| Product Backlog | Lista ordenada de todo lo que el producto podría necesitar. Vive todo el proyecto. |
| Sprint Backlog | Lo elegido para este sprint, más el plan para lograrlo. Se protege durante el sprint. |
| Incremento | Versión usable del producto que cumple la Definition of Done (se profundiza en la guía de Testing). |
Une cada pieza de Scrum con su propósito.
Ideas sueltas antes del primer Sprint Planning
Con la visión y las reglas del equipo listas, aparece una lluvia de ideas: reservar un espacio, ver disponibilidad en un calendario, cancelar una reserva, notificar por correo, iniciar sesión con cuenta UAB, reportes de uso, pagos, un chat con Bienestar Estudiantil. Un compañero quiere redactar ya mismo cada una como historia de usuario completa.
¿Qué hace el equipo con esa lista de ideas sueltas, en esta primera sesión?
Escribir criterios de aceptación detallados todavía es prematuro: en Sprint 0 el Product Backlog arranca como ideas crudas. Pulir ocho historias completas hoy es tiempo perdido si mañana cambia la prioridad — eso se hace en Refinamiento, la próxima sesión. Probá con otra opción.
El backlog no es una lista de lo urgente-ya: una idea que hoy no parece prioritaria puede volverse la más valiosa dentro de tres sprints, cuando el equipo entienda mejor el problema. Descartarla ahora la pierde para siempre — se ordena, no se borra. Probá con otra opción.
Exacto. El backlog inicial es una lista cruda y ordenada a ojo, no una lista perfecta — eso es justamente lo que distingue Sprint 0 de la próxima sesión (Refinamiento + Sprint Planning 1). Llegaste al final del kickoff: repasemos.
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.
En un proyecto con requisitos que van a cambiar seguro (la mayoría del software), ¿por qué un enfoque iterativo suele costar menos que uno secuencial?
El Product Backlog debe quedar perfecto y completo desde el kickoff, antes de arrancar el primer sprint.
¿Cuál de estas listas se protege durante el sprint, sin agregarle nada a mitad de camino salvo excepción justificada?
🎯 Reto Final: el kickoff de tu propio proyecto
Ahora con el producto real de tu equipo en este curso. Escribí, en no más de un párrafo por punto: 1) el problema, el usuario principal, la propuesta de valor y el alcance inicial de tu proyecto, 2) tres reglas concretas de tu Working Agreement, 3) cinco ideas crudas para tu Product Backlog inicial, ordenadas a ojo por valor.
Visión, reglas de equipo y primer backlog de tu proyecto real.
- El problema está escrito en una frase concreta, no en una idea de solución disfrazada de problema.
- El usuario principal es una sola persona o rol, no "todos".
- El alcance inicial dice explícitamente qué NO entra todavía.
- Las reglas del Working Agreement son operativas (cuándo, cómo, qué pasa si), no buenos deseos como "vamos a comunicarnos bien".
- El orden del backlog se puede justificar por valor, no por lo que resulta más fácil de programar primero.
Cheat Sheet
| Término | Idea clave |
|---|---|
| Sprint 0 | Sesión de kickoff: se forma el equipo, se define la visión y arranca el backlog crudo. No se escribe código todavía. |
| Proceso secuencial (cascada) | Analizar, diseñar, construir, probar y entregar una sola vez, de punta a punta. |
| Proceso iterativo | Los mismos pasos, repetidos en ciclos cortos que entregan algo real cada vez. |
| Visión del producto | Problema + usuario principal + propuesta de valor + alcance inicial, en una hoja. |
| Alcance inicial | Dice explícitamente qué NO entra todavía, no solo qué va a tener la app. |
| Working Agreement | Reglas operativas y cortas del equipo: cuándo, cómo se revisa, qué pasa si alguien no entrega. |
| Product Backlog | Lista única, visible y ordenada de todo lo que el producto podría necesitar. Arranca cruda. |
| Sprint Backlog | Lo elegido para este sprint. Se protege: no se cambia sin conversarlo. |
| Product Owner / Scrum Master / Desarrolladores | Qué construir y en qué orden / que el equipo trabaje bien / cómo construirlo y cuánto entra. |
| Incremento | Versión usable del producto al final del sprint, que cumple la Definition of Done. |
¿Sabías que...?
🌊 La "cascada" nunca se llamó así en el paper que la originó
Winston Royce describió el modelo secuencial en un artículo de 1970 — pero para señalar sus riesgos, no para recomendarlo sin más: el propio paper sugería iterar entre fases. El nombre "waterfall" se popularizó después, sin la parte de la advertencia.
🏉 Scrum viene del rugby
El nombre salió de un artículo de 1986 de Takeuchi y Nonaka sobre equipos de desarrollo de producto que avanzaban "como en un scrum": todos empujando juntos, pasándose la pelota, sin una cadena de mando rígida.
🧭 Lo que viene en la próxima guía
Ya tenés la visión y el backlog crudo. El próximo paso es convertir esas ideas sueltas en historias de usuario con criterio: formato, INVEST, criterios de aceptación y estimación con Planning Poker.