La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Extreme Programming (XP) Grupo 03. Extreme Programming - Agenda Introducción Proceso y Fases Roles Prácticas Conclusiones.

Presentaciones similares


Presentación del tema: "Extreme Programming (XP) Grupo 03. Extreme Programming - Agenda Introducción Proceso y Fases Roles Prácticas Conclusiones."— Transcripción de la presentación:

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 Extreme Programming - Introducción Como contraposición : Métodología Ágil Características : A los individuos y su interacción de los procesos y las herramientaspor encima El software que funcionade la documentación exhaustivapor encima La colaboración con el clientela negociación contractualpor encima La respuesta al cambioseguimiento de un planpor encima

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 Extreme Programming - Introducción Valores que inspiran XP FEEDBACKCORAJECOMUNICACIÓN SIMPLICIDAD

9 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 Los costos y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro.

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.

51 Extreme Programming – Roles en XP Roles Opcionales Consultor Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico. Doomsayer (Augur de desastres) Es el responsable de que se conozcan los riesgos involucrados, que las malas noticias sean notificadas en la medida correcta, y que no se sobredimensionen. Busca posibles riesgos en forma constante, presentándolos al equipo siempre con una posible solución.

52 Extreme Programming – Roles en XP Combinación de Roles Algunos roles pueden ser combinados en un mismo individuo. Por ejemplo, el Gestor y el Tracker. Sin embargo, otras combinaciones no son recomendadas; como ser: Programador–Tracker, Programador–Tester Cliente-Programador, Entrenador-Tracker.

53 Extreme Programming – Conclusiones XP es la metodología mas popular dentro de la familia surgida luego del manifiesto Ágil, las cuales buscan simplificar los procesos a través de la reducción de irreversibilidad de los mismos. Dicha metodología ha probado ser de gran utilidad en proyectos pequeños y con requerimientos altamente cambiantes, aunque posee características que la hacen aplicable en ciertos ambientes únicamente.

54 Extreme Programming – Conclusiones Conceptos conocidos en los que se basa XP: La alta comunicación funciona. Un único ambiente para el equipo aumenta la productividad dramáticamente. La importancia de la Validación. XP reduce el tiempo entre una idea, su criterio de validación, y su implementación. Requiere disponer de pruebas repetibles automatizadas que aseguren la consistencia en el futuro. El iterar funciona. XP obliga a iterar al establecer múltiples integraciones por día, iteraciones de una a tres semanas de largo que concluyan con un sistema funcionando, y nuevos lanzamientos cada pocos meses.

55 Extreme Programming – Conclusiones El futuro de XP Simplificación del proceso de planificación e integración continua. Búsqueda de valores y principios ocultos que puedan informar de métodos útiles. Límites de XP. Cuando se debe seguir? Cual es su limite de integrantes? El rol del Cliente. Es un rol complejo de interpretar, y probablemente su papel en el proceso de desarrollo de software continúe generando nuevas ideas.

56 Preguntas


Descargar ppt "Extreme Programming (XP) Grupo 03. Extreme Programming - Agenda Introducción Proceso y Fases Roles Prácticas Conclusiones."

Presentaciones similares


Anuncios Google