Metodologías Ágiles: Extreme Programming (XP)

1. Introducción a la Ingeniería del Software

No existe un proceso de desarrollo único que sirva para todo tipo de proyecto. XP no es válido para cualquier proyecto, especialmente para equipos grandes, clientes desconfiados o tecnologías sin soporte a cambios graduales. Los procesos clásicos tampoco son válidos para todos los proyectos.

2. ¿Qué es XP?

Definición: XP es un proceso ligero de desarrollo de software orientado a objetos.

Diseñado para centrarse en cuatro aspectos fundamentales:

• Escuchar
• Pruebas
• Codificar
• Diseñar

Características:

• El código es el centro de todo el proceso.
• Las prácticas se aplican de forma extrema.
• Ninguna de las ideas es nueva; la combinación de ideas y su aplicación extrema es lo que define a XP.

3. Aspectos Desconcertantes de XP

• Sin documentación de diseño explícita: No existen estándares predefinidos sobre cómo se debe documentar.
• Diseño emergente: El diseño se refleja en cada actividad diaria, pero no existe un diseño explícito previo.
• Simplicidad y disciplina: XP busca trabajar con tendencias naturales, pero requiere gran disciplina y consistencia.
• Idoneidad para proyectos específicos: XP es ideal para ciertos tipos de proyectos, no para todos.

4. Prácticas de XP

XP se basa en la aplicación de 12 prácticas (guías o reglas):

a. Proceso Continuo

• Releases frecuentes
• Refactoring
• Integración continua

b. Feedback Rápido

• Pruebas
• Programación en pareja
• Cliente in-situ

c. Conocimiento Compartido

• Propiedad colectiva del código
• Codificación estándar
• Planning game
• Metáfora
• Diseño simple

d. Beneficio al Desarrollador

• Semanas de 40 horas

5. Planning Game

Piezas: Requisitos de usuario

Participantes: Usuario y desarrollador

Acciones:

1. Recogida de requisitos del usuario: El usuario escribe los requisitos en tarjetas, usando un lenguaje propio del negocio. Cada tarjeta describe una función del sistema y se le asigna un valor de importancia. Para un proyecto de pocos meses, debería haber entre 50 y 100 tarjetas.
2. Estimación: El desarrollador asigna un coste a cada tarjeta, medido en semanas (1-3 semanas). Si una tarjeta supera las 3 semanas, el usuario debe dividirla.
3. Acuerdo: Usuario y desarrollador deciden qué tarjetas conforman la próxima release.
4. Valor y riesgo primero: El desarrollador ordena las tarjetas de la release priorizando las más importantes o de mayor riesgo. Se debe poder generar un sistema ejecutable en 2 semanas.

6. Releases Frecuentes

• Proceso de desarrollo iterativo.
• Ciclo de release no superior a 3 meses.
• Iteraciones de no más de 3 semanas.
• Implementación de tarjetas seleccionadas en cada iteración.
• División de tarjetas en tareas de programación de 1 a 3 días.
• Releases pequeñas y frecuentes para obtener feedback constante del usuario.

7. Metáfora del Sistema

Sinónimo de arquitectura del sistema. Proporciona una visión global de los objetivos del proyecto y define el ámbito para desarrolladores y usuarios. El sistema se construye a partir de una o más system metaphors.

8. Pruebas

Las pruebas son cruciales en XP y se escriben antes de codificar. Esto fuerza la concentración en las interfaces, acelera el desarrollo y asegura la codificación y el refactoring.

Características de las pruebas:

• Automatizadas (utilizando frameworks de pruebas como JUnit).
• Consideradas la especificación del sistema.

Tipos de pruebas:

1. Pruebas de aceptación (funcionales): El usuario proporciona los casos de prueba y los desarrolladores los automatizan.
2. Pruebas unitarias: Los desarrolladores escriben las pruebas para sus clases antes de implementarlas. Todas las pruebas unitarias deben ejecutarse con un 100% de éxito.

9. Refactoring

Proceso de mejora del código que mantiene la funcionalidad. Objetivos:

• Simplificar el diseño
• Mejorar la legibilidad del código
• Mejorar la tolerancia a cambios

El código debe ser autoexplicativo, usando nombres significativos. El refactoring es constante, eliminando código duplicado. Las pruebas garantizan que el refactoring no altera el comportamiento.

10. Programación en Pareja

• Dos programadores por ordenador: uno codifica y el otro revisa.
• Las parejas cambian constantemente.
• Mayor calidad del código, con menos defectos y más simple.
• Inspección continua del código.
• Coste 10-15% mayor que la programación individual.

11. Propiedad Colectiva del Código

El código pertenece al equipo, no a un programador individual. Cualquier programador puede modificarlo para simplificarlo o mejorarlo. Esto fomenta la colaboración y la calidad del código.

12. Integración Continua

• Integración al menos diaria.
• Construcción del sistema cada 2 horas.
• Ciclo: pruebas unitarias, codificación, integración, ejecución de pruebas, release.
• Disponibilidad constante de una versión probada del sistema.

13. Semanas de 40 Horas

Los programadores no deberían trabajar horas extras. Si lo hacen, indica un problema en la planificación. Esto mantiene la eficiencia y el descanso del equipo.

14. Usuario In-Situ

El usuario debe estar disponible para resolver ambigüedades, establecer prioridades y proporcionar casos de prueba. Se le considera parte del equipo.