Metodología eXtreme Programming 1
Desarrollada por Kent Beck. «Todo «Tod o en el so soft ftw war are e cam ambi bia. a. Lo Loss re requ quis isit itos os cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los
no
miembros del equipo cambian. El problema 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.»
2
1. ¿Qué es eXtreme Programming? •
•
•
•
Metodología para un ágil desarrollo de software. Programación basada en los deseos del cliente. El equipo lo conforman los jefes de proyecto, desarrolladores y el cliente. Se rige por valores y principios.
3
•
•
•
•
•
Los desarrolladores trabajan directamente con el cliente dura du rant nte e pe peri riod odos os co cort rtos os.. Para mejorar la interacción con el usuario se realiza entregas de so soft ftwar ware e pe peri riod odic icamn amnet ete. e. Colabo Cola bora raci ció ón pe perm rman anen ente te ent ntre re lo loss de dessar arro roll llad ado ore ress al tr trab abaj ajar ar en el código. El código se prueba y depura a lo largo del proceso de desarrollo. Existen indicadores que miden el progreso del proyecto para pode po derr ac actu tual aliz izar ar el pl plan an de de desa sarr rro oll llo o. 4
2. Introducción a la metodología XP •
•
•
•
Coste Tiempo Calidad Alcance En cascada
XP
Interactivo
Análisis
Tiempo
Diseño
Implementación
Pruebas
(a)
Alcance
(b)
(c) 5
3. Fases de la Metodología XP
eXtreme Programming I Planificación Planificación 1. Historia de Usuario 2. Plan de estrategias 3. Velocidad de Proyecto 4. Iteraciones 5. Rotaciones 6. Reuniones
• • • • • •
II. Diseño 1. Metáfora del Sistema 2. Tarjetas CRC 3. Soluciones Puntuales 4. Funcionalidad minima 5. Reciclaje
• • • • •
III. Desarrollo 1. Disponibilidad del Cliente 2. Unidad de Prueba 3. Programación por pareja 4. Integración
• • • •
IV. Pruebas 1. Implantación 2. Pruebas de Aceptación
• •
6
I. Planificación
Historia de Usuarios
7
I. Planificación Rotaciones La rotaciones evitarán que las personas se conviertan en si mismas en un cuello de botella. Las rotaciones permitirán que todo el mundo conozca cómo funciona el sistema. •
Reuniones Reuniones Re uniones de seguimiento diarias di arias •
Correcciones Deberemos corregir el proceso cuando éste falle. Todo el mundo debe estar al corriente de los cambios. Para que esto funcione correctamente hay que crear unidades de prueba de cada módulo que se desarrolle. •
•
•
8
II. Diseño Simplicidad La simplicidad es la llave •
Elegir una metáfora para el sistema La tarea de elegir una metáfora para el sistema nos permitirá mantener la coherencia de nombres de todo aquello que se va a implementar. •
Tarjetas CRC Las tarjetas CRC (clase, responsabilidad y colaboración) son una metodología para el diseño de software orientado por objetos creada por Kent Beck y Ward Cunningham.
9
II. Diseño Spike Un programa Spike, es un programa muy simple que explora una posible solución al problema Limitando la funcionalidad Las mejoras al final Reciclaje El reciclaje implicará mantener el código limpio y fácil de comprender, modificar y ampliar
10
III. Desarrollo •
•
•
• •
•
•
•
•
Disponibilidad del usuario Estándares de implementación Unidades de prueba o test Programación Pro gramación parejas Integración del código Frecuencia en la integración del código El código es propiedad de todos Dejar la optimizaciones para el final No a las horas extras
11
IV.. Prueb IV Pruebas as •
•
• •
Unidades de test o pruebas: Pilar básico Implantación: El código será implantado cuando supere sus correspondientess unidades de test correspondiente Protección Pro tección contra fallos: Solución, un test Pruebas Pru ebas de aceptación: Evaluación del cliente
12
Esta metodología promueve los siguientes valores: Comunicación Es muy importante entender cuáles son las ventajas de este medio. Cuando dos (o más) personas se comunican directamente pueden no solo consumir las palabras formuladas por la otra persona, sino que tambié ién n apr pre ecian loss ge lo gest stos os,, mi mira rada das, s, etc tc.. Coraje Un miembro de un equipo de desarrollo extremo debe de tener el coraje de exponer sus dudas, miedos, experiencias sin "embellecer" éstas de ninguna de las maneras. Simplicidad Dado que no se puede predecir como va a ser en el futuro, el software que se esta desarrollando; un equipo de programación extrema intenta mantener el software lo máss se má senc ncil illo lo po posi sibl ble. e. 13
Ventajas •
•
•
•
Proyectos cortos con equipos pequeños y rotable less en cuanto a ro role less. Se Basa en las historias de uso, definen los detalles técnicos sin me mete terrse co con n lo loss de deta tall lles es de im impl plem emen enttac ació ión n Proceso ligero porque no se les asignan roles organizativos al equipo, roles como el modelado o generación de la documentación, esto es reemplazado por la prescencia de un representante especializado del cliente, haciendo así más flexibl ble es los posibles cambios que se presenten durante el de desa sarr rrol ollo lo de dell so soft ftwa ware re.. La comunicación con el cliente es fluida después de cada iteración el cliente recibe un pedazo de programa fun unci cio ona nal, l, as asíí el cl clie ien nte es esttá in info form rmad ado o pe perm rman ane ent ntem eme ent nte ey puede intervenir rápidamente si el desarrollo se aleja de sus nec necesi esidade dades. s.
14
Desventajas •
Se debe designar a una persona totalmente involucrada en el negocio, lo que podría implicar que esta persona deje de hacer sus funciones para estar totalmente disponible al equipo de desarrollo, razón por la cual se considera mejor la utilización de este proceso para desarrollos internos, pues debe haber una gran confianza entre el cliente y el equipo de desarrollo, como mencionamos antes era poco probable que el cliente pueda prescindir de sus empleados esto incurriría en un coste adicional para el cliente. Por último como podríamos representar todo lo que se debe sin documentación alguna si no se anota ni se archiva nada, como alguien más puede tomar el lugar de uno de los miembros del equipo, o hacer mejoras en el sistema, esto crear aríía una de dep pende den ncia para con el equipo de desarrollo
15
Herramientas de Software XPlanner es una herramienta de gestión y control de proyectos para equipos de desarrollo que están utilizando XP ( eXtreme Programming Pro gramming ). Entre las características de este producto producto Open Ope n Source Source des destac tacan: an: •
•
•
•
•
•
•
•
•
•
Modelo de planificación muy simple Tarjetas virtuales de notas Soporte para almacenar y controlar proyectos, iteraciones, user us er st stor orie iess y tare tareas as Integración distribuida ( con notificación por email) Control del esfuerzo empleado en los proyectos Generación de métricas (velocidad del equipo, horas individuales empleadas, ...) Posibilidad de enlazar notas a historias de usuario y tareas Introducción de texto en formato TWiki con soporte soporte de integración con otras herramientas externas Soporte de inglés, español, alemán, italiano, portugués y danés Interfaces SOAP para integración y extensión de XPlanner 16
