Programacin eXtrema y Software Libre

Gregorio Robles
Universidad Rey Juan Carlos
grex@scouts-es.org
Jorge Ferrer
Universidad Politcnica de Madrid
jferrer@jorgeferrer.com
Copyrigt !C" #$$# %regorio Ro&les Mart'ne( y Jorge )errer *ar(uela. Permitida la
redistri&uci+n ilimitada de copias literales y la traducci+n del texto a otros idiomas
siempre y cuando se mantenga esta autori(aci+n y la nota de copyrigt.
Historial de revisiones
Revisi+n #.$ - versi+n , Congreso -ispalinux. /ctu&re #$$# 0$ de octu&re de #$$#
Resumen
1a programaci+n extrema es una metodolog'a de desarrollo ligera &asada en una serie
de valores y una docena de pr2cticas de. llammoslas as'. &uenas maneras 3ue propician
un aumento en la productividad a la ora de generar soft4are. Por otro lado. el soft4are
li&re es un movimiento nacido de la idea de 3ue los usuarios tienen una serie de
derecos so&re el soft4are 3ue permiten modificarlo. adaptarlo y redistri&uirlo. 5stas
caracter'sticas an eco 3ue el desarrollo de soft4are li&re aya desem&ocado en unos
mtodos de desarrollo informales similares a los 3ue se pregonan en la programaci+n
extrema y 3ue ser2n presentados. estudiados y comparados en este art'culo. 6e ar2
especial nfasis en las diferencias 3ue ay entre los dos mtodos y lo 3ue puede
aprender el soft4are li&re de la programaci+n extrema.
Tabla de contenidos
0. 6o&re este documento
#. 1a Programaci+n 5xtrema
#.0. 5l proceso de desarrollo extremo
#.#. ,alores de la programaci+n extrema
#.7. Principios de la programaci+n extrema
#.8. Pr2cticas de la programaci+n extrema
#.9. Conclusi+n
7. 5l 6oft4are 1i&re
7.0. 5l modelo de desarrollo de soft4are li&re
7.#. -erramientas de desarrollo
7.7. Conclusi+n
8. 6oft4are 1i&re y Programaci+n 5xtrema
8.0. Caracter'sticas intr'nsecas de programaci+n extrema en el soft4are li&re
8.#. Pr2cticas de dif'cil adaptaci+n
8.7. Pr2cticas interesantes
8.8. :esarrollo distri&uido y programaci+n extrema
8.9. ;nterrogantes y retos
9. Conclusiones
<. Referencias !en orden alfa&tico"
=. >i&liograf'a y otras direcciones de inters
! Sobre este documento
5n este art'culo se ar2 una introducci+n tanto de la programaci+n extrema como del
soft4are li&re. ?un3ue ser2n dos presentaciones &astante amplias. no se pretende llegar
a un gran nivel de detalle. 5xisten multitud de art'culos y li&ros so&re programaci+n
extrema y soft4are li&re 3ue tratan am&os temas de una manera muco m2s extensa@
alguno de los art'culos y li&ros se pueden encontrar en el apartado dedicado a las
referencias y direcciones de inters al final de este documento.
:espus de dar a conocer en 3u consisten la programaci+n extrema y el soft4are li&re
se proceder2 a compararlos. a ver 3u pr2cticas son comunes. as' como en 3u aspectos
difieren o ser'an necesarias modificaciones para poder llegar a compaginarlas. 1a
comparaci+n desem&ocar2 en un Altimo punto en el 3ue se muestran las conclusiones
3ue el autor a sacado de la ela&oraci+n del estudio.
"! La Programacin #$trema
1a programaci+n extrema se &asa en una serie de reglas y principios 3ue se an ido
gestando a lo largo de toda la istoria de la ingenier'a del soft4are. Usadas
conjuntamente proporcionan una nueva metodolog'a de desarrollo soft4are 3ue se
puede englo&ar dentro de las metodolog'as ligeras. 3ue son a3ullas en la 3ue se da
prioridad a las tareas 3ue dan resultados directos y 3ue reducen la &urocracia 3ue ay
alrededor tanto como sea posi&le !pero no m2s" B)o4lerC. 1a programaci+n extrema.
dentro de las metodolog'as 2giles. se puede clasificar dentro de las evolutivas
B-arrisonC.
Una de las caracter'sticas de eDtreme Programming es 3ue mucos de. si no todos. sus
ingredientes son de so&ra conocidos dentro de la rama de la ingenier'a del soft4are
desde ace tiempo. incluso desde sus comien(os. 1os autores de an seleccionado los
3ue an considerados como los mejores y an profundi(ado en sus relaciones y en c+mo
se refuer(an unos a otros. 5l resultado a sido una metodolog'a Anica y compacta. Por
eso. aun3ue se pueda alegar 3ue la programaci+n extrema no se &ase en principios nada
nuevos. se a de aclarar 3ue. en conjunto. es una nueva forma de ver el desarrollo de
soft4are.
?un3ue. como ya se a comentado. la programaci+n extrema se &asa en unos valores.
unos principios fundamentales y unas pr2cticas. en este art'culo no se van a enumerar
as' de primeras. ya 3ue el autor considera 3ue no es la mejor forma de presentarlos. 1os
principios y pr2cticas no se an eco a priori o por3ue s'. sino 3ue tienen un por3u a
partir de una forma glo&al de desarrollar soft4are 3ue. al menos en teor'a. parece ser
m2s eficiente.
Por tanto. en este art'culo se presentar2 la programaci+n extrema desde un punto de
vista pr2ctico para luego dar paso a enunciar los valores y principios 3ue se an extra'do
y las pr2cticas 3ue acen 3ue se lleven a &uen fin. 1a idea es seguir 3ue el lector pueda
seguir en los siguientes p2rrafos un proceso de desarrollo extremo tal y como de&er'a
darse en un e3uipo de desarrollo 3ue siguiera la metodolog'a DP. :e esta forma se ir2n
detallando y explicando las diferentes tcnicas utili(adas. as' como su ra(+n de ser.
Una ve( 3ue ayamos visto el proceso de desarrollo extremo. los valores. principios y
pr2cticas ser2n evidentes y no re3uerir2n muco detenimiento.
"!! #l %roceso de desarrollo e$tremo
1a programaci+n extrema parte del caso a&itual de una compaE'a 3ue desarrolla
soft4are. generalmente soft4are a medida. en la 3ue ay diferentes rolesF un e3uipo de
gesti+n. un e3uipo de desarrolladores y los clientes. 1a relaci+n con el cliente es
totalmente diferente a lo 3ue se a venido aciendo en las metodolog'as tradicionales
3ue se &asan fundamentalmente en una fase de captura de re3uisitos previa al desarrollo
y una fase de validaci+n posterior al mismo.
"!!! &nteraccin con el cliente
5n la programaci+n extrema al cliente no s+lo se le pide 3ue apoye al e3uipo de
desarrollo. en realidad podr'amos decir 3ue es parte de l. 6u importancia es capital a la
ora de a&ordar las istorias de los usuarios y las reuniones de planificaci+n. como
veremos m2s adelante. ?dem2s. ser2 tarea suya realimentar al e3uipo de desarrolladores
despus de cada iteraci+n con los pro&lemas con los 3ue se a encontrado. mostrando
sus prioridades. expresando sus sensaciones... 5xistir2n mtodos como prue&as de
aceptaci+n 3ue ayudar2n a 3ue la la&or del cliente sea lo m2s fruct'fera posi&le.
5n resumen. el cliente se encuentra muco m2s cercano al proceso de desarrollo. 6e
elimina la fase inicial de captura de re3uisitos y se permite 3ue stos se vayan
definiendo de una forma ordenada durante el tiempo 3ue dura el proyecto. 5l cliente
puede cam&iar de opini+n so&re la marca y a cam&io de&e encontrarse siempre
disponi&le para resolver dudas del e3uipo de desarrollo y para detallar los re3uisitos
especificados cuando sea necesario.
5l proceso de captura de re3uisitos de DP gira entorno a una lista de caracter'sticas 3ue
el cliente desea 3ue existan en el sistema final. Cada una de estas caracter'sticas reci&e
el nom&re de istorias de usuarios y su definici+n consta de dos fasesF
5n la primera fase el cliente descri&e con sus propias pala&ras las caracter'sticas y el
responsa&le del e3uipo de desarrollo le informa de la dificultad tcnica de cada una de
ellas y por lo tanto de su coste. ? travs del di2logo resultante el cliente deja por escrito
un conjunto de istorias y las ordena en funci+n de la prioridad 3ue tienen para l. 5n
este momento ya es posi&le definir unos itos y unas fecas aproximadas para ellos.
1a segunda fase consiste en coger las primeras istorias 3ue ser2n implementadas
!primera iteraci+n" y dividirlas en las tareas necesarias para llevarlas a ca&o. 5l cliente
tam&in participa. pero ay m2s peso del e3uipo de desarrollo. 3ue dar2 como resultado
una planificaci+n m2s exacta. 5n cada iteraci+n se repetir2 esta segunda fase para las
istorias planificadas para ella.
5ste proceso es una de las principales diferencias con las metodolog'as tradicionales.
?un3ue las istorias de usuarios guardan cierta relaci+n con otras tcnicas como los
casos de uso de UM1. su proceso de creaci+n es muy diferente. 5n lo 3ue al cliente se
refiere no se le exige 3ue especifi3ue exactamente lo 3ue 3uiere al principio con un
documento de re3uisitos de usuario. 1a parte 3ue se mantiene con este documento es
3ue es el cliente el 3ue tiene 3ue escri&ir lo 3ue 3uiere. no se permite 3ue alguien del
e3uipo de desarrolladores lo escri&a por l.
Como se a comentado. son los desarrolladores los 3ue se encargan de catalogar las
istorias de los usuarios y asignarles una duraci+n. Para ello se sigue una norma simpleF
las istorias de usuarios de&er'an poder ser a&orda&les en un espacio de tiempo de entre
una y tres semanas de programaci+n ideal. -istorias de los usuarios 3ue re3uieran
menos tiempo de implementaci+n son agrupadas. mientras 3ue a3ullas 3ue necesiten
m2s tiempo de&en ser modificadas o divididas. Una semana de programaci+n ideal es
una semana !cinco d'as de tra&ajo" de desarrollo por parte de un desarrollador sin
interferencias de otras partes del proyecto. ?l acer la planificaci+n se aplica un factor
de correcci+n medido de proyectos anteriores para ajustar este tiempo ideal al real.
1as istorias de los usuarios se plasmar2n en tarjetas. lo 3ue facilitar2 3ue el cliente
pueda especificar la importancia relativa entre las diferentes istorias de usuario. as'
como la tarea de los desarrolladores 3ue podr2n catalogarlas convenientemente. 5l
formato de tarjeta adem2s es muy provecoso a la ora de reali(ar prue&as de
aceptaci+n.
"!!"! Planificacin del %royecto
5s pro&a&lemente en este punto donde nos de&amos enfrentar a la planificaci+n de
entregas !release planning" donde planificaremos las distintas iteraciones. Para ello
existen una serie de reglas 3ue ay 3ue seguir para 3ue las tres partes implicadas en este
proceso !e3uipo de gesti+n. e3uipo de desarrollo y cliente" tengan vo( y se sientan parte
de la decisi+n tomada. 3ue al fin y al ca&o de&e contentar a todos.
1a planificaci+n de&e de seguir unas ciertas premisas. 1a primordial es 3ue las entregas
se agan cuanto antes y 3ue con cada iteraci+n el cliente reci&a una nueva versi+n.
Cuanto m2s tiempo se tarde en introducir una parte esencial. menos tiempo a&r2 para
tra&ajar en ella posteriormente. 6e aconsejan mucas entregas y muy frecuentes. :e esta
forma. un error en una parte esencial del sistema se encontrar2 pronto y. por tanto. se
podr2 arreglar antes.
6in em&argo. los re3uisitos anteriores en cuanto a la planificaci+n no de&en suponer
oras extra para el e3uipo de desarrollo. 5l argumento 3ue se es&o(a es 3ue lo 3ue se
tra&aja de m2s un d'a. se deja de tra&ajar al siguiente. :iversas pr2cticas como las
prue&as unitarias. la integraci+n continua o el juego de la planificaci+n permiten
eliminar los principales motivos por los 3ue suele ser necesario tra&ajar mucas oras
extra.
Pero lo mejor de todo es 3ue a la ora de planificar uno se puede e3uivocar. 5s m2s.
todos sa&emos 3ue lo comAn es e3uivocarse y por ello la metodolog'a ya tiene previsto
mecanismos de revisi+n. Por tanto. es normal 3ue cada 7 a 9 iteraciones se tengan 3ue
revisar las istorias de los usuarios y renegociar nuevamente la planificaci+n.
-emos visto 3ue al principio del proyecto se ace una planificaci+n en iteraciones 3ue
de&e ser retocada al ca&o de unas cuantas iteraciones. ? esto ay 3ue aEadir 3ue en cada
iteraci+n tam&in ay 3ue reali(ar la planificaci+n de la misma. lo 3ue a venido a
llamarse planificaci+n iterativa. 5n la planificaci+n iterativa se especifican las istorias
de los usuarios cuya implementaci+n se considera primordial y se aEaden a3ullas 3ue
no an pasado las prue&as de aceptaci+n de anteriores iteraciones. 1a planificaci+n de
una iteraci+n tam&in ace uso de tarjetas en las 3ue se escri&ir2n tareas. 3ue durar2n
entre uno y tres d'as !la duraci+n la de&en decidir los propios desarrolladores".
5s por eso. 3ue el diseEo 3ue seguimos se puede calificar de continuo. Como vemos
aEade agilidad al proceso de desarrollo y evita mirar demasiado adelante e implementar
tareas 3ue no estn programadas !algo 3ue se a venido a llamar programaci+n just-in-
time". Gam&in es cierto 3ue no ay nada 3ue pueda evitar 3ue los retrasos se acumulen
y como ya dec'a >rooHs en esos casos aEadir gente a un proyecto retrasado. s+lo lo
retrasa m2s.
? ra'( de lo anterior. podemos entender el siguiente consejoF optimi(a al final. 5l
eslogan su&yacente es ImaHe it 4orH. maHe it rigt and ten maHe it fastI !a( 3ue
funcione. a(lo &ien y entonces a( 3ue sea r2pido". J es 3ue nunca se sa&e a priori
d+nde puede estar el verdadero cuello de &otella. as' 3ue lo mejor es no aEadir
funcionalidad demasiado temprano y concentrarnos completamente en lo 3ue es
necesario oy. Para la optimi(aci+n siempre a&r2 tiempo despus cuando sea
prioritaria. si es 3ue de verdad llega a serlo.
1a planificaci+n en iteraciones y el diseEo iterativo dan pie a una pr2ctica poco comAn
en el desarrollo tradicional 3ue son las discusiones diarias de pie. :e esta forma. se
fomenta la comunicaci+n. ya 3ue los desarrolladores cuentan con tiempo para a&lar de
los pro&lemas a los 3ue se enfrentan y c+mo van con su!s" tarea!s". a la ve( 3ue su
car2cter informal las acen agrada&les y. so&re todo. no se alargan.
"!!'! (ise)o* desarrollo y %ruebas
5l desarrollo es la pie(a clave de todo el proceso de programaci+n extrema. Godas las
tareas tienen como o&jetivo 3ue se desarrollo a la m2xima velocidad. sin interrupciones
y siempre en la direcci+n correcta.
Gam&in se otorga una gran importancia al diseEo y esta&lece 3ue ste de&e ser revisado
y mejorado de forma continua segAn se van aEadiendo funcionalidades al sistema. 5sto
se contrapone a la pr2ctica conocida como I%ran diseEo previoI a&itual en otras
metodolog'as. 1os autores de DP opinan 3ue este enfo3ue es incorrecto dado 3ue a
priori no se tiene toda la informaci+n suficiente para diseEar todo el sistema y se limita
la posi&ilidad del cliente de cam&iar de opini+n respecto a las funcionalidades deseadas.
Como veremos a continuaci+n a cam&io se esta&lecen los mecanismos para ir
remodelando el diseEo de forma flexi&le durante todo el desarrollo.
1a clave del proceso de desarrollo de DP es la comunicaci+n. 1a gran mayor'a de los
pro&lemas en los proyectos de desarrollo son provocados por falta de comunicaci+n en
el e3uipo. as' 3ue se pone un gran nfasis en facilitar 3ue la informaci+n fluya lo m2s
eficientemente posi&le.
5s en este punto donde entra uno de los trminos estrella de la programaci+n extremaF la
met2fora. 5l principal o&jetivo de la met2fora es mejorar la comunicaci+n entre los
todos integrantes del e3uipo al crear una visi+n glo&al y comAn del sistema 3ue se
pretende desarrollar. 1a met2fora de&e estar expresada en trminos conocidos para los
integrantes del grupo. por ejemplo comparando lo 3ue se va a desarrollar con algo 3ue
se puede encontrar en la vida real. ?un3ue tam&in se incluye informaci+n so&re las
principales clases y patrones 3ue se usar2n en el sistema.
Un apoyo a la met2fora a lo largo del proyecto es una correcta elecci+n y comunicaci+n
de los nom&res 3ue se escojan durante el proyecto para los m+dulos. sistemas. clases.
mtodos. etc. Kom&res &ien puestos implican claridad. reusa&ilidad y simplicidad... tres
conceptos a los 3ue DP otorga una gran importancia.
?un3ue en general el diseEo es reali(ado por los propios desarrolladores en ocasiones se
reAnen a3uellos con m2s experiencia o incluso se involucra al cliente para diseEar las
partes m2s complejas. 5n estas reuniones se emplean un tipo de tarjetas denominadas
CRC !Class. Responsa&ilities and Colla&oration - Clases. Responsa&ilidades y
Cola&oraci+n" cuyo o&jetivo es facilitar la comunicaci+n y documentar los resultados.
Para cada clase identificada se rellenar2 una tarjeta de este tipo y se especificar2 su
finalidad as' como otras clases con las 3ue interaccione. 1as tarjetas CRC son una &uena
forma de cam&iar de la programaci+n estructurada a una filosof'a orientada a o&jetos.
?un3ue los grandes gurAs de la programaci+n extrema sostienen 3ue &ien ecas suelen
acer el diseEo o&vio. recomiendan acer sesiones CRC en caso de 3ue el sistema 3ue
se pretenda crear tenga un grado de complejidad grande. 5ste tipo de sesiones es una
simulaci+n. tarjetas CRC en mano. de las interacciones entre los diferentes o&jetos 3ue
puede reali(ar el e3uipo de desarrollo.
Como ya emos visto con anterioridad. uno de los principios de la programaci+n
extrema es la simplicidad. 5l diseEo de&e ser lo m2s simple posi&le. pero no m2s
simple. 5l paradigma L;66 !ILeep ;t 6mall and 6impleI para unos o ILeep it 6imple.
6tupidI para otros" se lleva asta las Altimas consecuencias. Por ejemplo. se ace
nfasis en no aEadir funcionalidad nunca antes de lo necesario. por las sencillas ra(ones
de 3ue pro&a&lemente aora mismo no sea lo m2s prioritario o por3ue 3ui(2s nunca
llegue a ser necesaria.
6upongamos 3ue ya emos planificado y dividido en tareas. como se a comentado en
los p2rrafos anteriores. 1o l+gico ser'a empe(ar ya a codificar. Pues no. Kos
encontramos con otro de los puntos clave de la programaci+n extrema !y 3ue s' es
innovador en ella"F las prue&as unitarias se implementan a la ve( ay 3ue el c+digo de
producci+n. :e eco cada ve( 3ue se va a implementar una pe3ueEa parte se escri&e
una prue&a sencilla y luego el c+digo suficiente para 3ue la pase. Cuando la aya pasado
se repite el proceso con la siguiente parte. ?un3ue intuitivamente esto pare(ca
contraproducente. a la larga ar2 3ue la generaci+n de c+digo se acelere. 1os creadores
de la programaci+n extrema argumentan 3ue encontrar un error puede llegar a ser cien
veces m2s caro 3ue reali(ar las prue&as unitarias. 1a idea. en definitiva. se resumen en
la siguiente fraseF IGodo c+digo 3ue pueda fallar de&e tener una prue&aI. ?dem2s. ay
3ue tener en cuenta 3ue se acen una ve( y luego se pueden reutili(ar multitud de veces.
incluso por otros desarrolladores 3ue desconocen los entresijos de esa parte o de todo el
sistema. por lo 3ue permiten compartir c+digo !otra de las pr2cticas 3ue permiten
acelerar el desarrollo tal y como se ver2 m2s adelante".
5sta forma de usar las prue&as unitarias ayuda a priori(ar y compro&ar la evoluci+n del
desarrollo y 3ue ofrecen realimentaci+n inmediata. Ja no ay imprescindi&les dos
e3uipos diferenciados 3ue desarrollan y prue&an cada uno por su cuenta. ?ora el ciclo
se &asa en implementar una prue&a unitaria. codificar la soluci+n y pasar la prue&a. con
lo 3ue se consigue un c+digo simple y funcional de manera &astante r2pida. Por eso es
importante 3ue las prue&as se pasen siempre al 0$$M BJeffriesC.
-ay muca literatura so&re las prue&as unitarias B>ecH#CB%ammaCB%amma#C. 1a
mayor'a de los autores est2n de acuerdo en 3ue cuanto m2s dif'cil sea implementar una
prue&a. m2s necesarias son. ?lgunos incluso dicen 3ue entonces 3ui(2s sea por3ue lo
3ue se intenta pro&ar no es lo suficientemente sencillo y a de rediseEarse. 5n cuanto a
erramientas para reali(ar tests unitarios. existen varias para los diferentes lenguajes. lo
3ue ace 3ue su ejecuci+n sea simple y. so&re todo. autom2tica B;mplC.
1as prue&as unitarias no se an de confundir con las prue&as de aceptaci+n 3ue an sido
mencionadas con anterioridad. Nstas Altimas son prue&as reali(adas por el cliente o por
el usuario final para constatar 3ue el sistema ace realmente lo 3ue l 3uiere. 5n caso de
3ue existan fallos. de&e especificar la prioridad en 3ue de&en ser solucionados los
diferentes pro&lemas encontrados. 5ste tipo de prue&as son prue&as de caja negra y se
acen contra las istorias de los usuarios. 6e suele tender a 3ue sean parcialmente
autom2ticos y 3ue los resultados sean pA&licos.
5s ora entonces de ampliar el ciclo de creaci+n de prue&as unitarias. codificaci+n. paso
de las prue&as y aEadirle un paso m2sF la integraci+n. 1a programaci+n extrema viene a
perseguir lo 3ue se a venido a llamar integraci+n continua. :e esta forma. acindolo
cada ve( con pe3ueEos fragmentos de c+digo. se evita la gran integraci+n final. 1as
ventajas de este enfo3ue es 3ue permite la reali(aci+n de prue&as completas y la pronta
detecci+n de pro&lemas de incompati&ilidad. ?dem2s. ya no ser2 necesario un e3uipo
independiente de integraci+n 3ue aga uso del m2gico pegamento al enfrentarse a
pro&lemas de divergencias y fragmentaci+n de c+digo.
5n todo desarrollo de programaci+n extrema de&er'a existir. por tanto. una versi+n
siempre integrada !incluso se puede asegurar su existencia mediante cerrojos - locHs".
1a sincroni(aci+n por parte de los desarrolladores con el repositorio central de&e darse
como m'nimo una ve( al d'a. de manera 3ue los cam&ios siempre se realicen so&re la
Altima versi+n. :e esta forma nos podemos asegurar de 3ue las modificaciones 3ue
acemos no se estn aciendo so&re una versi+n o&soleta.
Oui(2s el lector se aya sorprendido con la Altima afirmaci+n y pensar2 3ue la
pro&a&ilidad de encontrarse una versi+n de c+digo o&soleta !m2s antigua 3ue el c+digo
actual" es muy &aja. 5n cierto modo. esto es cierto en las metodolog'as tradicionales.
pero en la programaci+n extrema noF nos topamos con la importancia de refactori(ar
B)o4ler7C. Refactori(ar consiste &2sicamente en 3uitar redundancia. eliminar
funcionalidad 3ue no se usa o IrejuvenecerI diseEos viejos. Giene su justificaci+n
principal en 3ue el c+digo no s+lo tiene por3ue funcionar. tam&in de&e ser simple. 5sto
ace 3ue a la larga refactori(ar aorre muco tiempo y suponga un incremento de
calidad. Por cierto. tal es el nfasis 3ue se pone en la refactori(aci+n 3ue de la misma no
se li&ran ni las prue&as unitarias.
Como uno de los o&jetivos de la programaci+n extrema es 3ue cual3uier miem&ro del
e3uipo de desarrollo puede mejorar cual3uier parte del sistema. llegamos f2cilmente a la
conclusi+n de 3ue se &usca 3ue el c+digo sea de todos. Cual3uier desarrollador puede
reali(ar cam&ios. corregir erratas o refactori(ar en cual3uier momento. Para eso. entre
otras cosas. tenemos el colc+n de las prue&as unitarias por si nos e3uivocamos.
?dem2s. es una forma coerente de plasmar 3ue todo el e3uipo es responsa&le del
sistema en su conjunto y de 3ue no aya feudos personales. 5n consecuencia. un
desarrollador 3ue deje el proyecto !algo a&itual. por otra parte" no tiene por 3u
convertirse en un eco catastr+fico. 5l mejor mtodo para conseguir 3ue el c+digo sea
de todos es seguir unos est2ndares de codificaci+n consistentes. de manera 3ue la lectura
!y refactori(aci+n" por parte del resto del e3uipo de desarrollo se facilite al m2ximo.
Para terminar esta. ya extensa. descripci+n de un proceso de desarrollo de programaci+n
extrema. e dejado una de sus joyas para el final. 5l proceso de desarrollo no lo va a
acer un desarrollador en solitario. sino siempre con otra persona. algo 3ue se a venido
a llamar programaci+n por parejas. Una pareja de desarrolladores de&e compartir
ordenador. teclado y rat+n. 5l principal o&jetivo es reali(ar de forma continua y sin
parar el desarrollo una revisi+n de diseEo y de c+digo. 1as parejas de&en ir rotando de
forma peri+dica para acer 3ue el conocimiento del sistema se vaya difundiendo por el
e3uipo !facilit2ndose 3ue el c+digo sea de todos". a la ve( 3ue se fomentan el
entrenamiento cru(adoBJeffries#C. 5xisten estudios 3ue concluyen 3ue esta pr2ctica es
efica( en la pr2ctica justific2ndola con aspectos psicol+gicos y sociol+gicos BCocH&urnC.
Con este apoyo los gurAs de la programaci+n extrema no dudan en afirmar 3ue dos
personas tra&ajando conjuntamente en pareja generan en cantidad el mismo c+digo !o
mejor dico. la misma funcionalidad" 3ue dos personas por separado. pero de mayor
calidad. 6in em&argo esta es la pr2ctica 3ue m2s reticencias provoca por parte de jefes y
de los propios programadores.
"!"! +alores de la %rogramacin e$trema
5l proceso de desarrollo descrito en la secci+n anterior est2 fundamentado en una serie
de valores y principios 3ue lo gu'an. 1os valores representan a3uellos aspectos 3ue los
autores de DP an considerado como fundamentales para garanti(ar el xito de un
proyecto de desarrollo de soft4are. 1os cuatro valores de DP sonF
0. comunicaci+n.
#. simplicidad.
7. realimentaci+n y
8. coraje
1os partidarios de la programaci+n extrema dicen 3ue son los necesarios para conseguir
diseEos y c+digos simples. mtodos eficientes de desarrollo soft4are y clientes
contentos. 1os valores de&en ser intr'nsecos al e3uipo de desarrollo.
:e los cuatro valores. 3ui(2s el 3ue llame m2s la atenci+n es el de coraje. :etr2s de este
valor encontramos el lema Isi funciona. mej+raloI. 3ue coca con la pr2ctica a&itual de
no tocar algo 3ue funciona. por si acaso. ?un3ue tam&in es cierto 3ue tenemos las
prue&as unitarias. de modo 3ue no se pide a los desarrolladores una eroicidad. sino
s+lo coraje.
?lgunas voces. adem2s. aEaden un 3uinto valorF la umildad. J es 3ue con la 3ue
compartici+n de c+digo. la refactori(aci+n y el tra&ajo en e3uipo tan estreco una &uena
dosis de umildad siempre ser2 de agradecer.
"!'! Princi%ios de la %rogramacin e$trema
1os principios fundamentales se apoyan en los valores y tam&in son cuatro. 6e &usca
0. realimentaci+n velo(.
#. modificaciones incrementales.
7. tra&ajo de calidad y
8. asunci+n de simplicidad.
1os principios suponen un puente entre los valores !algo intr'nseco al e3uipo de
desarrollo" y las pr2cticas. 3ue se ver2n a continuaci+n. y 3ue est2n m2s ligadas a las
tcnicas 3ue se an de seguir.
"!,! Pr-cticas de la %rogramacin e$trema
Por su parte. las pr2cticas son las siguientesF
0. 5l juego de la planificaci+n !te planning game"
#. Pe3ueEas entregas !small releases"
7. Met2fora !metapor"
8. :iseEo simple !simple design"
9. Prue&as !testing"
<. Refactori(aci+n !refactoring"
=. Programaci+n por parejas !pair programming"
P. Propiedad colectiva !collective o4nersip"
Q. ;ntegraci+n continua !continous integration"
0$. 8$ oras semanales !8$-our 4eeH"
00. Cliente en casa !on-site costumer"
0#. 5st2ndares de codificaci+n !coding standards"
Ko es f2cil aplicar una nueva metodolog'a en un e3uipo de desarrollo ya 3ue o&liga a
aprender una nueva forma de tra&ajar. Gam&in o&liga a a&andonar c+mo se ac'an las
cosas antes. 3ue aun3ue no fuera la mejor forma posi&le ya se conoc'a. DP a sido
adoptado por un gran nAmero de e3uipos en los Altimos aEos y de sus experiencias se a
extra'do una conclusi+n sencillaF es mejor empe(ar a acer DP gradualmente.
5l proceso 3ue recomiendan los autores de DP es el siguienteF identifica el principal
pro&lema del proceso de desarrollo actual. 5scoge la pr2ctica 3ue ayuda a resolver ese
pro&lema y apl'cala. Cuando ese aya dejado de ser un pro&lema. escoge el siguiente.
5n realidad se recomienda 3ue se apli3uen las pr2cticas de dos en dos. 5l o&jetivo es
3ue las pr2cticas de DP se apoyan unas a otras y por tanto dos pr2cticas aportan m2s 3ue
la suma de am&as y por tanto es m2s f2cil compro&ar los resultados.
5l o&jetivo final de&e ser aplicar todas las pr2cticas. ya 3ue representan un conjunto
completo. Isi no las aplicas todas no est2s aciendo eDtreme ProgrammingI.
"!.! /onclusin
6egAn Lent >ecH. Ila programaci+n extrema es una forma ligera. eficiente. flexi&le.
predeci&le. cient'fica y divertida de generar soft4areI !Lent >ecH. 5xtreme
Programming 5xplained". ?' es nada. 5sta metodolog'a a surgido desde la
experiencia. como una forma de resolver los pro&lemas encontrados en los procesos de
desarrollo soft4are en los 3ue se an visto involucrados sus autores. 5ste tipo de
desarrollos eran en general de creaci+n de soft4are a la medida del cliente y ay
numerosas opiniones 3ue relatan el xito de esta metodolog'a en este 2m&ito. Oueda por
ver si es posi&le aplicar sus ideas tam&in en procesos de desarrollo muy diferentes.
como el seguido por la comunidad del soft4are li&re.
'! #l Software Libre
5n realidad. la definici+n de soft4are li&re es un concepto legalista. ya 3ue la Anica
diferencia entre el soft4are propietario y el soft4are li&re es precisamente su licencia
B6tallmanC. 5sto no es del todo cierto. por3ue se a venido constatando en la Altima
dcada 3ue esta distinci+n tiene unos efectos secundarios 3ue afectan a la manera en la
3ue se entiende y en la 3ue se genera el propio soft4are. Podemos ver 3ue la licencia
condiciona la manera de &uscar una forma eficiente de generaci+n y difusi+n del
soft4are.
'!! #l modelo de desarrollo de software libre
5ric 6. Raymond. gurA del soft4are li&re. se dio cuenta de ello en 0QQ= y en uno de sus
famosos escritos catalog+ el modelo de desarrollo de algunos !no todos" proyectos de
soft4are li&re como el modelo de &a(ar BRaymondCB>e(rouHovC. Para Raymond la
metodolog'a tradicional se pod'a comparar con la construcci+n de catedrales donde
exist'a un gran ar3uitecto 3ue ac'a el diseEo y el reparto de tareas. para 3ue
posteriormente un conjunto de operarios y peones reali(aran las operaciones pertinentes.
5n el modelo de &a(ar. por el contrario. no existe ese orden tan estricto. sino 3ue se
asemeja m2s &ien al caos 3ue se forma en un &a(ar oriental. 1a manera de interactuar
entre los diferentes actores en el caso del &a(ar no est2 controlada por ningAn tipo de
personas ni entidades. sino 3ue existe una enorme cantidad de intereses y de
intercam&ios de diferentes tipos !lo 3ue los economistas 3ue an estudiado el soft4are
li&re an llamado transacciones B%osCB1ernerC".
5ric Raymond acac+ la creaci+n de proyectos de soft4are li&re a necesidades e
intereses particulares de los propios desarrolladores. 3ue lan(an una aplicaci+n para
resolver su pro&lema y el de otras personas en idntica situaci+n. Ko es dif'cil imaginar
entonces 3ue en cada proyecto exista la figura del l'der. normalmente asociada a su
fundador o a uno de sus principales promotores. 5l l'der del proyecto no necesita ser
una persona dotada meramente de conocimientos tcnicos. sino 3ue de&e tener a&ilidad
para coordinar y motivar a todo a3ul 3ue est interesado en unirse al proyecto
reali(ando aportaciones. 5sto es as'. por3ue el origen del rediseEo suele situarse en los
propios usuarios. 3ue se revelan como los 3ue acen el tra&ajo de depuraci+n.
pro&a&lemente el proceso m2s tedioso en la generaci+n de soft4are. 6e da el eco de
3ue una cantidad grande de usuarios permite procesos de depuraci+n en paralelo y 3ue.
en caso de existir errores. su correcci+n puede darse de forma distri&uida. ya 3ue el
usuario 3ue encuentra una errata no tiene por 3u ser el usuarioRdesarrollador 3ue la
corrige.
'!"! Herramientas de desarrollo
Para poder llevar a la pr2ctica de manera efica( el 3ue los proyectos sean lo m2s
a&iertos 3ue se pueda. el modelo de &a(ar a supuesto la ela&oraci+n y perfecci+n de
numerosas erramientas. incluso de sitios centrali(ados 3ue intentan englo&ar todo el
proceso de desarrollo. como son 6ource)orge y sus clones !>erli/6 o 6avanna". 1as
erramientas son. con muca pro&a&ilidad. la mejor forma de ver y entender el
desarrollo 3ue sigue el soft4are li&re.
Uno de los principios &2sicos enunciados por Raymond. aun3ue no expresado
precisamente de esta forma. es 3ue el proceso de desarrollo de&e ser lo m2s a&ierto
posi&le. Una de las consecuencias es 3ue cuantos m2s ojos ay mirando el c+digo
mayor es la pro&a&ilidad de encontrar fallos antes BRaymondC. 1a erramienta 3ue
mejor se adapta a esta necesidad es un sistema de control de versiones a&ierto al
pA&lico. 1a Altima versi+n !y todas las anteriores" del c+digo estar2 disponi&le para todo
a3ul 3ue lo desee. 5l sistema de control de versiones. al igual 3ue todas las dem2s
erramientas utili(adas. son erramientas 3ue permiten la cola&oraci+n de manera
distri&uida. Cual3uier desarrollador en cual3uier lugar del mundo podr2 descargarse el
c+digo y corregir una errata 3ue aya encontrado.
5n realidad. la idea de Raymond va m2s all2. ya 3ue la IcomunidadI 3ue se crea
alrededor de un proyecto no se forma por s' sola. 6on necesarios una serie de acciones y
mecanismos para 3ue el proyecto sea conocido. :e esta forma. se consiguen usuarios
3ue son el primer paso para tener desarrolladores. 5sta tarea. aun3ue no necesariamente
tcnica. implica gran cantidad de tra&ajo. Uno de los mtodos evocados por Raymond y
proclamado incluso como principio por algunos es el famoso Irelease early. release
oftenI !entrega pronto. entrega frecuentemente". 3ue est2 pensado para captar la
atenci+n de una comunidad de usuarios !y desarrolladores" y mantenerla satisfeca con
la evoluci+n de una aplicaci+n 3ue satisfaga sus necesidades BRaymondC.
1a proliferaci+n del acceso a ;nternet a eco 3ue el ciclo de desarrollo se sustente
fuertemente en el uso de sus servicios. de manera 3ue se consigue un grupo potencial de
usuarios !y desarrolladores" muco mayor. 1as formas de comunicaci+n a&ituales son
las listas de correo. a&iertas a la suscripci+n de cual3uiera 3ue as' lo desee. 1os
mensajes de las lista de correo son almacenados en los llamados IarcivosI. lo 3ue
permite poder tener acceso a todas las decisiones y discusiones de la lista. :e esta
manera. todo 3ueda plasmado por escrito. Gam&in existen otros medios de
comunicaci+n como pueden ser los canales de ;RC.
6ource)orge y otros portales especiali(ados en sustentar la creaci+n de soft4are li&re lo
3ue acen es reali(ar las tareas de instalaci+n. configuraci+n y gesti+n de erramientas
3ue permiten este tipo de desarrollos. de manera 3ue un desarrollador 3ue 3uiera crear
un nuevo proyecto de soft4are li&re no se tenga 3ue preocupar de tener 3ue instalarse su
propio soft4are de control de versiones ni gestores de listas de correo-e. 5n definitiva.
los desarrolladores de soft4are li&re pueden desarrollar y gestionar sus proyectos de
manera 3ue se aprovece la sinergia producida por un entorno de desarrollo lo m2s
a&ierto posi&le.
'!'! /onclusin
Podemos concluir 3ue el soft4are li&re per se no est2 asociado a ninguna forma de
desarrollo espec'fica. sino 3ue se caracteri(a por una serie de condiciones !legales" 3ue
un programa de&e cumplir para ser considerado como tal. 6in em&argo. la experiencia
a demostrado formas y mtodos por los cuales proyectos de soft4are li&re tienen m2s
xito y evolucionan m2s r2pido y mejor 3ue otros. pro&a&lemente incluso mejor 3ue el
soft4are propietario. 1a idea principal es aprovecar las caracter'sticas impuestas por
las licencias para a&rir el proceso de desarrollo al mayor nAmero de personas y
aprovecar mecanismos de difusi+n predefinidos !independientes de los
desarrolladores" para llegar a tener un amplio grupo de usuarios. ?dem2s. la existencia
de erramientas de cola&oraci+n distri&uida permiten aprovecar al m2ximo efectos
sinergticos.
,! Software Libre y Programacin #$trema
? lo largo de las introducciones a la programaci+n extrema y al soft4are li&re emos
visto como algunas de las pr2cticas de la programaci+n extrema son intr'nsecas al
desarrollo del soft4are li&re. Por contra. existe otra serie de pr2cticas 3ue son de dif'cil
implantaci+n o 3ue generan serios interrogantes. 5ste apartado va a tratar so&re todo
esto.
?ntes de todo. es importante recordar 3ue para >ecH se est2 aciendo programaci+n
extrema si y s+lo si se siguen las doce pr2cticas. ninguna m2s ni ninguna menos B>ecHC
BJeffries7C. )o4ler es m2s flexi&le en este sentido y prefiere a&lar entonces de procesos
influenciados por la programaci+n extrema B)o4ler#C. ,emos 3ue mientras el soft4are
li&re es muy flexi&le en cuanto a su modelo de desarrollo !como ya emos visto con
anterioridad. en realidad es un concepto legal". la programaci+n extrema consta de un
conjunto conocido y cerrado de pr2cticas. 5sta caracter'stica ar2 3ue consideremos
invariante la programaci+n extrema y veamos 3u cosas son las 3ue pueden ser
interesantes para el desarrollo de soft4are li&re.
Como veremos. la programaci+n extrema no puede ser implantada en su pr2ctica
totalidad por el desarrollo de soft4are li&re. Por eso. retomando las pala&ras de )o4ler.
veremos asta 3u punto se puede influenciar el soft4are li&re por los procesos de
programaci+n extrema.
,!! /aracter0sticas intr0nsecas de %rogramacin e$trema en el software
libre
5n un p2rrafo anterior se a comentado 3ue el soft4are li&re sigue de por s' algunas
pr2cticas de la programaci+n extrema. Como son caracter'sticas ya adoptadas y
ampliamente conocidas. no nos detendremos muco en ellas.
1a m2s evidente de las pr2cticas comunes es pro&a&lemente la propiedad colectiva del
c+digo. caracter'stica esencial para la li&ertad del soft4are. ?l igual 3ue en la
programaci+n extrema. para facilitar el tra&ajo conjunto. se siguen uno est2ndares de
codificaci+n 3ue permiten una lectura r2pida y simple del c+digo. a la ve( 3ue
independi(a el c+digo de su autor. Un &uen ejemplo en cuanto a est2ndares de
codificaci+n es el proyecto P5?R. un repositorio de clases P-P BJansenC. 5n mucos
proyectos. las aportaciones de terceros no se aceptan. ni si3uiera revisan. asta 3ue
sigan los est2ndares esta&lecidos. Oue el c+digo sea comunitario en el soft4are li&re.
como se a dico antes. no implica en mucas ocasiones 3ue aya compartici+n de
conocimiento total como se recomienda en la programaci+n extrema.
5l paradigma Ientrega pronto. entrega frecuentementeI del soft4are li&re encaja
perfectamente con la idea de tener entregas frecuentes de la programaci+n extrema en
&usca de realimentaci+n. 5l 3ue se aga incapi en acer una primera entrega pronto
encaja. por su parte. perfectamente con la idea de 3ue se empiece por lo primordial y se
dejen funcionalidades avan(adas para el futuro. ? partir de a' el proceso iterativo de
pro&ar. codificar. pasar prue&as y refactori(ar de la programaci+n extrema se cumple
parcialmente en el soft4are li&re. Mientras las prue&as unitarias todav'a se utili(an poco
asiduamente. el proceso de tener pe3ueEas iteraciones se cumple casi al pie de la letra.
llegando incluso a tener proyectos con entregas diarias. 1a refactori(aci+n en s' no
ocurre como tal. siendo lo m2s frecuente una simple correcci+n de erratas. 1o m2s
frecuente es 3ue se de el caso de 3ue los usuarios agan depuraci+n !paralela" y 3ue
ofre(can realimentaci+n. ya sea con la soluci+n del pro&lema o como un aviso para 3ue
el desarrollador principal o cual3uier otra persona pueda corregirlo.
,!"! Pr-cticas de dif0cil ada%tacin
?l igual 3ue existen ciertas pr2cticas de la programaci+n extrema muy arraigadas y en
concordancia con el proceso de desarrollo mayoritario de soft4are li&re. existen otras
cuyo seguimiento se puede pr2cticamente descartar.
,!"!! ,1 2oras semanales
1a 3ue se puede eliminar. sin lugar a dudas. es el re3uisito de 3ue el e3uipo de tra&ajo
de&a tener una carga de tra&ajo ra(ona&le !8$ oras". 1os estudios reali(ados so&re
desarrolladores de soft4are li&re demuestran 3ue una gran mayor'a de los
desarrolladores de soft4are li&re cola&oran en proyectos en su tiempo li&re. 6e da la
circunstancia de 3ue un P$M le dedica menos de 09 oras semanales. 6in em&argo.
aun3ue esta pr2ctica est2 dirigida a un entorno la&oral. tam&in es cierto 3ue se &asa en
el eco de 3ue la capacidad creativa no se puede alargar m2s all2 de un cierto tiempo.
5l desarrollador necesita una serie de condiciones para poder ejercerla en su m2xima
expresi+n y una de ellas es 3ue el am&iente la&oral sea agrada&le.
5n el caso de los cola&oradores del soft4are li&re asumir esto es de perogrullo. ya 3ue
su cola&oraci+n es en cual3uier caso de manera voluntaria.
5n conclusi+n. esta pr2ctica es de dif'cil adaptaci+n en el mundo del soft4are li&re. pero
por otra parte tampoco es necesaria. por3ue los o&jetivos 3ue persigue ya son
alcan(ados por otros medios de por s'.
,!"!"! /liente en casa
5l segundo punto es ya un poco m2s complejo de solucionarF la cliente en casa. J lo es
por partida do&le. ya 3ue no es 3ue no podamos asegurar 3ue est en casa. es 3ue en
realidad no tenemos la certe(a de tener clientes. :e eco lo 3ue se tiene son usuarios.
6in em&argo. la figura del usuario difiere en &astantes aspectos de la de cliente.
5n comAn tienen 3ue. tanto en el soft4are li&re como en la programaci+n extrema. se
intente integrar al usuarioRcliente en el e3uipo de desarrollo. 5n la programaci+n
extrema esto se ace para agili(ar la realimentaci+n. mientras 3ue el soft4are li&re va
m2s all2 y tam&in se ve la posi&ilidad de 3ue el propio usuario termine formando parte
del e3uipo de desarrollo. con el o&jetivo de 3ue cola&ore tam&in en tareas de
depuraci+n. correcci+n y. con suerte. integraci+n.
6e diferencian en 3ue en la programaci+n extrema. todo el desarrollo gira en torno a las
istorias de los usuarios. 5l cliente es la fuente de ingresos y merece. por consiguiente.
todas las atenciones. 5l desarrollo de soft4are li&re es m2s ca+tico en este sentido. 5l
usuario reci&ir2 la funcionalidad 3ue precisa si existe algAn desarrollador 3ue est2
interesado en implementarla. 5l centro de decisi+n se a trasladado en este caso acia el
desarrollador. 6in em&argo. tam&in es cierto 3ue un usuario siempre tiene la
posi&ilidad de pagar a un desarrollador para 3ue aporte la funcionalidad al proyecto 3ue
satisfaga sus necesidades. 5sto lo puede acer incluso yendo en contra de la estrategia
general del proyecto. J es 3ue una de las consecuencias econ+micas de las licencias de
soft4are li&re es 3ue imposi&ilitan el vendor locH-in. esa situaci+n donde es el
fa&ricante de soft4are !a3ul 3ue tiene la propiedad intelectual" el 3ue decide de manera
unilateral el rum&o 3ue de&e tomar el soft4are. as' como lo 3ue se puede acer con l
B>araonaC.
Gam&in es cierto 3ue en los grandes proyectos de soft4are li&re se ace un gran
esfuer(o por conocer las necesidades de los usuarios para satisfacerles en pr+ximas
entregas. aun3ue este proceso no se encuentre formali(ado como en la programaci+n
extrema mediante el uso de tarjetas CRC. cuya adopci+n sea pro&a&lemente de gran
inters. 5l mecanismo a&itual 3ue tienen los usuarios para acer peticiones a los
desarrolladores suelen ser las listas de correo electr+nico del proyecto. 1a cercan'a del
usuario es parcial.
Resumiendo. emos visto 3ue el soft4are li&re suele carecer de cliente como tal. aun3ue
cuenta con la figura de usuario. -emos tratado las diferencias existentes entre clientes y
usuarios y las consecuencias 3ue acarrean en el proceso de desarrollo. Gam&in sa&emos
3ue a d'a de oy. en el soft4are li&re no existen mtodos formales para capturar
necesidades de los usuarios y compro&ar 3ue an sido satisfecas.
,!"!'! #l 3uego de %lanificacin
Como emos visto en el apartado anterior. la falta de cliente ar2 3ue sea muy dif'cil
3ue se pueda llevar a ca&o el juego de planificaci+n 3ue propone la programaci+n
extrema. 5n realidad. podemos asegurar 3ue tal y como se viene desarrollando el
soft4are li&re en este aspecto es todav'a m2s extremo 3ue el modelo de la programaci+n
extrema. ya 3ue prescinde segAn los casos parcial o totalmente de este paso.
1os nuevos proyectos suelen crearse para satisfacer necesidades personales por parte de
un desarrollador o un grupo de desarrolladores. 5n este miniestadio. el propio
desarrollador suele ser a la ve( el propio usuario. por lo 3ue no necesita un proceso de
formali(aci+n de istorias de los usuarios. 6egAn va creciendo el proyecto. es pro&a&le
3ue el juego de planificaci+n se aga m2s y m2s necesario. so&re todo si el nAmero de
usuarios crece y el e3uipo de desarrolladores est2 dispuesto a satisfacer las necesidades
de los usuarios llegando incluso a reali(ar una planificaci+n temporal del mismo. Como
en mucos de los puntos anteriores vemos 3ue no existen erramientas ni mecanismos
de soft4are li&re 3ue permitan formali(ar esto convenientemente.
1a mejor aproximaci+n es 3ui(2s >ug(illa 3ue permite ser utili(ado adem2s de para la
gesti+n de la generaci+n de informes de defectos y posterior correcci+n de los mismos.
para organi(ar y repartir tareas entre el e3uipo de desarrollo. /tro mtodo ampliamente
difundido es el uso de 4iHis. aplicaciones con interfa( 4e& a&iertas a la contri&uci+n de
todo el 3ue las visite. aun3ue ciertamente es una soluci+n &astante primitiva.
-erramientas como MrProject. un clon de la aplicaci+n para gesti+n de proyectos M6
Project. pueden favorecer 3ue esto mejore en un futuro pr+ximo.
,emos 3ue en lo 3ue al juego de planificaci+n se refiere. el soft4are li&re es todav'a
m2s extremo 3ue la propia programaci+n extrema. 6u ejecuci+n se retrasa asta estadios
en los 3ue es verdaderamente necesaria. siguiendo la idea 3ue aparece en otras partes de
la programaci+n extremaF Isi no lo necesitas aora. no lo agasI.
,!"!,! Programacin %or %are3as
1a programaci+n por parejas es una de las pie(as clave de la programaci+n extrema y
3ue. sin em&argo. parece 3ue no tiene ca&ida en el mundo del soft4are li&re. 6in
em&argo. es posi&le 3ue la programaci+n por parejas no sea tan Atil en el soft4are li&re
como lo puede ser en un proyecto en una empresa.
1a revisi+n entre iguales. tanto de c+digo como de diseEo. 3ue propicia el tra&ajo en
parejas. es una pr2ctica 3ue en mucos proyectos se da de por s'. 5l m2s conocido es el
caso de 1inux. donde se carece incluso de un repositorio C,6. 1inus Gorvalds 3uiere
3ue todas las aportaciones de c+digo se manden a la lista de correo. Ko como adjunto al
mensaje. sino incluso en el cuerpo del mensaje. :e esta forma est2 a la vista de todos y
no es una pr2ctica poco a&itual 3ue los parces sean anali(ados y comentados por
terceras personas en la propia lista.
5xisten otros mecanismos no formali(ados de aceptaci+n de cola&oraciones de c+digo.
%eneralmente lo m2s comAn es 3ue los desarrolladores principales sean los Anicos 3ue
tengan acceso de escritura al repositorio del sistema de control de versiones. Cual3uier
persona es capa( de descargarse la Altima versi+n del mismo. pero tendr2 3ue enviar a
los desarrolladores principales el parce para 3ue ste sea incluido. 6er2 tarea de estos
Altimos revisar la contri&uci+n y verificar 3ue sigue los par2metros de codificaci+n y
diseEo pertinentes.
/tra ventaja adicional en el mundo de la empresa de tener dos programadores
reali(ando tareas conjuntamente es por la alta movilidad la&oral. 5s &ien sa&ido. 3ue
mucos proyectos pierden un tiempo valios'simo cuando uno de los integrantes del
e3uipo deja el tra&ajo !una situaci+n 3ue. por cierto. se a dado con una pasmosa
frecuencia en los Altimos tiempos". 1a programaci+n por parejas intenta mitigar este
efecto. ya 3ue de los dos programadores se 3uedar2 uno 3ue tendr2 el conocimiento
suficiente so&re lo 3ue esta&a aciendo la pareja como para poder seguir adelante. 6in
em&argo. tam&in en este caso. las condiciones 3ue se dan en el desarrollo de soft4are
li&re acen 3ue esto no sea tan pro&lem2tico.
,emos en definitiva. 3ue aAn cuando la programaci+n por parejas se suple por otros
medios. no existe un mecanismo formal 3ue permita compro&ar 3ue los o&jetivos
promulgados por la misma se cumplen.
,!'! Pr-cticas interesantes
5n los siguientes puntos vamos a comentar las pr2cticas cuya adopci+n por parte del
mtodo de desarrollo del soft4are li&re puede ser interesante. 5s verdad 3ue estas
pr2cticas ya se encuentran m2s o menos arraigadas en diferentes proyectos. pero en
opini+n del autor esta situaci+n no es suficiente y. por tanto. se de&e fomentar su uso.
1as pr2cticas 3ue se incluyen en este apartado no cocan frontalmente con el modelo
actual de desarrollo de soft4are li&re. por lo 3ue su adopci+n se facilita. 5n la mayor'a
de los casos suponen m2s un cam&io de costum&re en la forma de programar y utili(ar
la informaci+n 3ue se maneja en un proyecto. Por contra. las consecuencias de este
ligero cam&io pueden suponer un sustancial aumento de calidad de las aplicaciones de
soft4are li&re.
,!'!! Pruebas unitarias y de ace%tacin
1as prue&as unitarias se de&er'an implementar con mayor frecuencia. ?un3ue se puede
considerar 3ue es una tcnica ya existente en los aEos =$. la programaci+n extrema
puede acer 3ue se incremente su uso en los proyectos de soft4are li&re y.
pro&a&lemente. 3ue sea su mayor aportaci+n a la misma. 1as prue&as unitarias no tienen
por 3u acerse estrictamente antes de codificar@ al fin y al ca&o es mejor tener prue&as.
aun3ue sea con posterioridad. 3ue no tenerlas.
Cuando un programador tiene 3ue modificar c+digo 3ue a sido desarrollado por otra
persona se corre un alto riesgo de 3ue introdu(ca alguna errata !&ug". 1as prue&as
unitarias reducen este riesgo dado 3ue avisar2n al instante si algo deja de funcionar.
Katuralmente para ello de&e ad3uirirse el 2&ito de ejecutar todas las prue&as del
sistema tras acer un cam&io. 5n los proyectos de soft4are li&re. la reducci+n de este
factor de riesgo es muy Atil. dado 3ue es muy a&itual modificar c+digo escrito por
otros.
5s pro&a&le 3ue la introducci+n de las prue&as unitarias conlleve un cam&io de filosof'a
en el mundo del soft4are li&re. :e la &As3ueda eroica de erratas en la 3ue se ace tanto
nfasis. se de&e pasar a la implantaci+n de &uenas maneras 3ue redunden en c+digo
menos proclive a tenerlos. 5n definitiva. se de&e tener a desarrolladores con talento
creando c+digo !3ue es pro&a&lemente lo 3ue mejor agan y m2s les estimule" en ve( de
repasando c+digo err+neo de otros.
5n un futuro. esperemos 3ue este tipo de prue&as puedan estar integradas en sistemas de
control de versiones como el C,6. Oui(2s aya 3ue esperar a 3ue 6u&version. la
erramienta de siguiente generaci+n de control de versiones 3ue todav'a se encuentra en
fase de desarrollo. las implemente. :e esta forma. las prue&as unitarias formar'an parte
del sistema de control de versiones.
Ko nos de&emos olvidar por otro lado de las prue&as de aceptaci+n. 1a mayor'a de los
proyectos de soft4are li&re carecen en sus p2ginas 4e& de informaci+n de acia d+nde
va el proyectoF las funcionalidades 3ue ser2n aEadidas en un futuro pr+ximo. los
cam&ios 3ue se van a acer. etc. Una &uena forma de resolver esto y a&rir el desarrollo a
m2s desarrolladores podr'a ser la creaci+n de prue&as de aceptaci+n previas a la
implementaci+n de la siguiente operaci+n 3ue podr2n ser compro&adas al final de la
misma. tal y como ocurren en los ciclos iterativos de la programaci+n extrema. 5sto
tam&in puede utili(arse para sa&er las funcionalidades 3ue son prioritarias para los
usuarios.
,!'!"! 4et-fora
5l o&jetivo de la met2fora del sistema es proporcionar a todo el e3uipo una misma
visi+n del fin del sistema y de su ar3uitectura general. Con ello se facilita 3ue todos los
desarrolladores a&len un mismo idioma y 3ue nuevos desarrolladores lo ad3uieran m2s
r2pido y integrarse en el proyecto sin dificultades. 5ste segundo aspecto es el 3ue puede
acerla interesante para el soft4are li&re. 1a posi&ilidad de conseguir el c+digo en
mucas ocasiones no re&aja suficientemente la &arrera de entrada 3ue existe para nuevas
incorporaciones. :e eco. estoy seguro de 3ue la informaci+n 3ue se puede plasmar de
manera concisa en la met2fora se encuentra dispersada en el c+digo y las listas de
correo.
Plasmar la met2fora por escrito puede suponer. por tanto. una forma de revisar el propio
diseEo del sistema por parte de los desarrolladores. ?simismo. ya 3ue estamos a&lando
de un nivel de a&stracci+n superior al de codificaci+n. puede alentar a la utili(aci+n de
patrones de diseEo. una pr2ctica &astante desconocida en el mundo del soft4are li&re.
5l uso de la met2fora junto con formas de documentaci+n de c+digo. del estilo de
javadoc y similares. puede paliar en parte la falta de documentaci+n 3ue existe en el
mundo de soft4are li&re. 5stas pr2cticas podr'an incluso llegarse a automati(arse
parcialmente !de eco javadoc es en s' una erramienta m2s 3ue una forma de
documentaci+n". Mucos adeptos a la programaci+n extrema se muestran contrarios a la
utili(aci+n de estas maneras de crear documentaci+n del c+digo. ya 3ue argumentan 3ue
el c+digo de&e ser lo suficientemente simple como para poder ser entendido por s'
mismo. 6in em&argo. a&r2 3ue tener en cuenta 3ue en mucas ocasiones para refrendar
las interfaces de una clase o &i&lioteca puede ser muy Atil. ya 3ue el desarrollador puede
no estar interesado en esa clase o &i&lioteca. sino en desarrollar una aplicaci+n 3ue la
utilice.
,!'!'! Refactori5acin
5l principal o&jetivo de la refactori(aci+n es 3ue en ve( de corregir c+digo err+neo se
reescri&a. una idea contrapuesta a la &As3ueda y ca(a de erratas 3ue tanto an
proclamado grandes gurAs del soft4are li&re. 5l nuevo c+digo. por su parte. de&e tener
un mejor diseEoF tiene 3ue ser m2s simple y estar mejor estructurado 3ue el anterior.
:etr2s de esta idea. est2 el convencimiento de 3ue con la inclusi+n de prue&as unitarias.
la correcci+n de erratas ser2 mucas veces muco m2s costosa 3ue la propia reescritura.
6i se mantiene un sistema lo m2s simple posi&le se facilita 3ue nuevos desarrollares
entren en el proyecto y realicen aportaciones. 5sta idea es la contraria al enfo3ue segAn
el cual lo primero es crear una gran infraestructura para 3ue luego sea m2s f2cil aEadir
funcionalidad. 5l principal pro&lema es 3ue en este caso no es necesario conocer esa
infraestructura para poder aportar . M2s grave aAn es 3ue no es posi&le crear una
infraestructura 3ue prevea todas las funcionalidades futuras. por lo 3ue si no se
refactori(a aca&ar2 siendo un impedimento.
Con refactori(aci+n continua se podr'a evitar 3ue aplicaciones enteras sean reescritas.
por3ue los errores de diseEo. la calidad del c+digo y otros par2metros acen imposi&le
mantener la antigua versi+n.
,!,! (esarrollo distribuido y %rogramacin e$trema
5l eco de 3ue el soft4are li&re se produ(ca mayoritariamente de forma distri&uida
ace indispensa&le un an2lisis un poco m2s exaustivo de la implicaci+n 3ue tiene la
distri&uci+n en las tcnicas de programaci+n extrema. Para ello vamos a retomar
algunos aspectos 3ue ya an sido comentados. aun3ue poniendo aora el nfasis en su
car2cter distri&uido.
1a generaci+n distri&uida de soft4are tam&in es interesante desde un punto de vista
netamente empresarial. 1a glo&ali(aci+n de la econom'a mundial a propiciado 3ue
exista un nAmero creciente de proyectos cuyo e3uipo de desarrollo. por ra(ones
econ+micas o personales. se encuentra distri&uido geogr2ficamente.
1a experiencia con los mtodos de desarrollo tradicionales a demostrado 3ue el
esfuer(o dedicado a documentar pormenori(adamente o crear documentaci+n extra no
a incrementado la eficiencia comunicativa del e3uipo 3ue tra&aja de manera
distri&uida. 5s m2s. en realidad. se a visto 3ue es contraproducente.
Por el contrario. nos encontramos con un dilema al intentar llevar a ca&o algunas de las
pr2cticas de la programaci+n extrema. ya 3ue varias de ellas asumen proximidad f'sica.
5s el caso de las siguientes pr2cticasF
0. Programaci+n por parejas
#. ;ntegraci+n continua
7. Juego de planificaci+n
8. Cliente en casa
5sto a dado paso a lo 3ue se a venido a llamar la programaci+n extrema distri&uida
!:DP - :istri&uted eDtreme Programming". 3ue permite a los miem&ros del e3uipo
estar en lugares geogr2ficos diferentes e incluso go(ar de una gran movilidad. 5l
mtodo se &asa en aplicar los valores y principios de la programaci+n extrema. pero
adapta las pr2cticas a un entorno de tra&ajo distri&uido. de manera 3ue se relaja la
asunci+n de proximidad f'sica.
5s verdad 3ue las tecnolog'as ;nternet an ayudado a 3ue el tra&ajo distri&uido sea
posi&le. pero tam&in es cierto 3ue esas tecnolog'as 3ue se usan !p2ginas 4e&. ;RC.
listas de correo. &it2cora de cam&ios y documentaci+n -- ya sea generada manual o
semiautom2ticamente" exist'an ya en los aEos =$. ?un3ue es constata&le 3ue estas
tecnolog'as no pueden reempla(ar la presencia en persona. el salto a las nuevas !y tan
prometidas" formas de comunicaci+n como la videoconferencia no son accesi&les al
pA&lico en general.
,!.! &nterrogantes y retos
5l soft4are li&re se a caracteri(ado en los Altimos aEos por3ue su proceso de desarrollo
es flexi&le. 5l eco de 3ue 3ueramos introducir varias tcnicas nuevas para acentuar la
calidad de las aplicaciones generadas. da pie a una serie de interrogantes y retos 3ue
a&r2 3ue ir solucionando.
,!.!! /om%atibilidad 2acia atr-s y de%endencias
5l diseEo iterativo 3ue promulga la programaci+n extrema coca frontalmente en
mucos proyectos con la compati&ilidad acia atr2s. Oui(2s esto tam&in sea una de las
de&ilidades de la programaci+n extrema. ya 3ue invita a reali(ar frecuentes entregas y
diseEo iterativo pero no a&orda la cuesti+n de mantener la compati&ilidad acia atr2s o
de la migraci+n de datos de versiones anteriores. 1a programaci+n extrema est2
orientada a satisfacer las necesidades de un cliente conocido donde este pro&lema est2
m2s controlado. 6in em&argo dentro de la industria del soft4are. y por supuesto con
mayor frecuencia en el soft4are li&re. no es lo general ya 3ue se dirigen a una gran
multitud de usuarios finales. 5s. por tanto. muy importante poder asegurar al usuario
3ue el tra&ajo reali(ado con anterioridad con la aplicaci+n pueda ser manipulado por las
nuevas versiones de la aplicaciones y en el caso de las li&rer'as 3ue se mantengan las
?P;s durante al menos un tiempo de migraci+n.
6in em&argo. el mayor pro&lema para utili(ar los mtodos de la programaci+n extrema
en el soft4are li&re son las dependencias. 1a programaci+n extrema asume 3ue el
proyecto se encuentra aislado en el mundo. una asunci+n 3ue en demasiadas ocasiones
no es cierta. Mucos desarrollos se &asan en otros pa3uetes 3ue a la ve( se encuentran
en fase de desarrollo y cuyas caracter'sticas cam&ian constantemente. 5n esta carrera es
muy dif'cil mantenerse independiente y aislado del mundo exterior. 1as prue&as de
regresi+n y las prue&as unitarias pueden ser dos maneras de mitigar los efectos de las
dependencias dentro del soft4are li&re.
,!.!"! &nterrogantes econmicos y %sicolgicos
Una de las cr'ticas a la programaci+n extrema es la dificultad de estimar cu2nto va a
costar un proyecto. un pro&lema asociado. por otra parte. tam&in a las metodolog'as
tradicionales. 5s verdad 3ue esto afecta en parte al soft4are li&re. ya 3ue mucos
proyectos no est2n u&icados en empresas ni tienen 3ue generar una estimaci+n de
costes. Por otro lado. ser'a interesante tener alguna forma de acerlo de manera m2s o
menos exacta para empresas 3ue reali(aran desarrollos de soft4are li&re.
1os efectos 3ue puede causar la refactori(aci+n no est2n del todo claros. 5l eco de
tener menos l'neas de c+digo despus de refactori(ar tiene un efecto psicol+gico
negativo importante. adem2s de 3ue siempre es doloroso tirar l'neas de c+digo.
? favor del soft4are li&re est2 el eco de 3ue los desarrolladores se suelen adaptar
r2pidamente a nuevas ideas. ya 3ue ven el desarrollo de soft4are li&re como un &uen
la&oratorio para tcnicas novedosas. 5sto no suele ser cierto en el mundo empresarial.
muco m2s inerte y pesado ante nuevos cam&ios. donde existe frecuentemente el
llamado s'ndrome de Ino lo emos inventado a3u'I.
Por supuesto. ay 3ue tener en cuenta 3ue gran parte del xito en la adopci+n de
tcnicas de programaci+n extrema depender2 de 3ue se creen nuevas erramientas 3ue
las soporten o 3ue las existentes integren los nuevos mtodos.
5n general. podemos concluir 3ue todav'a no existe la experiencia suficiente en
proyectos de soft4are li&re para poder a&lar de los efectos secundarios 3ue provocar'a
la adopci+n de las tcnicas de programaci+n extrema.
.! /onclusiones
? lo largo de este documento emos visto c+mo el mtodo de desarrollo seguido
mayoritariamente en el soft4are li&re y la programaci+n extrema tienen mucas
caracter'sticas comunes. Por otro lado. existen una serie de pr2cticas !prue&as. met2fora
y refactori(aci+n" 3ue ser'a muy interesantes adoptar en el soft4are li&re. ya 3ue
conllevar'an un aumento de la calidad. 1as prue&as permitir2n a los desarrolladores
reali(ar modificaciones con la seguridad de 3ue no rompen nada en otro lugar. la
met2fora proporciona una visi+n intuitiva del sistema y la refactori(aci+n est2 pensada
para mejorar la calidad del c+digo. 5stas tres iniciativas tienen como o&jetivo principal
transformar el modelo de desarrollo 3ue actualmente est2 centrado en demas'a en
encontrar y corregir erratas a una nueva forma de desarrollar en la 3ue el diseEo
iterativo y la codificaci+n tomen mayor relevancia. :ado 3ue lo segundo es m2s
divertido 3ue lo primero no dudo 3ue ser2 muy provecoso en un entorno donde la
mayor'a de los contri&uidores lo acen en su tiempo li&re y de manera altruista.
? la vista de lo 3ue se a ido exponiendo parece ser 3ue la mejor soluci+n para la
adopci+n de tcnicas de programaci+n extrema en el soft4are li&re es la existencia de
un nAcleo 3ue asegure las pr2cticas de la programaci+n extrema como pe3ueEas
entregas y 3ue permitan tener un diseEo simple y controlado !un ejemplo de esto podr'a
ser 1inux. donde de facto esto ya existe m2s o menos de esta manera". 5ste grupo puede
funcionar de por s' como un e3uipo de desarrollo distri&uido. teniendo asignada entre
otras tareas la de compro&ar 3ue las aportaciones exteriores cumplen los re3uisitos de
calidad necesarios para ser integradas en el proyecto.
/tro aspecto interesante es 3ue la programaci+n extrema ofrece mtodos formales para
plasmar informaci+n 3ue no existen de tal forma en el soft4are li&re. 6er'a interesante
contar con dicos mtodos para 3ue la &arrera de entrada a nuevos desarrolladores sea
m2s &aja. Un ejemplo interesante de estos mtodos son las tarjetas CRC 3ue permiten
tener una idea intuitiva del proyecto en un espacio de tiempo muy corto sin tener 3ue
anali(ar concien(udamente la organi(aci+n de ficeros y c+digo. Jendo m2s all2. se
podr'a utili(ar UM1 adem2s de las tarjetas CRC para especificar el diseEo de la
aplicaci+n BSillsC. 5s pro&a&le 3ue esto supongo una redefinici+n del uso de las tarjetas
CRC. ya 3ue en la programaci+n extrema sirven s+lo para comunicarse en una reuni+n.
careciendo despus de importancia como documentaci+n por3ue se asume 3ue se
3uedar2n o&soletas enseguida.
5n definitiva. se a podido ver c+mo la programaci+n extrema puede aportar nuevas
formas en &usca de optimi(ar el modelo de desarrollo de soft4are li&re. 5l tiempo dir2
si estas pr2cticas son asumidas por los diferentes proyectos de soft4are li&re y. en su
caso. si realmente ar2n go(ar de las ventajas 3ue se an presentado.
6! Referencias 7en orden alfab8tico9
0. B>araonaC JesAs Mar'a %on(2le( >araona I6oft4are li&re. monopolios y otras
yer&asI. ttpFRRsinetgy.orgRTjg&RarticulosRsoft-li&re-monopoliosR
#. B>ecHC Lent >ecH I5xtreme Programming 5xplainedF 5m&race CangeI.
?ddison-Sesley Pu& Co@ ;6>KF $#$0<0<80<. 0a edici+n octu&re 0QQQ
7. B>ecH#C Lent >ecH U 5ric %amma IJUnit CooH&ooHI.
ttpFRRjunit.sourceforge.netRdocRcooH&ooHRcooH&ooH.tm
8. B>e(rouHovC KiHolai >e(rouHov I? 6econd 1ooH at te Catedral and te
>a(aarI. ttpFRR444.firstmonday.dHRissuesRissue8V0#R&e(rouHovR
9. BCocH&urnC ?listair CocH&urn. 1aurie Silliams ICosts and >enefits of Pair
ProgrammingI. ttpFRRcolla&oration.csc.ncsu.eduRlaurieRPapersRDP6ardinia.P:)
<. B)o4lerC Martin )o4ler I;s :esign :eadWI.
ttpFRR444.martinfo4ler.comRarticlesRdesign:ead.tml
=. B)o4ler#C Martin )o4ler I,ariations on a Geme of DPI.
ttpFRR444.martinfo4ler.comRarticlesRxp,ariation.tml
P. B)o4ler7C Martin )o4ler IRefactoringF ;mprove te :esign of 5xisting CodeI.
?ddison-Sesley Pu& Co. ;6>KF $#$08P9<=#. 0a edici+n junio 0QQQ
Q. B%ammaC 5ric %amma U Lent >ecH IJUnit ? CooHXs GourI.
ttpFRRjunit.sourceforge.netRdocRcooHstourRcooHstour.tm
0$. B%amma#C 5ric %amma U Lent >ecH IJUnitGest ;nfectedF Programmers 1ove
Sriting GestsI. ttpFRRjunit.sourceforge.netRdocRtestinfectedRtesting.tm
00. B%osC Risa& ?iyer %os ICooHing pot marHetsF an economic model for te
trade in free goods and services on te ;nternetI.
ttpFRR444.firstmonday.dHRissuesRissue7V7RgosR
0#. B-arrisonC Peter -arrison I5volutionary ProgrammingI.
ttpFRR444.devcentre.orgRresearcRevoprogramming.tm
07. B;mplC ;mplementaciones de tests unitarios para diferentes lenguajes y
plataformas IGesting )rame4orHsI.
ttpFRR444.xprogramming.comRsoft4are.tm
08. BJansenC Martin Jansen. Gom2s ,.,. Cox U ?lexander Mer( IP5?R Coding
6tandardsI. ttpFRRpear.pp.netRmanualRenRstandards.pp
09. BJeffriesC Ron Jeffries I5ssential DPF Unit Gests at 0$$I.
ttpFRR444.xprogramming.comRxpmagRexpUnitGests?t0$$.tm
0<. BJeffries#C Ron Jeffries I5ssential DPF Junior R 6enior PairingI.
ttpFRR444.xprogramming.comRxpmagRpairing.tm
0=. BJeffries7C Ron Jeffries IGeyXre called Practices for a reasonI.
ttpFRR444.xprogramming.comRxpmagRPractices)oraReason.tm
0P. B1ernerC Jos 1erner U Jean Girole IGe 6imple 5conomics of /pen 6ourceI.
ttpFRR444.idei.asso.frRCommunR?rticlesRGiroleRsimpleeconomics-July-#8-
#$$0.pdf
0Q. BRaymondC 5ric 6. Raymond IGe Catedral and te >a(aarI.
ttpFRR444.tuxedo.orgRTesrR4ritingsRcatedral-&a(aarR
#$. B6tallmanC Ricard 6tallman IGe )ree 6oft4are :efinitionI.
ttpFRR444.fsf.orgRpilosopyRfree-s4.tml
#0. BSillsC ?lan Cameron Sills IUM1 meets DPI.
ttpFRR444.trireme.comR4itepapersRprocessRxp-umlRpaper.tm
:! ;ibliograf0a y otras direcciones de inter8s
0. Relaci+n de li&ros so&re ;ngenier'a del 6oft4are. patrones !patterns" y
Programaci+n 5xtrema !5xtreme Programming. DP".
ttpFRR444.ctv.esRU65R6RpagulloR&i&lioRingenieriaVdelVsoft4are.tm
#. :onnovan Sells I5xtreme ProgrammingF ? gentle introductionI.
ttpFRR444.extremprogramming.org
7. ?llison Pearce Silson I5xtreme ProgrammingI. ttpFRR444-
0$<.i&m.comRdeveloper4orHsRli&raryRit-aprcc$0RWd4(oneYi&m
8. cromatic I?n ;ntroduction to 5xtreme ProgrammingI.
ttpFRRlinux.oreillynet.comRlptRaRRlinuxR#$$0R$9R$8RxpVintro.tml
9. ?ndre4 McLinlay I5xtreme Programming and /pen 6ource 6oft4areI.
ttpFRR444.advogato.orgRarticleR#$#.tml
<. Ron Jeffries IManuals in 5xtreme ProgrammingI.
ttpFRR444.xprogramming.comRxpmagRmanuals;nDp.tm
=. Lent >ecH I6imple 6malltalH GestingF Sit PatternsI.
ttpFRR444.xprogramming.comRtestfram.tm
P. 1eig :odds IDP Meets DM1I. ttpFRR444.xml.comRpu&RaR#$$0R$8R$8Rxp.tml
Q. ,arios autores !SiHi" ICom&ining /pen 6ource ?nd DpI.
ttpFRRc#.comRcgiR4iHiWCom&ining/pen6ource?ndDp
0$. ?rmin Roerl U 6tefan 6cmiedel I?&solut extremZZZ 5xtreme Programming
und /pen 6ource 5nt4icHlungI !alem2n".
ttpFRR444.ent4icHler.comRleRausga&enR#$$0R0$RartiHelR#Ronline.stml
00. Proyecto %esti+n 1i&re de -ispalinux. ttpFRRgestion-li&re.ispalinux.es
0#. Jorge )errer I5xtreme Programming y 6oft4are 1i&re - ?prendiendo una
metodolog'a de soft4are XtradicionalXI.
ttpFRR444.jorgeferrer.comRdoctoradoRxp-y-s4-li&reR
07. ?n+nimo !,isi+n sarc2stica de la DP" IRiPF Programmer ;nvents Ke4
MetodologyI. ttpFRR444.&ad-managers.comRrumoursRstory$#0.stml