Extreme programming

De WikiCE

Extreme programming
Autores Álvaro Galván Lucas
Jose Manuel Torres Púa

Contenido

Un poco de historia

La Extreme programming (XP) como proceso de creación de software diferente al convencional nació de la mano de Kent Beck , autor de una gran cantidad de libros relacionados con el tema y quien estuvo trabajando con el lenguaje orientado a objetos Smalltalk.

En el año 1.996, Kent Beck entró a trabajar en la compañía Chrysler Coporation, la cual le encomendó trabajar en el desarrollo de una aplicación de nóminas, a raíz de la cual, nació la Extreme programming como tal.

Junto con Ward Cunningham y Ron Jeffries, Kent Beck perfeccionó esta metodología, y la promocionaron en la web Portland Pattern Repository, y posteriormente en muchas otras páginas que trataban sobre temas de programación.

Posteriormente, surgió el fenómeno de XP Free Zone (zona libre de XP) en determinas páginas webs, como petición de no hablar de Extreme programming en ellas.

Esta metodología es denominada Extreme Programming por el énfasis de ésta en tener unas buenas prácticas y seguirlas constantemente, pero de una forma extrema, es decir, defiende el seguir sus principios sin alejarse lo más mínimo de ellos, y cualquier otra práctica será considerada como no perteneciente a esta metodología.

Problemas de los proyectos software

Antes de comenzar a abordar de lleno la Extreme programming, haremos un breve resumen de los principales problemas que causan el fracaso de muchos proyectos software, y veremos que soluciones aporta XP ante los mismos, de manera que el usuario que pretenda usar este método ágil pueda saber que tipo de problemas principales puede resolver.

  • Retrasos y desviaciones.

Solución de XP: Versiones cortas.

  • Cancelación de un proyecto software.

Solución de XP: Entregas periódicas.

  • Sistemas deteriorados y defectos.

Solución de XP: Pruebas continuas.

  • Requisitos mal comprendidos.

Solución de XP: Cliente dentro del equipo.

  • Cambios de negocio.

Solución de XP: Versiones cortas.

  • Falsa riqueza de características.

Solución de XP: Realizar tareas prioritarias.

  • Cambios de personal.

Solución de XP: Anima el contacto y la integración.


Gráfico comparativo.

Definición

La Extremme programming consiste en una metodología de desarrollo ágil fundamentada en una serie de buenas prácticas y valores que tienen como objetivo el aumentar la productividad a la hora de desarrollar programas.

Persigue la búsqueda de un método que haga que el desarrollo sea mucho más sencillo, aplicando el sentido común.

Gracias a todas las características que posee, la XP se ha convertido en una metodología única y compacta, y se ha transformado en una nueva forma de ver el desarrollo software.

En todo momento, le da prioridad a los trabajos que disminuyen la burocracia que hay alrededor de la programación y a los trabajos que dan un resultado directo.

Principios y fundamentos básicos

Principios básicos de la Extreme Programming (XP).

La Extreme programming se fundamenta en 12 principios básicos agrupados en cuatro categorías:

Retroalimentación a escala fina

El principio de pruebas

Consiste en un período de tiempo de pruebas de aceptación del programa (período de caja negra) en el que se establecerán las entradas y las salidas (resultados esperados) de estas entradas. Estas pruebas tienen que estar automatizadas de manera que permitan realizar múltiples simulaciones del sistema una vez que esté funcionando.

Para realizar estas simulaciones se utilizan los llamados Ambientes de Prueba (Unit testing frameworks). En la página web de xprogramming podemos encontrar Ambientes de Prueba para todo tipo de lenguajes (C, C++, Java, etc.). Un ejemplo de este tipo ambientes para java es JUnit.

Proceso de planificación

El usuario deberá escribir todas sus necesidades, especificando las actividades concretas que realizará sistema. Se elaborará un documento llamado Historias del usuario (User Stories). Cada una de las Historias del usuario necesiará entre una y tres semanas de desarrollo. Se creará el llamado Plan de Liberación a partir de las Historias del usuario, el cual definirá los tiempos de entrega de la aplicación.

Durante esta fase serán necesario ir realizando reuniones periódicas con todo el equipo de desarrollo si se estima conveniente.

El cliente en el sitio

Al cliente se le dará el permiso para establecer la funcionalidad, determinar los requisitos, matizar las prioridades y responder a las preguntas de los programadores. De esta manera se conseguirá una fuerte interacción cara a cara con el programador, reduciendo drásticamente el tiempo de comunicación y la cantidad de documentación, así como los altos costes de su elaboración.

Habrá en todo momento un representante del cliente que estará con el equipo de desarrollo durante toda la realización del proyecto.

Programación en parejas

Este principio es llamado pair-programming, y consiste en que todos los programadores deberán escribir su código en parejas, compartiendo una única máquina. Como consecuencia de esto, se produciarán aplicaciones más buenas, consistentes y a bajo coste.

Este constituye uno de los principios más polémicos y radicales de XP, y mucha gente duda de su efectividad.

Proceso continuo en lugar de por lotes

Integración continua

Consiste en que, en lugar de crear versiones (builds) estables de acuerdo a un cronograma establecido, los equipos de programadores pueden resumir su código y reconstruir el sistema varias veces al día.

Como consecuencia de este principio, se reducen los problemas de integración comunes en proyectos largos y estilo cascada.

Refactorización

Con este principio, los programadores evalúan continuamente el diseño y recodifican lo necesario, obteniéndose un sistema que minimice el código duplicado e ineficiente.

Como consecuencia, a través de todo el proceso de desarrollo, los programadores mejoran el diseño del sistema.

Entregas pequeñas

Consiste en establecer un sistema simple y sencillo de entregas que se actualice constantemente, de manera que estas entregas no puedan pasar las dos o tres semanas como máximo.

Como consecuencia, se permite que el verdadero valor del negocio del producto sea evaluado en un ambiente real.

Entendimiento compartido

Diseño simple

Consiste en desarrollar programas lo más sencillos posibles, que cumplan en todo momento con los requisitos, de manera que se proporcione un sistema que satisfaga las necesidades inmediatas del cliente.

Como consecuencia de este principio, se rejuvenecen los diseños obsoletos de forma sencilla y se eliminan redundancias.

Metáfora

La metáfora es desarrollada por los programadores al comienzo del proyecto, y define una historia de como funciona el sistema completo.

Gracias a este principio, se logra sustituir los sistemas tradicionales de diagramas y modelos UML por breves descripciones de un trabajo de un sistema.

Propiedad colectiva del código

Este principio defiende el tener un código con propiedad compartida, de manera que nadie es el propietario de nada, y todos son el propietario de todo.

Como consecuencia de este principio, cuanta más gente haya trabajando en una pieza, menos errores aparecerán.

Estándar de codificación

Este principio consiste en definir una serie de reglas para escribir y documentar el código, así como la comunicación entre diferentes piezas de código desarrolladas por equipos diferentes.

Como consecuencia de este principio, el código en el sistema se verá como si hubiera sido escrito por una sola persona.

Bienestar del programador

La semana de 40 horas

Consiste en minimizar las horas extras de los programadores, de manera que se mantengan frescos, pues los programadores cansados escriben código de menor calidad.

Como consecuencia de este principio se genera un código de mayor calidad.

Los 4 valores

En esta sección se verán los valores principales de la programación extrema. Entenderemos por valor el enfoque (a nivel descriptivo) de como se desarrolla el software.


Valores que inspira XP.


Comunicación

La comunicación es un elemento muy importante en este tipo de metodología ágil. Los desarrolladores y los clientes deben cooperar para que se desarrole el proyecto de forma adecuada.

En caso de que el cliente deseara ver el programa en funcionamiento para especificar nuevos requisitos, entonces lo que debe hacer es reunirse con el equipo de desarrolladores. Los períodos habituales de reuniones se sitúan en un intervalo de 2 a 4 semanas.

Los programadores trabajarán por parejas, es decir, cada equipo estará conformado por dos personas. Los programadores suelen rotar, de forma que el el código pertenezca a todo un grupo y no a la pareja inicial.

En el momento que surgan problemas, todo el conjunto de personas implicadas podrán aportar posibles soluciones, ya que en algún momento han tenido que programar dicha sección o ayudar a la implementación de la misma.

El trabajo por parejas también reduce el riesgo de malas técnicas de codificación.

Las personas que tengan más experiencia pueden guiar a las más inexpertas. Al ser dos personas, los errores pueden ser detectados con mayor facilidad.

Simplicidad

Para este modelo, la simplicidad es fundamental. Los requerimientos que se tienen en cuenta son los relacionados con necesidades inmediatas, quedando, por tanto, descartados aquellos que tengan que ver con el futuro. Cuando se tienen en cuenta hechos futuros, la incertidumbre de los mismos pueden desembocar en pérdidas monetarias (no se da un hecho que se creía que se cumpliría).

Pese a que la mentalidad del programador puede caer en detalles de implementación, es necesario que se adapte a las necesidades exclusivas del cliente. El cliente es el que tiene la máxima prioridad, el proyecto será suyo y pagará por ello.

Refactorización

El código debería refactorizarse habitualmente. Ganaremos facilidad de uso, flexibilidad, manejabilidad, mejoras en el mantenimiento, etc. Además, disminuirá el acoplamiento y se detectarán zonas de código que puedan influir negativamente en el rendimiento. El código será más legible y se podrá aumentar la productividad.

Feedback

Los desarrolladores reciben a menudo correcciones o modificaciones por parte de los clientes. Los clientes, además, deben comprobar que el software es adecuado de acuerdo con sus necesidades establecidas de antemano. Todo esto conllevará constantes revisiones del código de los programas. Las parejas de programadores y el equipo debe mostrar resultados al cliente y el cliente indicar si el proceso es el correcto.

Se realizan bloques de test para la práctica totalidad de los módulos de los programas, lo que garantiza su funcionamiento y posteriormente se integran unos programas con otros que se implementan.

Por otra parte, los errores deben de ser detectados con la máxima antelación posible.

Coraje

Los desarroladores desean que su software tenga características como:

  • Que esté actualizado
  • Que añada una nueva funcionalidad
  • Soporten nuevas características

Sin embargo, los usuarios finales no quieren que el software cambie constantemente añadiendo mejoras. Desean que el producto sea final y que no sufra tantas modificaciones que afecten a su uso habitual.

Para muchos clientes estas mejoras no son tan sustanciales como para los desarrolladores y debemos que tener en cuenta que son los clientes los destinatarios finales del producto, así que debemos adaptarnos a sus preferencias.

Proceso de desarrollo

En la metodología ágil de la programación extrema (XP) el software es desarrollado siguiendo los criterios personales del cliente. Se pueden distinguir diversos roles:

  • Equipos:
    • Equipo de gestión
    • Equipo de desarrollo
  • Clientes

Este modelo no guarda relación con los tradicionales. En ellos, se capturaban los requisitos previamente, para luego desarrollar el software y validarlo finalmente. Ahora esas fases estarán más difusas y habrá una mayor interacción entre los roles implicados.

Interacción con el cliente

El cliente ahora se encuentra más cercano y no permanece ajeno al proceso de desarrollo. Como se elimina la primera fase de recopilación de requisitos, se permite que estos se vayan recogiendo progresivamente a lo largo del proceso de desarrollo del software, siempre por supuesto, de manera ordenada. Así, el cliente tiene la posibilidad de ir cambiando de opinión sobre la marcha. Sin embargo, el cliente debe estar siempre dispuesto a cooperar y resolver dudas del equipo de desarrollo. Esto es algo que no todos los clientes pueden consentir.

Historia de usuario

La historia de usuario consta de una lista de características necesarias para el cliente y que deben estar presentes en el producto final. Se distinguen dos fases:

  1. Primera fase: El cliente describe las características según una jerarquización (que determinará la prioridad de las mismas). El responsable del equipo será el encargado de informar sobre los aspectos relacionados con las dificultades técnicas y el coste asociado a cada una de las características mencionadas por el cliente.
  2. Segunda Fase: Nuevamente el cliente seleccionará las historias anteriores, pero esta vez las dividirá en trabajos a realizar. El cliente también participará, aunque haya más peso por parte del equipo de desarrollo. La planificación será, por tanto, más exacta. Este método deberá aplicarse a cada una de las historias.

Planificación del proyecto

La planificación estará constituida por etapas, donde se aplicarán las diferentes iteraciones. Para realizar correctamente la planificación se necesitarán reglas que se han de seguir por todas las partes implicadas (clientes, desarrolladores, equipos de gestión). Todos tendrán que participar en la planificación del proyecto y la decisión será conjunta.

El periodo de las entregas debe ser mínimo. En cada iteración, el cliente recibirá una nueva versión del software. Es aconsejable realizar muchas entregas y con frecuencia. De esta forma, los errores en la parte inicial del sistema tiene más posibilidades de detectarse.

En el proceso de planificación habrá errores, así que el sistema deberá de ser previsor con ellos. En cada serie de iteraciones, se procederá con una revisión tanto de las historias de los clientes como de renegociaciones de la planificación acordada.

En la programación tradicinal no aparecía la planificación iterativa (así como el diseño), así que se discutirá diariamente las características del sistema, para fomentar la comunicación y ver el progreso del proyecto y satisfacer las necesidades de los clientes.

Diseño, desarrollo y pruebas

La sección más importante en la programación extrema es el desarrollo. Se tendrá como objetivo la programación rápida (siempre en la dirección correcta) y a ser posible sin interrupciones.

El diseño también es fundamental. A medida que se añaden funcionalidades, hay que revisar el software y mejorarlo de forma continua mientras dure el mismo.

Otro de los elementos clave del proceso de desarrollo en XP es la comunicación. La mayor parte de los problemas en los proyectos son debidos a la falta de comunicación que se da en el equipo.

A la hora de hacer las pruebas, deben realizarse en pequeñas secciones de código y con pruebas sencillas. Una vez que la prueba se ha pasado, se amplia el código y se realizan nuevas pruebas. Todo el código que sea susceptible de fallar, debería ser comprobado.

En la programación extrema la integración es continua. Cada vez se tienen que ir integrando pequeñas zonas de código, para evitar que al finalizar el proyecto se tenga que emplear un gran esfuerzo en la integración final.

Esta metodología fomenta la programación en parejas, permitiendo que los programadores no trabajen solos, sino que siempre estén con otra persona. Una pareja de programadores compartirá el monitor, teclado y ratón. Las parejas de programadores tendrán que ir cambiando de manera periódica, para permitir que el conocimiento sea difundido por todo el grupo. Se ha demostrado que de esta forma la productividad es mayor, consiguiéndose más y mejor código.


Diagramas de iteración
Diagrama de iteraciones en el desarrollo.
Diagrama de iteraciones en la comunicación.
Diagrama de iteraciones en los planes.
Diagrama de iteraciones en la temporación.

Ventajas y desventajas

Ventajas

  • Da lugar a una programación sumamente organizada.
  • Ocasiona eficiencias en el proceso de planificación y pruebas.
  • Cuenta con una tasa de errores muy pequeña.
  • Propicia la satisfacción del programador.
  • Fomenta la comunicación entre los clientes y los desarrolladores.
  • Facilita los cambios.
  • Permite ahorar mucho tiempo y dinero.
  • Puede ser aplicada a cualquier lenguaje de programación.
  • El cliente tiene el control sobre las prioridades.
  • Se hacen pruebas continuas durante el proyecto.
  • La XP es mejor utilizada en la implementación de nuevas tecnologías.

Desventajas

  • Es recomendable emplearla solo en proyectos a corto plazo.
  • En caso de fallar, las comisiones son muy altas.
  • Requiere de un rígido ajuste a los principios de XP.
  • Puede no siempre ser más fácil que el desarrollo tradicional.

Ejemplo de aplicación

Como ejemplo se puede aplicar esta metodología en la industria financiera. El desarrollo rápido de software lo suficientemente flexible como para adaptarse a los continuos cambios de la industria sería vital. En el entorno de trabajo sería común el estrés (la presión complicaría aún más la tarea ya de por si complicada de obtener software de calidad). En este campo se prefiere habitualmente el software rápido, aunque contenga errores.

En este caso se trato de desarrollar rápidamente un software que fuese robusto y útil. La programación extrema tendría el conseguir una aplicación buena, de desarrollo rápido y útil. Estos son las características propias que puede abordar la programación extrema (XP).

Repo Margining System

Este es un ejemplo de un proyecto de estas características.

La aplicación permitiría el comercio electrónico a través del navegador y mantener informadas a las dos partes del trato. Además capturaría las ofertas que se hiciesen y las mostraría en un lugar dedicado para ello.

  • El equipo estaría formado por 7 integrantes.
  • El espacio laboral estaría habilitado para favorecer la comunicación entre los componentes.
  • Se empezaría desarrollando (utilizando el lenguaje de programación JAVA) las clases, para poder realizar las pruebas y posteriormente permitir el refactoring.
  • Todo el trabajo no se tendría que empezar desde cero, puesto que el equipo contaba con código de otros trabajos previos y que podrían reutilizar.

Referencias

Autores

  • Álvaro Galván Lucas
  • José Manuel Torres Púa
Herramientas personales