Programacion Extrema

Programación extrema y software libre
Diego Berrueta (diego@berrueta.net)*
22 de enero de 2006

Resumen

Como respuesta, ha surgido una nueva familia de
metodologías denominadas ágiles, cuyo rasgo prin-

Este artículo está dividido en tres partes. La prime-

cipal consiste en contemplar y dar respuesta a las

ra hace un repaso de la programación extrema (Extre-

necesidadesdinámicas del cliente. De entre las me-

me Programming, XP). La segunda analiza los puntos

todologías ágiles, la que goza de mayor popularidad

de coincidencia y de divergencia entre la programa-

es la programación extrema, propuesta en 1999 por

ción extrema y el modelo más habitual de desarrollo

Kent Beck, en un libro titulado precisamente abra-

de software libre (bazar). La últimaparte examina

za el cambio. La programación extrema recibe este

las herramientas opensource que dan soporte a las

calicativo precisamente porque deende un enfoque

prácticas y al proceso de la programación extrema.

radical. Reconoce las bondades de las prácticas de las
metodologías tradicionales (diseño, pruebas, revisio-

1.

nes de código, etc.) y propone llevarlas hasta suextre-

Programación extrema1

mo: si diseñar es bueno, diseñemos todo el tiempo,
si las pruebas son buenas, probemos todo el tiempo,

La programación extrema es una metodología pa-

etc.

ra el desarrollo de proyectos informáticos que trata
de dar solución a los problemas de la ingeniería del

1.1. Cuatro valores

software desde un enfoque completamente distinto al
que havenido siendo habitual. Los estudios demues-

La programación extrema, lejos de ser un proceso

tran que la mayoría de proyectos de software fraca-

incontrolado, es una metodología muy disciplinada y

san, porque exceden sus plazos, superan su presu-

que se apoya en cuatro valores fundamentales:

puesto, no se ajustan a las auténticas necesidades del
cliente, presentan una calidaddeciente o, en muchos

Comunicación. Se hace énfasis en que la comuni-

casos, son abortados. Las metodologías tradicionales

cación, para ser efectiva, debe involucrar a todos

han tratado de poner coto a esta situación mediante

los participantes en el proyecto, y debe ser libre

un control intensivo del proceso. Al hacerlo, se está

y sincera.

ignorando que las necesidades delcliente y sus expectativas realmente cambian durante el desarrollo

Simplicidad. Nunca debe perderse de vista que

del proyecto.

el objetivo de un proyecto es proporcionar valor
al cliente; no es demostrar la pericia técnica del

* This work is licensed under the Creative Commons

Attribution-NonCommercial-ShareAlike 2.5 Spain License. To
view a copy of this license, visithttp://creativecommons.org/
licenses/by-nc-sa/2.5/es/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California,
94105, USA.
1 Para la elaboración de esta sección se ha utilizado extensamente el material disponible en [2, 3, 10].

equipo ni construir una aplicación que resuelva
más problemas que los del cliente.
Realimentación. No se puede dirigir adecuadamente unproceso si no se dispone de realimentación permanente sobre su progreso. La reali-

1

mentación puede provenir del cliente, de los pro-

sosticado que contemple hipotéticas necesida-

gramadores, de herramientas automáticas, etc.

des futuras. La mejor forma de obtener una idea
de los futuros requisitos de un sistema es pro-

Coraje. A veces, hacer lo que es correcto requiereporcionar cuanto antes un prototipo al cliente y

valor. Por ejemplo, hay que tener coraje para

obtener realimentación; y la mejor forma de ob-

reescribir código que funciona pero ha alcanzado

tener un diseño simple que funcione es recurrir a

su límite de escalabilidad.

los patrones de diseño[7].

Estos cuatro valores dan origen a cinco principios bá-

Pruebas automáticas. ¾Cómo...