Capítulo 9: Planning Game iteración 2
Capítulo 9: Planning Game iteración 2
Lunes de la segunda semana. El equipo tiene un dato que no tenía la semana pasada: su velocity real. Cinco puntos. No ocho como esperaban. Esa diferencia entre expectativa y realidad es el regalo más valioso que la primera iteración dejó.
Anterior: Primer Small Release | Siguiente: Refactoring y Courage
Velocity: la verdad en números
Carlos dibuja en la pizarra un gráfico simple.
Carlos (TL): “Planificamos ocho puntos. Completamos cinco. Nuestra velocity es cinco. Para esta iteración, planificamos cinco puntos. No seis. No siete. Cinco.”
Diego (Dev): “Pero ya estamos más acomodados. Seguro podemos hacer más.”
Carlos (TL): “Probablemente. Pero la velocity se ajusta con datos, no con optimismo. Si esta semana completamos siete, la próxima planificamos seis, que es el promedio.”
Elena (Dev): “Es como una brújula que se calibra sola.”
Carlos (TL): “Exacto. Kent Beck dice que la velocity no es una meta: es una medición. No intentamos aumentarla artificialmente. Simplemente la observamos y planificamos en consecuencia.”
Ana mira los números con curiosidad.
Ana (PO): “¿Eso significa que con cinco puntos por semana y seis semanas restantes, puedo esperar unos treinta puntos de trabajo?”
Carlos (TL): “Aproximadamente. La velocity puede subir a medida que nos acomodamos. Pero treinta puntos es una estimación conservadora y confiable.”
Ana (PO): “Con eso puedo hablar con los stakeholders. Prefiero un número realista a una promesa inflada.”
Ana re-prioriza
Ana revisa su backlog con los ojos de alguien que ahora sabe cuánto “cuesta” cada cosa.
Ana (PO): “Si solo tengo cinco puntos esta semana, necesito elegir bien. Quiero: mover tarjetas en cualquier dirección, asignar personas a tarjetas, y terminar la story de asignación que quedó pendiente.”
Carlos (TL): “¿Cuánto suman?”
Elena (Dev): “Mover en cualquier dirección es un punto. Asignar personas es tres. La pendiente de la semana pasada ya tiene trabajo hecho, digamos un punto más.”
Carlos (TL): “Cinco puntos exactos. Cabe justo.”
Ana (PO): “Perfecto. ¿Y la deuda técnica que mencionó Carlos el viernes?”
El debate: deuda técnica vs features
Carlos había mencionado en la retrospectiva que había un par de áreas del código que necesitaban limpieza. El equipo debate si dedicar tiempo a eso o a features nuevas.
Carlos (TL): “Hay una parte del dominio donde la lógica de mover tarjetas está mezclada con la validación de columnas. Funciona, pero si agregamos más reglas va a ser difícil de mantener.”
Diego (Dev): “¿Cuánto tomaría limpiarlo?”
Carlos (TL): “Un punto. Medio día de pair.”
Ana (PO): “Pero eso me quita un punto de features.”
Carlos (TL): “Ana, si no limpiamos ahora, cada feature futura va a costar más porque el código es más difícil de modificar. Es como pagar intereses: cuanto más esperas, más pagas.”
Elena (Dev): “En mi proyecto anterior dejamos la deuda técnica sin pagar durante meses. Al final, agregar una feature simple tomaba tres veces más de lo esperado.”
Ana (PO): “Ok. Entiendo la analogía de los intereses. Tomemos un punto para limpiar. Pero entonces saco la story de asignación pendiente y la paso a la siguiente iteración.”
El equipo acuerda: cuatro puntos de features, un punto de refactoring. Total: cinco puntos.
Carlos (TL): “Noten lo que acaba de pasar. Ana tomó una decisión informada. No le ocultamos la deuda técnica ni la obligamos a pagarla. Le explicamos el costo y ella decidió. Eso es Communication y Respect.”
Estimando más rápido
Las estimaciones fluyen más rápido que la semana pasada. El equipo ya tiene un punto de referencia: “crear tablero” fue dos puntos. Todo se mide contra eso.
Diego (Dev): “¿Mover tarjeta en cualquier dirección? Un punto. Es la misma lógica que ya tenemos, solo quitamos la restricción de dirección.”
Elena (Dev): “De acuerdo. Un punto.”
Carlos (TL): “¿Asignar personas a tarjetas?”
Elena (Dev): “Tres puntos. Necesitamos un concepto nuevo: personas. El dominio, la API y la pantalla.”
Diego (Dev): “Tres me parece justo.”
No hay debate largo. No hay planning poker con cartas. Solo cuatro personas que ya comparten contexto y hablan el mismo lenguaje.
El tablero de la iteración 2
Carlos actualiza el tablero en la pizarra. Cuatro tarjetas en “Por hacer”:
- Mover tarjeta en cualquier dirección (1 punto)
- Concepto de persona en el dominio (1 punto, parte de asignar)
- Asignar persona a tarjeta, API y pantalla (2 puntos)
- Refactoring: separar lógica de movimiento y validación (1 punto)
Ana (PO): “Me gusta que el refactoring esté visible en el tablero. Así sé que están invirtiendo en calidad, no solo en features.”
Carlos (TL): “Transparencia total. Nunca escondemos trabajo técnico. Si tiene valor, merece estar en el tablero.”
Práctica XP del capítulo
Planning Game (segunda ronda): La segunda sesión de Planning Game es más fluida que la primera porque el equipo tiene velocity real como guía. Kent Beck enfatiza que la planificación en XP no es un compromiso inamovible: es una conversación continua entre el negocio y el equipo técnico. Cada iteración refina las estimaciones y mejora la previsibilidad. La discusión sobre deuda técnica vs features es un ejemplo de cómo el negocio y la técnica negocian con respeto mutuo.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Re-prioriza con datos reales, decide invertir en refactoring |
| Carlos | Facilita, presenta velocity, expone deuda técnica con honestidad |
| Diego | Estima con más confianza, usa referencias de la iteración anterior |
| Elena | Aporta estimaciones calibradas, comparte experiencia pasada |
Anterior: Primer Small Release | Siguiente: Refactoring y Courage