Metodologas giles y XP Patricio Letelier letelierdsic upv

Metodologías Ágiles y XP Patricio Letelier letelier@dsic. upv. es Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia

e. Xtreme Programming 2

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

Historia de XP Creado por Kent Beck para la plantilla del proyecto C 3 en Chrysler Kent fue contratado para dirigir el proyecto l Durante el proceso nació una nueva metodología: e. Xtreme Programming (XP) l C 3 concluyó exitosamente en 1997 l www. dsic. upv. es/~letelier/pub

Valores que fomenta XP Comunicación Simplicidad Retroalimentación Coraje www. dsic. upv. es/~letelier/pub

Roles XP c 2. com/cgi/wiki? Extreme. Roles Programador (Programmer) l l 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) l l Cliente (Customer) l l l www. dsic. upv. es/~letelier/pub Organiza y guía las reuniones Asegura condiciones adecuadas para el proyecto Es parte del equipo Determina qué construir y cuándo Establece las pruebas funcionales

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

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

Captura de Requisitos en XP Una ficha de User-Story www. dsic. upv. es/~letelier/pub

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: l l l 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 www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

Programación en XP Una ficha de Tarea www. dsic. upv. es/~letelier/pub

Modelo de un Proyecto XP www. dsic. upv. es/~letelier/pub

Espacio de trabajo XP Espacio abierto Mesas centrales Cubículos en el espacio exterior Espacio de trabajo del proyecto C 3 de Daimler. Chrysler www. dsic. upv. es/~letelier/pub

Prácticas XP • El juego de la planificación • Entregas pequeñas • Metáfora • Diseño simple • Pruebas • Refactoring www. dsic. upv. es/~letelier/pub • Programación en parejas • Propiedad colectiva • Integración contínua • Semana de 40 horas • Cliente in situ • Estándares de programación

Prácticas XP El Juego de la planificación Decisiones de negocio (cliente): l l Alcance ¿Cuándo debe estar listo el producto para que sea valioso en producción? Prioridad Prioriza la incorporación de las userstories 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 www. dsic. upv. es/~letelier/pub

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? l Consecuencias Tener en cuenta las consecuencias técnicas de determinadas decisiones de negocio l Proceso Organización del proceso y el equipo l 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 l www. dsic. upv. es/~letelier/pub

Prácticas XP. . . El Juego de la planificación Reunión diaria XP Reunión diaria “Stand-up Meeting” l Todo el equipo l l l De pie en un círculo l l Problemas Soluciones Evitar discusiones largas Sin conversaciones separadas www. dsic. upv. es/~letelier/pub

Prácticas XP Entregas pequeñas Cada entrega es lo más corta posible: l l 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 www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

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: l l 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 www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

www. dsic. upv. es/~letelier/pub

Prácticas XP Programación en parejas www. pairprogramming. com Todo el código se escribe en parejas l Se produce código de mayor calidad l Extiende el conocimiento “Se realiza el trabajo de 1 persona en casi la mitad del tiempo y mejor” (cuestionable) www. dsic. upv. es/~letelier/pub

Prácticas XP Propiedad colectiva Cualquiera puede modificar el código en cualquier momento Se evitan cuellos de botella en la codificación Todos asumen las responsabilidades sobre el conjunto del sistema Todos conocen algo sobre todas las partes y conocen muy bien aquéllas en las que trabajan www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

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: l l Responder preguntas Resolver disputas Establecer prioridades Discutir mejoras www. dsic. upv. es/~letelier/pub

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 www. dsic. upv. es/~letelier/pub

Prácticas XP Interacción entre Prácticas XP: Kent Beck www. dsic. upv. es/~letelier/pub

Conclusiones 32

Un día de trabajo en XP www. dsic. upv. es/~letelier/pub

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

Fuerzas que influyen los enfoque para el desarrollo de software Grado de Ceremonia/control en el proceso Tiempo 1950’s 1960’s www. dsic. upv. es/~letelier/pub 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

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

¿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 l Se están recogiendo datos (red NAME) http: //name. case. unibz. it/ l En un futuro se podrán hacer comparaciones sobre lo que es más conveniente www. dsic. upv. es/~letelier/pub

. . . ¿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 l A los programadores les gusta l A los clientes les gusta el control añadido l www. dsic. upv. es/~letelier/pub

¿Qué hace la gente con las Metodologías Ágiles? International Conference on e. Xtreme Programming and Agile Methods in Software Development (XP 200 x) l http: //www. xp 2003. org XP Agile Universe l http: //www. agileuniverse. com www. dsic. upv. es/~letelier/pub

Fin de la Presentación Metodologías Ágiles y XP Patricio Letelier letelier@dsic. upv. es Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia