Programación Extrema (XP)

12
Programación Extrema (XP) Metodologías Agiles

Transcript of Programación Extrema (XP)

Page 1: Programación Extrema (XP)

Programación Extrema (XP)Metodologías Agiles

Page 2: Programación Extrema (XP)

¿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.

Page 3: Programación Extrema (XP)

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

Page 4: Programación Extrema (XP)
Page 5: Programación Extrema (XP)

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

Page 6: Programación Extrema (XP)
Page 7: Programación Extrema (XP)

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.

Page 8: Programación Extrema (XP)

Procesos de XP

Page 9: Programación Extrema (XP)

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”

Page 10: Programación Extrema (XP)

Entregas pequeñas

Una entrega no debería tardar más 3 meses…

Page 11: Programación Extrema (XP)

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

Page 12: Programación Extrema (XP)

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.