PROYECTO INF-162

METODOLOGÍA EXTREME PROGRAMMING (XP) 

La programación extrema es una metodología de desarrollo ligero (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.

Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación.

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

ACTIVIDADES DE XP

Fig 1. actividades de la metodologia XP 

• Codificar

Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.

• Hacer pruebas

Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.

• Escuchar

En una frase, "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?".

Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

• Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

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

CICLO DE VIDA

         El ciclo de vida de Xp se enfatiza en el carácter interactivo e incremental del desarrollo.

         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:

Ciclo de vida de eXtreme Programming

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

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

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

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.

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

Historia de Usuario
Número:	Nombre Historia de Usuario:
Modificación (o extensión) de Historia de Usuario (Nro. y Nombre):
Usuario:		Iteración Asignada:
Prioridad en Negocio: (Alta / Media / Baja)		Puntos Estimados:
Riesgo en Desarrollo: (Alto / Medio / Bajo)		Puntos Reales:
Descripción:
Observaciones:

Modelo propuesto para una historia de usuario

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.

Caso de Prueba de Aceptación
Código:	Historia de Usuario (Nro. y Nombre):
Nombre:
Descripción:
Condiciones de Ejecución:
Entrada / Pasos de ejecución:
Resultado Esperado:
Evaluación de la Prueba:

Modelo propuesto para una prueba de aceptación

• Task Card

Tarea de Ingeniería
Número Tarea:	Historia de Usuario (Nro. y Nombre):
Nombre Tarea:
Tipo de Tarea : Desarrollo / Corrección / Mejora / Otra (especificar)		Puntos Estimados:
Fecha Inicio:		Fecha Fin:
Programador Responsable:
Descripción:

Modelo propuesto para una tarea de ingeniería

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

Modelo de tarjeta CRC

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realizan, 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.