Programacin extrema

La programacin extrema o eXtreme Programming (de ahora en adelante, XP)

es una metodologa de desarrollo de la ingeniera de software formulada por
Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el ms destacado de los procesos giles
de desarrollo de software. Al igual que stos, la programacin extrema se
diferencia de las metodologas tradicionales principalmente en que pone ms
nfasis en la adaptabilidad que en la previsibilidad. Los defensores de la 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 aproximacin mejor y ms realista que intentar definir todos
los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar
los cambios en los requisitos.

Se puede considerar la programacin extrema como la adopcin de las

mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a
cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida
del software.

Valores

Los valores originales de la programacin extrema son: simplicidad,

comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto,
fue aadido en la segunda edicin de Extreme Programming Explained. Los
cinco valores se detallan a continuacin:

Simplicidad

La simplicidad es la base de la programacin extrema. Se simplifica el diseo

para agilizar el desarrollo y facilitar el mantenimiento. Unos diseos complejos
del cdigo junto a sucesivas modificaciones por parte de diferentes
desarrolladores hacen que la complejidad aumente exponencialmente.

Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es

la manera de mantener el cdigo simple a medida que crece.

Tambin se aplica la simplicidad en la documentacin, de esta manera el

cdigo debe comentarse en su justa medida, intentando eso s que el cdigo
est autodocumentado. Para ello se deben elegir adecuadamente los nombres
de las variables, mtodos y clases. Los nombres largos no decrementan la
eficiencia del cdigo ni el tiempo de desarrollo gracias a las herramientas de
autocompletado y refactorizacin que existen actualmente.

Aplicando la simplicidad junto con la autora colectiva del cdigo y la

programacin por parejas se asegura que cuanto ms grande se haga el
proyecto, todo el equipo conocer ms y mejor el sistema completo.
Comunicacin

La comunicacin se realiza de diferentes formas. Para los programadores el

cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay
que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms
fiable que los comentarios ya que stos ltimos pronto quedan desfasados con
el cdigo a medida que es modificado. Debe comentarse slo aquello que no
va a variar, por ejemplo, el objetivo de una clase o la funcionalidad de un
mtodo.

Las pruebas unitarias son otra forma de comunicacin ya que describen el

diseo de las clases y los mtodos al mostrar ejemplos concretos de cmo utilizar
su funcionalidad. Los programadores se comunican constantemente gracias a
la programacin por parejas. La comunicacin con el cliente es fluida ya que
el cliente forma parte del equipo de desarrollo. El cliente decide qu
caractersticas tienen prioridad y siempre debe estar disponible para solucionar
dudas.

Retroalimentacin (feedback)

Al estar el cliente integrado en el proyecto, su opinin 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 ms importante.

Considrense 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 cdigo tambin es una
fuente de retroalimentacin gracias a las herramientas de desarrollo. Por
ejemplo, las pruebas unitarias informan sobre el estado de salud del cdigo.
Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a
cambios recientes en el cdigo.

Coraje o valenta

Muchas de las prcticas implican valenta. Una de ellas es siempre disear y

programar para hoy y no para maana. Esto es un esfuerzo para evitar
empantanarse en el diseo y requerir demasiado tiempo y trabajo para
implementar el resto del proyecto. La valenta le permite a los desarrolladores
que se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto
significa revisar el sistema existente y modificarlo si con ello los cambios futuros
se implementaran ms fcilmente. Otro ejemplo de valenta es saber cuando
desechar un cdigo: valenta para quitar cdigo fuente obsoleto, sin importar
cuanto esfuerzo y tiempo se invirti en crear ese cdigo. Adems, valenta
significa persistencia: un programador puede permanecer sin avanzar en un
problema complejo por un da entero, y luego lo resolver rpidamente al da
siguiente, slo si es persistente.
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
compaeros. Los miembros respetan su trabajo porque siempre estn luchando
por la alta calidad en el producto y buscando el diseo ptimo o ms eficiente
para la solucin a travs de la refactorizacin del cdigo. Los miembros del
equipo respetan el trabajo del resto no haciendo menos a otros, una mejor
autoestima en el equipo eleva su ritmo de produccin.

Caractersticas fundamentales

Las caractersticas fundamentales del mtodo son:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba
antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit
orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o
PHPUnit para PHP. Estas tres ltimas inspiradas en JUnit, la cual, a su vez, se insipir
en SUnit, el primer framework orientado a realizar tests, realizado para el
lenguaje de programacin Smalltalk.

Programacin en parejas: se recomienda que las tareas de desarrollo se lleven

a cabo por dos personas en un mismo puesto. La mayor calidad del cdigo
escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es
ms importante que la posible prdida de productividad inmediata.

Frecuente integracin del equipo de programacin con el cliente o usuario. Se

recomienda que un representante del cliente trabaje junto al equipo de
desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer

entregas frecuentes.

Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para
aumentar su legibilidad y mantenibilidad, pero sin modificar su comportamiento.
Las pruebas han de garantizar que en la refactorizacin no se ha introducido
ningn fallo.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el

desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo
promueve el que todo el personal pueda corregir y extender cualquier parte del
proyecto. Las frecuentes pruebas de regresin garantizan que los posibles
errores sern detectados.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen.

Cuando todo funcione se podr aadir funcionalidad si es necesario. La
programacin extrema apuesta que es ms sencillo hacer algo simple y tener
un poco de trabajo extra para cambiarlo si se requiere, que realizar algo
complicado y quizs nunca utilizarlo.

La simplicidad y la comunicacin son extraordinariamente complementarias.

Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se
debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar
sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se
puede reducir el equipo de programadores.

Roles

Programador

Escribe las pruebas unitarias y produce el cdigo del sistema. Es la esencia del
equipo.

Cliente

Escribe las historias de usuario y las pruebas funcionales para validar su

implementacin. Asigna la prioridad a las historias de usuario y decide cules se
implementan en cada iteracin centrndose en aportar el mayor valor de
negocio.

Tester

Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas

regularmente, difunde los resultados en el equipo y es responsable de las
herramientas de soporte para pruebas.

Tracker

Es el encargado de seguimiento. Proporciona realimentacin al equipo. Debe

verificar el grado de acierto entre las estimaciones realizadas y el tiempo real
dedicado, comunicando los resultados para mejorar futuras estimaciones.

Entrenador (coach)

Responsable del proceso global. Gua a los miembros del equipo para seguir el
proceso correctamente.

Consultor

Es un miembro externo del equipo con un conocimiento especfico en algn

tema necesario para el proyecto. Ayuda al equipo a resolver un problema
especfico. Adems, este tiene que investigar segn los requerimientos.

Gestor (Big boss)

Es el dueo de la tienda y el vnculo entre clientes y programadores. Su labor

esencial es la coordinacin.