Documentos exposicion

Extreme Programming

El Extreme Programming (XP) es un método para desarrollar software basado en cinco valores: simplicidad, comunicación, retroalimentación, coraje y respeto. Funciona al unir todo el equipo de trabajo en la presencia de simples prácticas.

La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Simplicidad

La simplicidad es el corazón de XP. Aplicando el principio de simplicidad afecta todo lo que haces, y profundamente impacta en tu habilidad de implementar satisfactoriamente XP. Al enfocarse en diseños simples minimizas el riesgo de utilizar mucho tiempo diseñando ambientes de trabajos sofisticados que el cliente quizás no requiera.

El mantener el código simple hace que los cambios sean más fáciles aun cuando los requerimientos inevitablemente cambien.  Al enfocarse en soluciones simples a los problemas de hoy minimizamos el costo de los cambios mediante pase el tiempo.

La teoría tradicional argumenta que el hacer cambios en algún software incrementa conforme el tiempo de vida del proyecto aumente. Así como es diez veces más difícil arreglar un error cuando estás en la fase de diseño, y 100 veces más difícil durante la fase de programar.

El enfoque de XP reconoce que el costo cambia generalmente como uno esperaría, pero este incremento no es inevitable. Si constantemente refactorizas y mantienes tu código simple, puedes evitar de esta manera el incremento de complejidad.

Comunicación

La comunicación viene de muchas formas. Para programadores, el código se comunica mejor cuando es simple. Es por esto que XP se enfoca en mantener el código simple. Una buena manera de describir código es utilizando comentarios, sin embargo es más

confiable auto-documentar.

Las pruebas unitarias son otra forma de comunicación. XP requiere que se escriban pruebas unitarias para la gran mayoría del código en un sistema. Las pruebas unitarias comunican el diseño  de una clase efectivamente, ya que estas pruebas demuestran ejemplos concretos de cómo utilizar la funcionalidad de la clase.

Existe una comunicación constante entre el cliente y los programadores. XP requiere un cliente en el sitio de trabajo para transmitir los requerimientos al equipo de trabajo. El cliente decide qué  características son más importantes, y siempre está disponible para responder preguntas.

Retroalimentación

XP fomenta tener ciclos de lanzamiento cortos, generalmente no mayor a dos semanas.

Con un ciclo de lanzamiento corto, el cliente es capaz de evaluar cada nueva característica a la par que esta es desarrollada, minimizando la necesidad de rehacer y haciendo que los programadores se enfoquen en que es lo más importante para el cliente. De esta forma los clientes pueden estar tranquilos de que pueden cancelar el proyecto en cualquier momento y tener un sistema que trabaje con las características que más les importaban.

Coraje

El tener coraje significa tomar las decisiones difíciles cuando sea necesario. Si una característica no funciona, arreglarla. Si parte del código no aspira a ser mejor, mejorarlo.

Los conceptos antes mencionados se pueden ver cómo simplemente sentido común, entonces, ¿Por qué se requiere tener coraje para implementar XP?

Para los gerentes, el concepto de programación en pares puede ser difícil de aceptar, ya que pareciera que la productividad se vería reducida  en 50% ya que solo la mitad de los programadores están escribiendo código en un determinado tiempo. De esta forma se requiere de coraje para confiar en que la programación en pares mejora la calidad sin reducir la velocidad del proyecto.

Enfocarse en la simplicidad es una de las facetas más difíciles de XP. Se necesita de coraje para implementar la característica que el cliente está pidiendo para hoy utilizando un enfoque simple, porque probablemente quieras construir flexibilidad para hacer frente a las características de mañana también.

El coraje es una virtud difícil de aplicar. Nadie quiere equivocarse o romper una promesa. Aunque, la única manera de recuperarse de un error es admitirlo y arreglarlo. Desarrollar software es desafiante, pero enfrentarse a ese desafío en lugar de evitarlo nos lleva a un mejor software.

Respeto

El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

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. Se aconseja escribir el código de la prueba antes de la codificación.
• Programación por 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 interacción del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
• 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 en 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. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Programación en Parejas

Cómo se ha mencionado antes, los equipos de trabajo de XP trabajan en parejas. Este par de programadores comporten una misma computadora, teclado y mouse (es buena idea tener dos monitores para que de esta forma ambos programadores puedan ver claramente la pantalla, pero no es forzosamente necesario). Los escritorios deben de estar configurados de tal forma que dos personas puedan sentarse lado a lado cómodamente y todo el equipo de trabajo debe de trabajar en la misma sala.

La forma de trabajar en parejas es la siguiente:

1.- Escoges un requerimiento del usuario para tu siguiente trabajo

2.- Pides ayuda de otro programador

3.- Ambos trabajan en una pequeña parte de funcionalidad

    * Se intenta trabajar en tareas pequeñas que tomen un par de horas

    * Después de finalizar la tarea, escoges un compañero  diferente.

Al emparejar programadores, los principiantes pueden ganar una valiosa experiencia de los expertos.

La programación en pareja es crucial porque XP requiere de un nivel muy alto de disciplina para poder ser satisfactorio. El programador que tiene el control del teclado, tiene un nivel de detalle muy fino sobre el código, y el que no, mientras tiene tiempo de pensar en el problema a un nivel más alto de abstracción. El observador debe siempre buscar maneras de simplificar el código, y pensar sobre adicionales pruebas unitarias.

Inspecciones de Código

Las inspecciones de código son una gran técnica para validar la calidad del código. En proyectos típicos, los programadores trabajan por su cuenta por varias semanas, y después presentan su código a un grupo de compañeros para una reunión de inspección formal.

Las inspecciones de códigos son una herramienta valiosa, los equipos de XP no se basan en inspecciones formales de códigos, primeramente porque todo el código es constantemente revisado ya que es desarrollado por pares de programadores. Ya que los programadores cambian de compañeros y trabajan en diferentes partes del sistema, el código es constantemente mejorado y refactorizado por personas adicionales al autor original.

Pruebas Unitarias

Las pruebas unitarias son pruebas escritas por los programadores para probar la funcionalidad de una pequeña parte de alguna aplicación.

La XP no puede ser realizada sin utilizar las pruebas unitarias. Las pruebas unitarias ayudan a construir confianza de que el código funciona correctamente. De igual forma las pruebas unitarias también proveen de seguridad, permitiendo que un par de programadores hagan cambios en una parte del código sin miedo, ya que esto permite verificar que el código funciona previo a alguna modificación, y si después de la modificación con sus pruebas unitarias también funcionan quiere decir que se ha cambiado el código y se ha mantenido el funcionamiento correcto de todo lo que ya se había realizado antes.

Ciclo de Vida de XP

El ciclo de vida de XP se enfatiza en el carácter interactivo 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.

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

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. 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 está 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: 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.

Roles

Programador

·         Pieza básica en desarrollos XP

·         Más responsabilidad que en otros modos de desarrollo

·         Responsable sobre el código

·         Responsable sobre el diseño (refactorización, simplicidad)

·         Responsable sobre la integridad del sistema (pruebas)

·         Capacidad de comunicación

·         Acepta críticas (código colectivo)

Cliente

·         Pieza básica en desarrollos XP

·         Define especificaciones

·         Influye sin controlar

·         Confía en el grupo de desarrollo

·         Define pruebas funcionales

Encargado de Pruebas

·         Apoya al cliente en la preparación/realización de las pruebas funcionales

·         Ejecuta las pruebas funcionales y publica los resultados

   

Encargado de Seguimiento (Tracker)

·         Recoge, analiza y publica información sobre la marcha del proyecto sin afectar    demasiado el proceso

·         Supervisa el cumplimiento de las estimaciones en cada iteración

·         Informa sobre la marcha de la iteración en curso

·         Controla la marcha de las pruebas funcionales, de los errores reportados, de las  responsabilidades aceptadas y de las pruebas añadidas por los errores                         encontrados

·          

 

Entrenador (Coach)

·         Experto en XP

·         Responsable del proceso en su conjunto

·         Identifica las desviaciones y reclama atención sobre las mismas

·         Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza)

·         Interviene directamente si es necesario

·         Atajar rápidamente el problema

 Consultor

·         Apoya al equipo XP en cuestiones puntuales

Jefe del Proyecto

·         Favorece la relación entre usuarios y desarrolladores

·         Confía en el equipo XP

·         Cubre las necesidades del equipo XP

·         Asegura que alcanza sus objetivos

Ventajas

·         Estar preparados para el cambio, significa reducir su coste.

·         Planificación más transparente para nuestros clientes, conocen las fechas de entrega   de funcionalidades.

·         Permitirá definir en cada iteración cuales son los objetivos de la siguiente

·         Permite tener realimentación de los usuarios muy útil.

·         La presión esta a lo largo de todo el proyecto y no en una entrega final

·          

Desventajas

·         Es recomendable emplearlo solo en proyectos a corto plazo.

·         Altas comisiones en caso de fallar

·         Requiere de un buen trabajo en equipo

·         No funciona si los programadores están separados geográficamente

·         No se ha probado que XP funcione para sistemas con problemas de escalabilidad.

Conclusión

No existe algo conocido como  “la mejor metodología”. Se deben de tener en cuenta  los recursos con los que se cuentan, y el enfoque del proyecto ya que, en el caso de XP valora el trabajo en equipo más que nada, y funciona bien cuando los requerimientos no son del todo claro o son cambiantes. De la misma manera, si cierto proceso de desarrollo con el cual se ha estado trabajando antes funciona bien, es sabio seguir trabajando con el mismo, sin embargo, se pueden utilizar algunas ideas de la XP dentro de otras metodologías.

Bibliografía

Victor Villafuerte R. Extreme Programming (2009). Consultado Febrero, 17, 2014 en www.extremeprogramming.host56.com .

O’Reilly & Associates, Inc. Extreme Programming Pocket Guide (2003)

Eric M. Burke & Brian M. Coyner. Java Extreme Programming Cookbook (2003)

Don Wells. Extreme Programming (2008). Consultado Febrero, 17. 2014 en:

http://www.extremeprogramming.org/