PDF de programación - Desarrollo en comunidad con eXtreme Programming

Desarrollo en comunidad con eXtreme

Programming

Jos¶e Dapena Paz

[email protected]

Igalia, C/Gutenberg 34B, 2o, A Coruña 15008, Spain,

[email protected],

WWW home page: http://www.igalia.com

Resumen El objetivo de esta contribuci¶on es la descripci¶on de buenas
pr¶acticas y herramientas para el desarrollo de software libre, centr¶ando-
nos en aquellas que facilitan la participaci¶on de la comunidad. Dentro de
estas t¶ecnicas, se profundizar¶a en las metodolog¶‡as ligeras, y en particu-
lar, en eXtreme Programming. A continuaci¶on se detallar¶an herramien-
tas y t¶ecnicas que permiten mejorar la comunicaci¶on en un proyecto de
software libre, tanto con desarrolladores, como con usuarios, as¶‡ como
mejorar su visibilidad.

1.

Introducci¶on

El modelo de Bazar, documentado por Eric S. Raymond en su libro La ca-
tedral y el Bazar (ver [1]), y de enorme popularidad en el mundo del software
libre, describe c¶omo un modelo iterativo de desarrollo, llevado por una comu-
nidad descentralizada, pod¶‡a llevar adelante un proyecto de software de gran
complejidad.

El texto de Raymond se centra en dos ejemplos: el n¶ucleo del sistema opera-
tivo Linux, y la utilidad para obtener correos remotos Fetchmail. El primero es
un proyecto de enorme complejidad y tamaño, que ha sido realizado con contri-
buciones de multitud de desarrolladores, bajo la direcci¶on (a veces ejecutiva, a
veces con menor implicaci¶on) de Linus Torvalds. El segundo, Fetchmail, fue desa-
rrollado por ¶el mismo, como prueba experimental de c¶omo funciona el desarrollo
en comunidad, y por tanto se utiliza de ejemplo principal.

El modelo de Bazar, tiene un conjunto de caracter¶‡sticas especiales, dentro
de los procedimientos de desarrollo de software. La principal es la enorme dis-
persi¶on de los desarrolladores, y la dedicaci¶on impredecible de ¶estos al proyecto.
Veremos durante el art¶‡culo c¶omo se puede aprovechar este hecho para facilitar
la creaci¶on de buenos proyectos, mediante la mejora de las infraestructuras y la
comunicaci¶on.

1.1. Mitos del desarrollo en comunidad

El planteamiento de Bazar, en el que un proyecto se desarrolla a partir de
las contribuciones (voluntarias o no) de un conjunto suflciente de personas, da
lugar a varios mitos y falacias:

El software libre est¶a desarrollado por aflcionados.
Desarrollo hacker, y soluciones ad hoc. Ausencia de metodolog¶‡as.
El ¶exito de un proyecto es m¶as casualidad que algo predecible.
Es imposible implantar medidas para el control de la calidad de un proyecto.

De forma resumida, todos estos puntos se resumen en uno: el mito de que es
imposible hacer Ingenier¶‡a del software libre, y productos de calidad profesional.
En los siguientes puntos expondr¶e los motivos para considerar que estos mitos

no tienen un fundamento real.

1.2.

>Cosas de aflcionados?

Si bien es cierto que los proyectos de software libre que tienen un cierto ¶exito,
tienen una participaci¶on signiflcativa de voluntarios y aflcionados, los productos
de m¶as ¶exito de software libre no se hacen por amor al arte.

La gesti¶on y elaboraci¶on de un proyecto es una tarea extremadamente com-
pleja, que exije un alto nivel de dedicaci¶on y conocimientos. Un proyecto puede
llegar a ser complejo y grande en la medida en que existe suflciente gente que
puede dedicar su tiempo completo a ¶el. Los n¶ucleos de los principales y m¶as
conocidos proyectos de software libre son llevados por profesionales, flnancia-
dos por universidades o empresas. Estos profesionales se dedican a sus tareas a
tiempo completo.

Por tanto, el desarrollo de un proyecto puede tener un coste econ¶omico sig-
niflcativo, debido a la necesidad de remunerar a un conjunto de desarrolladores.
La dedicaci¶on a tiempo completo suele exigirlo (<de algo tiene que vivir el desa-
rrollador!).

La b¶usqueda de flnanciaci¶on es un aspecto muy importante a tener en cuenta
para el desarrollo de un proyecto de software libre, por tanto. Fundaciones y
organizaciones sin ¶animo de lucro, pueden actuar como mediadoras para captar
la flnanciaci¶on de diferentes entidades.

Proyectos como Gnome y Apache son gestionados por fundaciones. Y el peso
de la direcci¶on y gesti¶on de estos proyectos es llevado por profesionales que
trabajan para diferentes entidades.

1.3.

>Sin metodolog¶‡a?

Si observamos los principales proyectos de software libre, nos encontramos
que a medida que van madurando se incorporan t¶ecnicas y m¶etodos altamente
considerados en la ingenier¶‡a del software. Esto no es casual.

El desarrollo en comunidad ha permitido que el software libre incorpore como
normales t¶ecnicas y herramientas de ingenier¶‡a de software como la gesti¶on de
requisitos, control de versiones, repositorios de incidencia, utilizaci¶on de patrones
de diseño y an¶alisis, y m¶ultiples formas de mejorar la comunicaci¶on entre los
desarrolladores.

Si bien es cierto que existe una fuerte componente ad hoc en las soluciones
iniciales, las comunidades de desarrolladores con necesidades heterog¶eneas llevan
a refactorizaciones excelentes, para poder cubrir las necesidades de todos.

1.4. El ¶exito no es casual

El ¶exito de un proyecto de software libre se basa principalmente en conseguir
una comunidad activa de desarrolladores y usuarios. Este ¶exito no es casual, y
existen m¶etodos para facilitar que suceda.

La t¶ecnicas que facilitan el incremento de la base de usuarios y desarrolladores
son una mezcla de Marketing y la gesti¶on de una infraestructura adecuada. Hay
que saber vender el proyecto, y es fundamental cuidar a los posibles interesados.

1.5. Se puede controlar la calidad

Es un hecho que hay muchos proyectos de software libre que responden mejor

a los requisitos de calidad que productos propietarios validados.

Esto se debe a que la comunidad del software libre ha desarrollado t¶ecnicas
que gestionan de forma transparente la calidad, a trav¶es de la gesti¶on de errores,
control de versiones, m¶etricas, autodocumentaci¶on o pruebas.

En los principales proyectos de software libre podemos encontrar la implan-

taci¶on de las mejores t¶ecnicas de control de calidad.

1.6. A continuaci¶on

Durante este art¶‡culo describir¶e algunas t¶ecnicas y m¶etodos que permiten

obtener un proyecto de software libre de ¶exito, y de gran calidad.

2.

eXtreme Programming

En esta secci¶on describir¶e un enfoque metodol¶ogico que encaja muy bien en el
desarrollo de proyectos de software libre en comunidad muy popular, denominado
eXtreme Programming.

eXtreme Programming es un conjunto de t¶ecnicas y pr¶acticas para el de-
sarrollo de software. Se encuadra dentro de la familia de metodolog¶‡as ligeras,
tratando de obtener m¶etodos sencillos de obtener software de calidad.

Sus principios b¶asicos son dos: la mejora de la comunicaci¶on con los usuarios,
para retroalimentar el proceso de desarrollo; y obtener cuanto antes un programa
que haga algo, partiendo de ¶esto para ir añadiendo incrementalmente nuevas
caracter¶‡sticas.

Estos objetivos encajan exactamente con los de el desarrollo de software
libre en comunidad. La mejora de los mecanismos de comunicaci¶on es una forma
excelente de cuidar a la comunidad de usuarios y desarrolladores. Y el segundo
punto coincide con el release early, release often del modelo de Bazar: es m¶as
f¶acil conseguir adeptos cuando hay algo que se pueda usar e instalar. Y lanzar
versiones nuevas con frecuencia aumenta la visibilidad p¶ublica del proyecto.

Estas t¶ecnicas se aplican a proyectos con un equipo de desarrollo medio-
grande, para solucionar un problema no trivial. Algunas de las medidas que
proponen no tienen sentido para proyectos pequeños. La propia formulaci¶on de
¶esta recomienda que no se apliquen aquellas que van a entorpecer el proyecto.

Las t¶ecnicas de eXtreme Programming (XP a partir de ahora) se dividen en

cuatro ¶ambitos: planiflcaci¶on, diseño, codiflcaci¶on y pruebas.

2.1. Planiflcaci¶on

En el ¶ambito de planiflcaci¶on de un proyecto, las t¶ecnicas que se sugieren son

las siguientes:

1. Historias de usuarios. El desarrollo es dirigido por una descripci¶on informal
de las necesidades de usuarios (dos o tres frases), que se denominan histo-
rias. Orientan el proceso de desarrollo (los objetivos que se planiflcan son
el cumplimiento de estas historias), y las pruebas de aceptaci¶on (se pueden
establecer m¶etodos m¶as o menos formales para veriflcar que ya se cubre una
historia. Una historia se divide en varias tareas planiflcables y medibles en
su estado de realizaci¶on.

3.

2. Sacar nuevas versiones con frecuencia. Es necesario deflnir un plan de ver-
siones, con una estricta planiflcaci¶on temporal. Una vez que se decide cu¶ando
se lanzar¶an versiones, se decide qu¶e historias se van a implementar en cada
versi¶on. Este plan indicar¶a, por tanto, diferentes iteraciones del proyecto y
qu¶e se debe implementar en cada una de ellas. La realizaci¶on de este plan de-
be tener en cuenta en la medida de lo posible, las prioridades de los usuarios,
para satisfacerles en mayor medida.
Iteraciones. Se recomienda un proceso de desarrollo iterativo de ciclo corto.
El primer objetivo es obtener algo funcional cuanto antes. Una vez que se
consigue, se comienza a implementar de forma incremental nuevas historias
de usuario en las sucesivas iteraciones, tal y como indica el plan. Un aspecto
importante es que al desarrollar una iteraci¶on, los desarrolladores se deben
centrar en los objetivos de esa iteraci¶on, y no en los de las pr¶oximas. Las
especiflcaciones de iteraciones futuras pueden cambiar, y por tanto podemos
llegar a hacer un trabajo innecesario. Por tanto, mejor es centrarse en im-
plementar estrictamente lo que se pide en la iteraci¶on actual, y conflar en la
refactorizaci¶on para incluir caracter¶‡sticas en el futuro. Es importante hacer
notar que los objetivos de las iteraciones se replaniflcan al principio de cada
una, para permitir ajustar en mayor medida ¶estas a la realidad del proyecto.
4. Trabajo en equipo. Es deseable cambiar a los desarrollad