Programación Extrema Leonardo Ramírez Z.

Contenido Motivación ¿Qué es Programación Extrema? La filosofía detrás de la Programación Extrema El proceso XP Resumen de prácticas de la metodología Conclusiones Referencias

Motivación Ingeniería de software a escala menor Modelos estudiados difíciles de aplicar a la realidad Requisitos poco claros Requisitos poco estables Elevado costo de introducir cambios durante el desarrollo Elevado riesgo en contratos de desarrollo de software

¿Qué es Programación Extrema o XP? Metodología liviana de desarrollo de software Conjunto de practicas y reglas empleadas para desarrollar software Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes Originada en el proyecto C3 para Chrysler 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

Filosofía detrás de XP

Simplicidad “Haz la cosa mas simple posible que funcione” “Mantén el sistema en la condición mas simple posible”

Comunicación El cliente es parte del equipo de desarrollo Comunicación entre gestión y desarrollo Comunicación entre desarrolladores

Testeo Velocidad, pero además calidad Testeo continuo a través de todo el proceso Testeo como herramienta de especificación y desarrollo Testeo como garantía de integridad del código frente a cambios

Agresividad Reacción frente a los cambios

El proceso XP

Un proyecto XP Prototipo arquitectónico Planificación de entregas Iteración Tests de aceptación Pequeñas entregas Historias de usuario Metáfora de sistema Prototipo requerimientos Estimación incierta Estimación confiable Plan de entregas Versión mas reciente Aprobación del cliente Escenarios de testeo Historias nuevas Velocidad del proyecto Próxima iteración bugs

Iteración Próxima iteración Planificación de iteración Desarrollo Versión mas reciente Velocidad de proyecto Plan de iteración Plan de entregas Bugs Historias de usuario Tests de aceptación fallados Funcionalidades nuevas Corrección de bugs Día a día Historias nuevas, Velocidad de proyecto Aprender y comunicar

Desarrollo Corrección de bugs Reunión de pie Manejo colectivo del software Próxima tarea o test de aceptación fallido Plan de iteración Día a día tareas Tests de aceptación fallados Tests de unidad pasados al 100% Test de aceptación aprobado Tareas sin terminar Demasiado por hacer Nueva funcionalidad Aprender y comunicar Programación en pares Reconstrucción de código

Manejo colectivo del código Próxima tarea o test de aceptación Creación de unidad de testeo Programación en pares 100% de unidades de testeo pasados Pares Unidad de testeo fallida Mover Gente Se necesita ayuda Cambio de par Unidad de testeo aprobada Código simple Código complejo Reconstrucción despiadada Ejecutar todas las unidades de testeo Test de aceptación aprobado Ejecutar test de aceptación fallados

Resumen de prácticas Proceso de planificación Entregas pequeñas Metáfora del sistema Diseño simple Testeo Reconstrucción Programación en pares Propiedad colectiva Integración continua Semana de 40 horas Cliente siempre disponible Estándares de codificación

Conclusiones Apostolado de metodologías exitosas Aporte de la experiencia práctica a los modelos teóricos Enfoque de conjunto de prácticas como rompecabezas Tecnología en expansión Importancia de revisitar las metodologías desde la experiencia práctica

Referencias K. Beck, “Embracing change with Extreme Programing”, Computer, Vol. 32, No. 5 Oct. 1999, pp L. Williams, R. Kessler, W. Cunningham and R. Jeffries, “Strenghthening the Case for Pair Programing”, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp R. Martin, “Extreme Programing Development through dialog”, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp C3 Team, “Chrysler goes to “Extremes”, Distributed Computing, Oct 1998, pp