Clase 6 — eXtreme Programming (XP): prácticas, roles y cierre del bloque ágil

Resumen Ejecutivo

Última clase del primer bloque (metodologías ágiles). Se profundiza en eXtreme Programming (XP) de Kent Beck (1999), destacada por el profesor como "la más ingenieril" de las metodologías ágiles: propone 12 prácticas concretas y no solo un marco general como Scrum. Se analizan las prácticas agrupadas por ámbito (programación diaria, gestión de equipo, planificación), los roles específicos (programador, cliente, tester, rastreador, coach, big boss), la fase de planificación en dos niveles (release + iteración), el desarrollo dirigido por pruebas (TDD) como práctica nuclear y la refactorización continua. Se cierra con las críticas a XP y el panorama actual: adopción muy baja de XP puro, pero sus prácticas están presentes en híbridos Scrum+XP y evolucionan en DevOps. ⚠️ EXAMEN: saber listar las 12 prácticas, los roles XP, y explicar TDD paso a paso son tres puntos centrales.

Conceptos Clave

eXtreme Programming (XP): metodología ágil de Kent Beck (1999, "Extreme Programming Explained") que lleva al extremo los principios del desarrollo iterativo: iteraciones lo más cortas y simples posibles, entregas lo más continuas posibles.
Las 12 prácticas de XP: ⚠️ EXAMEN — las veremos agrupadas.
Programación en parejas (pair programming): dos personas trabajando en la misma máquina/pantalla; una escribe y otra revisa en tiempo real. Alternan roles.
Desarrollo dirigido por pruebas (TDD): escribir primero la prueba unitaria (que falla), luego el código mínimo para pasarla, luego refactorizar. Red → Green → Refactor. ⚠️ EXAMEN
Refactorización: reescribir código preservando la funcionalidad, con el objetivo de mejorar legibilidad, eficiencia o mantenibilidad. Es parte del día a día, no una actividad puntual.
Propiedad colectiva del código: cualquier miembro del equipo tiene acceso y potestad para modificar cualquier parte del código. Exige estándares compartidos y trabajo en parejas como contrapeso.
Estándares de programación: convenios compartidos por el equipo sobre indentación, nombres, estructura. Ejemplos: PEP8 (Python), camelCase, paquetes minúsculas / clases con mayúscula inicial (Java). No son paradigmas (OO) ni patrones (MVC).
Juego de la planificación: la planificación como diálogo/negociación entre equipo y cliente — "es un juego" en el sentido de cooperación iterativa, no de cálculo estricto.
Metáfora del sistema: analogía del mundo real que guía el diseño (papelera de reciclaje, escritorio, ventana). Facilita la comprensión compartida.
Spike solution: prueba de código rápida "de usar y tirar" para evaluar la viabilidad de una idea o estimar un algoritmo.
Tarjeta CRC (Class-Responsibility-Collaborator): ficha que describe una clase por sus responsabilidades y las clases con las que colabora. Ayuda a detectar baja cohesión y alto acoplamiento.

Desarrollo del Temario

1. Contexto: XP dentro del bloque ágil

Progresión del bloque: 1. Tema 1 — agilidad vs tradicional, panorama general de metodologías. 2. Tema 2-4 — Scrum (marco ágil más fácil de entender y aplicar). 3. Tema 5 (esta clase) — XP, más complicada de llevar a la práctica pero no conceptualmente. Compatible y complementaria con Scrum y otras metodologías.

La idea clave: XP y Scrum no son excluyentes. Muchos equipos operan en híbridos Scrum+XP (Scrum para el marco general, prácticas XP dentro).

2. Valores, principios y fundamentos

Valores originales de Kent Beck: ⚠️ EXAMEN - Comunicación - Simplicidad - Retroalimentación (feedback) - Coraje - Respeto (añadido en 2004)

Se repiten en casi todas las metodologías ágiles. El respeto es especialmente relevante: la programación en parejas exige confianza mutua y aceptar críticas.

Principio filosófico: la agilidad pone a las personas en el centro. Los equipos son pequeños, sin gestor tradicional; las funciones de gestión se diluyen entre todos los miembros.

3. El porqué del "extremo"

Kent Beck lleva al extremo el desarrollo iterativo:

Iteraciones muy cortas (pueden ser semanales).
Entregas potencialmente continuas (enlace natural con DevOps, tema final de la asignatura).
Fases muy solapadas dentro de cada iteración (análisis + implementación + pruebas en paralelo, no en cascada).

La garantía de que podemos entregar con confianza en cada iteración viene de la cobertura de pruebas automatizadas: si tras un cambio las pruebas pasan, el software se mantiene en estado "potencialmente entregable".

4. Las 12 prácticas agrupadas

Grupo	Prácticas
Programación diaria / código	Diseño simple, desarrollo dirigido por pruebas, refactorización, estándares de programación
Equipo	Programación en parejas, propiedad colectiva del código, semana de 40 horas (ritmo sostenible), cliente in situ
Planificación / proceso	Juego de la planificación, entregas pequeñas, metáfora del sistema, integración continua

Interrelación entre prácticas: ⚠️ EXAMEN — las 12 prácticas se apoyan mutuamente. Ejemplo: la propiedad colectiva funciona porque hay programación en parejas (nadie toma decisiones arbitrarias en solitario) + estándares (todos escriben igual) + TDD (los cambios no rompen sin aviso).

5. Flujo del proceso XP

flowchart LR
    Explore[Exploración] --> Plan[Planificación<br/>de release]
    Plan --> Iter[Planificación<br/>de iteración]
    Iter --> Dev[Análisis + Desarrollo + Pruebas<br/>muy solapados]
    Dev --> Accept[Pruebas de aceptación]
    Accept -->|falla| Iter
    Accept -->|pasa| Release[Entrega<br/>potencial]
    Release --> Iter

Fases:

Exploración: entender requisitos, obtener historias de usuario, formar pila de producto. Especialmente relevante en proyectos con alta incertidumbre.
Planificación de release: qué historias se hacen en los próximos meses. Release puede ser de meses.
Planificación de iteración: qué historias se hacen en la iteración actual (1-2 semanas). Diálogo entre cliente y equipo.
Codificación + pruebas + diseño solapados.
Pruebas de aceptación al final de la iteración → si pasan, todo ok y se puede entregar.

Aunque la release esté planificada a meses, con TDD el software está siempre en estado entregable. Las entregas pueden ser tan frecuentes como se quiera.

6. Historias de usuario (en realidad, originadas en XP)

Las historias de usuario no son de Scrum; vienen de XP. Scrum las adoptó porque son útiles, pero sus creadores no las imponen.

Formato canónico: ⚠️ EXAMEN

Como [rol] quiero [funcionalidad] para [objetivo].

Ejemplo:

Como estudiante quiero comprar un pase de parking para poder conducir a la escuela.

Importancia del "para": ayuda a descubrir historias alternativas o descomponer historias grandes. Razonar sobre el objetivo permite ver casos como: - "... para ir con mi coche a diario" → compra normal. - "... para renovar el que tengo caducado" → función de renovación. - "... para que mis familiares vengan a mi defensa de TFG" → pase temporal.

Tarjetas físicas: habitualmente las historias se escriben en tarjetas. Por detrás se anotan criterios de aceptación, descripción técnica, restricciones, restricciones de interfaz, etc.

Criterios de aceptación: definen cuándo la historia está "hecha". Ejemplo para una funcionalidad de reserva médica:

"Los datos obligatorios de la cita son nombre del paciente, fecha, hora, nombre del médico, descripción breve del motivo." "Para insertar nuevas citas debe mostrarse un calendario con franjas horarias disponibles representadas gráficamente."

7. Las 12 prácticas en detalle

7.1. Planificación (Juego de la planificación)

Diálogo iterativo entre cliente y equipo. Dos niveles: release y iteración. Kent Beck tiende a hablar de horas más que de puntos de historia — los story points los popularizó Mike Cohn más tarde. ⚠️ EXAMEN: saber que los puntos de historia no nacen con Scrum, sino como evolución para evitar la presión de estimaciones exactas en horas.

Apunte del profesor: hoy incluso algunas corrientes abogan por no estimar en absoluto ("no estimates"). El debate sigue abierto.

7.2. Entregas pequeñas (Small releases)

Poner en producción rápido y con frecuencia. Valida con el usuario real.

7.3. Metáfora del sistema

Analogía del mundo cotidiano que guía el diseño. Papelera de reciclaje, escritorio, ventana.

7.4. Diseño simple

Hacer lo mínimo posible que funcione. Nada de anticiparse a requisitos futuros hipotéticos: YAGNI (You Aren't Gonna Need It).

Reflexión del profesor en clase: muchos desarrolladores experimentados (él mismo) tienden a sobre-diseñar. Anticipan parámetros, configuraciones, clases auxiliares "por si acaso". En un contexto ágil con alta incertidumbre, eso puede ser trabajo desperdiciado si los requisitos cambian.

7.5. Desarrollo dirigido por pruebas (TDD)

Ciclo rojo-verde-refactor: ⚠️ EXAMEN

flowchart LR
    Write[Escribir prueba] --> Fail{Falla?}
    Fail -->|sí<br/>esperado| Code[Escribir código mínimo<br/>que haga pasar la prueba]
    Code --> Test{Pasa?}
    Test -->|no| Code
    Test -->|sí| Refactor[Refactorizar]
    Refactor --> Test2{Sigue pasando?}
    Test2 -->|sí| Commit[Commit]
    Test2 -->|no| Refactor

Pasos: 1. Escribir la prueba primero — va a fallar porque el código no existe. 2. Escribir el código mínimo y suficiente para que la prueba pase. 3. Refactorizar el código (y las pruebas si es necesario) sin romper nada. 4. Commit.

Valor colateral de TDD: ⚠️ EXAMEN - Escribir la prueba primero obliga a pensar qué parámetros tiene el método, qué errores puede producir, qué valores frontera existen. - Crea una suite de pruebas viva que protege contra regresiones. - Justifica la confianza para poner en producción tras cada iteración.

7.6. Refactorización

Reescribir código manteniendo la funcionalidad. Motivaciones: legibilidad, eficiencia, limpieza (quitar logs temporales, variables basura, ñapas).

No siempre es para eficiencia. Apunte de un alumno: a veces es para legibilidad. El profesor lo valida: hacer código "lo más compacto posible" no es necesariamente mejor.

Conceptos relacionados: complejidad ciclomática (medible), patrones de refactorización de Fowler.

7.7. Programación en parejas (pair programming)

Dos personas en la misma pantalla. Una programa, la otra revisa. Alternan roles.

Beneficios: ⚠️ EXAMEN - Cuatro ojos ven más que dos. - Se reducen errores triviales en tiempo real. - Conocimiento compartido (si uno se va, el otro conoce el código). - Aprendizaje cruzado.

Críticas: "es más caro" — dos salarios para el trabajo de uno. El profesor matiza: no todo el tiempo, pero en momentos concretos (atascos, código crítico) es enormemente valioso.

7.8. Propiedad colectiva del código

Cualquiera puede tocar cualquier parte. Se opone al modelo de Feature-Driven Development (FDD), donde hay propietarios de clases concretas.

Requiere estándares + pair + TDD para no convertirse en caos.

7.9. Integración continua

Integrar cambios en la rama principal varias veces al día. Pruebas automatizadas validan cada integración. Enlace directo con DevOps.

7.10. Semana de 40 horas (ritmo sostenible)

No trabajar más de lo debido. Un equipo quemado produce peor código y más bugs.

7.11. Cliente in situ

El cliente está físicamente con el equipo durante la jornada de trabajo. Puede responder dudas al instante.

Crítica: ⚠️ EXAMEN - No siempre es factible (el cliente es externo, está en otra ciudad, no quiere). - Cuando hay cliente in situ, los cambios pueden ser más frecuentes (puede cambiar un requisito a mitad de iteración). Contraargumento: eso es precisamente lo que busca la agilidad — feedback temprano y reacción rápida.

Comparación con Scrum: en Scrum el Product Owner solo se espera en planning y review. En XP el cliente está siempre.

7.12. Estándares de programación

Convenios consistentes sobre código. Fundamental para que la propiedad colectiva funcione.

Ejemplos concretos: ⚠️ EXAMEN - PEP8 (Python): indentación 4 espacios, imports en líneas separadas, naming conventions. - camelCase / PascalCase / snake_case: convenios de capitalización. - Java: paquetes en minúsculas, clases con mayúscula inicial.

No son estándares: paradigmas (OO), patrones de diseño (MVC). Un estándar es una convención de escritura, no un paradigma arquitectónico.

8. Roles específicos de XP

⚠️ EXAMEN — saber diferenciar los 6 roles:

Rol	Función
Programmer (Programador)	Escribe código y pruebas unitarias. Se le exige mucho: técnico + comunicativo + con coraje + respetuoso + simple.
Customer (Cliente)	Equivalente al Product Owner de Scrum, pero in situ. Dueño de la especificación. Define y prioriza historias. Define pruebas funcionales (junto con el tester).
Tester	Ayuda al cliente a escribir pruebas de aceptación. Conoce frameworks de testing e integración continua.
Tracker (Rastreador)	Observa el proceso. Mide si se cumplen plazos y estimaciones. Puede ser un rol a tiempo parcial (un programador "se pone el gorro" algunas horas).
Coach	Equivalente al Scrum Master. Experto en la metodología, vela por que se respeten prácticas y roles. Ayuda a aplicar mejoras.
Big Boss (Jefe de proyecto)	NO es un project manager tradicional. No planifica ni asigna tareas (eso lo hace el equipo). Se encarga de que los objetivos se cumplan y el cliente quede satisfecho. Media entre partes cuando hay conflictos.

Crítica del profesor: XP tiene muchos roles, más que Scrum. Puede ser difícil diferenciarlos en la práctica, especialmente Big Boss vs Coach vs Tracker.

9. Evolución y debate sobre las 12 prácticas

Afirmación original de Kent Beck (1999): "El 80% del valor viene del 20% de las prácticas, pero tienes que aplicar todas. Si no, no es XP, es otra cosa."

Revisión de Kent Beck (2021): "La mayor parte sigue siendo válido, pero ya no lo diría así por cómo la gente interpreta ese tipo de afirmaciones. Sigo pensando que es bueno que un equipo sepa hacer todo esto, aunque no lo aplique siempre."

Conclusión del profesor: no hay que aplicar las 12 a rajatabla. Hay que conocerlas todas y aplicarlas cuando tengan sentido.

10. Críticas a XP

⚠️ EXAMEN — saber enumerar al menos 3:

Cliente in situ genera cambios frecuentes a mitad de iteración (contraargumento: eso es agilidad).
Requisitos muy informales (historias de usuario): no hay especificación formal. Contraargumento: historias de usuario se usan en muchas metodologías ágiles.
Conflictos de intereses entre múltiples clientes (XP asume un cliente; con varios se complica).
Carencia de diseño formal a priori. Problema general de la agilidad, no solo de XP.
Programación en parejas cara y difícil de vender a negocio.
Muy demandante: exige programadores senior, excelentes en múltiples dimensiones.
Aparentemente elitista: no todos los equipos pueden asumir las 12 prácticas.

11. Estado actual de la agilidad (encuestas)

Datos de encuestas estado de la agilidad (2018, 2021):

Scrum lidera la adopción (en 2021 alrededor del 60%+).
Scrum + Kanban (Scrumban) muy extendido — combinación usada en el laboratorio de esta asignatura.
Scrum + XP también popular.
XP puro: ~1-2%. Muy minoritario.
Modelo Spotify (escuadrones, tribus, capítulos, gremios, trío, alianza): popular pero complejo, pensado para cientos de personas.
Un sorprendente ~2% responde "no sabe" qué metodología usa.

Conclusión: la agilidad se practica a medida. Los equipos mezclan prácticas de varias metodologías. XP puro es raro, pero sus prácticas están presentes en todas partes (TDD, CI, pair, refactoring, estándares).

12. Extensiones de XP (informativo)

Para proyectos grandes existen extensiones que añaden prácticas (pruebas más sofisticadas, transformación cultural, aprendizaje continuo). No se profundiza en clase.

Preguntas de Autoevaluación

¿Por qué XP se llama "extreme"? Porque lleva al extremo los principios del desarrollo iterativo: iteraciones lo más cortas, simples y entregables posible.
Nombra 6 de las 12 prácticas de XP. TDD, refactorización, programación en parejas, propiedad colectiva, cliente in situ, estándares, entregas pequeñas, metáfora del sistema, juego de la planificación, integración continua, semana 40h, diseño simple.
Diferencia entre estándar de programación y paradigma. El estándar es una convención de escritura (PEP8, camelCase); el paradigma es una forma de pensar el software (OO, funcional).
Explica TDD paso a paso. 1. Escribir la prueba (falla). 2. Escribir el código mínimo para que pase. 3. Refactorizar. 4. Commit.
¿Cómo se complementan propiedad colectiva y programación en parejas? La propiedad colectiva permite que cualquiera toque cualquier código; la programación en parejas garantiza que ninguna decisión se toma en solitario.
Diferencia entre el cliente de XP y el Product Owner de Scrum. El cliente XP está in situ con el equipo durante la jornada; el PO de Scrum solo se espera en planning/review.
Nombra los 6 roles de XP. Programador, cliente, tester, rastreador, coach, big boss.
¿Por qué el Big Boss no es un jefe tradicional? Porque no planifica, no asigna tareas y no organiza el trabajo — todo eso lo hace el equipo colectivamente. Solo media y vela por objetivos.
¿Qué es una tarjeta CRC? Ficha de Clase-Responsabilidad-Colaborador: describe qué hace una clase y con cuáles colabora. Ayuda a detectar baja cohesión y alto acoplamiento.
¿Qué es una spike solution? Código rápido "de usar y tirar" para evaluar viabilidad o estimar esfuerzo.
Principio YAGNI vs el instinto de "dejar preparado por si acaso". YAGNI (You Aren't Gonna Need It) dice no anticipar; si no lo necesitas ahora, no lo construyas. El exceso de anticipación es común en seniors pero perjudicial en contextos ágiles con incertidumbre.
¿Qué pasa si un cliente de XP cambia un requisito en medio de una iteración? Es un efecto esperado: el equipo se adapta; es precisamente lo que busca la agilidad, feedback temprano.
Crítica principal a la programación en parejas y respuesta. Crítica: es cara (dos salarios, un trabajo). Respuesta: no todo el tiempo; en código crítico y momentos de bloqueo tiene un retorno alto.
¿Por qué XP puro se usa tan poco según las encuestas? Por demandas altas al equipo (senior, multidisciplinar, pair frecuente) y porque la mayoría prefiere híbridos Scrum+XP o Scrumban.
¿Qué valores introdujo XP en 2004 además de los 4 originales? Respeto.
Historias de usuario: ¿nacieron en Scrum? No, nacieron en XP y Scrum las adoptó.

Referencias

Kent Beck (1999) — Extreme Programming Explained: Embrace Change.
Kent Beck & Martin Fowler — Planning Extreme Programming (libro específico sobre planificación).
PEP8 — guía de estilo Python.
Próximo bloque: ingeniería de requisitos → arquitectura → DevOps. La clase 7 arranca este giro.