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