Metodología ágil de desarrollo de software extremo (AMS_XP) y software libre (OSS) (página 2)
Enviado por Adrian Anaya Villegas
Un modelo de desarrollo ágil, generalmente es un proceso Incremental, (pequeños y frecuentes releases o entregas con ciclos rápidos), también Cooperativo (Clientes y desarrolladores trabajan constantemente con una comunicación muy fina y constante), sencillo (El método es fácil de aprender y modificar para el equipo, es bien documentado por medio de libros o la Web) y finalmente adaptativo (capaz de permitir cambios de último momento).
En el 2001 en Utah-EEUU en la reunión de los 17 expertos de la industria del software, nace el término "ágil" aplicado al desarrollo de software. Incluyendo algunos de los creadores o impulsores de metodologías de software.
Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
Lista de los17expertosparticipantesenel manifesto ágil [3].
Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades d esarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y reconocimiento.
Tras esta reunión se creó The Agile Alliance[2]una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto Ágil [3], un documento que resume la filosofía "ágil".
Las características de las metodologías ágiles pueden explicarse a través de los siguientes cuatro principios fundamentales:
Los individuos e interacciones son más importantes que los procesos y las herramientas: dado que el proceso de desarrollo es creativo, no es posible pensar que las personas funcionen respondiendo a órdenes, a procesos rígidos.
Que el software funcione es más importante que la documentación exhaustiva: puesto que si el software no funciona la documentación no vale de nada. A nivel interno puede haber documentación, pero solo la necesaria y a nivel externo lo que el cliente requiera.
La colaboración con el cliente es más importante que la negociación de contratos: supone que la satisfacción del cliente con el producto será mayor, mientras exista una conversación y realimentación continúa entre éste y la empresa.
La respuesta ante el cambio es más importante que el seguimiento de un plan: puesto que si un proyecto de software no es capaz de adaptarse a los cambios fracasará, especialmente en productos de gran envergadura. La estrategia de planificación se basa en: planes detallados para las próximas semanas, planes aproximados para los próximos meses y muy generales para plazos mayores.
PREFERIMOS | DESCONFIAMOS |
A las personas y su comunicación | Los procesos y las herramientas |
El software que funciona | La documentación exhaustiva |
La colaboración con el cliente | La negociación contractual |
La respuesta al cambio | Seguimiento de un plan |
Esencia del manifesto ágil [3].
Los métodos ligeros o agiles son otra opción para el desarrollo, muy aplicado y además presenta adeptos y gurús en contra, algunos expertos mencionan que los procesos agiles son una moda y quedaran ahí, sin embargo existen empresas que desde hace tiempo utilizan y han evolucionado gracias a dichos métodos.
A continuación un grafico con una lista importante de empresas que usan metodologías de desarrollo ágil en algunos de sus proyectos.
Empresas que usan metodologías agiles en desarrollo[3]
En la actualidad se cuentan alrededor de 15 a 20 metodologías agiles sin contar los métodos híbridos de desarrollo que integran en sus practicas como ejemplo a Xp con Scrum. A continuación el listado de metodologías agiles en desarrollo de software más representativas con el año de creación, acrónimo y autor.
Metodologías que se basan en procesos rápidos, pensados en ser funcionales, adaptables y además manejan similitudes entre ellos y pueden complementarse o formar métodos híbridos.
Metodologías ligeras vs métodos tradicionales
Aunque las metodologías ligeras se basan en las ideas de los procesos tradicionales estas usan lo mas importante para el buen desarrollo del proyecto con lógica y dejando atrás el manejo excesivo de artefactos y burocracia.
Diferencias entre métodos agiles y metodologías tradicionales.
Desde el surgimiento de estas revolucionarias metodologías que no solo nacen para el desarrollo de sistemas software sino para el management o desarrollo de productos los incrementos en adeptos se presentan gradualmente con el tiempo y las tecnologías.
Y los que las usan, ¿Por qué razón o razones lo hacen?:
Para reducir el tiempo de desarrollo: 45%
Para mejorar la calidad: 43%
Para reducir costes: 23%
Para alinear el desarrollo con los objetivos de negocio: 39%
Otras razones: 12%.
¿Y cuál es el ranking de preferencias entre modelos ágiles?1º.- Extreme Programming (28%)2º.- FDD (26%)3º.- Scrum (20%)4º.- Crystal (6%) ágil5º.- DSDM (4%)Fuente: Agile Journal [2], nº1, Marzo-2006.
Logo [1].
Una de los métodos mas representativos dentro de las metodologías llamadas ligeras que lleva al extremo las prácticas para la consecución de sistemas funcionales y que cumplan las características del usuario cliente, surge como respuesta a la sobre planificación a la hora de generar software. Esta basada en la simplicidad, la comunicación, la retroalimentación y la refactorización de código.
"Un proceso ligero, de bajo riesgo, Flexible, predecible, científico y Divertido de desarrollar software"
(Kent Beck, Extreme Programming Explained)
"Una metodología ágil que requiere gran disciplina" (Allistair Cockburn)
Actividades de desarrollo Xp
El proceso de desarrollo SW se divide en cuatro tipos de actividades:
. Planificación
. Diseño
. Codificación
. Pruebas
Kent Beck nombra, "Las raíces de Xp se encuentran en la teoría de los sistemas complejos" Haciendo referencia a la teoría del caos aplicada en desarrollo de sistemas.
La Xp es una Idea relativamente nueva surgiendo y siendo aplicada en el proyecto C3 (Chrysler, 1996) gracias a Kent Beck, (Libro: "extreme Programming eXplained", 2000), adecuada para proyectos pequeños (2-20 personas), utilización de tecnologías orientadas a objetos y uso de lenguajes modernos.
Valores que fomenta la filosofía XP:
Comunicación
Simplicidad
Retroalimentación
Coraje
Actores
Programador (Programmer)
Responsable de decisiones técnicas
Responsable de construir el sistema
Sin distinción entre analistas, diseñadores o codificadores
En XP, los programadores diseñan, programan y realizan las pruebas
Cliente (Customer)
Es parte del equipo
Determina qué construir y cuándo
Escribe tests funcionales para determinar cuándo está completo un determinado aspecto
Entrenador (Coach)
El líder del equipo – toma las decisiones importantes
Principal responsable del proceso
Tiende a estar en un segundo plano a medida que el equipo madura
Rastreador (Tracker)
Metric Man
Observa sin molestar
Conserva datos históricos
Probador (Tester)
Ayuda al cliente con las pruebas funcionales
Se asegura de que los tests funcionales se ejecutan
Proceso
Captar requisitos
User Stories
Methaphor
Planificar
Release planning
Iteration planning
Desarrollar
Programming
Presentar la entrega
Prácticas clave en XP
1. El juego de planificación (The planning game)
2. Entregas pequeñas (Short releases)
3. Metáfora (Metaphor)
4. Diseños simples (Simple designs)
5. Pruebas (Testing)
6. Refactorización (Refactoring)
7. Programación en parejas (Pair programming)
8. Dominio colectivo del código(Collective code ownership)
9. Integración contínua (Continuous integration)
10. Semana de 40 horas (40-hour week)
11. Cliente in situ (On site customer)
12. Estándares de codificación (Coding standard)
Costo en desarrollo vs tiempo (Xtreme Programming)
En la práctica se observa que el enfoque tradicional con respecto al tiempo incrementa los costes en el proceso de desarrollo análisis, Diseño, Implementación, Integración, pruebas, producción y capacitación del sistema.
Grafica Coste Tiempo (enfoque tradicional vs Xp)
Mientras que la programación extrema al manejar los principios y practicas con pocos artefactos, entregas continuas, juego de planificación, retroalimentación con el cliente en casa, metáforas de desarrollo, estándares de programación, 40 horas semanales, programación en parejas, stand up meeting, tarjetas CRC, pruebas unitarias y refactorización disminuye el tiempo de desarrollo e implementación obteniendo un producto conocido por el usuario y a su medida, cabe resaltar que Xp no es recomendado para proyectos grandes y equipos amplios.
Teoría de caos en metodologías
Una situación inesperada o imprevista y no controlada puede servir para probar como se organizan los sistemas para cumplir con un fin común (sinergia)[4], y solucionar un problema. Ejemplo de esto es como lo nombra Billy Reynoso[6 ] en el acontecimiento del 11 de septiembre que conmociono al mundo en Manhattan Estados Unidos, generando unos procesos y practicas para unir individuos quienes actuaron de forma rápida y eficaz organizándose para controlar y salvar vidas.
En sistemas de software libre podemos mencionar a grupos de desarrolladores alrededor del globo uniéndose, integrándose con un mismo fin de solucionar problemas software o encaminar un proyecto de Sl. A esta aplicación la podemos retomar como orden a partir del caos.
Como se comenta en el documento publicado en el sitio Http://www.monografias.com llamado DESARROLLO DE SOFTWARE BAJO METODOLOGIAS AGILES (Agile Methods XP) EN LA PRACTICA[5]haciendo referencia a la conformación de equipos de trabajo:
Los grupos de trabajo de desarrolladores que se conforman solos, se organizan autónomamente o auto conforman, funcionan en el desarrollo de proyectos con mejores resultados y obtienen mejores logros, ya que se conocen, forman un ambiente o entorno acorde para trabajo e interacciones con el cliente buenas. Los equipos que son conformados sistemáticamente enfrentan problemas desde el inicio, desarrollo y fin de un proyecto, ya que desconocen el manejo de trabajo en el grupo nuevo mientras se acoplan al equipo.
En el desarrollo de sistemas Oss se presenta que una gran cantidad de desarrolladores conocen el problema, codifican e integran continuamente desde distintos puntos remotos, generando un orden a partir del caos, un orden gratis, "de una cantidad de variables aleatorias surge implícitamente un orden en un determinado tiempo", se auto organiza el proceso de generación de sistemas software, obteniendo resultados de eficiencia, calidad, confiables y con el tiempo expandibles.
Tanto en los procesos del SL como en los Ams están orientados o se permiten practicas de reutilización de código, en Metodologías ligeras se retoma el código de otros programadores y se complementa, corrige o refactoriza, además se usan en estos dos enfoques paterms o patrones de diseños, en el SL o OSS igualmente programadores desarrollan usan, corrigen, refactorizan a menor escala y entregan su código a una comunidad.
Raymond cataloga el modelo de desarrollo del software libre como un modelo donde no existe un orden estricto de creación, sino que se trata más de un caos en el desarrollo, tema al que se hará referencia en próximos títulos dentro de este documento.
La interactuación entre diferentes actores no es controlada por ningún tipo de persona o entidad como en otros métodos, sino que lo que prima es una gran cantidad de "intereses e intercambios de distintos tipos".
Raymond desde la experiencia manejada con Unix comenta, " He estado predicando durante años el evangelio de Unix de herramientas pequeñas, prototipado rápido y programación evolutiva", filosofía acorde a Sl y Ams.
Según [6], el desarrollo final de un sistema 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 ejecutarlo y convencer al resto de potenciales desarrolladores de que puede evolucionar hasta convertirse en algo realmente bueno en un futuro previsible.
Ejemplo de esto es cuando un usuario software requiere un sistema y no posee los medios o facilidades y busca como otra opción de calidad los sistemas Open Source Software para llenar sus requerimientos o necesidades, ayudar y desarrollar lo que se desea, genera una satisfacción y se obtienen beneficios por estos servicios y en la mayoría de los casos los sistemas desarrollados son acordes a los frutos esperados.
En el proceso de desarrollo OSS los desarrolladores hacen de cliente y desarrollador al mismo tiempo, por este motivo y por que se ve al Sl como términos para licenciar sistemas y una manera colaborativa de desarrollar Sw de calidad con incrementos pequeños y frecuentes no se toma como una recopilación de buenas prácticas de ingeniería de software.
Cuando se habla de OSS se hace referencia a rapidez, proyectos que se establecen con rapidez, igual que los requerimientos, los detalles del diseño se revisan en línea, el código es escrito por pequeños grupos de desarrolladores agiles, las pruebas son un proceso rápido y colaborativo y la retroalimentación es abundante e instantánea.
El Oss es catalogado como incremental gracias a la distribución temprana y frecuente de releases, son testeadas las entregas pequeñas frecuentemente por la comunidad de desarrollo por lo que se puede deducir que los dos enfoques que tratamos son de tipo incremental.
Dos de los precursores de sistemas Oss son Richard Stallman en el área Filosófica fundador y el señor Linus Trovals aplicando, comunicando y desarrollando el software Libre como el SO Linux, dichos visionarios influyeron en la generación de una especie de revolución como ya se mencionaba en procesos y practicas de desarrollo.
Trovals se refiere a la filosofía del desarrollo Sl como "release early, release often", traducido "entrega pronto, entrega frecuente", esta idea del Sl encaja adecuadamente con la práctica de realizar entregas frecuentes de la Xp buscando la retroalimentación. De esta forma se complementan los dos párrafos anteriormente nombrados.
Richard Stallman cabe resaltar que inicio su labor sobre GNU UNIX en la década de los 80´s y por ende estableciendo la FSF [5] en el año de 1985 como punto de inicio del movimiento OSS.
Igualmente el personaje codificador de XP Kent Beck participaría en proyectos de software libre como el de Junit para Java.
El origen de los enfoques ágil y libre son bastante antiguos y como nombra Beck [4] estos se han revitalizado y su interés aumentado para procesos agiles especialmente Xp, y lo prueba Fuggetta [4] para el Sl.
Herramientas de desarrollo que sustentan el Oss
Internet: Tecnología que sustenta el ciclo de desarrollo de procesos de Sl, debido a la mencionada herramienta el aumento de practicas Oss ha aumentado exponencialmente con el tiempo.
Cvs abiertos al publico: SourceForge y sus clones berliOs o Savannah,
Sitios especializados en sustentar la creación de software libre y 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.
Características intrínsecas de Xp en el Sl.
La propiedad colectiva del código es una práctica esencial que rodea ambos enfoques en el que los programadores y equipo de trabajo manejan y aplican para dar un deseado fin a sus intereses.
El paradigma de "entrega pronto, entrega frecuente" ya mencionado propuesto por Linus Trovals, hace referencia en el Sl y encaja con la idea de entregas frecuentes en desarrollo Xp.
Características de difícil aplicación
Carga de trabajo de 40 horas semanales: Se recomienda dentro de las practicas de Xp una carga razonable de trabajo de mínimo 40 horas de desarrollo, en ocasiones esporádicas que se necesite sobrepasar el tiempo de trabajo se recomienda no ser continuas esta acumulación de tiempo según la metodología Xp.
Las encuestas y 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. Un 80% le dedica menos de 15 horas semanales al desarrollo. 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. Basado en [7].
Debido al desarrollo distribuido que usamos en Oss las practicas mas difíciles de implementar o implantar son las de proximidad física como programación en parejas, integración continua, juego de planificación y el antes mencionado cliente en casa, debido a lo anterior surge DXp (DISTRIBUITED ESTREME PROGRAMMING), permitiendo a los miembros del equipo estar ben lugares geográficamente dispersos y de movilidad, este método se basa y aplica los valores y principios de de la Xp pero adaptada a practicas y a un entorno de trabajo distribuido disminuyendo la interacción física.
The planning game, el juego de la planificación: Se dificulta a razón de la ausencia del cliente como tal. Además los proyectos son desarrollados para satisfacer necesidades e intereses personales, se observa que no hay historias como las manejadas en el método ágil que tratamos.
La programación en parejas es una práctica ausente o de muy difícil aplicación para realizar en proyectos Sl debido a que los participantes del sistema se encuentran divididos alrededor del globo y en distintos usos horarios.
Al criterio del autor otra práctica dentro del desarrollo es el manejo de tarjetas CRC al interior de una comunidad Oss.
Prácticas de interesante aplicación
Pruebas unitarias y de aceptación: la implementación de pruebas con frecuencia es muy común, ya que se practican de forma unitarias e informando a la comunidad pertinente, los sistemas CVS facilitan la integración de pruebas ayudando a integrar pruebas de aceptación antes de las de implementación.
Técnica existente desde la década de los 70´s, Se recomienda la implementación de testing unitarios y de aceptación con mayor frecuencia en el desarrollo de los proyectos.
Prácticas interesantes
La metáfora es aplicable en los dos enfoques ya que se aplica intrínsecamente y los nuevos desarrolladores se adaptan de forma temprana y eficaz en la mayoría de veces
El uso de patrones de diseño: Muy usados en métodos tradicionales y Ams pero bastante desconocidos en el Sl.
Mejoras en la falta de información que existe en el software: En Oss los desarrolladores usan estándares de programación y comentan el código de forma adecuada para que próximos colaboradores o el mismo continúe con el desarrollo del proyecto, en programación ágil XP se propone que el código desarrollado sea tan simple, manejable y entendible como para no usar comentarios, aunque en ocasiones y en la practicas se extiende la programación y al realizar pausas se ve la necesidad para tener guías para comunicarse entre desarrolladores vía comentarios.
La refactorización es aplicada en muchos aspectos buscando la calidad, el código erróneo se recomienda reescribirlo antes que corregirlo.
La compatibilidad hacia atrás y dependencias es una debilidad que se genera al desarrollar con Xp en el que se realizan entregas frecuentes y diseño iterativo pero no aborda la compatibilidad hacia atrás o migración de datos de versiones anteriores.
Los interrogantes a nivel económico y psicológico en cuanto a la dificultad de estimar cuanto va a costar un proyecto, a nivel de Sl hay ausencia en los procesos de estimación ya que son inexactos para los proyectos.
La tabla muestra una comparación entre las metodologías de desarrollo de SW ágiles y OSS, teniendo en cuenta las áreas o dimensiones de análisis. Observando esta tabla, vemos que el OSS tiene varios puntos en común con los métodos ágiles. Tomado de [7].
Comparativa entre los métodos de retroalimentación con el cliente
Existen diversidad de formas de comunicarse o retroalimentar ideas en el desarrollo de sistemas para obtener información sobre la empresa, los procesos, manejo empresarial, tecnologías usadas, organigramas .Etc.
En procesos De software libre la comunicación tiende y se basa en las tecnologías de la World Wide Web o internet, Correo electrónico, video conferencia, IRC, sistemas Cvs, Chats, foros, grupos y más, potenciando y agilizando los procesos para propuestas de proyectos, desarrollo, correcciones y entregas del mismo.
En desarrollos de tipo tradicional se observan varios métodos para realizar comunicación, en los Mt (métodos tradicionales) se observa que un equipo por lo general trabaja distante al cliente, reuniéndose cada mes o tres meses dependiendo el proyecto y los pactos, además se pueden presentar interacciones vía video tape, por teléfono entre otros.
En Ams y refiriéndose a Xp el tipo de comunicación se propone se presente a diario con el usuario cliente y con reuniones extras a estas frecuentemente.
A continuación se presenta una gráfica mostrando los distintos tipos de comunicación propuesto por Alistair Cockburn [6]y su efectividad en la práctica.
Métodos de comunicación más Eficaces en desarrollos
Describiendo según la imagen anterior que las personas que intercambian las ideas ya sea cliente – equipo de trabajo o desarrollador- desarrollador de manera" Face to Face" o cara a cara, obtienen una eficaz comunicación, y buena retroalimentación para el buen desarrollo de algún proyecto.
Las comunicación vía teléfono, Video tape, email o cartas quedan en un nivel inferior de calificación para obtener una rica y eficaz comunicación para interactuar con los miembros que participan en un proyecto software.
La agilidad de un proyecto se ve afectada en gran parte por los modos de interacción con el usuario interesado por obtener un software, tanto en métodos tradicionales como métodos de Oss se puede captar que las interacciones con el cliente se dan a mas baja escala por el tipo de comunicación usada, mientras que en Sl el cliente es parte fundamental e importante del equipo de trabajo, sintiéndose este parte y generando un lazo en el que se proporciona toda la información requerida y a medida del desarrollo el final es mas parecido a lo que el desea, generando satisfacción por los proceso seguidos.
El software libre es un concepto legalista, ya que una de las diferencias entre el software propietario y el software libre es su licencia [Stallman]. 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.
Es software libre los términos de la licencia se pueden consultar en la Web de la FSF [4].
Los actores que intervienen en el uso, creación y participación de perspectivas Oss adquieren o reciben libertades como:
Hacer uso de los sistemas como mejor le parezca y donde mejor le parezca.
Redistribuirlo a quien quiera y por los medios que quiera.
Realizar modificaciones, mejoras o adaptaciones.
Hacer distribuciones de modificaciones.
La Licencia Pública General permite a cualquiera trabajar en sistemas Sl, Ejemplo Linux. Puede ser vendido, como así también copiado sin costo o restricción alguna. Este tipo de licencia de software libre requiere que si se realiza un cambio o agregado al código GPL, éste debe permanecer bajo los mismos términos de GPL, de manera que ningún desarrollador gane alguna ventaja encima de otros contribuyentes del desarrollo.
Bajo la GPL el derecho de propiedad de Linux puede ser sostenido por Linus Torvalds y otros pero ellos no tienen ningún otro derecho para restringir el uso de él.
The GNU General Public License
A continuación le mostramos la Licencia Publica General GNU (La GPL1 o
copyleft 2), a la cual está sometido el Linux. Se reproduce aquí para aclarar algunas de las confusiones que se dan sobre el estado del copyright de
Linux_Linux no es shareware, y no está en el dominio público. El grueso del
Núcleo de Linux está bajo copyright Oc1993 de Linus Torvalds, y otro software y partes del núcleo están bajo copyright de sus autores. En este caso, Linux
tiene copyright, sin embargo, Ud. Puede distribuirlo en los términos de la GPL
que se imprime a continuación en su versión original.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright Oc1989, 1991 Free Software Foundation, Inc. 675 Mass Ave,
Cambridge, MA 02139, USA everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed3.
La programación extrema puede aportar nuevas formas de buscar y optimizar el modelo de desarrollo de software libre.
Pruebas, metáfora y refactorización son prácticas que serian interesantes plasmar mas formalmente en el desarrollo libre ceñido a la aplicación de Xp.
Los resultados en distintos proyectos del paradigma del Sl demuestran que es un complemento valioso a los múltiples métodos de desarrollo de software en los últimos años.
Los enfoques de métodos de agilidad y de Sl tienen la distinción de que los últimos operan de modo geográficamente distribuido y por ende se toma al cliente en los procesos Oss como un codesarrollador.
Raymond hace referencia en el Sl a los voluntarios, mientras que Beck lo hace con empleados. [6] se interesa más en que los desarrolladores de código abierto realicen por lo menos un poco de trabajo previo.
Referencias
[1] Web Programación extrema
Http:// www.programacionextrema.org
[2] Revista electrónica sobre metodologías de desarrollo de software:
Http:// www.agilejournal.com
[3] Documento que resume la filosofía ágil Manifiesto ágil:
http://www.agilemanifesto.org
[4] A. Fuggetta. "Open Source Software – an Evaluation",
Journal of Systems and Software, 66(1), 2003.
[5] Free software fundation, software libre y términos de licencia.
http://www.fsf.org
[6] Reynoso Billy Carlos. Métodos Agiles en Desarrollo de Software, Introducción a la Arquitectura de Software. Universidad de Buenos Aires.
billyr@microsoft.c om.ar
http://www.microsoft.com/spanish/msdn/arquitectura.
[7] Open source software y metodologías agiles ¿Qué tanto se parecen?
cjacuna[arroba]dit.upm.es, Curso de Software Libre (2002-2003)
Doctorado en Informática y Modelización Matemática
Universidad Rey Juan Carlos.
Http://www.agile-spain.com, tiene como objetivo dar a conocer las metodologías agiles en español.
[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] E.S. Raymond. The Cathedral and the Bazar, Version 3.0, 2002. [accedido el 15 de junio de 2005]. Publicado también por O"Reilly en 2001.
[7] Programación eXtrema y Software Libre, Gregorio Robles, Universidad Rey Juan Carlos, Jorge Ferrer.
http://es.wikipedia.org/wiki/Programación_extrema
[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.
[9] M. Fowler. Principles of XP, 2003. [accedido el 15 de junio de 2005].
Http://www.controlchaos.com
www.controlchaos.com
www.crystalmethodologies.org
www.dsdm.org
www.adaptivesd.com
Autor:
Edison Arley Plaza Marin
Adrian Anaya Villegas
[1] Free Software Fundation, http://www.fsf.org/philosophy/free-sw.es.html
[2] www.agilealliance.com
[3] Cortes?a Unkasoft
[4] Sinergia: Propiedad de los sistemas que se cumple cuando los componentes del mismo funcionan con el mismo fin, hacia el mismo lado o prop?sito.
[5] "DESARROLLO DE SOFTWARE BAJO METODOLOGIAS AGILES (Agile Methods XP) EN LA PRACTICA", Edison Arley Plaza Marin – Adrian Anaya Villegas, A?o 2007.
[6] Http://alistaircockburn.us, Pagina oficial de Alistair Cockburn, alistair.cockburn[arroba]acm.org.
| Página siguiente |