Traducción: Rafael Martínez
Martínez (Grupo de
Lengua e
Informática de ATI)
2. Principios ágiles en el
Software Libre
3. Valores y principios de XP en el
Software Libre
Resumen: las
metodologías de desarrollo
ágiles y el Software Libre
son enfoques muy conocidos para el desarrollo de software. Aunque
son muy diferentes, presentan muchas concordancias como, por
ejemplo, los principios y
valores
básicos. En particular, hay muchas analogías entre
el desarrollo de Software Libre
y la programación extrema (enfoque al código
e inclusión de cambios, por citar algunas). Este
artículo presenta estos principios y valores
básicos e identifica las concordancias entre ambas
metodologías.
Palabras claves: metodologías
ágiles, programación extrema, Software
Libre.
Las metodologías ágiles (AMS, Agile
Methods) se han desarrollado con mucho éxito
en los últimos años [3] al igual que el Software
Libre (SL) [1][8]. Aunque estos enfoques de desarrollo de
software parecen muy diferentes, presentan muchas concordancias,
como demostró Koch [11].
Tanto las AMs como el SL empujan hacia una organización menos formal y
jerárquica en el desarrollo de software y más
centrada en la persona, con un
énfasis mayor en:
– centrarse en el objetivo
principal del desarrollo — producir un sistema de
gestión con la cantidad correcta de
funcionalidades. Esto significa que el sistema final tiene que
incluir sólo el mínimo número de
características necesarias para satisfacer por completo
al cliente
real.
– eliminar actividades que se relacionaron con algunos
documentos
'formales' de especificaciones que no tienen una
relación directa clara con el resultado final del
producto.
Este enfoque está claramente vinculado a la
"gestión ligera" ( Lean Management) [16].
Las AMs reconocen explícitamente sus
vínculos con la gestión ligera [13], mientras que
el SL los mantiene implícitos. Más aún, el
desarrollo de software mediante las AMs o el SL parecen similares
bajo varios puntos de vista, como éstos:
1. Los orígenes de ambos enfoques son bastante
antiguos, pero ahora se han revitalizado con renovado interés,
como reconoce explícitamente Beck [4] para las AMs (en
particular la programación extrema — XP, eXtreme
Programming) y prueba Fuggetta para el SL [10].
2. Ambos son rompedores [6], en el sentido de que
alteran valores establecidos en la producción de software.
3. Ambos han tenido éxito, mientras que
enfoques más tradicionales han fallado (el proyecto C3
para AMs [4] y el navegador de Mozilla/Firefox para el SL
[7][12])).
4. Los promotores de las AMs también
están participando en el desarrollo del SL (por ejemplo,
Beck con JUnit). Este artículo aspira a proporcionar una
visión general de las concordancias entre las
metodologías ágiles (XP, eXtreme Programming, en
particular) y el SL desde el punto de vista de los principios
fundamentales y de los valores
que ambas comunidades comparten.
El artículo está organizado como sigue: la
sección 2 identifica los principios ágiles
generales para el SL; la sección 3 se centra en los
valores y principios específicos de XP y los identifica en
el campo del SL; finalmente, la sección 4 traza las
conclusiones y propone posteriores investigaciones.
2. Principios ágiles
en el Software Libre
Los principios básicos compartidos por todas las
AMs están enumerados en el llamado Agile Manifesto [2]. La
tabla 1 identifica los principios de las AMs en el SL.
En conjunto, es evidente que el SL adopta muchos de los
valores fomentados por los partidarios de las AMs. Tales evidencias
reclaman un análisis subsecuente para determinar el
grado y la profundidad de dicha adopción.
Por otra parte, las AMs y el SL son clases de métodos de
desarrollo de software que incluyen un amplio número de
métodos específicos.
Por tanto, es importante considerar los casos
específicos para determinar cómo se dan realmente
en la práctica las interacciones entre las AMs y el SL,
más allá de consideraciones que, por sí
solas, resultan bastante inútiles al final.
3. Valores y principios de XP en
el Software Libre
En general, además de las concordancias entre el
SL y las AMs, es interesante analizar estas relaciones entre el
SL y una de las más populares metodologías
ágiles: la programación extrema (XP, eXtreme
Programming). XP está centrada en cuatro valores
principales (hay una exposición
my amplia en las dos ediciones del libro de Beck
[4][5]):
1. Comunicación Comunicación: los
desarrolladores necesitan intercambiar información e ideas sobre el proyecto, a
los directivos, y a los clientes de
forma honrada, confiable y fácil. La información
debe fluir de manera continua y rápida.
2. Sencillez Sencillez: siempre que sea posible hay
que elegir soluciones
simples. Esto no significa estar equivocado o aplicar enfoques
simplistas. Beck utiliza a menudo el siguiente aforismo "
simple pero no demasiado simple ".
3. Retroalimentación
Retroalimentación: en todos los niveles las personas
deberían obtener una retroalimentación muy
rápida sobre lo que hacen. Los clientes, los directivos
y los desarrolladores tienen que alcanzar una
comprensión común de la meta del
proyecto, y también acerca del estado
actual del proyecto, sobre qué necesitan realmente los
clientes en primer lugar primero y sobre sus prioridades, y
qué desarrolladores pueden hacerlo y en que tiempo. Esto
está fuertemente conectado con las comunicaciones. También debería
haber una retroalimentación inmediata del trabajo que
está haciendo la gente, es decir, del código que
se está produciendo – todo lo cual exige pruebas,
integraciones, versiones y entregas frecuentes.
4. Valor Valor:
cada persona implicada en el proyecto debería de tener
el valor (y el derecho) de expresar su valoración sobre
el proyecto. Todos deberían de tener el valor de ser
abiertos y dejar que todos examinasen e incluso modificasen su
trabajo. Los cambios no deberían ser vistos con terror y
los desarrolladores deberían tener el valor de encontrar
mejores soluciones y modificar el código siempre que sea
necesario y factible. Estos valores están presentes de
varias maneras en la descripción de Raymond de Open Source
[14], resumidos en la tabla 2 2. Por otra parte, según
lo observado en [9], ocultos en el interior de la primera
versión del libro de Beck [4] hay 15 principios,
divididos en 5 principios fundamentales y otros 10
principios.
Tabla 1. Principios de las
AMs en el Software Libre.
Los principios fundamentales son:
1. Retroalimentación rápida rápida:
volviendo al valor de la retroalimentación, ésta
debería ocurrir tan pronto como fuera posible, tener el
impacto más alto en el proyecto y limitar lo más
posible las interrupciones potenciales.
2. Asumir la sencillez sencillez: según lo
mencionado, la sencillez es un valor muy importante. Por lo
tanto, la sencillez debería ser asumida en todas las fases
del desarrollo.
3. Cambios incrementales incrementales: el cambio (en su
mayor parte procedente de la retroalimentación) no
debería hacerse todo de una vez. Por consiguiente
debería ser un proyecto permanente e incremental, dirigido
a crear un sistema evolutivo.
4. Adopción del cambio cambio: el cambio
debería ser manejado con valor y no ser evitado. El
sistema en su totalidad, y el código, debería ser
organizado para facilitar el cambio más amplio
posible.
5. Calidad del
trabajo trabajo: la calidad debería ser la principal
preocupación. La carencia de calidad genera revisiones y
derroches que deberían ser evitados en la mayor medida
posible. Otros principios de XP son:
- Enseñe a aprender aprender: la
identificación de requisitos es un proceso de
aprendizaje
global. Por lo tanto, el aprendizaje
es de suma importancia en el sistema. - b. Inversión inicial pequeña
pequeña: el trabajo
previo debería ser lo más escaso posible, puesto
que subsiguientes cambios pueden destruirlo. - Jugar a ganar ganar: todos los desarrollos
deberían ser guiados por la clara convicción de
qué lo que hacemos es realmente factible. Experimentos
concretos concretos: las ideas deberían no ser validadas
a través de discusiones largas y teóricas sino
vía experimentaciones concretas en el código
base. - Comunicación abierta, honesta honesta:
la
comunicación debería ser siempre simple y
fácil. El cliente no debería ocultar sus
prioridades ni los desarrolladores y directivos deberían
ocultar el estado
actual del trabajo.
6. Trabajar con los instintos de la gente – no contra
ellos ellos: el papel de los directivos es obtener lo mejor de
los desarrolladores, así que deberían explotarse
las inclinaciones naturales de éstos. Un espíritu
de equipo fuerte debería ser aprovechado. Por otra parte,
en las relaciones entre los directivos, desarrolladores y
clientes no deberían ignorarse los miedos, ansiedades e
incomodidades sino ser manejados correctamente.
7. Aceptar responsabilidades responsabilidades: todo el
personal del
proyecto (clientes, directivos y desarrolladores) debería
aceptar voluntariamente sus propias responsabilidades. Tales
responsabilidades deberían entonces ser asignadas con
completa confianza.
8. Adaptación local local: la metodología debería ser adaptada
sabiamente a las necesidades de cada contexto de
desarrollo.
9. Viaje con poco equipaje equipaje: en los proyectos XP es
importante mantener la mínima cantidad de documentos
posible, evidentemente sin comprometer la integridad del
proyecto.
10. Honradez en las métricas métricas: el
proyecto debería ser seguido con métricas objetivas
y comprensibles. Las métricas deberían ser
recogidas mediante un procedimiento
ligero que no altere la naturaleza de
XP.
En esta sección repasamos la aplicación al
código abierto de los principios fundamentales: la
retroalimentación rápida, aceptar la sencillez,
cambio incremental, aceptar los cambios, la calidad del trabajo.
Hemos discutido ya la aplicación de la re-
retroalimentación troalimentación y la sencillez
desde punto de vista de Beck. Fowler [9] comparte gran parte del
punto de vista de Back y hace énfasis en la mejora
continua del código fuente creado para que sea tan
sencillo como sea posible. Respecto a los cambios incrementales
incrementales,
Raymond [14] los reconoce abiertamente como uno de sus
principios guía desde su temprana experiencia con Unix: " He
estado predicando durante años el evangelio de Unix de
herramientas
pequeñas, prototipado rápido y programación
evolutiva ".
En lo que se refiere a aceptar los cambios propuestos
por otros, hemos ya mencionado la opinión de Raymond [14]
sobre la necesidad de escuchar a los clientes incluso si no " te
pagan en dinero".
Raymond [14] llega más lejos y en la regla número
12 declara el papel central de la aceptación del cambio: "
a menudo, las más llamativas y más innovadoras
soluciones vienen de darse cuenta que tu concepto del
problema era incorrecto ".
Raymond [14] va más lejos que Beck [4] en esta
materia. Ambos
están de acuerdo en que los prototipos ( spikes en la
jerga de Beck) pueden ser muy útiles para alcanzar una
mejor comprensión de un dominio de
aplicación complejo. Raymond [14] también proclama
que el sistema que se está desarrollando puede ayudar a
identificar nuevas ideas para nuevos desarrollos – regla
14: " cualquier herramienta debería ser útil de la
manera prevista, pero una herramienta verdaderamente grande lleva
por si misma a usos que usted nunca esperó ". Es
innecesario decir que cuando redactó el borrador de la
regla 14 Raymond [14] no se preocupó de asegurar al
cliente que no malgastará sus recursos.
Respecto al trabajo de calidad calidad, en Raymond [14]
no hay una referencia explícita al rol esencial de la
calidad como lo hay en [4]. Sin embargo, a lo largo de su
ensayo hay una
evidencia constante del orgullo que los desarrolladores de
código abierto depositan en su código, un orgullo
que proviene únicamente de la calidad del trabajo
realizado.
Ahora dirigimos nuestra atención a los otros principios:
enseñe a aprender; inversión inicial
pequeña; jugar a ganar; experimentos concretos;
comunicación abierta, honrada; trabajar con los instintos
de la gente personal – no contra ellos; aceptación de
responsabilidades; adaptación local; vieaje con poco
equipaje; honradez en las métricas.
Raymond acentúa el rol de escuchar y aprender de
los comentarios de los otros. Sin embargo, no hay una
mención explícita a aprender a enseñar
enseñar.
Tabla 2. Valores de XP en el
Software Libre.
Hay también poca preocupación por no tener
una pequeña inversión inicial y viajar con poco
equipaje equipaje. La razón es que los proyectos de
código abierto son dirigidos sobre todo por
desarrolladores, menos inclinados a emplear siglos en la "
parálisis del análisis" o en producir documentación inútil y están
más preocupados por entregar código útil. La
atención de Raymond [14] se concentra más bien en
probar que se requiere poco trabajo previo. " Cuando empiezas a
construir una comunidad, lo que
necesitas es ser capaz de presentar una promesa plausible. Tu
programa no
tiene que funcionar especialmente bien. Puede ser primitivo,
plagado de errores, incompleto y pobremente documentado. Lo
qué se tiene que hacer sin falta es (a) ejecutarlo y (b)
convencer al resto de potenciales desarrolladores de que puede
evolucionar hasta convertirse en algo realmente bueno en un
futuro previsible ".
Jugar a ganar y los experimentos concretos son una parte
integral de cualquier esfuerzo automotivado, así que no es
necesario extenderse en la explicación. Si hablamos de
valores, es evidente el papel que Raymond [14] otorga a una
comunica- comunicación ción abierta y honrada
honrada. Al ser un enfoque centrado en el desar-rollador, el
código abierto también aboga por trabajar con los
ins- instintos tintos de la gente – no contra ellos y
confía en la aceptación de
responsabilidades.
Las primeras dos reglas de Raymond son " Todo buen
trabajo de software se inicia rascando el picor personal de un
desarrollador", y los " Los buenos desarrolladores saben
qué escribir. Los grandes saben qué reescribir (y
reutilizar)". La regla 4 parece también bastante
aplicable: " Si tienes una actitud
correcta los problemas
interesantes te encontrarán".
Si bien no hay una métrica formal en el ensayo de
Raymond [14], sí que hay un énfasis en hacer
entregas de código con frecuencia, de tal manera que
queden claros el estado del proyecto y los errores todavía
existentes. Esto se asemeja a la honradez en las métricas
métricas.
En conjunto, observamos que hay un nivel
considerablemente alto de solapamiento entre los valores
adoptados por las AMs (XP en particular) y los de desarrollo de
código abierto según Raymond. La
comunicación, la retroalimentación y la sencillez
son apoyadas completamente por ambos enfoques.
El valor también se supone implícitamente
al realizar un proyecto de código abierto. Yendo a los
principios, hay también un buen nivel de acuerdo en los
principios fundamentales, aparte de la calidad que se da por
supuesta en el trabajo de Raymond, aunque no abogue por
ella.
En cuanto a los "demás principios" de XP, las
únicas diferencias vienen de los diferentes puntos de
vista: Raymond trata sobre todo con voluntarios, mientras que
Beck lo hace con empleados. Conceptos tales como viaje con poco
equipaje, poco trabajo previo, etc., no preocupan particularmente
a Raymond, que, por otra parte, está más interesado
en que los desarrolladores de código abierto realicen por
lo menos un poco de trabajo previo.
En cuanto a las prácticas, la situación es
claramente diferente. Las prácticas relacionadas con el
proceso, el entendimiento compartido y el bienestar del
programador son un tanto similares en los dos casos. Las
prácticas relacionadas con una cuidadosa
retroalimentación no están tan extensamente
presentes en la descripción de Raymond.
Como nota final, nos gustaría poner de manifiesto
que ambas experiencias, la de Beck y la de Raymond, proceden de
un uso temprano de lenguajes de
programación de muy fácil uso, expresivos y
poderosos: Smalltalk y Lisp, respectivamente. Un análisis
del papel de los lenguajes de programación en las AMs y en
el desarrollo de SL podía ser un tema interesante para
otro estudio.
Alberto Sillitti es Doctor en Ingeniería y Profesor
Adjunto en la Libera Università di Bolzano
(Italia).
Participa en varios proyectos financiados por la Unión
Europea en el área de la Ingeniería del
Software relacionados con las metodologías ágiles y
el software de código abierto. Sus áreas de
investigación incluyen la Ingeniería
del Software, la Ingeniería del Software basada en
componentes, la integración y métricas de los
servicios
web,
metodologías ágiles y código
abierto.
Giancarlo Succi es Doctor en Ingeniería,
Profesor de Ingeniería del Software y Director del Centro
para Ingeniería Aplicada del Software en la Libera
Università di Bolzano (Italia). Sus áreas de
investigación incluyen las metodologías
ágiles, el desarrollo de código abierto,
Ingeniería empírica del Software, líneas del
producto de software, reutilización del software e
Ingeniería del Software aplicada a Internet. Es autor de
más de 100 artículos publicados en conferencias y
revistas internacionales, así como de un libro.
Novática, revista de ATI
(Asociación de Técnicos de
Informática)
Alberto Sillitti, Giancarlo Succi
Freie Universität Bozen / Libera Università
di Bolzano (Italia)
Referencias
[1] P. Abrahamsson, O. Salo, J. Ronkainen.
Agile software development methods, VTT Publications,
2002. <http://www.inf.vtt.fi/pdf/publications/
2002/P478.pdf> [accedido el 15 de junio de 2005].
[2] Agile Alliance, Agile Manifesto, 2001.
<http:/ /www.agilemanifesto.org/> [accedido el de junio de
2005].
[3] L. Barnett. "Teams Begin Adopting Agile
Processes". Forrester Research, noviembre 2004.
[4] K. Beck. Extreme Programming Explained:
Embracing Change, Addison Wesley, 1999.
[5] K. Beck. Extreme Programming Explained:
Embracing Change, Second Edition, Addison Wesley,
2004.
[6] C.M. Christensen. The Innovator’s
Dilemma, Harper Business, 2003.
[7] M.A. Cusumano, D.B. Yoffie. Competing on
Internet Time: Lessons From Netscape & Its Battle with
Microsoft, Free Press, 1998.
[8] J. Feller, B. Fitzgerald. Understanding
Open Source Software Development, Addison-Wesley,
2002.
[9] M. Fowler. Principles of XP, 2003.
<http:// www.martinfowler.com/bliki/PrinciplesOfXP.html>
[accedido el 15 de junio de 2005].
[10] A. Fuggetta. "Open Source Software –
an Evaluation", Journal of Systems and Software, 66(1),
2003.
[11] S. Koch. "Agile Principles and Open Source
Software Development: A Theoretical and Empirical Discussion",
5th International Conference on eXtreme Programming and Agile
Processes in Software Engineering (XP2004), Garmisch-
Partenkirchen, Germany, 6 – 10 June, 2004.
[12] S. Krishnamurthy. "The Launching of Mozilla
Firefox – A Case Study in Community-Led Marketing",
2005. <http://opensource.mit.edu/papers/ sandeep2.pdf>
[accedido el 15 de junio de 2005].
[13] M. Poppendieck, T. Poppendieck. Lean
Software Development: An Agile Toolkit for Software Development
Managers, Addison Wesley, 2003. [14] E.S. Raymond.
The Cathedral and the Bazar, Version 3.0, 2002.
<http://www.catb.org/~esr/
writings/cathedral-bazaar/cathedral-bazaar/> [accedido el 15
de junio de 2005]. Publicado también por O’Reilly en
2001.
[15] M.B. Twidale, D.M. Nichols D.M. (2005).
""Exploring Usability Discussions in Open Source Development",
38th Hawaii International Conference on System Sciences,
2005. <http:// csdl.computer.org/comp/proceedings/hicss/2005/
2268/07/22680198c.pdf>.
[16] J.P. Womack, D.T. Jones. Lean Thinking:
Banish Waste and Create Wealth in Your Corporation, Revised
and Updated, Free Press, 2003.