Extreme Programming (XP)

1. Extreme Programming (XP) Grupo 03

2. Extreme Programming - Agenda • Introducción • Proceso y Fases • Roles • Prácticas • Conclusiones

3. Extreme Programming - Introducción • Proceso : conjunto de actividades ordenadas para lograr una serie de objetivos • Proceso Pesado : * fuerte dependencia de planificaciones * se establecen actividades * se establecen artefactos * se establecen herramientas y notaciones * ESTAMOS MUY CONTROLADOS

4. A los individuos y su interacción por encima de los procesos y las herramientas El software que funciona por encima de la documentación exhaustiva La colaboración con el cliente por encima la negociación contractual La respuesta al cambio por encima seguimiento de un plan Extreme Programming - Introducción • Como contraposición : Métodología Ágil • Características :

5. Extreme Programming - Introducción • Resumen * Estamos menos controlado * Preparados para el cambio * Cliente forma parte del equipo * Pocos artefactos * Más importante software funcionando que documentación

6. Extreme Programming - Introducción • XP es una Métodología Ágil • Desarrollado por Kent Beck «Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.»

7. Extreme Programming - Introducción • Estadísticas : método que más popularidad ha alcanzado de las metodologías ágiles • Se basa en la suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo • Asume que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde.

8. FEEDBACK CORAJE COMUNICACIÓN SIMPLICIDAD Extreme Programming - Introducción • Valores que inspiran XP

9. Los costos y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro. Extreme Programming - Introducción • Simplicidad • La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada momento sólo las necesidades actuales. • Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las necesidades reales

10. Extreme Programming - Introducción • FeedBack • Una metodología basada en el desarrollo incremental iterativo de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones. • De esta forma fallos se localizan muy pronto. • La planificación no puede evitar algunos errores, que sólo se evidencian al desarrollar el sistema. • La retro-información es la herramienta que permite reajustar la agenda y los planes.

11. Extreme Programming - Introducción • Coraje • Implica saber tomar decisiones difíciles. • Reparar un error cuando se detecta • Mejorar el código siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora • Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y cuándo se van a entregar

12. Extreme Programming - Introducción • Comunicación • XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente

13. Extreme Programming – Proceso y Fases • 1. El cliente define el valor de negocio a implementar • 2. El programador estima el esfuerzo necesario para su implementación • 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo • 4. El programador construye ese valor de negocio • 5. Vuelve al paso 1

14. Extreme Programming – Proceso y Fases • El costo del cambio

15. Extreme Programming – Proceso y Fases • Historias de Usuario • Técnica para especificar los reqs. • Son tarjetas de papel • Debe ser lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas

16. Extreme Programming – Proceso y Fases • Fases • Exploración • Planificación de la Entrega • Iteraciones • Producción • Mantenimiento • Muerte del Proyecto

17. Extreme Programming – Proceso y Fases

18. Reglas y prácticas de XP • Conjunto de actividades simples que guían los diferentes aspectos del desarrollo para seguir el proceso. • Se dividen en áreas del desarrollo • Planificación • Diseño • Codificación • Verificación

19. Reglas y prácticas de XP - Planificación • El “Juego de la Planificación” • Planificación se vuelve “emocional” • Todos quieren planificar mejor • Conflictos • Mirar la planificación como un Juego • Objetivos • Jugadores • Piezas • Reglas

20. Reglas y prácticas de XP - Planificación • El “Juego de la Planificación” • Piezas: Historias de Usuario • Objetivo: Poner en producción la mayor cantidad de Historias de Usuario • Jugadores: Desarrolladores y Encargados del Negocio

21. Reglas y prácticas de XP - Planificación • El “Juego de la Planificación” • Movimientos: • Escribir Historia de Usuario • Estimarla • Comprometerse a realizar: • Por Historia • Por Fecha • Valor y Riesgo Primero • Recuperación por Sobrecarga • Cambio de Valor de Historia • Introducir nueva Historia • Dividir una Historia • Salto • Re-estimar

22. Reglas y prácticas de XP - Planificación • Escribir Historias de Usuario • Similar a los Casos de Uso • Usadas para estimaciones de tiempo en la planificación de las liberaciones • Usados en lugar del Documento de Requerimientos • Escritas por el Cliente en términos del Cliente • Guían la creación de Pruebas de Aceptación

23. Reglas y prácticas de XP - Planificación • Los Planes de Liberación organizan el Calendario • Surgen en las reuniones de Planificación de Liberaciones • Utilizados para crear Planes de Iteraciones • Decisiones Técnicas por el personal Técnico y decisiones de negocio por el personal de Negocio

24. Reglas y prácticas de XP - Planificación • El equipo estima la duración de la implementación de cada Historia de Usuario en “Semanas Ideales de Implementación” • El cliente prioriza las Historias teniendo en cuenta el valor que le aporta al sistema tenerla completa

25. Reglas y prácticas de XP - Planificación • Medir la “Velocidad del Proyecto” • ¿Cuánto trabajo está siendo completado en el proyecto? • Suma de las estimaciones de las Historias de Usuario completas al fin de la Iteración • Utilizada para planificar la siguiente Iteración

26. Reglas y prácticas de XP - Planificación • Utilizamos la “Velocidad del Proyecto” para planificar • Por Fecha • Por Alcance

27. Reglas y prácticas de XP - Planificación • Liberaciones pequeñas y frecuentes • Producir rápidamente versiones operativas del sistema • No debería tardar más de 3 meses

28. Reglas y prácticas de XP - Planificación • Rotación del Equipo • Ayuda a evitar “Islas de Conocimiento” • Mejora la flexibilidad del equipo • Evita la sobrecarga de una persona

29. Reglas y prácticas de XP - Planificación • Mejorar el proceso cuando sea necesario • Es bueno tener reglas para saber qué esperar del equipo • Si se detectan problemas en el avance se debe revisar qué está mal • Debe consultarse al equipo sobre qué cosas dificultan el funcionamiento

30. Reglas y prácticas de XP - Diseño • Diseño simple: • Implementar la solución más simple que pueda funcionar • La complejidad innecesaria y el código extra debe ser removido inmediatamente • No agregar nuevas funcionalidades antes de que sean agendadas

31. Reglas y prácticas de XP - Diseño • Metáforas: • El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo • Es una historia compartida que describe cómo debería funcionar el sistema • Solventan el hecho de no contar con una definición de la arquitectura desde el comienzo, ya que en XP la arquitectura se asume evolutiva

32. Reglas y prácticas de XP - Diseño • Tarjetas CRC: • Las Tarjetas CRC (Class, Responsibilities and Collaboration) sirven para diseñar el sistema en conjunto entre todo el equipo • Permiten reducir el modo de pensar procedural y apreciar la tecnología de objetos

33. Reglas y prácticas de XP - Diseño • No agregar funcionalidades antes de lo planeado: • Parecería que fuera más rápido agregarlas ahora pero nosotros debemos recordarnos constantemente que no las necesitamos ahora realmente y quizás nunca las necesitemos • Funcionalidades extra siempre nos hacen atrasar y malgastar nuestros recursos

34. Reglas y prácticas de XP - Diseño • Refactorización: • Es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios • Mejora la estructura interna del código sin alterar su comportamiento externo • Nos ahorra tiempo e incrementa la calidad

35. Reglas y prácticas de XP - Codificación • El cliente está siempre disponible: • Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio • La comunicación oral es más efectiva que la escrita, ya que esta última toma mucho tiempo en generarse y puede tener más riesgo de ser mal interpretada

36. Reglas y prácticas de XP - Codificación • Las historias de usuario son escritas por los clientes con la ayuda de los desarrolladores • El cliente debe negociar la selección de las historias de usuario que serán incluidas en una liberación • Como los detalles no son incluidos en las historias de usuario, los desarrolladores necesitarán hablar con los clientes para obtenerlos • El cliente es necesario con las pruebas

37. Reglas y prácticas de XP - Codificación • El tiempo del cliente es ahorrado al principio por no requerir una especificación detallada de los requerimientos y ahorrado después ya que el sistema es mucho más probable que sea de su agrado

38. Reglas y prácticas de XP - Codificación • Estándares de programación: • XP enfatiza la comunicación de los programadores a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación • Mantienen el código legible para los miembros del equipo, facilitando los cambios

39. Reglas y prácticas de XP - Codificación • Pruebas unitarias: • La producción de código está dirigida por las pruebas unitarias • Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema • Otros desarrolladores podrán ver como usar el código observando las pruebas

40. Reglas y prácticas de XP - Codificación • Programación en parejas: • Incrementa la calidad del software sin impactar el tiempo para cumplir lo prometido • Muchos errores son detectados conforme son introducidos en el código • Los diseños son mejores y el tamaño del código menor • Los problemas de programación se resuelven más rápido

41. Reglas y prácticas de XP - Codificación • Se posibilita la transferencia de conocimientos de programación entre los miembros del equipo • Varias personas entienden las diferentes partes del sistema • Los programadores conversan mejorando así el flujo de información y la dinámica del equipo

42. Reglas y prácticas de XP - Codificación • Integración secuencial: • Solo una pareja de desarrolladores puede integrar, testear y liberar cambios al repositorio de código en un momento determinado • Se permite que la última versión esté consistentemente identificada

43. Reglas y prácticas de XP - Codificación • Integración continua: • Cada pieza de código es integrada en el sistema una vez que esté lista. • Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día • Es una forma de que todo el mundo esté trabajando con casi la última versión • Evita o detecta antes los problemas de compatibilidad

44. Reglas y prácticas de XP - Codificación • Propiedad colectiva del código: • Cualquier programador puede cambiar cualquier parte del código en cualquier momento. • Motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, • Evita que algún programador sea imprescindible para realizar cambios en alguna porción de código

45. Reglas y prácticas de XP - Codificación • 40 horas por semana: • Se debe trabajar un máximo de 40 horas por semana • No se trabajan horas extras en dos semanas seguidas • El trabajo extra desmotiva al equipo

46. Extreme Programming – Roles en XP • Los roles siempre presentes en esta metodología son los siguientes: • Programador • Cliente • Encargado de pruebas (Tester) • Encargado de seguimiento (Tracker) • Entrenador (Coach) • Gestor (Big Boss)

47. Extreme Programming – Roles en XP • Roles Opcionales en los proyectos: • Consultor • Doomsayer (Augur de desastres)

48. Extreme Programming – Roles en XP • El programador escribe las pruebas unitarias y produce el código del sistema. Define las tareas que conlleva cada historia de usuario, y estima el tiempo que requerirá cada una. • El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio.

49. Extreme Programming – Roles en XP • El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. • El encargado de seguimiento verifica las estimaciones realizadas, evalúa el progreso de cada iteración y así como la factibilidad de los objetivos con las restricciones de tiempo y recursos presentes. Mantiene contacto directo con el equipo de desarrollo, realizando cambios para lograr los objetivos de cada iteración.

50. Extreme Programming – Roles en XP • El entrenador es responsable del proceso global. Experto en XP, provee de las guías a los miembros del equipo para que se apliquen las prácticas XP y se siga el proceso correctamente. Determina la tecnología y metodologías a usar por el equipo de desarrollo. • El Gestor es el dueño del equipo y sus problemas.Experto en tecnología y labores de gestión. Construye el plantel del equipo, obtiene los recursos necesarios y maneja los problemas que se generan. Administra a su vez las reuniones (planes de iteración, agenda de compromisos, etc). No le dice al grupo lo que tiene que hacer, cuando hacerlo, ni verifica el avance de las tareas.