Metodología XP

1. Introducción

EXtreme Programming (de ahora en adelante, XP) es una metodología de desarrollo de la ingeniería de
software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software.
Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de
la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e
incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos
en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en
los requisitos.

La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada para la gestión
de proyectos. Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de
desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y el buen clima
de trabajo. Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el equipo de
desarrollo y es idónea para proyectos con requisitos imprecisos y muy cambiantes.

La metodología XP define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad
y alcance. El método especifica que de estas cuatro variables, tres de ellas podrán ser fijadas
arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto), y el valor
de la restante deberá ser establecido por el equipo de desarrollo, quien establecerá su valor en función de
las otras tres. Por ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el precio,
el grupo de desarrollo tendrá libertad para determinar el tiempo que durará el proyecto. Se trata de
establecer un equilibrio entre las cuatro variables del proyecto.

2. El equipo de un proyecto XP

Los equipos de un proyecto de esta tipología y magnitud tienen normalmente las siguientes figuras y
roles:

 Clientes: Establecen las prioridades y marca el proyecto. Suelen ser los usuarios finales del producto
y quiénes marcan las necesidades.
 Programadores: Serán los que se encargarán de desarrollar el Extreme Programming.
 Testers: se encargan de ayudar al cliente sobre los requisitos del producto.
 Coach: Asesoran al resto de componentes del equipo y marcan el rumbo del proyecto.
 Manager: Ofrece recursos, es el responsable de la comunicación externa y quien coordina las
actividades.

En general, no obstante, los participantes en este tipo de equipos no siempre toman un rol fijo y
contribuyen con los conocimientos de cada uno en aras del beneficio colectivo.

3. Ciclo de vida XP
Al igual que otras metodologías de gestión de proyectos, tanto Ágiles como tradicionales, el ciclo XP
incluye:

 Entender lo que el cliente necesita > Fase de Exploración

 Estimar el esfuerzo > Fase de Planificación
 Crear la solución > Fase de Iteraciones
 Entregar el producto final al cliente > Fase de puesta en producción

Lo que caracteriza a XP, al igual que al resto de métodos Agiles es un ciclo de vida dinámico. ¿Cómo lo
logra XP? Mediante ciclos de desarrollo cortos (llamados iteraciones), al fin de los cuales se generan
unos entregables funcionales. En cada iteración se realiza un ciclo completo de análisis, diseño,
desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas específicas de XP. Un proyecto
con XP, implica de entre a 10 a 15 iteraciones habitualmente.

 Fase de la exploración

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la
primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se
exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de
exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan
los programadores con la tecnología.

 Fase del planeamiento

Se priorizan las historias de usuario y se acuerda el alcance del reléase (lanzamiento). Los programadores
estiman cuánto esfuerzo requiere cada historia y a partir de allí se define el cronograma. La duración del
cronograma del primer release no excede normalmente dos meses. La fase de planeamiento toma un par
de días. Se deben incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa de
planeamiento se realiza a un número de iteraciones, cada una toma de una a cuatro semanas en ejecución.
La primera iteración crea un sistema con la arquitectura del sistema completo. Esto es alcanzado
seleccionando las historias que harán cumplir la construcción de la estructura para el sistema completo.
El cliente decide las historias que se seleccionarán para cada iteración. Las pruebas funcionales creadas
por el cliente se ejecutan al final de cada iteración. Al final de la última iteración el sistema está listo
para producción.

 Fase de producción

Requiere prueba y comprobación extra del funcionamiento del sistema antes de que éste se pueda liberar
al cliente. En esta fase, los nuevos cambios pueden todavía ser encontrados y debe tomarse la decisión
de si se incluyen o no en el release actual. Durante esta fase, las iteraciones pueden ser aceleradas de una
a tres semanas. Las ideas y las sugerencias pospuestas se documentan para una puesta en práctica
posterior por ejemplo en la fase de mantenimiento. Después de que se realice el primer release productivo
para uso del cliente, el proyecto de Xp debe mantener el funcionamiento del sistema mientras que realiza
nuevas iteraciones.

 Fase de mantenimiento

Requiere de un mayor esfuerzo para satisfacer también las tareas del cliente. Así, la velocidad del
desarrollo puede desacelerar después de que el sistema esté en la producción. La fase de mantenimiento
puede requerir la incorporación de nueva gente y cambiar la estructura del equipo.

 Fase de muerte

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan
las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la
documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay
presupuesto para mantenerlo.

4. Características fundamentales

Las características fundamentales del método son:

 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

 Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de
regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las
herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la
plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez se
inspiró en SUnit, el primer framework orientado a realizar tests (pruebas), realizado para el lenguaje
de programación Smalltalk.
 Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas
en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es
revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad
inmediata.
 Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
 Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
 Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad
y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la
refactorización no se ha introducido ningún fallo.
 Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo
en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender
cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores
serán detectados.
 Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se
podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo
hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo
complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación

resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos
tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se
puede reducir el equipo de programadores.

5. Prácticas básicas de xp

De forma aislada, cualquier práctica individual de Xp tiene poco sentido, pero en conjunto, unas
compensan las carencias que las otras puedan tener.

 El juego de la Planificación - (Planning Game)

El alcance de la siguiente versión está definido por las consideraciones de negocios (prioridad de los
módulos, fechas de entrega) y estimaciones técnicas (estimaciones de funciones, consecuencias). El
objetivo del juego es maximizar el valor del software producido, La estrategia es poner en producción
las características más importantes lo antes posible, Las Piezas clave son las Story Cards, Los Jugadores
son los desarrolladores y el cliente y las Movidas son Exploración, Selección y Actualización.

 Versiones Pequeñas (Short Releases)

Un sistema simple se pone rápidamente en producción. Periódicamente, se producen nuevas versiones

agregando en cada iteración aquellas funciones consideradas valiosas para el cliente

 Metáfora del Sistema (Metaphor)

Cada Proyecto es guiado por una historia simple de cómo funciona el sistema en general, reemplaza a la
arquitectura y debe estar en lenguaje común, entendible para todos (Cliente y Desarrolladores), esta
puede cambiar permanentemente.

 Diseño Simple (Simple Designs)

El sistema se diseña con la máxima simplicidad posible (YAGNY - "No vas a necesitarlo"), Se plasma
el diseño en tarjetas CRC (Clase - Responsabilidad - Colaboración), no se implementan características
que no son necesarias, con esta técnica, las clases descubiertas durante el análisis pueden ser filtradas
para determinar qué clases son realmente necesarias para el sistema.
  Pruebas Continuas (Testing)

Los casos de prueba se escriben antes que el código. Los desarrolladores escriben pruebas unitarias y los
clientes especifican pruebas funcionales.

 Refactorización (Refactoring)

Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo, eliminando código
duplicado, simplificando funciones, Mejorando el código constantemente, si el código se está volviendo
complicado se debería modificar el diseño y volver a uno más simple. Refactoring (Modificar la forma
del código sin cambiar su funcionamiento).

 Programación por parejas (Pair Programming)

El código es escrito por dos personas trabajando en el mismo computador. "Una sola maquina con un
teclado y un mouse"

 Posesión Colectiva del Código (Collective Code Ownership)

Nadie es dueño de un módulo. Cualquier programador puede cambiar cualquier parte del sistema en
cualquier momento, siempre se utilizan estándares y se excluyen los comentarios, Los test siempre deben
funcionar al 100% para realizar integraciones con todo el código permanentemente.

 Integración continua (Continuous Integration)

Los cambios se integran en el código base varias veces por día. Todos los casos de prueba se deben pasar
antes y después de la integración, se dispone de una máquina para la integración y se realizan test
funcionales en donde participa el cliente.

 Semana laboral de 40 horas (40-Hour Week)

Cada Trabajador trabaja no más de 40 Horas por semana. Si fuera necesario hacer horas extra, esto no
debería hacerse dos semanas consecutivas. Sin héroes, esto hace que se reduzca la rotación del personal
y mejora la calidad del producto.

 Cliente en el Sitio (On Site Customer)

El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual está disponible para responder
preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy Junior no sirve y un cliente
muy Sénior no es disponible. "Lo ideal es un cliente Analista".

 Estándares de Codificación (Coding Standard)

Todo el código debe estar escrito de acuerdo a un estándar de codificación.