El Juego de Planificación

El juego de planificación de XP se basa en un principio simple: El negocio decide qué construir. Los desarrolladores deciden cómo construirlo.

Esta separación es crítica:

• El negocio entiende el valor, la prioridad y el tiempo. Saben qué funcionalidades importan a los clientes y cuándo se necesitan.
• Los desarrolladores entienden el esfuerzo, la complejidad y las restricciones técnicas. Saben qué es difícil y qué es fácil.

Ninguno puede hacer el trabajo del otro. El negocio no puede estimar el esfuerzo técnico. Los desarrolladores no pueden decidir la prioridad del negocio. El juego de planificación los reúne con roles claros.

El negocio elige:

• Qué funcionalidades construir
• En qué orden construirlas
• Cuándo lanzar

Los desarrolladores proporcionan:

• Estimaciones para cada funcionalidad
• Opciones técnicas y compensaciones
• Evaluaciones de riesgo

La planificación de lanzamiento responde: ¿Qué estará en el próximo lanzamiento y cuándo se enviará?

XP dice que puedes fijar dos de estas tres variables:

• Alcance: Qué funcionalidades se incluyen
• Cronograma: Cuándo se envía el lanzamiento
• Recursos: Quién está trabajando en ello

No puedes fijar las tres. Algo tiene que ser flexible.

Lanzamiento con fecha fija: "Enviamos el 1 de marzo. ¿Cuánto podemos lograr?" El alcance es negociable.

Lanzamiento con alcance fijo: "Necesitamos estas funcionalidades. ¿Cuándo podemos enviarlas?" La fecha es negociable.

El proceso del juego de planificación:

1. El negocio lista las funcionalidades deseadas en orden de prioridad
2. Los desarrolladores estiman cada funcionalidad
3. Basándose en la velocidad, calculan cuántas funcionalidades caben para la fecha (o cuánto tiempo tomará completar el alcance)
4. El negocio ajusta las prioridades si es necesario
5. Comprometerse con un plan, pero esperar replanificar

Replanifica regularmente. A medida que aprendes más, actualiza el plan de lanzamiento. XP no asume que el plan inicial es sagrado.

La planificación de iteración es más detallada. Ocurre al inicio de cada iteración (usualmente semanal o quincenal).

El proceso:

1. El negocio presenta las historias de mayor prioridad para la iteración
2. Los desarrolladores dividen las historias en tareas (fragmentos de 2-4 horas)
3. Los desarrolladores se asignan tareas según interés y habilidad
4. El equipo se compromete con lo que completarán esta iteración

Reglas clave:

• Solo el negocio establece la prioridad
• Solo los desarrolladores estiman y se comprometen
• No te comprometas en exceso (deja margen para lo inesperado)
• Incluye trabajo técnico (infraestructura, refactorización) en el plan

Durante la iteración:

• Rastrea el progreso visiblemente (tablero kanban, burndown)
• Si estás fuera de curso, comunícalo inmediatamente
• No agregues alcance a mitad de iteración (protege el enfoque)
• Si vas adelantado, toma la siguiente historia

La planificación de iteración es más ligera que la planificación de lanzamiento. Las historias ya están estimadas. El enfoque está en dividirlas en tareas y comprometerse con cantidades realistas.

Los planes cambian. XP espera esto y construye adaptación.

Cuándo ajustar:

• Las estimaciones estaban equivocadas (la historia fue más grande de lo esperado)
• Las prioridades cambiaron (el cliente descubrió nuevos requisitos)
• La capacidad del equipo cambió (enfermedad, rotación)
• Las dependencias externas fallaron (API no lista)

Cómo ajustar:

1. Expón el problema inmediatamente (transparencia)
2. Cuantifica el impacto (estamos 2 historias atrasados)
3. Propón opciones (reducir alcance, extender o reducir calidad—pero nunca calidad)
4. El negocio decide (ellos tienen la prioridad)

Lo que nunca cambia: Calidad. XP no intercambia calidad por alcance o cronograma. Si estás atrasado, envías menos—no más descuidado.

El juego de planificación asume ajuste continuo. El plan inicial es un punto de partida, no un compromiso con un resultado exacto. Como dice Kent Beck: "El propósito de planificar es la planificación, no el plan."

El juego de planificación requiere un cliente—alguien que represente las prioridades del negocio.

Esto podría ser:

• El usuario final real (ideal pero raro)
• Un product owner (terminología Scrum)
• Un gerente de producto
• Un analista de negocio

El cliente debe:

• Estar disponible para responder preguntas (idealmente a diario)
• Tomar decisiones de prioridad rápidamente
• Aceptar compensaciones cuando las cosas cambian
• Proporcionar criterios de aceptación para las historias

El "cliente en sitio" de XP originalmente significaba alguien físicamente presente con el equipo. En equipos distribuidos modernos, "en sitio" podría significar "en Slack" o "en el standup diario". La clave es la disponibilidad, no la ubicación física.

Sin un cliente, la planificación falla. Los desarrolladores adivinan la prioridad. El alcance se expande porque nadie decide qué queda fuera. El equipo construye lo incorrecto.