Metodologías Ágiles y XP

Presentación del tema: "Metodologías Ágiles y XP"— Transcripción de la presentación:

1 Metodologías Ágiles y XP
Patricio Letelier Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia

2 Contenidos Introducción a Metodologías Ágiles Extreme Programming (XP)
Prácticas de XP Conclusiones

3 ¿Qué es una Metodología Ágil? www.agilealliance.com
Las Metodologías Ágiles (AMs) valoran: Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas Desarrollar software que funciona más que conseguir una buena documentación  Minimalismo respecto del modelado y la documentación del sistema La colaboración con el cliente más que la negociación de un contrato Responder a los cambios más que seguir estrictamente una planificación

4 ¿Por qué surgen las Metodologías Ágiles (AMs)?
Dificultad para implantar metodologías tradicionales. Sofisticadas herramientas CASE y notaciones (UML) Una solución a medida para un segmento importante de proyectos de desarrollo de software Pugna entre comunidades/gurús “Aceptar el cambio” ...

5 Costo de los Cambios en SW
Tradicional Costo del cambio Suposición AMs tiempo

6 Manifiesto de las AMs agilemanifesto.org
Principios: La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor Dar la bienvenida a los cambios. Los AMs capturan los cambios para que el cliente tenga una ventaja competitiva Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente

7 … Manifiesto de las AMs La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto Construir proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir el trabajo El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo El software que funciona es la medida principal de progreso

8 … Manifiesto de las AMs Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante La atención continua a la calidad técnica y al buen diseño mejora la agilidad La simplicidad es esencial Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser más efectivo, y según esto ajusta su comportamiento

9 Comparación Ágil - ¬Ágil
Metodología Ágil Metodología No Ágil Pocos Artefactos Más Artefactos Pocos Roles Más Roles No existe un contrato tradicional o al menos es bastante flexible Existe un contrato prefijado Cliente es parte del equipo de desarrollo (además in-situ) El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio Grupos grandes Menos énfasis en la arquitectura La arquitectura es esencial

10 Principales AMs Crystal Methodologies, Alistarir Cockburn,
SCRUM, Ken Schwaber & Jeff Sutherland, DSDM (Dynamic Systems Development Method), Lean Programming, Mary Poppendieck, FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, Extreme Programming, Kent Beck Adaptative Software Development, Jim Highsmith A Practical Guide to Feature-Driven Development (The Coad Series) by Stephen R Palmer, John M. Felsing , Prentice Hall, 2002 Kent Beck, Extreme Programming Explained, Addison-Wesley, 1999 DSDM: Business Focused Development, Second Edition by Jennifer Stapleton (Editor), Consortium Dsdm, Barry Fazackerley, DSDM Consortium, Addison-Wesley, 2003 Agile Software Development with SCRUM by Schwaber Ken, Mike Beedle, Ken Schwaber, Robert C. Martin, Prentice Hall; 1st edition (October 15, 2001) Agile Software Development by Alistair Cockburn , Addison-Wesley Pub Co; 1st edition (December 15, 2001) Agile Software Development Ecosystems by Jim Highsmith, Addison Wesley Professional; 1st edition (March 26, 2002) Lean Development: An Agile Toolkit for Software Development Managers by Mary Poppendieck, Tom Poppendieck, Addison Wesley Professional; 1st edition (June 4, 2003)

11

12 eXtreme Programming

13 ¿Qué es XP? Es una metodología ágil Diseñada para entornos dinámicos
Pensada para equipos pequeños (hasta 10 programadores) Orientada fuertemente hacia la codificación Énfasis en la comunicación informal, verbal

14 Historia de XP Creado por Kent Beck para la plantilla del proyecto C3 en Chrysler Kent fue contratado para dirigir el proyecto Durante el proceso nació una nueva metodología: eXtreme Programming (XP) C3 concluyó exitosamente en 1997

15 Valores que fomenta XP Comunicación Simplicidad Retroalimentación
Coraje

16 Roles XP c2.com/cgi/wiki?ExtremeRoles
Programador (Programmer) Responsable de decisiones técnicas Responsable de construir el sistema Sin distinción entre analistas, diseñadores o codificadores En XP, los programadores diseñan, programan y realizan las pruebas Jefe de Proyecto (Manager) Organiza y guía las reuniones Asegura condiciones adecuadas para el proyecto Cliente (Customer) Es parte del equipo Determina qué construir y cuándo Establece las pruebas funcionales

17 ... Roles XP Entrenador (Coach) Encargado de Pruebas (Tester)
Responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura Encargado de Pruebas (Tester) Ayuda al cliente con las pruebas funcionales Se asegura de que las pruebas funcionales se superan Rastreador (Tracker) Metric Man Observa sin molestar Conserva datos históricos

18 Captura de Requisitos en XP
Historias del Usuario (User-Stories) Establecen los requisitos del cliente Trozos de funcionalidad que aportan valor Se les asignan tareas de programación con un nº de horas de desarrollo Las establece el cliente Son la base para las pruebas funcionales

19 Captura de Requisitos en XP Una ficha de User-Story

20 Planificación en XP Planificación por entregas (releases)
Se priorizan aquellas user-stories que el cliente selecciona porque son más importantes para el negocio Entregas: Son lo más pequeñas posibles Se dividen en iteraciones (iteración = 2 o 3 semanas) Están compuestas por historias A cada programador se le asigna una tarea de la user-story

21 Programación en XP La programación de tareas se realiza por parejas
La pareja diseña, prueba, implementa e integra el código de la tarea Código dirigido por las pruebas Código modular, intentando refactorizar siempre que se pueda

22 Programación en XP Una ficha de Tarea

23 Modelo de un Proyecto XP

24 Espacio de trabajo XP Espacio abierto Mesas centrales
Cubículos en el espacio exterior Espacio de trabajo del proyecto C3 de DaimlerChrysler

25 Prácticas XP El juego de la planificación Programación en parejas
Entregas pequeñas Metáfora Diseño simple Pruebas Refactoring Programación en parejas Propiedad colectiva Integración contínua Semana de 40 horas Cliente in situ Estándares de programación

26 Prácticas XP El Juego de la planificación
Decisiones de negocio (cliente): Alcance  ¿Cuándo debe estar listo el producto para que sea valioso en producción? Prioridad  Prioriza la incorporación de las user-stories Composición de entregas  ¿Qué se necesita para que el negocio sea mejor antes de tener el sw? Fechas de entrega  Fechas cuando el software funcionando causaría una gran diferencia

27 Prácticas XP ... El Juego de la planificación
Decisiones técnicas (programadores y otros): Estimaciones  ¿Cuánto tiempo tardará en implementarse una user-story? Consecuencias  Tener en cuenta las consecuencias técnicas de determinadas decisiones de negocio Proceso  Organización del proceso y el equipo Planificación detallada  Dentro de una entrega, qué user-stories se realizan primero. Intentar trasladar los segmentos de desarrollo más arriesgados al principio, intentando respetar las prioridades del negocio

28 Prácticas XP ... El Juego de la planificación Reunión diaria XP
Reunión diaria “Stand-up Meeting” Todo el equipo Problemas Solutiones De pie en un círculo Evitar discusiones largas Sin conversaciones separadas

29 Prácticas XP Entregas pequeñas
Cada entrega es lo más corta posible: Contenga requisitos más valiosos del sistema (básicos) Reducen el riesgo  mayor retroalimentación desde el cliente, y más frecuente Minimizar el nº de user-stories que componen una entrega  No realizar user-stories a medias

30 Prácticas XP Metáfora Cada proyecto XP es guiado por una metáfora global Da un contexto al equipo para entender los elementos básicos y sus relaciones Proporciona integridad conceptual

31 Prácticas XP Diseño simple
Se diseña “la cosa más simple que pueda funcionar” Uso de tarjetas CRC Diseño de software correcto, es aquel que: Supera todas las pruebas No tiene lógica duplicada Pone de manifiesto las intenciones importantes de los programadores Tiene el mínimo número de clases y métodos

32 Prácticas XP Pruebas Las pruebas unitarias se escriben ANTES que el código Pruebas automatizadas Permiten el desarrollo de proyectos de forma rápida y segura Pruebas unitarias  programadores Pruebas funcionales  cliente Resultado  Un programa cada vez más seguro

33 Prácticas XP Refactoring www.refactoring.com
Refactorización = Mejora del código Intentar eliminar complejidad Código duplicado  Refactorización Se plantea su aplicación después de implementar cada user-story

34

35 Prácticas XP Programación en parejas www.pairprogramming.com
Toda el código se escribe en parejas Se produce código de mayor calidad Extiende el conocimiento “Se realiza el trabajo de 1 persona en casi la mitad del tiempo y mejor” (cuestionable)

36 Prácticas XP Propiedad colectiva
Cualquiera puede modificar el código en cualquier momento  Se evitan cuellos de botella en la codificación Todos asume las responsabilidades sobre el conjunto del sistema Todos conocen algo sobre todas las partes y conocen muy bien aquéllas en las que trabajan

37 Prácticas XP Integración contínua
El código se integra y se prueba después de pocas horas Existe una ordenador dedicado para la integración Cada pareja integra su código en dicho ordenador

38 Prácticas XP Semana de 40 horas
Filosofía: “Los programadores que descansan son más productivos” El exceso de trabajo es un serio problema en un proyecto La gente está más fresca y tiene mejores ideas

39 Prácticas XP Cliente in situ
Cliente real = Aquel que usará el sistema cuando esté en producción El cliente real debe estar con el equipo de trabajo: Responder preguntas Resolver disputas Establecer prioridades Discutir mejoras

40 Prácticas XP Estándares de programación
Son fundamentales cuando los programadores cambian de pareja o hacen refactoring del código de otros Se consigue un código con el mismo estilo, homogéneo, legible

41 Prácticas XP Interacción entre Prácticas
XP: Kent Beck

42 Conclusiones

43 Un día de trabajo en XP Obtenido desde (actualmente no está disponible)

44 No todas las ideas/prácticas ágiles son buenas
Mala Precaución Buena SW funcionando >> Documentation Propiedad colectiva Mejora de la calidad iterativamente Colaboración >> Contrato Stories Pair Programming Frequent Releases Daily Stand-up Meetings Create Great Architectures Historias de usuario Programación en parejas Releases frecuentes Reunión “Stand-up” cada día Crear buenas arquitecturas Working SW >> Documentation Collective Ownership Improve Quality Iteratively Collaboration>>Contracts Nightly Builds (too early to tell) Refactor (when time appropriate) Ever-Present Customers (unlikely to work in real world) Continuous Integration (unlikely for non-trivial) Don’t Create Things to Discard (moderation!) x Nightly Builds Refactoring Cliente in situ Integración contínua No crear cosas que se desecharán Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002

45 Fuerzas que influyen los enfoque para el desarrollo de software
Grado de Ceremonia/control en el proceso Fundamentalistas Tendencia global Libertarios Trasparencia traducida desde “A History of Agile Methods” presentada por Alan Davis en las JISBD 2003 (Noviembre 2003, El Escorial, España) libertario, ria. 1. adj. Que defiende la libertad absoluta y, por lo tanto, la supresión de todo gobierno y de toda ley.□ V. comunismo ~ Tiempo 1950’s 1960’s 1970’s 1980’s 1990’s 2000’s 2010’s Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002

46 ¿Qué resultado proveen las Metodologías Ágiles?
Hay pocos datos concretos del índice de éxito de proyectos Está teniendo un gran auge Aumento en el número de proyectos ¿Por qué? Tiene el apoyo de muchos gurús en ingeniería de sw Es un proceso para gente que odia los procesos Tiene sentido ¿Política? ... Pugna entre comunidades

47 ¿Cuándo utilizar una Metodología Ágil?
¿Existe ya un proceso? Si ¿Reacciona bien a los cambios? Si ¿Está el equipo contento con él? Si  Mejor esperar Se están recogiendo datos (red NAME) En un futuro se podrán hacer comparaciones sobre lo que es más conveniente

48 ... ¿Cuándo utilizar una Metodología Ágil?
¿Existe ya un proceso? No o existe pero no reacciona bien a los cambios o existe pero el equipo no está contento con él  Una Metodología Ágil puede ser una buena forma de empezar Fácil de financiar A los programadores les gusta A los clientes les gusta el control añadido

49 ¿Qué hace la gente con las Metodologías Ágiles?
International Conference on eXtreme Programming and Agile Methods in Software Development (XP200x) XP Agile Universe

50 Metodologías Ágiles y XP
Fin de la Presentación Metodologías Ágiles y XP Patricio Letelier Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia