Metodología eXtreme Programming

1

Desarrollada 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 noes 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 clientedurante periodos cortos.

• Para mejorar la interacción con el usuario se realiza entregasde software periodicamnete.

• Colaboración permanente entre los desarrolladores al trabajaren el código.

• El código se prueba y depura a lo largo del proceso dedesarrollo.

• Existen indicadores que miden el progreso del proyecto parapoder actualizar el plan de desarrollo.

4

• Coste

• Tiempo

• Calidad

• Alcance

Análisis

Diseño

Implementación

Pruebas

Tiempo

Alcance(a) (b) (c)

En cascada Interactivo XP

2. Introducción a la metodología XP

5

3. Fases de la

Metodología XP

eXtreme Programming

I 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

Historia de Usuarios

7

I. Planificación

8

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 de seguimiento diarias

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.

9

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.

10

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

11

III. Desarrollo

• Disponibilidad del usuario

• Estándares de implementación

• Unidades de prueba o test

• Programació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

12

IV. Pruebas

• Unidades de test o pruebas: Pilar básico

• Implantación: El código será implantado cuando supere sus

correspondientes unidades de test

• Protección contra fallos: Solución, un test

• Pruebas de aceptación: Evaluación del cliente

13

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én aprecian

los gestos, miradas, etc.

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ás sencillo posible.

14

Ventajas

• Proyectos cortos con equipos pequeños y rotables en cuanto

a roles.

• Se Basa en las historias de uso, definen los detalles técnicos

sin meterse con los detalles de implementació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 flexibles los posibles cambios que se presenten durante

el desarrollo del software.

• La comunicación con el cliente es fluida después de cada

iteración el cliente recibe un pedazo de programa

funcional, así el cliente está informado permanentemente y

puede intervenir rápidamente si el desarrollo se aleja de

sus necesidades.

15

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ía una dependencia para con el equipo de desarrollo

16

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 ). Entre las características de este producto

Open Source destacan:

• Modelo de planificación muy simple

• Tarjetas virtuales de notas

• Soporte para almacenar y controlar proyectos, iteraciones,

user stories y tareas

• 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 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