Extreme Programming: Simulación de un equipo real
Extreme Programming: Simulación de un equipo real
“Extreme Programming es sobre cambio social. Se trata de soltar los hábitos y patrones que fueron adaptativos en el pasado, pero ahora se interponen en el camino de hacer buen trabajo.” — Kent Beck
Siguiente: El equipo se reúne
Sobre este tutorial
Este tutorial es diferente. No hay código. Ni una sola línea. Lo que vas a leer es la simulación de un equipo real aplicando Extreme Programming durante varias semanas para construir un tablero Kanban.
Conocerás a cuatro personas:
| Persona | Rol | Personalidad |
|---|---|---|
| Ana | Product Owner | Pragmática, enfocada en el valor de negocio |
| Carlos | Tech Lead | Experimentado en XP, paciente, mentor |
| Diego | Developer | Entusiasta pero impulsivo, primer contacto con XP |
| Elena | Developer | Metódica, viene de equipos waterfall, escéptica al inicio |
El proyecto que construyen usa FastAPI (Python) en el backend con Arquitectura Hexagonal y React en el frontend. Pero eso es solo el contexto. Lo que importa es cómo trabajan juntos.
Filosofía
Este tutorial está basado en la saga de libros de Kent Beck: Extreme Programming Explained: Embrace Change (1ra y 2da edición). Los cinco valores de XP guían cada capítulo:
- Communication — Hablar cara a cara, no por tickets
- Simplicity — Hacer lo más simple que podría funcionar
- Feedback — Ciclos cortos, aprender rápido
- Courage — Decir la verdad, cambiar lo que no funciona
- Respect — Cada persona aporta valor al equipo
Índice de capítulos
Fase 1: Formación del equipo y arranque
- El equipo se reúne — Ana presenta la visión. Carlos propone XP. El equipo acepta el compromiso.
- Planning Game inicial — User stories en tarjetas. Estimación. Primera iteración definida.
- Metaphor y arquitectura — La metáfora del sistema. Arquitectura Hexagonal sin jerga.
- Setup y coding standards — Convenciones del equipo. CI desde el día 1.
Fase 2: Primera iteración — Lo mínimo
- Día 1: Primer pair programming — Diego y Elena hacen pair. TDD como disciplina.
- Día 2: Feedback temprano — Ana cambia una prioridad. El equipo se adapta.
- Día 3: Integración continua real — Primer conflicto de merge. “Si duele, hazlo más seguido.”
- Primer Small Release — Demo a Ana. Retrospectiva. Sustainable pace.
Fase 3: Iteraciones de crecimiento
- Planning Game iteración 2 — Velocity real vs estimada. Re-priorización.
- Refactoring y Courage — Código que huele mal. Miedo a romper cosas. Tests como red de seguridad.
- Collective Code Ownership — Nadie es dueño de nada. Conflicto y resolución.
- El cliente cambia de opinión — Cambio grande: swimlanes. Negociación sana.
- Segundo Small Release — Demo con stakeholders. Feedback real de usuarios.
Fase 4: Madurez del equipo
- Whole Team en crisis — Bug en producción. Sin culpables. Whole team lo resuelve.
- Sustainable Pace — No a las horas extra. Calidad sobre velocidad.
- On-site Customer — Ana presente todo el día. Velocidad de decisiones.
- Retrospectiva profunda — 6 iteraciones completadas. Métricas y ajustes.
Fase 5: Entrega y cierre
- Release Planning — Planificación del release final. Scope vs tiempo.
- Release final — Deploy a producción. Primer usuario real.
- Lecciones aprendidas — Retrospectiva final. Qué llevarían al próximo proyecto.
Cómo leer este tutorial
Lee los capítulos en orden. Cada uno construye sobre el anterior. No necesitas saber programar para entender lo que sucede. Si eres developer, te vas a identificar con Diego y Elena. Si eres líder técnico, con Carlos. Si eres product owner, con Ana.
Al final de cada capítulo encontrarás:
- Práctica XP del capítulo: qué práctica de Kent Beck se aplicó
- Qué hace cada uno: una tabla con el rol de cada persona en ese momento
Siguiente: El equipo se reúne