La
programación extrema (XP) usa un enfoque orientado a objetos como paradigma preferido
de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto
de cuatro actividades estructurales: planeación, diseño, codificación y
pruebas.
Planeación. Comienza escuchando (actividad
para tomar requerimientos que permite que los miembros técnicos del equipo XP
entiendan el contexto del negocio y las características y funcionalidad requeridas).
Escuchar lleva a la creación de historias del usuario que
describen la salida, características y funcionalidad del software a elaborar.
Cada historia es escrita por el cliente, el cual le asigna un valor 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. En cualquier momento es posible
escribir nuevas historias.
Los
clientes y desarrolladores trabajan juntos para decidir cómo agrupar las historias
para la siguiente entrega (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 en pocas semanas, 2) las historias con
más valor entrarán a la programación de actividades y se implementarán primero
o 3) las historias más riesgosas entrarán a la programación de actividades y se
implementarán primero.
Después de
la primera entrega del proyecto (incremento 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 a uno más complejo. 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 requerirá
después.
XP
estimula el uso de las 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 del trabajo de diseño que se genera como
parte del proceso XP.
Si
en 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. 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 sí mejore la estructura interna. Es una manera
disciplinada de limpiar el código (y modificar o simplificar el diseño interno)
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 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á mejor 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 del
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
(es frecuente que dos cabezas piensen más que una) y para el aseguramiento de
la calidad también en tiempo real (el código se revisa conforme se crea).
También mantiene a los desarrolladores centrados en el problema de 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 se 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 realizan
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 estrategia 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”, las pruebas de la integración y validación del sistema
pueden efectuarse a diario. Esto da al equipo XP una indicación continua del
avance y también lanza señales de alerta si las cosas marchan mal: “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 en las características y funcionalidad
generales del sistema que son visibles y revisables por parte del cliente. Las
pruebas de aceptación se derivan de las historias de los usuarios que se han
implementado como parte de la liberación del software.
