Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

Agilidad y desarrollo de Software Libre



    Traducción: Rafael Martínez
    Martínez (Grupo de
    Lengua e
    Informática de ATI)

    1.
    Introducción

    2. Principios ágiles en el
    Software Libre

    3. Valores y principios de XP en el
    Software Libre

    4. Conclusiones

    Autores

    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.

    1.
    Introducción

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.

    4.
    Conclusiones

    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.

    Autores

    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.

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter