La programación extrema (XP) es una metodología ágil para el desarrollo de software, enfocada en la flexibilidad y colaboración del equipo en entornos cambiantes. Promueve la simplicidad, el feedback continuo y la comunicación directa entre programadores y clientes, facilitando entregas frecuentes y prueba de pequeñas partes del sistema. Sin embargo, es más adecuada para proyectos a corto plazo y puede carecer de documentación, lo que puede dificultar la comprensión del sistema si fracasa el proyecto.

1. Programación Extrema
(XP)
Metodologías Agiles

2. ¿Qué es la Programación Extrema?
▪ Conjunto de prácticas y reglas empleadas para desarrollar software
▪ Pensado para enfrentar ambientes muy cambiantes
▪ En vez de planificar, analizar y diseñar para el futuro distante, hacer
todo esto un poco cada vez, a través de todo el proceso de
DESARROLLO de software
▪ Es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje
de los desarrolladores, y propiciando un buen clima de trabajo.

3. Origen
▪ Formulado por Kent Beck en 1996
▪ El primer libro fue editado en el año 1999: Extreme Programming
Expained.
▪ Pensado para un grupo pequeño y muy integrado (2-12 personas)
▪ Equipo con formación elevada y capacidad de aprender
▪ Los principios y prácticas son de sentido común pero llevadas al
extremo

5. Principios
▪ SIMPLICIDAD: Consiste en desarrollar solo el sistemas que realmente se
necesita. Implica resolver en cada momento solo las necesidades actuales
▪ FEDDBACK una metodología basada en desarrollo interactivo de
pequeñas partes, con entregas y pruebas frecuentes y continuas,
proporciona un flujo de retroinformación valioso para detectar los
problemas o desviaciones (TEST DEL CLIENTE)
▪ DECICION implica tomar decisiones difíciles, reparar errores cuando se
detecta mejorar el código siempre que tras el feedback y las sucesivas
pruebas
▪ COMUNICACION comunicación directa y continua a clientes y
desarrolladores

7. Roles
▪ Programador: Produce el código del sistema
▪ Cliente: Escribe las historias de usuario y las pruebas funcionales, centrándose en
aportar el mayor valor de negocio
▪ Tester (Pruebas): Ejecuta pruebas regularmente, difunde los resultados en el equipo
▪ Tracker (seguimiento):Verifica estimaciones y tiempo real dedicado.
▪ Entrenador: Guía a los miembros del equipo para seguir el proceso correctamente
▪ Consultor: Es un miembro externo del equipo con un conocimiento específico en algún
tema necesario para el proyecto
▪ Jefe de Proyecto (Big Boss): Es el dueño de la tienda y el vínculo entre clientes y
programadores. Su labor esencial es la coordinación.

8. Procesos de XP

9. Procesos de XP
▪ Planeación: Escuchar al cliente, crear las historias, organizar las
historias por su valor.
▪ Diseño: El programador estima el esfuerzo necesario para su
implementación.
▪ Codificación: Programación por parejas, da un mecanismo de
solución de problemas y aseguramiento de calidad en tiempo real.
▪ Pruebas: “Corregir pequeños problemas cada cierto número de horas
toma menos tiempo que resolver problemas enormes antes del plazo
final”

10. Entregas pequeñas
Una entrega no debería tardar más 3 meses…

11. Ventajas
▪ Da lugar a una programación sumamente organizada
▪ Cuanta con una tasa de errores muy pequeña
▪ Propicia la satisfacción del programador
▪ Facilita los cambios
▪ Permite ahorrar mucho tiempo y dinero
▪ Puede ser aplicada a cualquier lenguaje de programación
▪ El cliente tiene el control sobre las prioridades
▪ Se hacen pruebas continuas durante el proyecto
▪ A los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto

12. Desventajas
▪ Es recomendable emplearla solo en proyectos a corto plazo, hay
restricciones en cuanto a tamaño de los proyectos.
▪ Requiere de un rígido ajuste a los principios de XP
▪ Puede no siempre ser mas fácil que el desarrollo tradicional
▪ Falta de documentación del diseño. Al no haber documentación es el
código (junto con sus comentarios) lo que se toma como
documentación.
▪ Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo
mismo ocurre con el diseño. La comprensión del sistema se queda en
las mentes de los desarrolladores.