Funcionamiento

Planeación

La actividad de planeación (también llamada juego de planeación) comienza escuchando –actividad para recabar requerimientos que permiten que los miembros técnicos del equipo XP entiendan el contexto del negocio para el software y adquieren la sensibilidad de la salida y características principales y funcionalidad que se requieren-. Escuchar lleva a la creación de algunas “historias” (también llamadas historias del usuario) que describen la salida necesaria, características y funcionalidad del software que se va a elaborar. Cada historia (similar a los casos de usos) es escrita por el cliente y colocada en una tarjeta indizada. El cliente asigna un valor (es decir, una prioridad) a la historia con base en el valor general de la característica o función para el negocio. Después, los miembros del equipo XP evalúan cada historia y le asignan un costo, medido en semanas de desarrollo. Si se estima que la historia requiere más de 3 semanas de desarrollo, se pide al cliente que la descomponga en historias más chicas y de nuevo se asigna un valor  y costo. Es importante observar que en cualquier momento es posible escribir nuevas historias.

Los clientes y desarrolladores trabajan juntos para decidir cómo agrupar las historias en la siguiente entrega (el siguiente incremento de software) que desarrollará el equipo XP. Una vez que se llega a un compromiso sobre la entrega (acuerdo sobre las historias por incluir, la fecha de entrega y otros aspectos del proyecto), el equipo XP ordena las historias que serán desarrolladas en una de 3 formas: 1) Todas las historias se implementarán de inmediato (en pocas semanas), 2) Las historias con más valor entrarán a la programación de actividades y se implementarán en primer lugar o 3) Las historias más riesgosas formarán parte de la programación de actividades y se implementarán primero.

Después de la primera entrega del proyecto (también llamada implemento de software) el equipo XP calcula la velocidad de éste. En pocas palabras, la velocidad del proyecto es el número de historias de los clientes implementadas durante la primera entrega. La velocidad del proyecto se usa para: 1) Ayudar a estimar las fechas de entrega y programar las actividades para las entregas posteriores, y 2) Determinar si se ha hecho un gran compromiso para todas las historias durante todo el desarrollo del proyecto. Si esto ocurre, se modifica el contenido de  las entregas o se cambian las fechas de entrega final

A medida que avanza el trabajo, el cliente puede agregar historias, cambiar el valor de una ya existente, descomponerlas o eliminarlas. Entonces, el equipo XP reconsidera todas las entregas faltantes y modifica sus planes en consecuencia.

Diseño

El diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseño sencillo siempre se prefiere sobre una representación más compleja. Además, el diseño guía la implementación de una historia conforme se escribe: Nada más y nada menos. Se desalienta el diseño de funcionalidad adicional porque el desarrollador supone que se requería después.

XP estimula el uso de tarjetas CRC como un mecanismo eficaz para pensar en el software en un contexto orientado a objetos. Las tarjetas CRC (clase-responsabilidad-colaborador) identifican y organizan las clases orientadas a objetos que son relevantes para el incremento actual de software. Las tarjetas CRC son el único producto de trabajo de  diseño que se generan como parte del proceso XP.

Sin el diseño de una historia se encuentra un problema de diseño difícil, XP recomienda la creación inmediata de un prototipo operativo de esa porción del diseño. Entonces, se implementa y evalúa el prototipo del diseño, llamado solución en punta. El objetivo es disminuir el riesgo cuando comience la implementación verdadera y validar las estimaciones originales para la historia que contiene el problema de diseño.

XP estimula el rediseño, técnica de construcción que también es un método para la optimización del diseño. Fowler describe el rediseño del modo siguiente:

 “Rediseño es el proceso mediante el cual se cambia un sistema de software en forma tal que no altere el comportamiento externo del código, pero si mejore la estructura interna. Es una manera disciplinada de limpiar el código que minimiza la probabilidad de introducir errores. En esencia, cuando se rediseña, se mejora el diseño del código después de haber sido escrito.

Como el diseño XP virtualmente no utiliza notación y genera pocos, si alguno, productos del trabajo que no sean tarjetas CRC y soluciones en punta, el diseño es visto como un artefacto en transición que puede y debe modificarse continuamente a medida que avanza la construcción.

El objetivo del rediseño es controlar dichas modificaciones, sugiriendo pequeños cambios en el diseño que “son capaces de mejorarlo en forma radical”. Sin embargo, debe notarse que el esfuerzo que requiere el rediseño aumenta en forma notable con el tamaño de la aplicación.

Un concepto central en XP es que el diseño ocurre tanto antes como después de que comienza la codificación. Rediseñar significa que el diseño se hace de manera continua conforme se construye el sistema. En realidad, la actividad de construcción en sí misma dará al equipo XP una guía para mejorar el diseño.

Codificación

Después de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño preliminar, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso (incremento de software). Una vez creada la prueba unitaria, el desarrollador está capacitado para centrarse en lo que debe implementarse para pasar la prueba. No se agrega nada extraño (MS). Una vez que el código está terminado, se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentación instantánea para los desarrolladores.

Un concepto clave durante la actividad de codificación (y uno de los aspectos de los que más se habla en la XP) es la programación por parejas. XP recomienda que dos personas trabajen juntas en una estación de trabajo con el objeto de crear código para una historia. Esto da un mecanismo para la solución de problemas en tiempo real y para el aseguramiento de la calidad también en tiempo real. También mantiene a los desarrolladores centrados en el problema que se trate. En la práctica, cada persona adopta un papel un poco diferente. Por ejemplo una de ellas tal vez piense en los detalles del código de una porción particular del diseño, mientras la otra se asegura de que siguen los estándares de codificación (parte necesaria de XP) o de que el código para la historia satisfará la prueba unitaria desarrollada a fin de validar el código confrontándolo con la historia.

A medida que las parejas de programadores terminan su trabajo, el código que desarrollan se integra con el trabajo de los demás. En ciertos casos, esto lo lleva a cabo a diario un equipo de integración. En otros, las parejas de programadores tienen la responsabilidad de la integración. Esta estrategia de “integración continua” ayuda a evitar los problemas de compatibilidad e interfaces y brinda un ambiente de “prueba de humo” que ayuda a descubrir a tiempo los errores.

Pruebas

La creación de pruebas unitarias antes de que comience la codificación es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el uso de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula una estrategias de pruebas de regresión, siempre que se modifique el código (lo que ocurre con frecuencia, dada la filosofía del rediseño en XP).

A medida que se organizan las pruebas unitarias individuales en un “grupo de prueba universal” [Wel99], las pruebas de la integración y validación del sistema puede efectuase a diario.

Esto da el equipo XP una indicación continua del envase y también lanza señales de alerta si las cosas marchan mal. Wells [Wel99] dice: “corregir pequeños problemas cada cierto número de horas toma menos tiempo que resolver problemas enormes justo antes del plazo final.”

Las pruebas de aceptación XP, también llamadas pruebas del cliente son especificadas por el cliente y se centran es las características y funcionalidad generales del sistema que son visibles y revisables por parte del cliente. Las pruebas de aceptaciones derivan de las historias de los usuarios que se han implementado como parte de la liberación del software.