Factory

XP Extreme Programming

Extreme Programming (XP) es una metodología ágil de desarrollo de software propuesta por Kent Beck a fines de los 90. Trabaja en ciclos cortos anidados (trimestre, semana, día) y apuesta por el feedback rápido: pruebas primero, integración continua y releases pequeños. Recorre el flujo y abre cada etapa para ver su proceso.

Sobre las fuentes: las referencias son libros y artículos reales que conozco, pero no abrí cada texto para verificar los detalles. Las citas están a nivel de obra, sin número de página, y el contenido de cada etapa es una síntesis mía: conviene contrastarla con los libros antes de citarla.

SíNo: corregirSiguiente iteraciónHistoriasEl cliente cuenta qué necesitaPlan de releaseJuego de planificación (trimestral)Plan de iteraciónCiclo semanalPareja + TDDPrueba, código, refactorIntegración continuaBuild de diez minutos¿Build verde?Aceptación del clientePruebas de aceptaciónRelease pequeñoA producción, seguidoRetrospectivaMirar el proceso

Cómo leer este flujo

XP no define una secuencia lineal: son ciclos anidados que se repiten. El diagrama los ordena en una sola línea para leerlos: la parte alta (historias, plan de release) corre cada trimestre; la planificación y la aceptación, cada semana; y la pareja con TDD y la integración continua, varias veces al día. La línea punteada indica que, tras la retrospectiva, se vuelve a planificar.

Es una representación didáctica, no un diagrama oficial de Beck.

Valores

  • Comunicación

    Todo el equipo, incluido el cliente, habla seguido y cara a cara; los problemas se dicen temprano.

  • Simplicidad

    Hacer lo más simple que funcione hoy, sin construir para necesidades que aún no existen.

  • Retroalimentación

    Pruebas, builds, releases y clientes responden rápido para poder corregir el rumbo.

  • Coraje

    Decir la verdad sobre estimaciones, refactorizar y descartar código que ya no sirve.

  • Respeto

    Valor agregado en la 2.ª edición: cada persona del equipo cuida a las demás y al proyecto.

Prácticas

La lista y los nombres varían entre la 1.ª y la 2.ª edición del libro de Beck; esta es una versión resumida.

  • Juego de planificación

    Negocio decide alcance y prioridad; desarrollo estima. Se repite por release y por iteración.

  • Releases pequeños

    Entregas frecuentes de poco alcance para aprender de producción.

  • Programación en parejas

    Dos personas, un teclado: revisión continua y conocimiento compartido.

  • Desarrollo guiado por pruebas

    Primero la prueba que falla, luego el código, luego la limpieza.

  • Refactorización

    Mejorar el diseño sin cambiar el comportamiento, en pasos pequeños.

  • Diseño simple / incremental

    El diseño evoluciona con el código en vez de definirse completo al inicio.

  • Propiedad colectiva

    Cualquiera puede cambiar cualquier parte del código.

  • Integración continua

    Integrar y construir varias veces al día con todas las pruebas.

  • Ritmo sostenible

    Evitar las horas extra crónicas; un equipo cansado programa peor.

  • Equipo completo / cliente en sitio

    Quien necesita el software trabaja con quien lo construye.

Roles

  • Cliente

    Escribe y prioriza historias, define y acepta las pruebas de aceptación.

  • Programador

    Estima, programa en pareja, escribe pruebas e integra.

  • Entrenador (coach)

    Cuida que se siga el proceso y facilita; no manda.

  • Seguimiento (tracker)

    Mide velocidad y avance. Rol de la 1.ª edición / literatura posterior; no verificado en el texto.

Proceso de cada etapa

  • Historias El cliente cuenta qué necesita

    El cliente escribe historias cortas de lo que el usuario quiere lograr. Son una promesa de conversación, no una especificación completa.

    Quién
    Cliente (con apoyo del equipo para aclarar).
    Ciclo
    Continuo
    Entra
    • Necesidades del negocio y de los usuarios
    • Feedback de releases anteriores
    Produce
    • Lista de historias en lenguaje del cliente
    • Criterios básicos de aceptación
    Prácticas involucradas
    Historias (Stories), Equipo completo (Whole Team), Cliente en sitio

    Fuentes (sin verificar a nivel de página)

    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.
    • libro Beck y Fowler. Planning Extreme Programming. Addison-Wesley, 2000.

  • Plan de release Juego de planificación (trimestral)

    Negocio y desarrollo negocian qué historias entran en el próximo release: el negocio decide alcance y prioridad, el desarrollo estima y advierte costos.

    Quién
    Cliente y programadores; el entrenador (coach) facilita.
    Ciclo
    Ciclo trimestral
    Entra
    • Historias
    • Velocidad medida del equipo
    • Estimaciones de costo
    Produce
    • Plan de release priorizado
    • Tema o meta del trimestre
    Prácticas involucradas
    Ciclo trimestral (Quarterly Cycle), Juego de planificación (Planning Game), Estimación

    Fuentes (sin verificar a nivel de página)

    • libro Beck y Fowler. Planning Extreme Programming. Addison-Wesley, 2000.
    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.

  • Plan de iteración Ciclo semanal

    Al inicio de la semana el equipo elige las historias que cabrán según su velocidad, las divide en tareas y las reparte.

    Quién
    Todo el equipo.
    Ciclo
    Ciclo semanal
    Entra
    • Plan de release
    • Velocidad de la iteración anterior
    Produce
    • Historias comprometidas
    • Tareas con responsable
    Prácticas involucradas
    Ciclo semanal (Weekly Cycle), Juego de planificación, Espacio de trabajo informativo

    Fuentes (sin verificar a nivel de página)

    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.
    • libro Jeffries, Anderson y Hendrickson. Extreme Programming Installed. Addison-Wesley, 2000.

  • Pareja + TDD Prueba, código, refactor

    Dos personas programan juntas una tarea: escriben una prueba que falla, escriben el código mínimo para pasarla y limpian el diseño sin cambiar el comportamiento. Repiten en pasos pequeños.

    Quién
    Programadores, en parejas que rotan.
    Ciclo
    Ciclo diario
    Entra
    • Tarea de la iteración
    • Código del equipo (propiedad colectiva)
    Produce
    • Código con pruebas automáticas
    • Diseño simple y sin duplicación
    Prácticas involucradas
    Programación en parejas, Test-first / TDD (rojo, verde, refactor), Refactorización, Diseño incremental, Propiedad colectiva del código, Estándar de codificación, Ritmo sostenible

    Fuentes (sin verificar a nivel de página)

    • libro Beck. Test-Driven Development: By Example. Addison-Wesley, 2002.
    • libro Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.

  • Integración continua Build de diez minutos

    Cada pareja integra sus cambios a la línea principal varias veces al día y se ejecuta el build completo con todas las pruebas, apuntando a que tome unos diez minutos.

    Quién
    Programadores; el servidor de integración ejecuta el build.
    Ciclo
    Varias veces al día
    Entra
    • Cambios de la pareja
    • Suite de pruebas automáticas
    Produce
    • Línea principal integrada
    • Resultado del build
    Prácticas involucradas
    Integración continua, Build de diez minutos (Ten-Minute Build), Despliegue incremental

    Fuentes (sin verificar a nivel de página)

    • artículo Fowler. «Continuous Integration», martinfowler.com, 2006.
    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.

  • ¿Build verde? Decisión del flujo

    Punto de decisión: si el build falla, arreglarlo pasa a ser la prioridad del equipo antes de seguir agregando cambios.

    Quién
    Todo el equipo.
    Ciclo
    Varias veces al día
    Entra
    • Resultado del build
    Produce
    • Decisión: seguir o volver a corregir
    Prácticas involucradas
    Integración continua, Propiedad colectiva del código

    Fuentes (sin verificar a nivel de página)

    • artículo Fowler. «Continuous Integration», martinfowler.com, 2006.

  • Aceptación del cliente Pruebas de aceptación

    El cliente comprueba que cada historia hace lo que pidió, idealmente con pruebas de aceptación automáticas que él mismo definió.

    Quién
    Cliente, con apoyo de programadores y de quien pruebe.
    Ciclo
    Ciclo semanal
    Entra
    • Historia terminada e integrada
    • Criterios de aceptación
    Produce
    • Historia aceptada o devuelta con comentarios
    Prácticas involucradas
    Cliente en sitio, Pruebas de aceptación, Equipo completo

    Fuentes (sin verificar a nivel de página)

    • libro Beck. Extreme Programming Explained: Embrace Change, 1.ª ed. Addison-Wesley, 1999.
    • libro Jeffries, Anderson y Hendrickson. Extreme Programming Installed. Addison-Wesley, 2000.

  • Release pequeño A producción, seguido

    Se pone en producción un incremento pequeño y útil con frecuencia, para recibir feedback real y reducir el riesgo de cada entrega.

    Quién
    Programadores y operación; el cliente decide cuándo.
    Ciclo
    Semanal a trimestral
    Entra
    • Historias aceptadas
    • Línea principal verde
    Produce
    • Software en producción
    • Feedback de usuarios reales
    Prácticas involucradas
    Releases pequeños (Small Releases), Despliegue incremental, Integración continua

    Fuentes (sin verificar a nivel de página)

    • libro Beck. Extreme Programming Explained: Embrace Change, 1.ª ed. Addison-Wesley, 1999.
    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.

  • Retrospectiva Mirar el proceso

    El equipo revisa qué funcionó y qué no, mide su velocidad y decide qué cambiar en su forma de trabajar. XP espera adaptación constante del proceso.

    Quién
    Todo el equipo; el entrenador facilita.
    Ciclo
    Ciclo semanal
    Entra
    • Resultados de la iteración
    • Feedback de producción
    • Métricas simples
    Produce
    • Ajustes al proceso
    • Velocidad actualizada
    • Nuevas historias o cambios de prioridad
    Prácticas involucradas
    Retrospectiva, Mejora (Improvement), Reflexión

    Fuentes (sin verificar a nivel de página)

    • libro Beck y Andres. Extreme Programming Explained: Embrace Change, 2.ª ed. Addison-Wesley, 2004.
Ver el diagrama como código Mermaid 
flowchart TD
    H["Historias<br/>El cliente cuenta qué necesita"] --> R["Plan de release<br/>Ciclo trimestral"]
    R --> I["Plan de iteración<br/>Ciclo semanal"]
    I --> P["Pareja + TDD<br/>Prueba, código, refactor"]
    P --> CI["Integración continua<br/>Build de diez minutos"]
    CI --> B{"¿Build verde?"}
    B -- No --> P
    B -- Sí --> A["Aceptación del cliente"]
    A --> S["Release pequeño"]
    S --> RE["Retrospectiva"]
    RE -.-> I