Copyright (C) 2002 Gregorio Robles Mart�nez y Jorge Ferrer Zarzuela. Permitida la redistribuci�n ilimitada de copias literales y la traducci�n del texto a otros idiomas siempre y cuando se mantenga esta autorizaci�n y la nota de copyright.
| Historial de revisiones | |
|---|---|
| Revisi�n 2.0 - versi�n V Congreso Hispalinux, Octubre 2002 | 10 de octubre de 2002 |
Resumen
La programaci�n extrema es una metodolog�a de desarrollo ligera basada en una serie de valores y una docena de pr�cticas de, llam�moslas as�, buenas maneras que propician un aumento en la productividad a la hora de generar software. Por otro lado, el software libre es un movimiento nacido de la idea de que los usuarios tienen una serie de derechos sobre el software que permiten modificarlo, adaptarlo y redistribuirlo. Estas caracter�sticas han hecho que el desarrollo de software libre haya desembocado en unos m�todos de desarrollo informales similares a los que se pregonan en la programaci�n extrema y que ser�n presentados, estudiados y comparados en este art�culo. Se har� especial �nfasis en las diferencias que hay entre los dos m�todos y lo que puede aprender el software libre de la programaci�n extrema.
Tabla de contenidos
En este art�culo se har� una introducci�n tanto de la programaci�n extrema como del software libre. Aunque ser�n dos presentaciones bastante amplias, no se pretende llegar a un gran nivel de detalle. Existen multitud de art�culos y libros sobre programaci�n extrema y software libre que tratan ambos temas de una manera mucho m�s extensa; alguno de los art�culos y libros se pueden encontrar en el apartado dedicado a las referencias y direcciones de inter�s al final de este documento.
Despu�s de dar a conocer en qu� consisten la programaci�n extrema y el software libre se proceder� a compararlos, a ver qu� pr�cticas son comunes, as� como en qu� aspectos difieren o ser�an necesarias modificaciones para poder llegar a compaginarlas. La comparaci�n desembocar� en un �ltimo punto en el que se muestran las conclusiones que el autor ha sacado de la elaboraci�n del estudio.
La programaci�n extrema se basa en una serie de reglas y principios que se han ido gestando a lo largo de toda la historia de la ingenier�a del software. Usadas conjuntamente proporcionan una nueva metodolog�a de desarrollo software que se puede englobar dentro de las metodolog�as ligeras, que son aqu�llas en la que se da prioridad a las tareas que dan resultados directos y que reducen la burocracia que hay alrededor tanto como sea posible (pero no m�s) [Fowler]. La programaci�n extrema, dentro de las metodolog�as �giles, se puede clasificar dentro de las evolutivas [Harrison].
Una de las caracter�sticas de eXtreme Programming es que muchos de, si no todos, sus ingredientes son de sobra conocidos dentro de la rama de la ingenier�a del software desde hace tiempo, incluso desde sus comienzos. Los autores de han seleccionado los que han considerados como los mejores y han profundizado en sus relaciones y en c�mo se refuerzan unos a otros. El resultado ha sido una metodolog�a �nica y compacta. Por eso, aunque se pueda alegar que la programaci�n extrema no se base en principios nada nuevos, se ha de aclarar que, en conjunto, es una nueva forma de ver el desarrollo de software.
Aunque, como ya se ha comentado, la programaci�n extrema se basa en unos valores, unos principios fundamentales y unas pr�cticas, en este art�culo no se van a enumerar as� de primeras, ya que el autor considera que no es la mejor forma de presentarlos. Los principios y pr�cticas no se han hecho a priori o porque s�, sino que tienen un porqu� a partir de una forma global de desarrollar software que, al menos en teor�a, parece ser m�s eficiente.
Por tanto, en este art�culo se presentar� la programaci�n extrema desde un punto de vista pr�ctico para luego dar paso a enunciar los valores y principios que se han extra�do y las pr�cticas que hacen que se lleven a buen fin. La idea es seguir que el lector pueda seguir en los siguientes p�rrafos un proceso de desarrollo extremo tal y como deber�a darse en un equipo de desarrollo que siguiera la metodolog�a XP. De esta forma se ir�n detallando y explicando las diferentes t�cnicas utilizadas, as� como su raz�n de ser.
Una vez que hayamos visto el proceso de desarrollo extremo, los valores, principios y pr�cticas ser�n evidentes y no requerir�n mucho detenimiento.
La programaci�n extrema parte del caso habitual de una compa��a que desarrolla software, generalmente software a medida, en la que hay diferentes roles: un equipo de gesti�n, un equipo de desarrolladores y los clientes. La relaci�n con el cliente es totalmente diferente a lo que se ha venido haciendo en las metodolog�as tradicionales que se basan fundamentalmente en una fase de captura de requisitos previa al desarrollo y una fase de validaci�n posterior al mismo.
En la programaci�n extrema al cliente no s�lo se le pide que apoye al equipo de desarrollo, en realidad podr�amos decir que es parte de �l. Su importancia es capital a la hora de abordar las historias de los usuarios y las reuniones de planificaci�n, como veremos m�s adelante. Adem�s, ser� tarea suya realimentar al equipo de desarrolladores despu�s de cada iteraci�n con los problemas con los que se ha encontrado, mostrando sus prioridades, expresando sus sensaciones... Existir�n m�todos como pruebas de aceptaci�n que ayudar�n a que la labor del cliente sea lo m�s fruct�fera posible.
En resumen, el cliente se encuentra mucho m�s cercano al proceso de desarrollo. Se elimina la fase inicial de captura de requisitos y se permite que �stos se vayan definiendo de una forma ordenada durante el tiempo que dura el proyecto. El cliente puede cambiar de opini�n sobre la marcha y a cambio debe encontrarse siempre disponible para resolver dudas del equipo de desarrollo y para detallar los requisitos especificados cuando sea necesario.
El proceso de captura de requisitos de XP gira entorno a una lista de caracter�sticas que el cliente desea que existan en el sistema final. Cada una de estas caracter�sticas recibe el nombre de historias de usuarios y su definici�n consta de dos fases:
En la primera fase el cliente describe con sus propias palabras las caracter�sticas y el responsable del equipo de desarrollo le informa de la dificultad t�cnica de cada una de ellas y por lo tanto de su coste. A trav�s del di�logo resultante el cliente deja por escrito un conjunto de historias y las ordena en funci�n de la prioridad que tienen para �l. En este momento ya es posible definir unos hitos y unas fechas aproximadas para ellos.
La segunda fase consiste en coger las primeras historias que ser�n implementadas (primera iteraci�n) y dividirlas en las tareas necesarias para llevarlas a cabo. El cliente tambi�n participa, pero hay m�s peso del equipo de desarrollo, que dar� como resultado una planificaci�n m�s exacta. En cada iteraci�n se repetir� esta segunda fase para las historias planificadas para ella.
Este proceso es una de las principales diferencias con las metodolog�as tradicionales. Aunque las historias de usuarios guardan cierta relaci�n con otras t�cnicas como los casos de uso de UML, su proceso de creaci�n es muy diferente. En lo que al cliente se refiere no se le exige que especifique exactamente lo que quiere al principio con un documento de requisitos de usuario. La parte que se mantiene con este documento es que es el cliente el que tiene que escribir lo que quiere, no se permite que alguien del equipo de desarrolladores lo escriba por �l.
Como se ha comentado, son los desarrolladores los que se encargan de catalogar las historias de los usuarios y asignarles una duraci�n. Para ello se sigue una norma simple: las historias de usuarios deber�an poder ser abordables en un espacio de tiempo de entre una y tres semanas de programaci�n ideal. Historias de los usuarios que requieran menos tiempo de implementaci�n son agrupadas, mientras que aqu�llas que necesiten m�s tiempo deben ser modificadas o divididas. Una semana de programaci�n ideal es una semana (cinco d�as de trabajo) de desarrollo por parte de un desarrollador sin interferencias de otras partes del proyecto. Al hacer la planificaci�n se aplica un factor de correcci�n medido de proyectos anteriores para ajustar este tiempo ideal al real.
Las historias de los usuarios se plasmar�n en tarjetas, lo que facilitar� que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, as� como la tarea de los desarrolladores que podr�n catalogarlas convenientemente. El formato de tarjeta adem�s es muy provechoso a la hora de realizar pruebas de aceptaci�n.
Es probablemente en este punto donde nos debamos enfrentar a la planificaci�n de entregas (release planning) donde planificaremos las distintas iteraciones. Para ello existen una serie de reglas que hay que seguir para que las tres partes implicadas en este proceso (equipo de gesti�n, equipo de desarrollo y cliente) tengan voz y se sientan parte de la decisi�n tomada, que al fin y al cabo debe contentar a todos.
La planificaci�n debe de seguir unas ciertas premisas. La primordial es que las entregas se hagan cuanto antes y que con cada iteraci�n el cliente reciba una nueva versi�n. Cuanto m�s tiempo se tarde en introducir una parte esencial, menos tiempo habr� para trabajar en ella posteriormente. Se aconsejan muchas entregas y muy frecuentes. De esta forma, un error en una parte esencial del sistema se encontrar� pronto y, por tanto, se podr� arreglar antes.
Sin embargo, los requisitos anteriores en cuanto a la planificaci�n no deben suponer horas extra para el equipo de desarrollo. El argumento que se esboza es que lo que se trabaja de m�s un d�a, se deja de trabajar al siguiente. Diversas pr�cticas como las pruebas unitarias, la integraci�n continua o el juego de la planificaci�n permiten eliminar los principales motivos por los que suele ser necesario trabajar muchas horas extra.
Pero lo mejor de todo es que a la hora de planificar uno se puede equivocar. Es m�s, todos sabemos que lo com�n es equivocarse y por ello la metodolog�a ya tiene previsto mecanismos de revisi�n. Por tanto, es normal que cada 3 a 5 iteraciones se tengan que revisar las historias de los usuarios y renegociar nuevamente la planificaci�n.
Hemos visto que al principio del proyecto se hace una planificaci�n en iteraciones que debe ser retocada al cabo de unas cuantas iteraciones. A esto hay que a�adir que en cada iteraci�n tambi�n hay que realizar la planificaci�n de la misma, lo que ha venido a llamarse planificaci�n iterativa. En la planificaci�n iterativa se especifican las historias de los usuarios cuya implementaci�n se considera primordial y se a�aden aqu�llas que no han pasado las pruebas de aceptaci�n de anteriores iteraciones. La planificaci�n de una iteraci�n tambi�n hace uso de tarjetas en las que se escribir�n tareas, que durar�n entre uno y tres d�as (la duraci�n la deben decidir los propios desarrolladores).
Es por eso, que el dise�o que seguimos se puede calificar de continuo. Como vemos a�ade agilidad al proceso de desarrollo y evita mirar demasiado adelante e implementar tareas que no est�n programadas (algo que se ha venido a llamar programaci�n just-in-time). Tambi�n es cierto que no hay nada que pueda evitar que los retrasos se acumulen y como ya dec�a Brooks en esos casos a�adir gente a un proyecto retrasado, s�lo lo retrasa m�s.
A ra�z de lo anterior, podemos entender el siguiente consejo: optimiza al final. El eslogan subyacente es "make it work, make it right and then make it fast" (haz que funcione, hazlo bien y entonces haz que sea r�pido). Y es que nunca se sabe a priori d�nde puede estar el verdadero cuello de botella, as� que lo mejor es no a�adir funcionalidad demasiado temprano y concentrarnos completamente en lo que es necesario hoy. Para la optimizaci�n siempre habr� tiempo despu�s cuando sea prioritaria, si es que de verdad llega a serlo.
La planificaci�n en iteraciones y el dise�o iterativo dan pie a una pr�ctica poco com�n en el desarrollo tradicional que son las discusiones diarias de pie. De esta forma, se fomenta la comunicaci�n, ya que los desarrolladores cuentan con tiempo para hablar de los problemas a los que se enfrentan y c�mo van con su(s) tarea(s), a la vez que su car�cter informal las hacen agradables y, sobre todo, no se alargan.
El desarrollo es la pieza clave de todo el proceso de programaci�n extrema. Todas las tareas tienen como objetivo que se desarrollo a la m�xima velocidad, sin interrupciones y siempre en la direcci�n correcta.
Tambi�n se otorga una gran importancia al dise�o y establece que �ste debe ser revisado y mejorado de forma continua seg�n se van a�adiendo funcionalidades al sistema. Esto se contrapone a la pr�ctica conocida como "Gran dise�o previo" habitual en otras metodolog�as. Los autores de XP opinan que este enfoque es incorrecto dado que a priori no se tiene toda la informaci�n suficiente para dise�ar todo el sistema y se limita la posibilidad del cliente de cambiar de opini�n respecto a las funcionalidades deseadas. Como veremos a continuaci�n a cambio se establecen los mecanismos para ir remodelando el dise�o de forma flexible durante todo el desarrollo.
La clave del proceso de desarrollo de XP es la comunicaci�n. La gran mayor�a de los problemas en los proyectos de desarrollo son provocados por falta de comunicaci�n en el equipo, as� que se pone un gran �nfasis en facilitar que la informaci�n fluya lo m�s eficientemente posible.
Es en este punto donde entra uno de los t�rminos estrella de la programaci�n extrema: la met�fora. El principal objetivo de la met�fora es mejorar la comunicaci�n entre los todos integrantes del equipo al crear una visi�n global y com�n del sistema que se pretende desarrollar. La met�fora debe estar expresada en t�rminos conocidos para los integrantes del grupo, por ejemplo comparando lo que se va a desarrollar con algo que se puede encontrar en la vida real. Aunque tambi�n se incluye informaci�n sobre las principales clases y patrones que se usar�n en el sistema.
Un apoyo a la met�fora a lo largo del proyecto es una correcta elecci�n y comunicaci�n de los nombres que se escojan durante el proyecto para los m�dulos, sistemas, clases, m�todos, etc. Nombres bien puestos implican claridad, reusabilidad y simplicidad... tres conceptos a los que XP otorga una gran importancia.
Aunque en general el dise�o es realizado por los propios desarrolladores en ocasiones se re�nen aquellos con m�s experiencia o incluso se involucra al cliente para dise�ar las partes m�s complejas. En estas reuniones se emplean un tipo de tarjetas denominadas CRC (Class, Responsabilities and Collaboration - Clases, Responsabilidades y Colaboraci�n) cuyo objetivo es facilitar la comunicaci�n y documentar los resultados. Para cada clase identificada se rellenar� una tarjeta de este tipo y se especificar� su finalidad as� como otras clases con las que interaccione. Las tarjetas CRC son una buena forma de cambiar de la programaci�n estructurada a una filosof�a orientada a objetos. Aunque los grandes gur�s de la programaci�n extrema sostienen que bien hechas suelen hacer el dise�o obvio, recomiendan hacer sesiones CRC en caso de que el sistema que se pretenda crear tenga un grado de complejidad grande. Este tipo de sesiones es una simulaci�n, tarjetas CRC en mano, de las interacciones entre los diferentes objetos que puede realizar el equipo de desarrollo.
Como ya hemos visto con anterioridad, uno de los principios de la programaci�n extrema es la simplicidad. El dise�o debe ser lo m�s simple posible, pero no m�s simple. El paradigma KISS ("Keep It Small and Simple" para unos o "Keep it Simple, Stupid" para otros) se lleva hasta las �ltimas consecuencias. Por ejemplo, se hace �nfasis en no a�adir funcionalidad nunca antes de lo necesario, por las sencillas razones de que probablemente ahora mismo no sea lo m�s prioritario o porque quiz�s nunca llegue a ser necesaria.
Supongamos que ya hemos planificado y dividido en tareas, como se ha comentado en los p�rrafos anteriores. Lo l�gico ser�a empezar ya a codificar. Pues no. Nos encontramos con otro de los puntos clave de la programaci�n extrema (y que s� es innovador en ella): las pruebas unitarias se implementan a la vez hay que el c�digo de producci�n. De hecho cada vez que se va a implementar una peque�a parte se escribe una prueba sencilla y luego el c�digo suficiente para que la pase. Cuando la haya pasado se repite el proceso con la siguiente parte. Aunque intuitivamente esto parezca contraproducente, a la larga har� que la generaci�n de c�digo se acelere. Los creadores de la programaci�n extrema argumentan que encontrar un error puede llegar a ser cien veces m�s caro que realizar las pruebas unitarias. La idea, en definitiva, se resumen en la siguiente frase: "Todo c�digo que pueda fallar debe tener una prueba". Adem�s, hay que tener en cuenta que se hacen una vez y luego se pueden reutilizar multitud de veces, incluso por otros desarrolladores que desconocen los entresijos de esa parte o de todo el sistema, por lo que permiten compartir c�digo (otra de las pr�cticas que permiten acelerar el desarrollo tal y como se ver� m�s adelante).
Esta forma de usar las pruebas unitarias ayuda a priorizar y comprobar la evoluci�n del desarrollo y que ofrecen realimentaci�n inmediata. Ya no hay imprescindibles dos equipos diferenciados que desarrollan y prueban cada uno por su cuenta. Ahora el ciclo se basa en implementar una prueba unitaria, codificar la soluci�n y pasar la prueba, con lo que se consigue un c�digo simple y funcional de manera bastante r�pida. Por eso es importante que las pruebas se pasen siempre al 100% [Jeffries].
Hay mucha literatura sobre las pruebas unitarias [Beck2][Gamma][Gamma2]. La mayor�a de los autores est�n de acuerdo en que cuanto m�s dif�cil sea implementar una prueba, m�s necesarias son. Algunos incluso dicen que entonces quiz�s sea porque lo que se intenta probar no es lo suficientemente sencillo y ha de redise�arse. En cuanto a herramientas para realizar tests unitarios, existen varias para los diferentes lenguajes, lo que hace que su ejecuci�n sea simple y, sobre todo, autom�tica [Impl].
Las pruebas unitarias no se han de confundir con las pruebas de aceptaci�n que han sido mencionadas con anterioridad. �stas �ltimas son pruebas realizadas por el cliente o por el usuario final para constatar que el sistema hace realmente lo que �l quiere. En caso de que existan fallos, debe especificar la prioridad en que deben ser solucionados los diferentes problemas encontrados. Este tipo de pruebas son pruebas de caja negra y se hacen contra las historias de los usuarios. Se suele tender a que sean parcialmente autom�ticos y que los resultados sean p�blicos.
Es hora entonces de ampliar el ciclo de creaci�n de pruebas unitarias, codificaci�n, paso de las pruebas y a�adirle un paso m�s: la integraci�n. La programaci�n extrema viene a perseguir lo que se ha venido a llamar integraci�n continua. De esta forma, haci�ndolo cada vez con peque�os fragmentos de c�digo, se evita la gran integraci�n final. Las ventajas de este enfoque es que permite la realizaci�n de pruebas completas y la pronta detecci�n de problemas de incompatibilidad. Adem�s, ya no ser� necesario un equipo independiente de integraci�n que haga uso del m�gico pegamento al enfrentarse a problemas de divergencias y fragmentaci�n de c�digo.
En todo desarrollo de programaci�n extrema deber�a existir, por tanto, una versi�n siempre integrada (incluso se puede asegurar su existencia mediante cerrojos - locks). La sincronizaci�n por parte de los desarrolladores con el repositorio central debe darse como m�nimo una vez al d�a, de manera que los cambios siempre se realicen sobre la �ltima versi�n. De esta forma nos podemos asegurar de que las modificaciones que hacemos no se est�n haciendo sobre una versi�n obsoleta.
Quiz�s el lector se haya sorprendido con la �ltima afirmaci�n y pensar� que la probabilidad de encontrarse una versi�n de c�digo obsoleta (m�s antigua que el c�digo actual) es muy baja. En cierto modo, esto es cierto en las metodolog�as tradicionales, pero en la programaci�n extrema no: nos topamos con la importancia de refactorizar [Fowler3]. Refactorizar consiste b�sicamente en quitar redundancia, eliminar funcionalidad que no se usa o "rejuvenecer" dise�os viejos. Tiene su justificaci�n principal en que el c�digo no s�lo tiene porque funcionar, tambi�n debe ser simple. Esto hace que a la larga refactorizar ahorre mucho tiempo y suponga un incremento de calidad. Por cierto, tal es el �nfasis que se pone en la refactorizaci�n que de la misma no se libran ni las pruebas unitarias.
Como uno de los objetivos de la programaci�n extrema es que cualquier miembro del equipo de desarrollo puede mejorar cualquier parte del sistema, llegamos f�cilmente a la conclusi�n de que se busca que el c�digo sea de todos. Cualquier desarrollador puede realizar cambios, corregir erratas o refactorizar en cualquier momento. Para eso, entre otras cosas, tenemos el colch�n de las pruebas unitarias por si nos equivocamos. Adem�s, es una forma coherente de plasmar que todo el equipo es responsable del sistema en su conjunto y de que no haya feudos personales. En consecuencia, un desarrollador que deje el proyecto (algo habitual, por otra parte) no tiene por qu� convertirse en un hecho catastr�fico. El mejor m�todo para conseguir que el c�digo sea de todos es seguir unos est�ndares de codificaci�n consistentes, de manera que la lectura (y refactorizaci�n) por parte del resto del equipo de desarrollo se facilite al m�ximo.
Para terminar esta, ya extensa, descripci�n de un proceso de desarrollo de programaci�n extrema, he dejado una de sus joyas para el final. El proceso de desarrollo no lo va a hacer un desarrollador en solitario, sino siempre con otra persona, algo que se ha venido a llamar programaci�n por parejas. Una pareja de desarrolladores debe compartir ordenador, teclado y rat�n. El principal objetivo es realizar de forma continua y sin parar el desarrollo una revisi�n de dise�o y de c�digo. Las parejas deben ir rotando de forma peri�dica para hacer que el conocimiento del sistema se vaya difundiendo por el equipo (facilit�ndose que el c�digo sea de todos), a la vez que se fomentan el entrenamiento cruzado[Jeffries2]. Existen estudios que concluyen que esta pr�ctica es eficaz en la pr�ctica justific�ndola con aspectos psicol�gicos y sociol�gicos [Cockburn]. Con este apoyo los gur�s de la programaci�n extrema no dudan en afirmar que dos personas trabajando conjuntamente en pareja generan en cantidad el mismo c�digo (o mejor dicho, la misma funcionalidad) que dos personas por separado, pero de mayor calidad. Sin embargo esta es la pr�ctica que m�s reticencias provoca por parte de jefes y de los propios programadores.
El proceso de desarrollo descrito en la secci�n anterior est� fundamentado en una serie de valores y principios que lo gu�an. Los valores representan aquellos aspectos que los autores de XP han considerado como fundamentales para garantizar el �xito de un proyecto de desarrollo de software. Los cuatro valores de XP son:
comunicaci�n,
simplicidad,
realimentaci�n y
coraje
Los partidarios de la programaci�n extrema dicen que son los necesarios para conseguir dise�os y c�digos simples, m�todos eficientes de desarrollo software y clientes contentos. Los valores deben ser intr�nsecos al equipo de desarrollo.
De los cuatro valores, quiz�s el que llame m�s la atenci�n es el de coraje. Detr�s de este valor encontramos el lema "si funciona, mej�ralo", que choca con la pr�ctica habitual de no tocar algo que funciona, por si acaso. Aunque tambi�n es cierto que tenemos las pruebas unitarias, de modo que no se pide a los desarrolladores una heroicidad, sino s�lo coraje.
Algunas voces, adem�s, a�aden un quinto valor: la humildad. Y es que con la que compartici�n de c�digo, la refactorizaci�n y el trabajo en equipo tan estrecho una buena dosis de humildad siempre ser� de agradecer.
Los principios fundamentales se apoyan en los valores y tambi�n son cuatro. Se busca
realimentaci�n veloz,
modificaciones incrementales,
trabajo de calidad y
asunci�n de simplicidad.
Los principios suponen un puente entre los valores (algo intr�nseco al equipo de desarrollo) y las pr�cticas, que se ver�n a continuaci�n, y que est�n m�s ligadas a las t�cnicas que se han de seguir.
Por su parte, las pr�cticas son las siguientes:
El juego de la planificaci�n (the planning game)
Peque�as entregas (small releases)
Met�fora (metaphor)
Dise�o simple (simple design)
Pruebas (testing)
Refactorizaci�n (refactoring)
Programaci�n por parejas (pair programming)
Propiedad colectiva (collective ownership)
Integraci�n continua (continous integration)
40 horas semanales (40-hour week)
Cliente en casa (on-site costumer)
Est�ndares de codificaci�n (coding standards)
No es f�cil aplicar una nueva metodolog�a en un equipo de desarrollo ya que obliga a aprender una nueva forma de trabajar. Tambi�n obliga a abandonar c�mo se hac�an las cosas antes, que aunque no fuera la mejor forma posible ya se conoc�a. XP ha sido adoptado por un gran n�mero de equipos en los �ltimos a�os y de sus experiencias se ha extra�do una conclusi�n sencilla: es mejor empezar a hacer XP gradualmente.
El proceso que recomiendan los autores de XP es el siguiente: identifica el principal problema del proceso de desarrollo actual. Escoge la pr�ctica que ayuda a resolver ese problema y apl�cala. Cuando ese haya dejado de ser un problema, escoge el siguiente. En realidad se recomienda que se apliquen las pr�cticas de dos en dos. El objetivo es que las pr�cticas de XP se apoyan unas a otras y por tanto dos pr�cticas aportan m�s que la suma de ambas y por tanto es m�s f�cil comprobar los resultados.
El objetivo final debe ser aplicar todas las pr�cticas, ya que representan un conjunto completo, "si no las aplicas todas no est�s haciendo eXtreme Programming".
Seg�n Kent Beck, "la programaci�n extrema es una forma ligera, eficiente, flexible, predecible, cient�fica y divertida de generar software" (Kent Beck, Extreme Programming Explained). Ah� es nada. Esta metodolog�a ha surgido desde la experiencia, como una forma de resolver los problemas encontrados en los procesos de desarrollo software en los que se han visto involucrados sus autores. Este tipo de desarrollos eran en general de creaci�n de software a la medida del cliente y hay numerosas opiniones que relatan el �xito de esta metodolog�a en este �mbito. Queda por ver si es posible aplicar sus ideas tambi�n en procesos de desarrollo muy diferentes, como el seguido por la comunidad del software libre.
En realidad, la definici�n de software libre es un concepto legalista, ya que la �nica diferencia entre el software propietario y el software libre es precisamente su licencia [Stallman]. Esto no es del todo cierto, porque se ha venido constatando en la �ltima d�cada que esta distinci�n tiene unos efectos secundarios que afectan a la manera en la que se entiende y en la que se genera el propio software. Podemos ver que la licencia condiciona la manera de buscar una forma eficiente de generaci�n y difusi�n del software.
Eric S. Raymond, gur� del software libre, se dio cuenta de ello en 1997 y en uno de sus famosos escritos catalog� el modelo de desarrollo de algunos (no todos) proyectos de software libre como el modelo de bazar [Raymond][Bezroukov]. Para Raymond la metodolog�a tradicional se pod�a comparar con la construcci�n de catedrales donde exist�a un gran arquitecto que hac�a el dise�o y el reparto de tareas, para que posteriormente un conjunto de operarios y peones realizaran las operaciones pertinentes. En el modelo de bazar, por el contrario, no existe ese orden tan estricto, sino que se asemeja m�s bien al caos que se forma en un bazar oriental. La manera de interactuar entre los diferentes actores en el caso del bazar no est� controlada por ning�n tipo de personas ni entidades, sino que existe una enorme cantidad de intereses y de intercambios de diferentes tipos (lo que los economistas que han estudiado el software libre han llamado transacciones [Ghosh][Lerner]).
Eric Raymond achac� la creaci�n de proyectos de software libre a necesidades e intereses particulares de los propios desarrolladores, que lanzan una aplicaci�n para resolver su problema y el de otras personas en id�ntica situaci�n. No es dif�cil imaginar entonces que en cada proyecto exista la figura del l�der, normalmente asociada a su fundador o a uno de sus principales promotores. El l�der del proyecto no necesita ser una persona dotada meramente de conocimientos t�cnicos, sino que debe tener habilidad para coordinar y motivar a todo aqu�l que est� interesado en unirse al proyecto realizando aportaciones. Esto es as�, porque el origen del redise�o suele situarse en los propios usuarios, que se revelan como los que hacen el trabajo de depuraci�n, probablemente el proceso m�s tedioso en la generaci�n de software. Se da el hecho de que una cantidad grande de usuarios permite procesos de depuraci�n en paralelo y que, en caso de existir errores, su correcci�n puede darse de forma distribuida, ya que el usuario que encuentra una errata no tiene por qu� ser el usuario/desarrollador que la corrige.
Para poder llevar a la pr�ctica de manera eficaz el que los proyectos sean lo m�s abiertos que se pueda, el modelo de bazar ha supuesto la elaboraci�n y perfecci�n de numerosas herramientas, incluso de sitios centralizados que intentan englobar todo el proceso de desarrollo, como son SourceForge y sus clones (BerliOS o Savannah). Las herramientas son, con mucha probabilidad, la mejor forma de ver y entender el desarrollo que sigue el software libre.
Uno de los principios b�sicos enunciados por Raymond, aunque no expresado precisamente de esta forma, es que el proceso de desarrollo debe ser lo m�s abierto posible. Una de las consecuencias es que cuantos m�s ojos hay mirando el c�digo mayor es la probabilidad de encontrar fallos antes [Raymond]. La herramienta que mejor se adapta a esta necesidad es un sistema de control de versiones abierto al p�blico. La �ltima versi�n (y todas las anteriores) del c�digo estar� disponible para todo aqu�l que lo desee. El sistema de control de versiones, al igual que todas las dem�s herramientas utilizadas, son herramientas que permiten la colaboraci�n de manera distribuida. Cualquier desarrollador en cualquier lugar del mundo podr� descargarse el c�digo y corregir una errata que haya encontrado.
En realidad, la idea de Raymond va m�s all�, ya que la "comunidad" que se crea alrededor de un proyecto no se forma por s� sola. Son necesarios una serie de acciones y mecanismos para que el proyecto sea conocido. De esta forma, se consiguen usuarios que son el primer paso para tener desarrolladores. Esta tarea, aunque no necesariamente t�cnica, implica gran cantidad de trabajo. Uno de los m�todos evocados por Raymond y proclamado incluso como principio por algunos es el famoso "release early, release often" (entrega pronto, entrega frecuentemente), que est� pensado para captar la atenci�n de una comunidad de usuarios (y desarrolladores) y mantenerla satisfecha con la evoluci�n de una aplicaci�n que satisfaga sus necesidades [Raymond].
La proliferaci�n del acceso a Internet ha hecho que el ciclo de desarrollo se sustente fuertemente en el uso de sus servicios, de manera que se consigue un grupo potencial de usuarios (y desarrolladores) mucho mayor. Las formas de comunicaci�n habituales son las listas de correo, abiertas a la suscripci�n de cualquiera que as� lo desee. Los mensajes de las lista de correo son almacenados en los llamados "archivos", lo que permite poder tener acceso a todas las decisiones y discusiones de la lista. De esta manera, todo queda plasmado por escrito. Tambi�n existen otros medios de comunicaci�n como pueden ser los canales de IRC.
SourceForge y otros portales especializados en sustentar la creaci�n de software libre lo que hacen es realizar las tareas de instalaci�n, configuraci�n y gesti�n de herramientas que permiten este tipo de desarrollos, de manera que un desarrollador que quiera crear un nuevo proyecto de software libre no se tenga que preocupar de tener que instalarse su propio software de control de versiones ni gestores de listas de correo-e. En definitiva, los desarrolladores de software libre pueden desarrollar y gestionar sus proyectos de manera que se aproveche la sinergia producida por un entorno de desarrollo lo m�s abierto posible.
Podemos concluir que el software libre per se no est� asociado a ninguna forma de desarrollo espec�fica, sino que se caracteriza por una serie de condiciones (legales) que un programa debe cumplir para ser considerado como tal. Sin embargo, la experiencia ha demostrado formas y m�todos por los cuales proyectos de software libre tienen m�s �xito y evolucionan m�s r�pido y mejor que otros, probablemente incluso mejor que el software propietario. La idea principal es aprovechar las caracter�sticas impuestas por las licencias para abrir el proceso de desarrollo al mayor n�mero de personas y aprovechar mecanismos de difusi�n predefinidos (independientes de los desarrolladores) para llegar a tener un amplio grupo de usuarios. Adem�s, la existencia de herramientas de colaboraci�n distribuida permiten aprovechar al m�ximo efectos sinerg�ticos.
A lo largo de las introducciones a la programaci�n extrema y al software libre hemos visto como algunas de las pr�cticas de la programaci�n extrema son intr�nsecas al desarrollo del software libre. Por contra, existe otra serie de pr�cticas que son de dif�cil implantaci�n o que generan serios interrogantes. Este apartado va a tratar sobre todo esto.
Antes de todo, es importante recordar que para Beck se est� haciendo programaci�n extrema si y s�lo si se siguen las doce pr�cticas, ninguna m�s ni ninguna menos [Beck][Jeffries3]. Fowler es m�s flexible en este sentido y prefiere hablar entonces de procesos influenciados por la programaci�n extrema [Fowler2]. Vemos que mientras el software libre es muy flexible en cuanto a su modelo de desarrollo (como ya hemos visto con anterioridad, en realidad es un concepto legal), la programaci�n extrema consta de un conjunto conocido y cerrado de pr�cticas. Esta caracter�stica har� que consideremos invariante la programaci�n extrema y veamos qu� cosas son las que pueden ser interesantes para el desarrollo de software libre.
Como veremos, la programaci�n extrema no puede ser implantada en su pr�ctica totalidad por el desarrollo de software libre. Por eso, retomando las palabras de Fowler, veremos hasta qu� punto se puede influenciar el software libre por los procesos de programaci�n extrema.
En un p�rrafo anterior se ha comentado que el software libre sigue de por s� algunas pr�cticas de la programaci�n extrema. Como son caracter�sticas ya adoptadas y ampliamente conocidas, no nos detendremos mucho en ellas.
La m�s evidente de las pr�cticas comunes es probablemente la propiedad colectiva del c�digo, caracter�stica esencial para la libertad del software. Al igual que en la programaci�n extrema, para facilitar el trabajo conjunto, se siguen uno est�ndares de codificaci�n que permiten una lectura r�pida y simple del c�digo, a la vez que independiza el c�digo de su autor. Un buen ejemplo en cuanto a est�ndares de codificaci�n es el proyecto PEAR, un repositorio de clases PHP [Jansen]. En muchos proyectos, las aportaciones de terceros no se aceptan, ni siquiera revisan, hasta que sigan los est�ndares establecidos. Que el c�digo sea comunitario en el software libre, como se ha dicho antes, no implica en muchas ocasiones que haya compartici�n de conocimiento total como se recomienda en la programaci�n extrema.
El paradigma "entrega pronto, entrega frecuentemente" del software libre encaja perfectamente con la idea de tener entregas frecuentes de la programaci�n extrema en busca de realimentaci�n. El que se haga hincapi� en hacer una primera entrega pronto encaja, por su parte, perfectamente con la idea de que se empiece por lo primordial y se dejen funcionalidades avanzadas para el futuro. A partir de ah� el proceso iterativo de probar, codificar, pasar pruebas y refactorizar de la programaci�n extrema se cumple parcialmente en el software libre. Mientras las pruebas unitarias todav�a se utilizan poco asiduamente, el proceso de tener peque�as iteraciones se cumple casi al pie de la letra, llegando incluso a tener proyectos con entregas diarias. La refactorizaci�n en s� no ocurre como tal, siendo lo m�s frecuente una simple correcci�n de erratas. Lo m�s frecuente es que se de el caso de que los usuarios hagan depuraci�n (paralela) y que ofrezcan realimentaci�n, ya sea con la soluci�n del problema o como un aviso para que el desarrollador principal o cualquier otra persona pueda corregirlo.
Al igual que existen ciertas pr�cticas de la programaci�n extrema muy arraigadas y en concordancia con el proceso de desarrollo mayoritario de software libre, existen otras cuyo seguimiento se puede pr�cticamente descartar.
La que se puede eliminar, sin lugar a dudas, es el requisito de que el equipo de trabajo deba tener una carga de trabajo razonable (40 horas). Los estudios realizados sobre desarrolladores de software libre demuestran que una gran mayor�a de los desarrolladores de software libre colaboran en proyectos en su tiempo libre. Se da la circunstancia de que un 80% le dedica menos de 15 horas semanales. Sin embargo, aunque esta pr�ctica est� dirigida a un entorno laboral, tambi�n es cierto que se basa en el hecho de que la capacidad creativa no se puede alargar m�s all� de un cierto tiempo. El desarrollador necesita una serie de condiciones para poder ejercerla en su m�xima expresi�n y una de ellas es que el ambiente laboral sea agradable.
En el caso de los colaboradores del software libre asumir esto es de perogrullo, ya que su colaboraci�n es en cualquier caso de manera voluntaria.
En conclusi�n, esta pr�ctica es de dif�cil adaptaci�n en el mundo del software libre, pero por otra parte tampoco es necesaria, porque los objetivos que persigue ya son alcanzados por otros medios de por s�.
El segundo punto es ya un poco m�s complejo de solucionar: la cliente en casa. Y lo es por partida doble, ya que no es que no podamos asegurar que est� en casa, es que en realidad no tenemos la certeza de tener clientes. De hecho lo que se tiene son usuarios. Sin embargo, la figura del usuario difiere en bastantes aspectos de la de cliente.
En com�n tienen que, tanto en el software libre como en la programaci�n extrema, se intente integrar al usuario/cliente en el equipo de desarrollo. En la programaci�n extrema esto se hace para agilizar la realimentaci�n, mientras que el software libre va m�s all� y tambi�n se ve la posibilidad de que el propio usuario termine formando parte del equipo de desarrollo, con el objetivo de que colabore tambi�n en tareas de depuraci�n, correcci�n y, con suerte, integraci�n.
Se diferencian en que en la programaci�n extrema, todo el desarrollo gira en torno a las historias de los usuarios. El cliente es la fuente de ingresos y merece, por consiguiente, todas las atenciones. El desarrollo de software libre es m�s ca�tico en este sentido. El usuario recibir� la funcionalidad que precisa si existe alg�n desarrollador que est� interesado en implementarla. El centro de decisi�n se ha trasladado en este caso hacia el desarrollador. Sin embargo, tambi�n es cierto que un usuario siempre tiene la posibilidad de pagar a un desarrollador para que aporte la funcionalidad al proyecto que satisfaga sus necesidades. Esto lo puede hacer incluso yendo en contra de la estrategia general del proyecto. Y es que una de las consecuencias econ�micas de las licencias de software libre es que imposibilitan el vendor lock-in, esa situaci�n donde es el fabricante de software (aqu�l que tiene la propiedad intelectual) el que decide de manera unilateral el rumbo que debe tomar el software, as� como lo que se puede hacer con �l [Barahona].
Tambi�n es cierto que en los grandes proyectos de software libre se hace un gran esfuerzo por conocer las necesidades de los usuarios para satisfacerles en pr�ximas entregas, aunque este proceso no se encuentre formalizado como en la programaci�n extrema mediante el uso de tarjetas CRC, cuya adopci�n sea probablemente de gran inter�s. El mecanismo habitual que tienen los usuarios para hacer peticiones a los desarrolladores suelen ser las listas de correo electr�nico del proyecto. La cercan�a del usuario es parcial.
Resumiendo, hemos visto que el software libre suele carecer de cliente como tal, aunque cuenta con la figura de usuario. Hemos tratado las diferencias existentes entre clientes y usuarios y las consecuencias que acarrean en el proceso de desarrollo. Tambi�n sabemos que a d�a de hoy, en el software libre no existen m�todos formales para capturar necesidades de los usuarios y comprobar que han sido satisfechas.
Como hemos visto en el apartado anterior, la falta de cliente har� que sea muy dif�cil que se pueda llevar a cabo el juego de planificaci�n que propone la programaci�n extrema. En realidad, podemos asegurar que tal y como se viene desarrollando el software libre en este aspecto es todav�a m�s extremo que el modelo de la programaci�n extrema, ya que prescinde seg�n los casos parcial o totalmente de este paso.
Los nuevos proyectos suelen crearse para satisfacer necesidades personales por parte de un desarrollador o un grupo de desarrolladores. En este miniestadio, el propio desarrollador suele ser a la vez el propio usuario, por lo que no necesita un proceso de formalizaci�n de historias de los usuarios. Seg�n va creciendo el proyecto, es probable que el juego de planificaci�n se haga m�s y m�s necesario, sobre todo si el n�mero de usuarios crece y el equipo de desarrolladores est� dispuesto a satisfacer las necesidades de los usuarios llegando incluso a realizar una planificaci�n temporal del mismo. Como en muchos de los puntos anteriores vemos que no existen herramientas ni mecanismos de software libre que permitan formalizar esto convenientemente.
La mejor aproximaci�n es quiz�s Bugzilla que permite ser utilizado adem�s de para la gesti�n de la generaci�n de informes de defectos y posterior correcci�n de los mismos, para organizar y repartir tareas entre el equipo de desarrollo. Otro m�todo ampliamente difundido es el uso de wikis, aplicaciones con interfaz web abiertas a la contribuci�n de todo el que las visite, aunque ciertamente es una soluci�n bastante primitiva. Herramientas como MrProject, un clon de la aplicaci�n para gesti�n de proyectos MS Project, pueden favorecer que esto mejore en un futuro pr�ximo.
Vemos que en lo que al juego de planificaci�n se refiere, el software libre es todav�a m�s extremo que la propia programaci�n extrema. Su ejecuci�n se retrasa hasta estadios en los que es verdaderamente necesaria, siguiendo la idea que aparece en otras partes de la programaci�n extrema: "si no lo necesitas ahora, no lo hagas".
La programaci�n por parejas es una de las piezas clave de la programaci�n extrema y que, sin embargo, parece que no tiene cabida en el mundo del software libre. Sin embargo, es posible que la programaci�n por parejas no sea tan �til en el software libre como lo puede ser en un proyecto en una empresa.
La revisi�n entre iguales, tanto de c�digo como de dise�o, que propicia el trabajo en parejas, es una pr�ctica que en muchos proyectos se da de por s�. El m�s conocido es el caso de Linux, donde se carece incluso de un repositorio CVS. Linus Torvalds quiere que todas las aportaciones de c�digo se manden a la lista de correo. No como adjunto al mensaje, sino incluso en el cuerpo del mensaje. De esta forma est� a la vista de todos y no es una pr�ctica poco habitual que los parches sean analizados y comentados por terceras personas en la propia lista.
Existen otros mecanismos no formalizados de aceptaci�n de colaboraciones de c�digo. Generalmente lo m�s com�n es que los desarrolladores principales sean los �nicos que tengan acceso de escritura al repositorio del sistema de control de versiones. Cualquier persona es capaz de descargarse la �ltima versi�n del mismo, pero tendr� que enviar a los desarrolladores principales el parche para que �ste sea incluido. Ser� tarea de estos �ltimos revisar la contribuci�n y verificar que sigue los par�metros de codificaci�n y dise�o pertinentes.
Otra ventaja adicional en el mundo de la empresa de tener dos programadores realizando tareas conjuntamente es por la alta movilidad laboral. Es bien sabido, que muchos proyectos pierden un tiempo valios�simo cuando uno de los integrantes del equipo deja el trabajo (una situaci�n que, por cierto, se ha dado con una pasmosa frecuencia en los �ltimos tiempos). La programaci�n por parejas intenta mitigar este efecto, ya que de los dos programadores se quedar� uno que tendr� el conocimiento suficiente sobre lo que estaba haciendo la pareja como para poder seguir adelante. Sin embargo, tambi�n en este caso, las condiciones que se dan en el desarrollo de software libre hacen que esto no sea tan problem�tico.
Vemos en definitiva, que a�n cuando la programaci�n por parejas se suple por otros medios, no existe un mecanismo formal que permita comprobar que los objetivos promulgados por la misma se cumplen.
En los siguientes puntos vamos a comentar las pr�cticas cuya adopci�n por parte del m�todo de desarrollo del software libre puede ser interesante. Es verdad que estas pr�cticas ya se encuentran m�s o menos arraigadas en diferentes proyectos, pero en opini�n del autor esta situaci�n no es suficiente y, por tanto, se debe fomentar su uso.
Las pr�cticas que se incluyen en este apartado no chocan frontalmente con el modelo actual de desarrollo de software libre, por lo que su adopci�n se facilita. En la mayor�a de los casos suponen m�s un cambio de costumbre en la forma de programar y utilizar la informaci�n que se maneja en un proyecto. Por contra, las consecuencias de este ligero cambio pueden suponer un sustancial aumento de calidad de las aplicaciones de software libre.
Las pruebas unitarias se deber�an implementar con mayor frecuencia. Aunque se puede considerar que es una t�cnica ya existente en los a�os 70, la programaci�n extrema puede hacer que se incremente su uso en los proyectos de software libre y, probablemente, que sea su mayor aportaci�n a la misma. Las pruebas unitarias no tienen por qu� hacerse estrictamente antes de codificar; al fin y al cabo es mejor tener pruebas, aunque sea con posterioridad, que no tenerlas.
Cuando un programador tiene que modificar c�digo que ha sido desarrollado por otra persona se corre un alto riesgo de que introduzca alguna errata (bug). Las pruebas unitarias reducen este riesgo dado que avisar�n al instante si algo deja de funcionar. Naturalmente para ello debe adquirirse el h�bito de ejecutar todas las pruebas del sistema tras hacer un cambio. En los proyectos de software libre, la reducci�n de este factor de riesgo es muy �til, dado que es muy habitual modificar c�digo escrito por otros.
Es probable que la introducci�n de las pruebas unitarias conlleve un cambio de filosof�a en el mundo del software libre. De la b�squeda heroica de erratas en la que se hace tanto �nfasis, se debe pasar a la implantaci�n de buenas maneras que redunden en c�digo menos proclive a tenerlos. En definitiva, se debe tener a desarrolladores con talento creando c�digo (que es probablemente lo que mejor hagan y m�s les estimule) en vez de repasando c�digo err�neo de otros.
En un futuro, esperemos que este tipo de pruebas puedan estar integradas en sistemas de control de versiones como el CVS. Quiz�s haya que esperar a que Subversion, la herramienta de siguiente generaci�n de control de versiones que todav�a se encuentra en fase de desarrollo, las implemente. De esta forma, las pruebas unitarias formar�an parte del sistema de control de versiones.
No nos debemos olvidar por otro lado de las pruebas de aceptaci�n. La mayor�a de los proyectos de software libre carecen en sus p�ginas web de informaci�n de hacia d�nde va el proyecto: las funcionalidades que ser�n a�adidas en un futuro pr�ximo, los cambios que se van a hacer, etc. Una buena forma de resolver esto y abrir el desarrollo a m�s desarrolladores podr�a ser la creaci�n de pruebas de aceptaci�n previas a la implementaci�n de la siguiente operaci�n que podr�n ser comprobadas al final de la misma, tal y como ocurren en los ciclos iterativos de la programaci�n extrema. Esto tambi�n puede utilizarse para saber las funcionalidades que son prioritarias para los usuarios.
El objetivo de la met�fora del sistema es proporcionar a todo el equipo una misma visi�n del fin del sistema y de su arquitectura general. Con ello se facilita que todos los desarrolladores hablen un mismo idioma y que nuevos desarrolladores lo adquieran m�s r�pido y integrarse en el proyecto sin dificultades. Este segundo aspecto es el que puede hacerla interesante para el software libre. La posibilidad de conseguir el c�digo en muchas ocasiones no rebaja suficientemente la barrera de entrada que existe para nuevas incorporaciones. De hecho, estoy seguro de que la informaci�n que se puede plasmar de manera concisa en la met�fora se encuentra dispersada en el c�digo y las listas de correo.
Plasmar la met�fora por escrito puede suponer, por tanto, una forma de revisar el propio dise�o del sistema por parte de los desarrolladores. Asimismo, ya que estamos hablando de un nivel de abstracci�n superior al de codificaci�n, puede alentar a la utilizaci�n de patrones de dise�o, una pr�ctica bastante desconocida en el mundo del software libre.
El uso de la met�fora junto con formas de documentaci�n de c�digo, del estilo de javadoc y similares, puede paliar en parte la falta de documentaci�n que existe en el mundo de software libre. Estas pr�cticas podr�an incluso llegarse a automatizarse parcialmente (de hecho javadoc es en s� una herramienta m�s que una forma de documentaci�n). Muchos adeptos a la programaci�n extrema se muestran contrarios a la utilizaci�n de estas maneras de crear documentaci�n del c�digo, ya que argumentan que el c�digo debe ser lo suficientemente simple como para poder ser entendido por s� mismo. Sin embargo, habr� que tener en cuenta que en muchas ocasiones para refrendar las interfaces de una clase o biblioteca puede ser muy �til, ya que el desarrollador puede no estar interesado en esa clase o biblioteca, sino en desarrollar una aplicaci�n que la utilice.
El principal objetivo de la refactorizaci�n es que en vez de corregir c�digo err�neo se reescriba, una idea contrapuesta a la b�squeda y caza de erratas que tanto han proclamado grandes gur�s del software libre. El nuevo c�digo, por su parte, debe tener un mejor dise�o: tiene que ser m�s simple y estar mejor estructurado que el anterior. Detr�s de esta idea, est� el convencimiento de que con la inclusi�n de pruebas unitarias, la correcci�n de erratas ser� muchas veces mucho m�s costosa que la propia reescritura.
Si se mantiene un sistema lo m�s simple posible se facilita que nuevos desarrollares entren en el proyecto y realicen aportaciones. Esta idea es la contraria al enfoque seg�n el cual lo primero es crear una gran infraestructura para que luego sea m�s f�cil a�adir funcionalidad. El principal problema es que en este caso no es necesario conocer esa infraestructura para poder aportar . M�s grave a�n es que no es posible crear una infraestructura que prevea todas las funcionalidades futuras, por lo que si no se refactoriza acabar� siendo un impedimento.
Con refactorizaci�n continua se podr�a evitar que aplicaciones enteras sean reescritas, porque los errores de dise�o, la calidad del c�digo y otros par�metros hacen imposible mantener la antigua versi�n.
El hecho de que el software libre se produzca mayoritariamente de forma distribuida hace indispensable un an�lisis un poco m�s exhaustivo de la implicaci�n que tiene la distribuci�n en las t�cnicas de programaci�n extrema. Para ello vamos a retomar algunos aspectos que ya han sido comentados, aunque poniendo ahora el �nfasis en su car�cter distribuido.
La generaci�n distribuida de software tambi�n es interesante desde un punto de vista netamente empresarial. La globalizaci�n de la econom�a mundial ha propiciado que exista un n�mero creciente de proyectos cuyo equipo de desarrollo, por razones econ�micas o personales, se encuentra distribuido geogr�ficamente.
La experiencia con los m�todos de desarrollo tradicionales ha demostrado que el esfuerzo dedicado a documentar pormenorizadamente o crear documentaci�n extra no ha incrementado la eficiencia comunicativa del equipo que trabaja de manera distribuida. Es m�s, en realidad, se ha visto que es contraproducente.
Por el contrario, nos encontramos con un dilema al intentar llevar a cabo algunas de las pr�cticas de la programaci�n extrema, ya que varias de ellas asumen proximidad f�sica. Es el caso de las siguientes pr�cticas:
Programaci�n por parejas
Integraci�n continua
Juego de planificaci�n
Cliente en casa
Esto ha dado paso a lo que se ha venido a llamar la programaci�n extrema distribuida (DXP - Distributed eXtreme Programming), que permite a los miembros del equipo estar en lugares geogr�ficos diferentes e incluso gozar de una gran movilidad. El m�todo se basa en aplicar los valores y principios de la programaci�n extrema, pero adapta las pr�cticas a un entorno de trabajo distribuido, de manera que se relaja la asunci�n de proximidad f�sica.
Es verdad que las tecnolog�as Internet han ayudado a que el trabajo distribuido sea posible, pero tambi�n es cierto que esas tecnolog�as que se usan (p�ginas web, IRC, listas de correo, bit�cora de cambios y documentaci�n -- ya sea generada manual o semiautom�ticamente) exist�an ya en los a�os 70. Aunque es constatable que estas tecnolog�as no pueden reemplazar la presencia en persona, el salto a las nuevas (y tan prometidas) formas de comunicaci�n como la videoconferencia no son accesibles al p�blico en general.
El software libre se ha caracterizado en los �ltimos a�os porque su proceso de desarrollo es flexible. El hecho de que queramos introducir varias t�cnicas nuevas para acentuar la calidad de las aplicaciones generadas, da pie a una serie de interrogantes y retos que habr� que ir solucionando.
El dise�o iterativo que promulga la programaci�n extrema choca frontalmente en muchos proyectos con la compatibilidad hacia atr�s. Quiz�s esto tambi�n sea una de las debilidades de la programaci�n extrema, ya que invita a realizar frecuentes entregas y dise�o iterativo pero no aborda la cuesti�n de mantener la compatibilidad hacia atr�s o de la migraci�n de datos de versiones anteriores. La programaci�n extrema est� orientada a satisfacer las necesidades de un cliente conocido donde este problema est� m�s controlado. Sin embargo dentro de la industria del software, y por supuesto con mayor frecuencia en el software libre, no es lo general ya que se dirigen a una gran multitud de usuarios finales. Es, por tanto, muy importante poder asegurar al usuario que el trabajo realizado con anterioridad con la aplicaci�n pueda ser manipulado por las nuevas versiones de la aplicaciones y en el caso de las librer�as que se mantengan las APIs durante al menos un tiempo de migraci�n.
Sin embargo, el mayor problema para utilizar los m�todos de la programaci�n extrema en el software libre son las dependencias. La programaci�n extrema asume que el proyecto se encuentra aislado en el mundo, una asunci�n que en demasiadas ocasiones no es cierta. Muchos desarrollos se basan en otros paquetes que a la vez se encuentran en fase de desarrollo y cuyas caracter�sticas cambian constantemente. En esta carrera es muy dif�cil mantenerse independiente y aislado del mundo exterior. Las pruebas de regresi�n y las pruebas unitarias pueden ser dos maneras de mitigar los efectos de las dependencias dentro del software libre.
Una de las cr�ticas a la programaci�n extrema es la dificultad de estimar cu�nto va a costar un proyecto, un problema asociado, por otra parte, tambi�n a las metodolog�as tradicionales. Es verdad que esto afecta en parte al software libre, ya que muchos proyectos no est�n ubicados en empresas ni tienen que generar una estimaci�n de costes. Por otro lado, ser�a interesante tener alguna forma de hacerlo de manera m�s o menos exacta para empresas que realizaran desarrollos de software libre.
Los efectos que puede causar la refactorizaci�n no est�n del todo claros. El hecho de tener menos l�neas de c�digo despu�s de refactorizar tiene un efecto psicol�gico negativo importante, adem�s de que siempre es doloroso tirar l�neas de c�digo.
A favor del software libre est� el hecho de que los desarrolladores se suelen adaptar r�pidamente a nuevas ideas, ya que ven el desarrollo de software libre como un buen laboratorio para t�cnicas novedosas. Esto no suele ser cierto en el mundo empresarial, mucho m�s inerte y pesado ante nuevos cambios, donde existe frecuentemente el llamado s�ndrome de "no lo hemos inventado aqu�".
Por supuesto, hay que tener en cuenta que gran parte del �xito en la adopci�n de t�cnicas de programaci�n extrema depender� de que se creen nuevas herramientas que las soporten o que las existentes integren los nuevos m�todos.
En general, podemos concluir que todav�a no existe la experiencia suficiente en proyectos de software libre para poder hablar de los efectos secundarios que provocar�a la adopci�n de las t�cnicas de programaci�n extrema.
A lo largo de este documento hemos visto c�mo el m�todo de desarrollo seguido mayoritariamente en el software libre y la programaci�n extrema tienen muchas caracter�sticas comunes. Por otro lado, existen una serie de pr�cticas (pruebas, met�fora y refactorizaci�n) que ser�a muy interesantes adoptar en el software libre, ya que conllevar�an un aumento de la calidad. Las pruebas permitir�n a los desarrolladores realizar modificaciones con la seguridad de que no rompen nada en otro lugar, la met�fora proporciona una visi�n intuitiva del sistema y la refactorizaci�n est� pensada para mejorar la calidad del c�digo. Estas tres iniciativas tienen como objetivo principal transformar el modelo de desarrollo que actualmente est� centrado en demas�a en encontrar y corregir erratas a una nueva forma de desarrollar en la que el dise�o iterativo y la codificaci�n tomen mayor relevancia. Dado que lo segundo es m�s divertido que lo primero no dudo que ser� muy provechoso en un entorno donde la mayor�a de los contribuidores lo hacen en su tiempo libre y de manera altruista.
A la vista de lo que se ha ido exponiendo parece ser que la mejor soluci�n para la adopci�n de t�cnicas de programaci�n extrema en el software libre es la existencia de un n�cleo que asegure las pr�cticas de la programaci�n extrema como peque�as entregas y que permitan tener un dise�o simple y controlado (un ejemplo de esto podr�a ser Linux, donde de facto esto ya existe m�s o menos de esta manera). Este grupo puede funcionar de por s� como un equipo de desarrollo distribuido, teniendo asignada entre otras tareas la de comprobar que las aportaciones exteriores cumplen los requisitos de calidad necesarios para ser integradas en el proyecto.
Otro aspecto interesante es que la programaci�n extrema ofrece m�todos formales para plasmar informaci�n que no existen de tal forma en el software libre. Ser�a interesante contar con dichos m�todos para que la barrera de entrada a nuevos desarrolladores sea m�s baja. Un ejemplo interesante de estos m�todos son las tarjetas CRC que permiten tener una idea intuitiva del proyecto en un espacio de tiempo muy corto sin tener que analizar concienzudamente la organizaci�n de ficheros y c�digo. Yendo m�s all�, se podr�a utilizar UML adem�s de las tarjetas CRC para especificar el dise�o de la aplicaci�n [Wills]. Es probable que esto supongo una redefinici�n del uso de las tarjetas CRC, ya que en la programaci�n extrema sirven s�lo para comunicarse en una reuni�n, careciendo despu�s de importancia como documentaci�n porque se asume que se quedar�n obsoletas enseguida.
En definitiva, se ha podido ver c�mo la programaci�n extrema puede aportar nuevas formas en busca de optimizar el modelo de desarrollo de software libre. El tiempo dir� si estas pr�cticas son asumidas por los diferentes proyectos de software libre y, en su caso, si realmente har�n gozar de las ventajas que se han presentado.
[Barahona] Jes�s Mar�a Gonz�lez Barahona "Software libre, monopolios y otras yerbas", http://sinetgy.org/~jgb/articulos/soft-libre-monopolios/
[Beck] Kent Beck "Extreme Programming Explained: Embrace Change", Addison-Wesley Pub Co; ISBN: 0201616416, 1a edici�n octubre 1999
[Beck2] Kent Beck & Erich Gamma "JUnit Cookbook", http://junit.sourceforge.net/doc/cookbook/cookbook.htm
[Bezroukov] Nikolai Bezroukov "A Second Look at the Cathedral and the Bazaar", http://www.firstmonday.dk/issues/issue4_12/bezroukov/
[Cockburn] Alistair Cockburn, Laurie Williams "Costs and Benefits of Pair Programming", http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
[Fowler] Martin Fowler "Is Design Dead?", http://www.martinfowler.com/articles/designDead.html
[Fowler2] Martin Fowler "Variations on a Theme of XP", http://www.martinfowler.com/articles/xpVariation.html
[Fowler3] Martin Fowler "Refactoring: Improve the Design of Existing Code", Addison-Wesley Pub Co, ISBN: 0201485672, 1a edici�n junio 1999
[Gamma] Erich Gamma & Kent Beck "JUnit A Cook's Tour", http://junit.sourceforge.net/doc/cookstour/cookstour.htm
[Gamma2] Erich Gamma & Kent Beck "JUnitTest Infected: Programmers Love Writing Tests", http://junit.sourceforge.net/doc/testinfected/testing.htm
[Ghosh] Rishab Aiyer Ghosh "Cooking pot markets: an economic model for the trade in free goods and services on the Internet", http://www.firstmonday.dk/issues/issue3_3/ghosh/
[Harrison] Peter Harrison "Evolutionary Programming", http://www.devcentre.org/research/evoprogramming.htm
[Impl] Implementaciones de tests unitarios para diferentes lenguajes y plataformas "Testing Frameworks", http://www.xprogramming.com/software.htm
[Jansen] Martin Jansen, Tom�s V.V. Cox & Alexander Merz "PEAR Coding Standards", http://pear.php.net/manual/en/standards.php
[Jeffries] Ron Jeffries "Essential XP: Unit Tests at 100", http://www.xprogramming.com/xpmag/expUnitTestsAt100.htm
[Jeffries2] Ron Jeffries "Essential XP: Junior / Senior Pairing", http://www.xprogramming.com/xpmag/pairing.htm
[Jeffries3] Ron Jeffries "They're called Practices for a reason", http://www.xprogramming.com/xpmag/PracticesForaReason.htm
[Lerner] Josh Lerner & Jean Tirole "The Simple Economics of Open Source", http://www.idei.asso.fr/Commun/Articles/Tirole/simpleeconomics-July-24-2001.pdf
[Raymond] Eric S. Raymond "The Cathedral and the Bazaar", http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
[Stallman] Richard Stallman "The Free Software Definition", http://www.fsf.org/philosophy/free-sw.html
[Wills] Alan Cameron Wills "UML meets XP", http://www.trireme.com/whitepapers/process/xp-uml/paper.htm
Relaci�n de libros sobre Ingenier�a del Software, patrones (patterns) y Programaci�n Extrema (Extreme Programming, XP), http://www.ctv.es/USERS/pagullo/biblio/ingenieria_del_software.htm
Donnovan Wells "Extreme Programming: A gentle introduction", http://www.extremprogramming.org
Allison Pearce Wilson "Extreme Programming", http://www-106.ibm.com/developerworks/library/it-aprcc01/?dwzone=ibm
chromatic "An Introduction to Extreme Programming", http://linux.oreillynet.com/lpt/a//linux/2001/05/04/xp_intro.html
Andrew McKinlay "Extreme Programming and Open Source Software", http://www.advogato.org/article/202.html
Ron Jeffries "Manuals in Extreme Programming", http://www.xprogramming.com/xpmag/manualsInXp.htm
Kent Beck "Simple Smalltalk Testing: With Patterns", http://www.xprogramming.com/testfram.htm
Leigh Dodds "XP Meets XML", http://www.xml.com/pub/a/2001/04/04/xp.html
Varios autores (Wiki) "Combining Open Source And Xp", http://c2.com/cgi/wiki?CombiningOpenSourceAndXp
Armin Roehrl & Stefan Schmiedel "Absolut extrem!!! Extreme Programming und Open Source Entwicklung" (alem�n), http://www.entwickler.com/le/ausgaben/2001/10/artikel/2/online.shtml
Proyecto Gesti�n Libre de Hispalinux, http://gestion-libre.hispalinux.es
Jorge Ferrer "Extreme Programming y Software Libre - Aprendiendo una metodolog�a de software 'tradicional'", http://www.jorgeferrer.com/doctorado/xp-y-sw-libre/
An�nimo (Visi�n sarc�stica de la XP) "RiP: Programmer Invents New Methodology", http://www.bad-managers.com/rumours/story021.shtml