Unidad IV Programación Extrema

4.1 ¿Que  es la programación extrema ?

Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

XP se basa en cuatro principios: simplicidad, comunicación, retroalimentación y valor. Además, orientada por pruebas y refactorización, se diseña e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad. Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos

responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programación.

4.2 Ciclo de vida de la XP

El ciclo de vida de XP se enfatiza en el carácter iterativo e incremental del desarrollo, 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.

Fase de 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. 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.

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

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

4.3 Variables de la Programación Extrema 

XP define cuatro variables para proyectos de software y son: 

Coste:

XP nos propone que juguemos todas las partes implicadas en el proyecto hasta que el valor que alcancen las cuatro variables sea el correcto para todas las partes: “Si quieres mas calidad en menos tiempo tendrás que aumentar el equipo e incrementar el coste”.

Tiempo:

Siempre se quiere entregar el trabajo mas rápido, por tanto probar menos, codificar más rápido y peor, sin hacer planteamientos maduros, esto repercutiría en la confianza de los clientes, al entregarle trabajos con fallos. 

Calidad :

Con la calidad suele suceder un fenómeno extraño: frecuentemente un proyecto que tratemos de aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo, siempre con unos márgenes obviamente. Cuando un equipo de desarrollo se acostumbra a realizar pruebas intensivas, se siguen estándares de codificación, poco a poco se comenzara a andar mas rápido y mas seguro, por tanto mas preparados para futuros cambios, sin estrés y así sucesivamente.

Ámbito:

El ámbito del proyecto, suele ser conveniente que sea establecida por el equipo de desarrollo. Es una variable muy importante que nos va a decir donde vamos a llegar con nuestro software, que problemas vamos a resolver y cuales vamos a dejar para siguientes versiones. Y es que los requisitos nunca son claros al principio y el mismo desarrollo del software hace cambiar los requisitos. Por tanto el ámbito debe de ser dúctil, podremos jugar con el, si el tiempo para el lanzamiento es limitado, siempre habrá cosas que pudramos diferir para siguientes versiones.  Además con el agravante de que estas cuatro variables

4.4 Escenario de uso de las XP

Escenario de Exploración

Planificación de la entrega  

Comenzar Iteración   

Escenario de Programación 

Prueba de Aceptación 

4.5 Desarrollo de practicas 

La Planificación del juego - (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 historias del usuario, Los actores son los desarrolladores y el cliente y las actividades 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.

Diseño Simple (Simple Designs)

El sistema se diseña con la máxima simplicidad posible. 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. 

En esta imagen se representan todas las prácticas básicas de XP, cabe notar que las líneas

no representan un orden, sino que representan como una se refuerza con la otra.