Programación eXtrema y Software Libre

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.

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.

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 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.