A propósito de programación extrema XP (eXtreme Programming) (página 2)

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.

[4] nos dice que para evaluar Xp hay que mirar la gran
foto, es decir, todo el conjunto de prácticas:

Figura No.1. Practicas de XP, Tomado
de [2], [4]

• El juego de la
  Planificación – (Planning
  Game)

El alcance de la siguiente versión esta 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 esta
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 modulo. 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 lo casos de prueba se deben pasar
antes y después de la integración, se dispone de una maquina 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 esta 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

6.
Ciclo de Vida

El ciclo de vida
de Xp se enfatiza en el carácter interactivo e incremental del
desarrollo, Según [1] una iteración de desarrollo
es un período de tiempo en el que se realiza un conjunto
de funcionalidades determinadas que en el caso de Xp corresponden
a un conjunto de historias de usuarios.

Las iteraciones son relativamente cortas ya que se
piensa que entre más rápido se le entreguen
desarrollos al cliente, más retroalimentación se va a obtener y esto va
a representar una mejor calidad del producto a largo plazo.
Existe una fase de análisis inicial orientada a programar
las iteraciones de desarrollo y cada iteración incluye
diseño, codificación y pruebas, fases superpuestas
de tal manera que no se separen en el tiempo.

La siguiente figura muestra las fases
en las que se subdivide el ciclo de vida Xp:

Figura No.2. Ciclo de vida de eXtreme
Programming, Tomado de [1], [2]

[1] y [3] nos describen cada una de las fases en las que
se subdivide el ciclo de vida de eXtreme Programming:

6.1. 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.

6.2 Fase del planeamiento:
se priorizan las historias de usuario y se acuerda el alcance del
release. 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 esta listo para producción.

6.3. 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.

6.4. 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.

6.5. 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.

7.
Actores y Responsabilidades de Xp

Existen diferentes roles (actores) y responsabilidades
en Xp para diferentes tareas y propósitos durante el
proceso:

Programador (Programmer)

• Responsable de decisiones técnicas
• Responsable de construir el sistema
• Sin distinción entre analistas,
  diseñadores o codificadores
• En Xp, los programadores diseñan, programan y
  realizan las pruebas

Cliente (Customer)

• Es parte del equipo
• Determina qué construir y
  cuándo
• Escribe tests funcionales para determinar
  cuándo está completo un determinado
  aspecto

Entrenador (Coach)

• El líder
  del equipo – toma las decisiones importantes
• Principal responsable del proceso
• Tiende a estar en un segundo plano a medida que el
  equipo madura

Rastreador (Tracker)

• Metric Man
• Observa sin molestar
• Conserva datos
  históricos

Probador (Tester)

• Ayuda al cliente con las pruebas
  funcionales
• Se asegura de que los tests funcionales se
  ejecutan

8.
Artefactos Xp

A continuación describimos los artefactos de Xp,
entre los que se encuentran: Historias de Usuario, Tareas de
Ingeniería y Tarjetas CRC.

8.1. Historias de Usuario

Representan una breve descripción del comportamiento del sistema,
emplea terminología del cliente sin lenguaje
técnico, se realiza una por cada característica
principal del sistema, se emplean para hacer estimaciones de
tiempo y para el plan de
lanzamientos, reemplazan un gran documento de requisitos y
presiden la creación de las pruebas de
aceptación.

Tabla No.1. Modelo
propuesto para una historia de usuario, Tomado de
[3]

Estas deben proporcionar sólo el detalle
suficiente como para poder hacer
razonable la estimación de cuánto tiempo requiere
la implementación de la historia, difiere de los casos de
uso porque son escritos por el cliente, no por los programadores,
empleando terminología del cliente. "Las historias de
usuario son más "amigables" que los casos de uso
formales".

Las Historias de Usuario tienen tres
aspectos:

• Tarjeta: en ella se almacena suficiente información para identificar y detallar
  la historia.
• Conversación: cliente y programadores discuten
  la historia para ampliar los detalles (verbalmente cuando sea
  posible, pero documentada cuando se requiera
  confirmación)
• Pruebas de Aceptación: permite confirmar que
  la historia ha sido implementada correctamente.

Tabla No.2. Modelo propuesto para una
prueba de aceptación, Tomado de [3]

8.2. Task Card

Tabla No.3. Modelo propuesto para una
tarea de ingeniería, Tomado de [3]

8.3. Tarjetas CRC (Clase –
Responsabilidad – Colaborador).

Estas tarjetas se dividen en tres secciones que
contienen la información del nombre de la clase, sus
responsabilidades y sus colaboradores. En la siguiente figura se
muestra cómo se distribuye esta
información.

Tabla No.4. Modelo de tarjeta CRC,
Tomado de [2]

Una clase es cualquier persona, cosa,
evento, concepto,
pantalla o reporte. Las responsabilidades de una clase son las
cosas que conoce y las que realiza, sus atributos y métodos.
Los colaboradores de una clase son las demás clases con
las que trabaja en conjunto para llevar a cabo sus
responsabilidades.

En la práctica conviene tener pequeñas
tarjetas de cartón, que se llenarán y que son
mostradas al cliente, de manera que se pueda llegar a un acuerdo
sobre la validez de las abstracciones propuestas.

Los pasos a seguir para llenar las tarjetas son los
siguientes:

• Encontrar clases
• Encontrar responsabilidades
• Definir colaboradores
• Disponer las tarjetas

Para encontrar las clases debemos pensar qué
cosas interactúan con el sistema (en nuestro caso el
usuario), y qué cosas son parte del sistema, así
como las pantallas útiles a la aplicación (un
despliegue de datos, una entrada de parámetros y una
pantalla general, entre otros). Una vez que las clases
principales han sido encontradas se procede a buscar los
atributos y las responsabilidades, para esto se puede formular la
pregunta ¿Qué sabe la clase? y ¿Qué
hace la clase? Finalmente se buscan los colaboradores dentro de
la lista de clases que se tenga.

9.
Críticas a eXtreme Programming

Algunas de las críticas recopiladas de Xp
son:

Xp tiene muchas críticas especialmente contra la
programación por parejas por parte de
muchos programadores con gran sentimiento de posesión del
código, piensan que ellos son los mejores conocedores de
las herramientas y lenguajes que utilizan y que si alguien no lo
entiende es por que no sabe lo suficiente.

También se critica el mito de las 40
horas semanales ya que es un lujo para las exigencias del
mercado.

También hay críticas hacia Xp que dicen
que solo puede funcionar con programadores muy buenos, como Kent
Beck, que son capaces de hacer un buen diseño, sencillo y
fácilmente extensible.

Xp es mas una filosofía de trabajo que
una metodología. Por otro lado ninguna de las
practicas defendidas por Xp son invención de este método, Xp
lo que hace es ponerlas todas juntas.

Xp esta diseñado para grupos de
pequeños programadores, más de 10 ya seria muy
complicado, y mas aun para que estén en el mismo centro de
trabajo.

10.
BIBLIOGRAFÍA

[1] Hurtado, Julio Ariel, Bastiarrica Cecilia. Proyecto
SIMEP-SW Mayo 08 de 2005, Modelo de Procesos,
Calidad y Mejoramiento: CMM, TSP, PSP, ISO, IEEE,
SPICE, etc.

[2] Reynoso Billy Carlos. Metodos Agiles en Desarrollo
de Software, Introducción a la Arquitectura de Software.
Universidad de
Buenos
Aires.

billyr[arroba]microsoft.com.ar

http://www.microsoft.com/spanish/msdn/arquitectura.

[3] José H. Canós, Patricio Letelier y
Mª Carmen Penadés. Metodologías Ágiles
para el desarrollo de software. Universidad Politécnica de
Valencia. { jhcanos | letelier | mpenades
}[arroba]dsic.upv.es

[4] Cubel Navarro, Jose Mª. eXtreme Programming
Laboratorio de
Sistemas de
Información, Universidad Politécnica de
Valencia.

[5] Manuel Calero Solís. Una explicación
de la programación extrema (XP), V Encuentro usuarios
xBase 2003 MADRID
http://www.apolosoftware.com/

XP Agile Universe: www.agileuniverse.com. Conference on
eXtreme Programming and Agile Processes in Software.

Letelier Patricio, Metodologías Ágiles
para el desarrollo de software: Aplicando Extreme Programming.
Universidad Politécnica de Valencia.

Calero Solís, Manuel. Apolo Software. Una
explicación de Programación extrema.
http://www.apolosoftware.com/

Robles, Gregorio. Programación eXtrema (y
Software
Libre)

grex[arroba]gsyc.escet.urjc.es

Web’s Programación extrema:

www.programacionextrema.org

http://www.extremeprogramming.org

http://www.xprogramming.com

Autor:

Adrian Anaya Villegas

Popayan – Cauca – Colombia

Edison Arley Plaza Marín

Carrera 32 No. 4-57

Popayan – Cauca – Colombia