eXtreme Programming

eXtreme Programming — normalmente solo XP — es el miembro más exigente de la familia ágil. East Agile Tracker está construido pensando primero en XP; todo lo demás se deriva de eso.

Esta página cubre qué es XP, por qué funciona y cómo practicarlo con el tracker como tu superficie de planificación.

Qué es XP

XP fue creado por Kent Beck a finales de la década de 1990. El primer libro — Extreme Programming Explained: Embrace Change — se publicó en 1999. Empezó, como muchas cosas, con un equipo frustrado tratando de entregar un sistema de nóminas en Chrysler.

La apuesta de XP es que la forma correcta de gestionar la incertidumbre en el software es hacer las cosas que funcionan, y hacerlas más a menudo. ¿Probar? Prueba todo el tiempo. ¿Integrar? Integra cada hora. ¿Hablar? Habla constantemente. ¿Planificar? Planifica cada iteración, y replanifica a medida que aprendes.

“XP es una metodología ligera para equipos de tamaño pequeño a mediano que desarrollan software ante requisitos vagos o que cambian rápidamente.” — Kent Beck

Los cinco valores

XP nombra cinco valores de los que cuelga todo lo demás:

1. Comunicación — El equipo habla. A diario. Sobre el trabajo, el diseño, los obstáculos. Cara a cara cuando es posible. Los silos son el enemigo.
2. Simplicidad — Haz la cosa más simple que pudiera funcionar. Puedes añadir complejidad más adelante si realmente la necesitas. Probablemente no lo harás.
3. Retroalimentación — Del código (pruebas), del equipo (programación en parejas, revisiones), del usuario (lanzamientos frecuentes). Obtenla rápido.
4. Coraje — Di la verdad sobre el progreso, las estimaciones y el diseño. Tira el código que no funciona. Refactoriza lo que te frena.
5. Respeto — Todos en el equipo — y ahora, cada agente del equipo — aportan valor. Trataos en consecuencia.

Las prácticas

XP es famoso por sus doce prácticas originales, organizadas en cuatro áreas:

Planificar

• El juego de la planificación (Planning Game) — El equipo y el cliente planifican juntos: qué viene a continuación, en qué orden, cómo de grande es cada pieza.
• Lanzamientos pequeños — Entrega a menudo. Días, no meses. Obtén retroalimentación sobre algo concreto.
• Historias de usuario — Los requisitos son conversaciones, captadas como historias breves desde el punto de vista del usuario. “Como usuario, quiero X, para que Y.”

Diseñar

• Diseño simple — El diseño más simple que pasa las pruebas y expresa cada concepto necesario. Nada más.
• Refactorización — Mejora el diseño del código que ya funciona. Constantemente.
• Metáfora del sistema — Una historia compartida de cómo funciona el sistema, usada para hacer coherentes las decisiones de diseño.

Codificar

• Programación en parejas — Dos desarrolladores, un teclado. Uno conduce, el otro navega. Cambiad a menudo.
• Propiedad colectiva del código — Cualquiera puede mejorar cualquier código. Sin feudos.
• Integración continua — Integra y prueba el código muchas veces al día. Detecta las roturas de inmediato.
• Estándares de codificación — Estilo acordado para que el código se lea como si lo hubiera escrito una sola persona.

Probar

• Desarrollo guiado por pruebas (TDD) — Escribe primero la prueba que falla, luego el código que la hace pasar.
• Pruebas de aceptación — El cliente define, en código o en forma ejecutable, qué significa “terminado” para cada historia.

Por qué funciona XP

XP es incómodo. La programación en parejas te obliga a pensar en voz alta. El TDD te obliga a saber cómo es el éxito antes de escribir el código. La integración continua mata tus ramas favoritas de larga duración. Los lanzamientos pequeños hacen que no puedas esconderte detrás de una hoja de ruta de seis meses.

Funciona porque todas estas cosas acortan los bucles de retroalimentación. Cuanto más rápido descubres que te equivocaste, más barata es la corrección. XP trata, fundamentalmente, de hacer que el bucle de retroalimentación sea lo más estrecho posible.

También trata de coraje y respeto. Solo puedes hacer XP en un equipo que confíe lo suficiente en sí mismo como para equivocarse en voz alta.

El modelo disciplinado de historias

East Agile Tracker codifica una teoría específica de la planificación. Trata esta sección como el manual de operaciones de por qué el modelo de datos tiene el aspecto que tiene — y como la guía de campo de qué hacer (y no hacer) en la práctica.

Por qué importan los cuatro tipos de historia

Todo es una historia, pero hay cuatro clases, y la distinción es justo de lo que se trata:

• Las features llevan puntos y son lo único que “cuenta” para la velocidad. Esto te obliga a trocear el trabajo en valor observable por el usuario.
• Los bugs no llevan puntos (cero). Los defectos no ganan crédito, lo que hace visible el coste del retrabajo en lugar de premiarlo.
• Los chores tampoco llevan puntos — trabajo necesario sin valor directo para el usuario (infraestructura, refactorizaciones, configuración). Mantenerlos en cero presiona al equipo para que los agrupe dentro de features siempre que sea posible, de modo que el marco de valor siga siendo honesto.
• Las releases son marcadores de cero puntos usados para anclar hitos y permitir que la herramienta proyecte una fecha.

El efecto en el comportamiento es lo que importa: cuando los bugs y los chores no puntúan, un equipo tiende de forma natural a expresar el trabajo como funcionalidad orientada al usuario, y se vuelve muy consciente del coste de los defectos. Eso es una disciplina de planificación codificada en el modelo de datos.

El backlog único y ordenado

Tres zonas, una regla.

• El Icebox es la reserva de ideas sin priorizar.
• El Backlog es una lista estrictamente ordenada, de prioridad única — sin empates, sin “P1/P1/P1”.
• La zona Current contiene la(s) iteración(es) activa(s).

El product owner es dueño del orden de arriba abajo, y la invariante es que la parte superior del backlog siempre es lo más importante y mejor especificado, y la claridad disminuye legítimamente a medida que bajas. Una historia cerca de la parte superior con criterios de aceptación vagos es un fallo de planificación. El Icebox tiene permiso para ser un cementerio; el Backlog no.

Planificación automática basada en la velocidad

Esta es la parte que la mayoría de los equipos reimplementan mal en otros sitios. La planificación al estilo del tracker calcula una velocidad media móvil a partir de los puntos aceptados recientemente y automáticamente arrastra esa cantidad de puntos de historias a la siguiente iteración — no te “comprometes” manualmente a un sprint, lo hacen los datos empíricos por ti. Dos consecuencias que vale la pena conservar:

• Estimas solo las features, usando puntos relativos (Fibonacci 1/2/3/5/8 o nuestra más ajustada 0/1/2/3), no horas. La estimación es una conversación de dimensionamiento, no una promesa.
• No manipulas la velocidad. Inflar los puntos para “parecer rápido”, o puntuar los chores, rompe la proyección que mantiene honesto a todo el sistema. La velocidad es un instrumento de medición, y no manipulas tu propio instrumento.

La recompensa es que la proyección de la fecha de release se convierte en un cálculo en lugar de una negociación, y la conversación con las partes interesadas pasa de “¿puedes comprometerte a X para el viernes?” a “a la velocidad actual, esta release aterriza alrededor de la fecha Y — este es el equilibrio entre alcance y fecha”.

El ciclo de vida de la historia y el bucle de aceptación

La máquina de estados es Start → Finish → Deliver → Accept / Reject. El estado crítico es Deliver: un ingeniero marca una historia como entregada, pero no está terminada hasta que el product owner la acepta explícitamente frente a sus criterios de aceptación — o la rechaza, devolviéndola. Esto incorpora un bucle de retroalimentación del cliente en cada historia, en lugar de aplazar la aceptación a una demo de fin de sprint.

Los criterios de aceptación deben estar en la historia antes de que se inicie, idealmente en forma Given/When/Then para que se correspondan directamente con las pruebas de aceptación. INVEST es la comprobación de cordura sobre si una historia está bien formada:

• Independent — se puede entregar sin otras historias.
• Negotiable — capta la intención, no una especificación congelada.
• Valuable — para un usuario o una parte interesada.
• Estimable — el equipo puede dimensionarla.
• Small — cabe cómodamente en una iteración.
• Testable — tiene criterios de aceptación que se pueden ejercitar.

Cadencia

Las ceremonias de planificación son ligeras y regulares:

• Una reunión semanal de planificación de la iteración para puntuar las historias nuevas y fijar los criterios de aceptación en la parte superior del backlog.
• Una reunión diaria breve centrada en el flujo y los bloqueadores.
• Una retrospectiva por iteración para ajustar el proceso.

Las iteraciones suelen ser de una o dos semanas — lo bastante cortas para que una mala estimación sea barata de descubrir.

Las prácticas de ingeniería que hacen que la planificación funcione

La planificación al estilo del tracker es la mitad visible de XP; se desmorona sin la mitad de ingeniería.

• Test-first / TDD y una verdadera batería de pruebas de aceptación son lo que permite que “entregado” signifique algo.
• La integración continua y los lanzamientos pequeños y frecuentes mantienen corto el tiempo de ciclo, de modo que la velocidad es estable en lugar de irregular.
• La programación en parejas (o una revisión sólida) mantiene bajo el trabajo en curso — termina antes de empezar — que es la mayor palanca sobre el tiempo de ciclo.
• Un product owner disponible es lo que evita que se estanque el bucle de aceptar/rechazar.

Antipatrones a vigilar

Los fallos recurrentes:

• Tratar el Backlog como un aparcamiento en lugar de un verdadero orden de prioridad.
• Estimar los bugs y los chores para que la velocidad parezca mejor.
• Arrastrar historias enormes que no pueden terminarse en una iteración. Divide hasta que cada una sea entregable de forma independiente.
• Dejar que las historias se acumulen en Delivered porque nadie las acepta.

Cualquiera de estos convierte calladamente un sistema empírico de nuevo en planificación ilusoria. El tracker no puede impedir que los hagas; solo puede hacerlos visibles. Mira tu columna Delivered al final de cada iteración — si está creciendo, esa es tu señal.

XP con East Agile Tracker

El tracker es la superficie de planificación que los equipos de XP han estado deseando desde los días de Pivotal Tracker. Cada concepto se corresponde directamente:

Historias de usuario → Historias

Las historias de usuario de XP son las historias de East Agile Tracker. Escríbelas en el tipo Feature. Usa la descripción para la conversación; usa los comentarios para el debate continuo. Los criterios de aceptación van en la descripción.

El juego de la planificación → El tablero

El juego de la planificación en XP es una conversación entre el negocio y el equipo sobre la prioridad y el tamaño. En East Agile Tracker:

1. La persona de producto escribe historias en el Backlog y las ordena por prioridad.
2. El equipo estima las features en puntos (escala Fibonacci o East Agile).
3. El sistema planifica automáticamente las iteraciones a partir de la velocidad.
4. El equipo inicia historias desde la parte superior de la columna Current.

Eso es todo. El “juego” vive en la conversación; el tracker solo lleva el marcador.

Lanzamientos pequeños → Releases (el tipo de historia)

XP dice que se lance a menudo. Release es uno de los cuatro tipos de historia en East Agile Tracker. Crea una release para cada hito de lanzamiento; arrástrala a la iteración en la que se lanza. Las releases se saltan Started/Finished/Delivered y van directas a Accepted cuando lanzas.

Integración continua → La máquina de estados de la historia

La máquina de estados no es CI en sí — eso es tu sistema de build — pero la ruta Finished → Delivered → Accepted refleja el bucle de aceptación del cliente que describe XP. Termina el trabajo, entrégalo al cliente, acéptalo cuando se confirme que funciona.

Velocidad → “El tiempo de ayer”

XP lo llama el tiempo de ayer (yesterday’s weather): cuánto hiciste la iteración pasada es la mejor predicción de cuánto harás en esta. East Agile Tracker calcula la velocidad automáticamente — promedio de las iteraciones recientes, estrategia configurable — y la usa para planificar automáticamente la capacidad de la siguiente iteración.

Pruebas de aceptación → Revisiones

Las revisiones de historia en el tracker se corresponden con la aceptación. Asigna un revisor (el cliente, el product owner o incluso un agente actuando como tal). Aprueban o rechazan. Rechazar devuelve la historia a Started.

Programación en parejas → Copropiedad

Los equipos de XP emparejan al codificar. En el tracker, esto se manifiesta como varios owners en una historia. Asigna ambos miembros de la pareja a la historia; ambos nombres aparecen en la tarjeta.

XP con agentes — la nueva práctica

XP se escribió antes de que los agentes de IA pudieran contribuir de forma significativa al software. Creemos que esta es la actualización más importante de XP en veinticinco años.

En nuestra práctica — y para lo que está construido el tracker — un agente es un miembro del equipo de XP con nombre propio. Tiene su propio rol, su propio compañero de pareja (humano o agente) y su propio registro de auditoría. Puede hacer cualquier cosa que pueda hacer un miembro humano del equipo en la superficie de planificación: estimar, ser owner de historias, comentar, transicionar, aceptar revisiones.

Los valores de XP siguen vigentes. Comunicación: los agentes se comunican leyendo el flujo de eventos y publicando comentarios. Simplicidad: los agentes están limitados a los roles que les concedes. Retroalimentación: cada acción del agente está en el registro de auditoría, revisable de inmediato. Coraje: sé honesto sobre lo que tus agentes hicieron bien y lo que no. Respeto: los compañeros de equipo que son agentes aportan valor — reconócelo.

No ponemos a los agentes dentro del tracker haciendo la codificación. Damos la superficie de planificación a personas y agentes trabajando juntos. Tú aportas el agente de programación — Claude Code, Codex, el tuyo propio — y lo conectas al tracker a través de la API. El agente toma historias, hace el trabajo, comenta, transiciona. Tú revisas el rastro y aceptas.

Esto es la Planificación Ágil Inclusiva. Es XP, con el equipo que realmente tiene.

Lecturas adicionales

• Extreme Programming Explained — El libro fundacional de Kent Beck, 1999.
• El Manifiesto Ágil — Donde empezó la familia.
• Desarrollo ágil — La imagen más amplia.
• Instrucciones de uso — Guía práctica del tracker.
• Guía de la API — Conectar tu agente de programación.