Capítulo 2: Planning Game inicial
Capítulo 2: Planning Game inicial
Martes por la mañana. Ana llega con un paquete de tarjetas de índice y un marcador grueso. El Planning Game es el corazón de la planificación en XP: el negocio decide qué es importante y los desarrolladores dicen cuánto cuesta.
Anterior: El equipo se reúne | Siguiente: Metaphor y arquitectura
Ana presenta las stories
Ana reparte tarjetas sobre la mesa. Cada una tiene una frase escrita en lenguaje de negocio.
Ana (PO): “He escrito lo que necesitan los usuarios. Una idea por tarjeta. No les digo cómo hacerlo, les digo qué necesitan.”
Las tarjetas dicen cosas como:
- “Como usuario, quiero crear un tablero nuevo para organizar mi trabajo”
- “Como usuario, quiero agregar columnas a mi tablero”
- “Como usuario, quiero crear tarjetas dentro de una columna”
- “Como usuario, quiero mover una tarjeta de una columna a otra”
- “Como usuario, quiero asignar una persona a una tarjeta”
- “Como usuario, quiero ver quién está trabajando en qué”
- “Como usuario, quiero archivar tarjetas completadas”
- “Como usuario, quiero poner límites WIP en las columnas”
Diego (Dev): “¿Límites WIP?”
Ana (PO): “Work In Progress. Si una columna tiene límite de tres, no puedes agregar una cuarta tarjeta hasta que muevas una. Es lo que hace que un Kanban sea un Kanban.”
El equipo estima
Carlos explica la mecánica del Planning Game.
Carlos (TL): “Ana decide qué es importante. Nosotros decimos cuánto esfuerzo cuesta. Usamos puntos, no horas. Un punto es la story más pequeña que podamos imaginar.”
Elena (Dev): “¿Por qué puntos y no horas?”
Carlos (TL): “Porque las horas nos tientan a comprometernos con fechas exactas. Los puntos miden complejidad relativa. Una story de dos puntos es el doble de compleja que una de un punto, no el doble de horas.”
El equipo toma la primera tarjeta: “crear un tablero nuevo”.
Diego (Dev): “Eso suena simple. Un punto.”
Elena (Dev): “¿Pero incluye persistencia? ¿El tablero se guarda?”
Ana (PO): “Sí, si cierro el navegador y vuelvo, el tablero debe estar ahí.”
Elena (Dev): “Entonces no es un punto. Necesitamos base de datos, API, pantalla. Yo digo tres puntos.”
Carlos (TL): “Bien. Tenemos discrepancia: uno contra tres. Eso es valioso. Diego, ¿por qué dijiste uno?”
Diego (Dev): “Estaba pensando solo en la interfaz.”
Elena (Dev): “Y yo estaba pensando en el flujo completo.”
Carlos (TL): “Siempre estimamos el flujo completo: desde que el usuario hace clic hasta que los datos están guardados. ¿Qué les parece dos puntos como compromiso?”
Ambos asienten. Dos puntos para “crear tablero”.
Priorizando las stories
Con todas las stories estimadas, Ana las ordena en la mesa por prioridad.
Ana (PO): “Lo primero que necesito ver funcionando es: crear tablero, agregar columnas y crear tarjetas. Sin eso, no hay producto.”
Carlos (TL): “¿Y mover tarjetas?”
Ana (PO): “Es importante, pero puedo vivir una semana sin eso si me muestran que las otras tres funcionan.”
Diego (Dev): “¿Y los límites WIP?”
Ana (PO): “Eso puede esperar. Es la cereza del pastel, no el pastel.”
Ana separa las tarjetas en dos grupos: “primera iteración” y “después”. Carlos suma los puntos del primer grupo.
Definiendo “done”
Carlos plantea una pregunta que incomoda.
Carlos (TL): “¿Cuándo una story está terminada? Necesitamos acordar qué significa ‘done’.”
Diego (Dev): “Cuando el código funciona.”
Carlos (TL): “¿Y los tests?”
Diego (Dev): “Ah, sí. Cuando funciona y tiene tests.”
Elena (Dev): “Y cuando pasa CI. No quiero que algo ‘funcione’ en la máquina de Diego pero no en el servidor.”
Ana (PO): “Y cuando yo puedo verlo funcionando. No me sirve algo que solo existe en la terminal de alguien.”
El equipo define “done” como:
- Tests escritos y pasando
- Código integrado en la rama principal
- CI verde
- Ana puede verlo funcionando en un entorno accesible
Carlos (TL): “Eso es un Definition of Done sólido. Noten que no dije ‘documentado’ ni ‘optimizado’. Simple Design: lo mínimo necesario para que sea útil y confiable.”
La primera iteración
El equipo acuerda su primera iteración de una semana. Las stories seleccionadas suman ocho puntos. Nadie sabe si es mucho o poco porque es su primera iteración juntos.
Elena (Dev): “¿Y si no terminamos todo?”
Carlos (TL): “Entonces aprendemos nuestra velocity real. La primera iteración es un experimento. No es un compromiso de sangre.”
Ana (PO): “¿No me van a prometer que terminan?”
Carlos (TL): “No. Te vamos a prometer que vamos a trabajar disciplinadamente y que al final de la semana sabremos cuántos puntos podemos hacer por iteración. Esa información vale más que una promesa vacía.”
Ana frunce el ceño pero asiente. Carlos tiene razón: una promesa basada en datos es mejor que un compromiso basado en esperanza.
El tablero del Planning Game
Carlos toma la pizarra y dibuja tres columnas: “Por hacer”, “En progreso” y “Hecho”. Pega las tarjetas de la primera iteración en “Por hacer”.
Diego (Dev): “Estamos usando un Kanban para construir un Kanban.”
Carlos (TL): “La meta-ironía de la ingeniería de software.”
El equipo se ríe. Es el primer momento de levedad desde que empezaron. Ana toma una foto del tablero con su teléfono.
Práctica XP del capítulo
Planning Game: En XP, la planificación es un juego con dos jugadores. El negocio (Ana) decide el alcance y las prioridades. El equipo técnico decide las estimaciones y la forma de construir. Ningún jugador puede hacer las dos cosas. Kent Beck enfatiza que la planificación es un acto de comunicación: el negocio dice qué necesita, el equipo dice qué cuesta, y juntos encuentran el mejor plan posible para la siguiente iteración.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Escribe stories, define prioridades, acepta el Definition of Done |
| Carlos | Facilita el Planning Game, enseña la mecánica de estimación |
| Diego | Estima, descubre que no consideraba el flujo completo |
| Elena | Estima con más rigor, aporta criterio técnico al Definition of Done |
Anterior: El equipo se reúne | Siguiente: Metaphor y arquitectura