Download - Metodologías Ágiles y XP
Metodologías Ágiles y XP
Patricio [email protected]
Departamento de Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
2
eXtreme Programming
www.dsic.upv.es/~letelier/pub
¿Qué es XP?
Es una metodología ágilDiseñada para entornos dinámicosPensada para equipos pequeños (hasta 10
programadores)Orientada fuertemente hacia la codificaciónÉnfasis en la comunicación informal, verbal
www.dsic.upv.es/~letelier/pub
Historia de XP
Creado por Kent Beck para la plantilla del proyecto C3 en ChryslerKent fue contratado para dirigir el proyectoDurante el proceso nació una nueva
metodología: eXtreme Programming (XP)C3 concluyó exitosamente en 1997
www.dsic.upv.es/~letelier/pub
Valores que fomenta XP
Comunicación
Simplicidad
Retroalimentación
Coraje
www.dsic.upv.es/~letelier/pub
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
www.dsic.upv.es/~letelier/pub
... Roles XP
Entrenador (Coach) 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
www.dsic.upv.es/~letelier/pub
Captura de Requisitos en XP
Historias del Usuario (User-Stories)Establecen los requisitos del cliente Trozos de funcionalidad que aportan valorSe les asignan tareas de programación con
un nº de horas de desarrolloLas establece el clienteSon la base para las pruebas funcionales
www.dsic.upv.es/~letelier/pub
Captura de Requisitos en XPUna 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: 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 C3 de DaimlerChrysler
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
• Programación en parejas
• Propiedad colectiva
• Integración contínua
• Semana de 40 horas
• Cliente in situ
• Estándares de programación
www.dsic.upv.es/~letelier/pub
Prácticas XPEl 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
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? 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
www.dsic.upv.es/~letelier/pub
Reunión diaria “Stand-up Meeting” Todo el equipo
Problemas Soluciones
De pie en un círculo Evitar discusiones largas Sin conversaciones separadas
Prácticas XP... El Juego de la planificación
Reunión diaria XP
www.dsic.upv.es/~letelier/pub
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
Prácticas XPEntregas pequeñas
www.dsic.upv.es/~letelier/pub
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
Prácticas XPMetáfora
www.dsic.upv.es/~letelier/pub
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
Prácticas XPDiseño simple
www.dsic.upv.es/~letelier/pub
Las pruebas unitarias se escriben ANTES que el códigoPruebas automatizadas Permiten el desarrollo de proyectos de forma rápida y seguraPruebas unitarias programadoresPruebas funcionales clienteResultado Un programa cada vez más seguro
Prácticas XPPruebas
www.dsic.upv.es/~letelier/pub
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
Prácticas XPRefactoring
www.refactoring.com
www.dsic.upv.es/~letelier/pub
www.dsic.upv.es/~letelier/pub
Todo 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)
Prácticas XPProgramación en parejas
www.pairprogramming.com
www.dsic.upv.es/~letelier/pub
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
Prácticas XPPropiedad colectiva
www.dsic.upv.es/~letelier/pub
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
Prácticas XPIntegración contínua
www.dsic.upv.es/~letelier/pub
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
Prácticas XPSemana de 40 horas
www.dsic.upv.es/~letelier/pub
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
Prácticas XPCliente in situ
www.dsic.upv.es/~letelier/pub
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
Prácticas XPEstándares de programación
www.dsic.upv.es/~letelier/pub
Prácticas XPInteracción entre Prácticas
XP: Kent Beck
32
Conclusiones
www.dsic.upv.es/~letelier/pub
Un día de trabajo en XP
www.dsic.upv.es/~letelier/pub
StoriesPair ProgrammingFrequent Releases
Daily Stand-up MeetingsCreate Great Architectures
Working SW >> DocumentationCollective OwnershipImprove Quality IterativelyCollaboration>>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
MalaPrecaución
Buena
• Nightly Builds• Refactoring• Cliente in situ• Integración contínua• No crear cosas que se desecharán
Historias de usuario Programación en parejas
Releases frecuentes Reunión “Stand-up” cada día
Crear buenas arquitecturas
• SW funcionando >> Documentation• Propiedad colectiva• Mejora de la calidad iterativamente• Colaboración >> Contrato
No todas las ideas/prácticas ágiles son buenas
Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002
www.dsic.upv.es/~letelier/pub
Fuerzas que influyen los enfoque para el desarrollo de software
Grado de Grado de Ceremonia/control Ceremonia/control
en el procesoen el proceso
TiempoTiempo
1950’s1950’s 1960’s1960’s 1970’s1970’s 1980’s1980’s 1990’s1990’s 2000’s2000’s 2010’s2010’s
Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002
www.dsic.upv.es/~letelier/pub
¿Qué resultado proveen las Metodologías Ágiles?
Hay pocos datos concretos del índice de éxito de proyectosEstá teniendo un gran auge Aumento en el número de proyectos ¿Por qué?
Tiene el apoyo de muchos gurúes en ingeniería de swEs un proceso para gente que odia los procesosTiene sentido¿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 esperarSe están recogiendo datos (red NAME) http://
name.case.unibz.it/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? Noo existe pero no reacciona bien a los cambioso existe pero el equipo no está contento con él
Una Metodología Ágil puede ser una buena forma de empezar
Fácil de financiarA los programadores les gustaA los clientes les gusta el control añadido
www.dsic.upv.es/~letelier/pub
¿Qué hace la gente con las Metodologías Ágiles?
International Conference on eXtreme Programming and Agile Methods in Software Development (XP200x) http://www.xp2003.org
XP Agile Universe http://www.agileuniverse.com
Metodologías Ágiles y XP
Departamento de Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
Fin de la Presentación
Patricio [email protected]