Programación extrema


La programación extrema o eXtreme Programming (XP)
es un enfoque de la ingeniería de software formulado por Kent Beck. Es el más destacado de los procesos ágiles de desarrollo de software.La programación extrema o XP es un conjunto de valores, principios y practicas para desarrollar aplicaciones de alta calidad rápidamente que ofrece la máxima calidad para el consumidor tan rápido como sea posible.La programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

XP no es una metodología de desarrollo de software propiamente dicha, pues no tiene una gran cantidad de papeleo o normas que los desarrolladores deben seguir, pero si lo es en el sentido de que es un proceso repetible para desarrollar software.

metodologia_xp3.JPG

Valores




Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:

  • Simplicidad:

La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
  • Comunicación:
La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características tienen prioridad y siempre debe estar disponible para solucionar dudas.
  • Retroalimentación (feedback):
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
  • Coraje o valentía:
Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad. La simplicidad es uno de los principios más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (frameworks) mientra el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentación para saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código en sucesivas aproximaciones.
  • Respeto:
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan 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, si no orientandolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de produccion en el equipo.

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. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas dos últimas inspiradas en JUnit.
  • 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. 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 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.


Programación extrema (Pipeline)
Variación de la programación extrema clásica que consigue cuadriplicar la eficacia de la misma.

Principios (Pipeline)

Las 12 practicas que forman parte de la programación extrema son:


The Planning Game (Juego de planificación): Los desarrolladores y el negocio cooperan para producir rápidamente un buen valor de negocio . El juego de planificación aparece a varias escalas, pero las reglas son las mismas.El negocio llega con una lista de características deseadas para el sistema, cada característica es escrita como una Historia de Usuario, que da a la característica un nombre y describe lo que requiere.Los desarrolladores estima cuanto esfuerzo hace falta para cada historia, y cuanto esfuerzo puede hacer el equipo en un intervalo de tiempo dado (la iteración)El negocio decide entonces que Historias implementar y en que orden tanto como cuando y con que frecuencia producir versiones del sistema.

SmallReleases (Pequeñas versiones): Empiezan con la minima funcionalidad. Sacarlas pronto y frecuentemente, añadiendo unas pocas características cada vez

SystemMetaphor(Metáfora del sistema): Cada proyecto cuenta con una metáfora organizativa, que proporciona una manera fácil de recordar las convenciones de nombres.

Simple Design (Diseño simple): Siempre usa el diseño más simple que pueda tener el trabajo hecho. Los requisitos pueden cambiar mañana, así que solo haz lo que es necesario para alcanzar los requisitos propuestos para hoy
ContinousTesting (Pruebas continuas): Antes de que los programadores añadan una característica, escriben una prueba para ella, cuando la prueba funciona, el trabajo está hecho.

Refactoring: Eliminar cualquier código duplicado generado en la sesión de codificación, puedes hacerlo sin miedo, ya que tienes los tests.
PairProgramming (Programación en parejas): Todo el código productivo es escrito por dos programadores sentados en una sola máquina, esencialmente, todo el código es revisado mientras es escrito.

CollectiveCodeOwnership: Nadie posee ningún módulo de código. Cualquier desarrollador debe poder trabajar en cualquier parte del código en cualquier momento

ContinuousIntegration(Integración continua): Todos los códigos son integrados en el código base al menos diariamente, los tests tienen que correr ambos al 100% antes y después de cada modificacion.

40-HourWorkWeek (40 horas a la semana): Los programadores se van a casa a su hora. En la hora del almuerzo, está permitido pasarse del tiempo una vez a la semana. Pero múltiples semanas de llegar tarde serán consideradas como un signo de que algo va muy mal en el equipo

On-siteCustomer: El equipo de desarrollo tiene acceso continuo a un consumidor real, que es quien realmente está usando el sistema.

Coding Standards: Todo el código sigue los mismos standards. Idealmente, tu no deberías ser capaz de saber quien del equipo ha tocado una parte específica del código.

Referencias Externas:



Sitio en Wikipedia en español
Sitio dedicado a la programación extrema (en español)
Sitio dedicado a la programación extrema (en inglés)


Integrantes del grupo
Isaac Bravo
Victor Chico
Dick Flores