Programación extrema
- 2. • Nace como un intento exitoso, de establecer un conjunto de prácticas que facilitasen la finalización de los proyectos. Después de unas cuantas exitosas pruebas, estas prácticas se plasmaron de forma teórica, dando lugar a esta metodología. • El término extreme es debido a que las prácticas que se utilizaron, fueron llevadas hasta el extremo.
- 3. OBJETIVOS • Satisfacer al cliente, darle al cliente lo que quiere y cuando quiere. respondiendo rápidamente sus necesidades, aunque realice cambios en fases avanzadas del proyecto. • Trabajar en grupo, tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo. • Mejorar la productividad de los proyectos.
- 4. VALORES DE XP • Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores: • Comunicación entre los integrantes del grupo de trabajo • Sencillez. Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. • Retroalimentación. Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema. • Valentía. Asumir retos y afrontar problemas
- 5. PROCESO • XP tiene un ciclo de vida y esta compuesto de seis fases: 1. Fase de exploración 2. Fase de planificación 3. Fase de iteraciones 4. Fase de producción 5. Fase de mantenimiento 6. Fase de cierre de proyecto
- 6. FASE DE EXPLORACIÓN • Historia de Usuario • Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras más específicas o generales, añadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas.
- 7. FASE DE PLANIFICACIÓN • En esta fase se establece la prioridad de las diferentes historias y se acuerda el contenido de la primera entrega del proyecto. La estimación temporal se basa en un cálculo estimado por parte de los desarrolladores de cada una de las historias, la primera entrega no suele tardar más de dos meses en realizarse. La duración de esta fase no suele exceder el plazo de unos pocos días.
- 8. FASE DE ITERACIONES. • Esta fase incluye la realización de diferentes fases antes de liberar la primera versión del producto. La planificación realizada en la etapa anterior se divide en diferentes iteraciones, de una duración variable entre una semana y cuatro. Los usuarios son los que deciden que historias se van a realizar en cada iteración, sabiendo que en la primera se suele realizar un sistema con la arquitectura de todo el sistema, seleccionando aquellas historias que ayuden a construirla. Las pruebas funcionales creadas por el cliente son ejecutadas al final de cada iteración, de tal manera que al final de esta fase obtenemos una versión lista para producción
- 9. FASE DE PRODUCCIÓN • En esta fase se llevan a cabo se llevan a cabo un conjunto de pruebas extras, de rendimiento y funcionamiento que son necesarias antes de poder entregar el producto al cliente. Si se encuentran cambios importantes que se deban realizar al producto, se debe decidir si incluirlos en esta versión o dejarlos para posteriores. Las iteraciones de esta fase no deben durar más de tres semanas
- 10. FASE DE MANTENIMIENTO • Una vez se ha liberada la primera versión a los usuarios, el proyecto se debe mantener en el entorno de producción siempre y cuando aún hayan iteraciones en fase de producción. Esto supone un esfuerzo considerable en la fase de mantenimiento e incluso se sugiere la contratación de nuevo personal para dar soporte a los clientes e incluso cambiar la estructura del equipo.
- 11. FASE DE CIERRE DEL PROYECTO • Es la fase en que los clientes ya no tienen más historias que deban ser implementadas. Es necesario para que podamos considerar que estamos en esta fase, que se satisfagan todas las necesidades de los clientes y otros aspectos como fiabilidad, rendimiento, etc. La documentación del proyecto se realiza en esta fase, ya que ni la arquitectura, ni el diseño, ni el código sufrirán cambio alguno. También podemos encontrarnos en esta fase si las historias que se desean implementar tienen un coste demasiado elevado para su desarrollo.
- 12. ROLES EN XP • Cliente. Es el encargado de escribir las historias y las pruebas funcionales, y es el que decide cuando un requisito es satisfecho. • Programador. Escribe tanto las pruebas como el código de la aplicación y se debe comunicar fluidamente y frecuentemente con sus compañeros. • Probador. Ayuda a escribir las pruebas funcionales al cliente, ejecuta regularmente las pruebas funcionales, transmite los resultados de las pruebas y mantiene las herramientas. • Rastreador. Es el encargado dar el “feedback” en XP. Se encarga de seguir las estimaciones hechas por los clientes y de ir avisando de las desviaciones posibles y como cuanto se ajustan a la realidad, con tal de mejorar las futuras estimaciones. También se encarga de realizar el seguimiento de las iteraciones y valorar si los objetivos se pueden alcanzar con los recursos disponibles (tiempo, personal) o si es necesario hacer algún cambio.
- 13. • Coach o tutor. Es la persona responsable de todo el proceso. Es importante que tenga conocimientos y experiencia en otros proyectos de XP y de este modo guiar y ayudar al equipo a adaptarse • Consultor. Es un miembro externo que tiene los conocimientos técnicos necesarios. El consultor guía al equipo para solucionar los problemas específicos. • Gestor o Manager. Más conocido como el jefe. Es el que toma las decisiones críticas y esta en permanente contacto con el equipo para poder discernir las diferentes situaciones críticas.
- 14. PRINCIPALES TÉCNICAS DE XP 1. El juego de la planificación (the planning game) 2. Pequeñas entregas (small releases) 3. Metáfora (metaphor) 4. Diseño simple (simple design) 5. Pruebas (testing) 6. Refactorización (refactoring) 7. Programación por parejas (pair programming) 8. Propiedad colectiva (collective ownership) 9. Integración continua (continous integration) 10. 40 horas semanales (40-hour week) 11. Cliente en casa (on-site costumer) 12. Estándares de codificación (coding standards)