Programación Extrema (XP)

Programación Extrema (XP) Sitio web http://www.pri.jovenclub.cu/jc/sc

Programación Extrema Es un enfoque de la ingeniería de software formulado por Kent Beck. Es una de las llamadas Metodologías ágiles de desarrollo de software más exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de software.

Introducción

Actualmente la mayoría de los programadores no pensamos en una metodología de desarrollo a la hora de crear algún software, o sea tenemos cierta tendencia en embebernos en cuestiones técnicas, hablar de lenguajes de programación, de técnicas de programación, de entornos de desarrollo o de editores de recursos.

Pero se nos pasan por alto temas muy importantes como es la ingeniería de software, la manera en que debemos de hacer nuestro software. Alrededor de cómo hacer software hay un gran número de teorías, propuestas, etc.
El primer paso es conocer las metodologías más relevantes o buscar a alguien que las conozca, y en una situación ideal haber trabajado con varias de ellas.

No hay metodología que funcione de manera universal, de hecho cada vez más las metodologías se conciben como 'Marcos' metodológicos que son necesario ajustar para cada organización y tipo de Proyecto|proyecto. Realizar este ajuste es algo que requiere de una experiencia y un conocimiento previo. El problema con la implantación de una metodología es que no se suele tener una segunda oportunidad.

A la hora de seleccionar una metodología la primera decisión que se plantea es: ¿Una metodología ágil o una metodología guiada por plan? Puesto que la gran mayoría de proyectos se pueden beneficiar mucho del uso de una metodología ágil, pero indudablemente existen proyectos y entornos en los que es condición, generalmente impuesta por el cliente o la dirección de la empresa, que el proyecto se desarrolle con 'más control'.

Para plantearte el uso de una metodología ágil tenemos que ser capaces de asumir completamente el Manifiesto Ágil y ser capaces de hacer que sea el paradigma que guíe la gestión de nuestro proyecto, y desde luego es sumamente importante que logremos un sponsor.

Tener un sponsor es vital en todo proyecto de implantación de una metodología, pero sobretodo es vital para implantar una metodología ágil, pues exige que se produzcan profundos cambios en la cultura tradicional relativa a la gestión de proyectos.
Poniendo de menos a más ágil, de más 'revolucionaria' a menos, entre las metodologías más populares, tenemos las siguientes:
• eXtreme Programming
• CMMI con una implanción tradicional
• Rational Unified Process
• MSF for CMMI Process Improvement
• MSF Agile
• Scrum

Definiciones Relacionadas con la Programación

Programación: La programación es un proceso por el cual se escribe (en un lenguaje de programación), se prueba, se depura y se mantiene el código fuente de un programa. Los programas son los elementos que forman el software, que es el conjunto de las instrucciones que ejecuta el hardware de una computadora para realizar una tarea determinada. Por lo tanto, la programación es una de las principales áreas dentro de la informática.

Metodología: La Metodología, (del griego metà "más allá", odòs "camino" y logos "estudio"), hace referencia al conjunto de procedimientos basados en principios lógicos, utilizados para alcanzar una gama de objetivos que rigen en una investigación científica o en una exposición doctrinal. El término puede ser aplicado a las artes cuando es necesario efectuar una observación o análisis más riguroso o explicar una forma de interpretar la obra de arte.
El término método se utiliza para el procedimiento que se emplea para alcanzar los objetivos de un proyecto y la metodología es el estudio del método.

Ingeniería de Software: Es la disciplina o área de la informática

que ofrece métodos y técnicas para desarrollar y mantener software de calidad. <Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet,Intranet, etc.

Programación Extrema

La programación extrema o EXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software.

Al igual que éstos, 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.

Resumiendo: Se puede definir 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.

¿Qué es la programación extrema XP?

La Programación Extrema (PX), mejor conocida por su nombre en inglés Extreme Programming (XP), es una de las llamadas Metodologias Agiles de desarrollo de software más exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de software hace aproximadamente unos seis años, y ha causado un gran revuelo entre el colectivo de programadores del mundo. Kent Beck, su autor, es un programador que ha trabajado en múltiples empresas y que actualmente lo hace como programador en la conocida empresa automovilística DaimlerChrysler.

Con sus teorías ha conseguido el respaldo de gran parte de la industria del software y el rechazo de otra parte.
La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar una pura lógica.

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é auto-documentado.

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 auto-documentado 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íaLos 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.

• RespetoEl 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, si no orientándolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

Las Cuatro Actividades Básicas

Ahora que tenemos nuestros cuatro valores estamos preparados para construir una
Disciplina de desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen software?

Codificar

Es la única actividad de la que no podremos prescindir. Sin código fuente no hay
Programa|programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en XP en pareja el código expresa tu interpretación del problema, así podemos utilizar el código para comunicar, para hacer mías tus 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 me dan la oportunidad de saber si lo que implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo.

No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro código, con el tiempo llegaras a conclusiones sobre las pruebas y podrás pensar que si dos de tus pruebas ya funcionan la tercera prueba no será necesaria escribirla, sin caer en demasiada confianza. Programar y probar es más rápido que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perderás mucho tiempo en la depuración.

Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro.

Escuchar

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 que 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 cuales 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, divídela en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

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.

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.

Programacion extrema Pipeline

Variacion de la programacion extrema clasica que consigue quadriplicar la eficacia de la misma

Principios Pipeline

La programación extrema en pipeline se basa en la arquitectura Harvard de los procesadores, de tal manera que con un número n de escritorios remotos donde n es igual al número de participantes en la programación del proyecto se puede aumentar la eficiencia del trabajo hasta 4 veces, entiéndase que cada x tiempo un programador deja de programar una clase o parte del programa para programar otra diferente en el escritorio remoto de otro de los componentes del equipo así podríamos definir el término eficiencia como e=x+(n*nc-1) donde x es el tiempo de cada ciclo, n el número de escritorios remotos o participantes, nc es el numero de iteraciones del proyecto.

Fuentes

• [ http://www.marblestation.com/?p=644
  • http://geeks.ms/blogs/rcorral/archive/2007/01/15/iquest-que-metodolog-iacute-a-de-desarrollo-elegir.aspx]

• Una explicación de programación extrema (XP) de Manuel Calero Solís.

• [1]

Enlaces externos

• Sitio dedicado a la divulgación de la programación extrema (en inglés)

• Foro Yahoo Group creado para discutir XP en Espanol (200 miembros)

• Resumen de programación extrema