1

UNA APROXIMACIÓN HOLÍSTICA A LAS METODOLOGÍAS ÁGILES DESDE LA PROGRAMACIÓN EXTREMA

Paula Andrea Pardo Clavijo1, Santiago Triana Hernández2, Néstor Gabriel Forero Saboya3

RESUMEN

La Programación eXtrema (XP) dentro de los paradigmas de desarrollo de software, constituye un escenario novedoso por su integridad y calidad para la factoría de software, al integrar como elemento diferenciador las entidades de interacción, participación del usuario e importancia de la respuesta frente al cambio, las diferentes fases que tiene la programación extrema registran los principios de oportunidad, efectividad y calidad que deben caracterizar a cualquier proyecto que se construye como respuesta a los requerimientos funcionales establecidos por una organización. Desde su integridad y naturaleza estructural, se procede, en este artículo, a realizar un tratamiento inductivo de la programación extrema que da como resultado una aproximación holística a las metodologías ágiles. Algunos de los aspectos considerados son las fases metodológicas resaltadas en la XP, precediendo el proceso de desarrollo, al exaltar los valores y principios declarados en el manifiesto ágil, enmarcando los procesos que maneja, su estilo de desarrollo en la producción de software y la interacción con el cliente. Palabras Claves. Metodología ágil, Planificación, Programación Extrema, Software.

ABSTRACT

Extreme Programming within software development paradigms, is a novel scenario for integrity and quality to the software factory, as a differentiator by integrating entities interaction, user participation and importance of the response to changes or modifications, the different phases recorded involving the principles of opportunity, effectiveness and quality that should characterize any project that is built in response to a functional requirement established by an organization. Since its integrity and structural nature, we proceed in this article to make inductive treatment resulting in a holistic approach of agile methodologies. Some of the aspects considered are highlighted methodological phases in XP prefacing methodology development process, to promote the values and principles stated in the Agile Manifesto, framing processes that was handled in this, his style of development in software production and the interaction with the customer. Keywords. Agile Methodology, Planning Extreme Programming, Software.

INTRODUCCIÓN

finales de la década de los 90´s, múltiples metodologías empezaron a llamar la

atención del público en general, cada una compuesta por diferentes ideas tradicionales y a la vez innovadoras, exaltando la cooperación entre los equipos de programación y los usuarios, buscando la comunicación

personalizada para omitir la extensa documentación. A principios del siglo XXI se reunieron varios desarrolladores de productos de software de diversa índole, con el fin de establecer qué elementos tenían en común dentro de su quehacer ingenieril. De esta reunión se acuño el término "agile" cobijado y declarado en el

A

__________________________1Ingeniera de sistemas egresada de la Universidad Libre. Estudiante de Master en Administración y Gestión de Empresas Universidad de La Rioja. paulaa.pardoc@unilibrebog.edu.co 2Ingeniero de sistemas egresado de la Universidad Libre, programa de Ingeniería de sistemas Sede Bosque Popular. santiago.trianah@unilibrebog.edu.co 3Ingeniero Industrial; MS.C. En Ingeniería Telemática; candidato a Ph.D. En Ingeniería Telemática, Universidad de Vigo. MS.C En Ingeniería Industrial, Universidad Distrital. nestorg.foreros@unilibrebog.edu.co

2

“Manifesto for Agile Software Development”, en donde uno de los apartados más significativos es la declaración que compartía el valor del desarrollo, en el cual se resalta: Los individuos y la interacción por encima de los procesos y herramientas. El software que funciona por encima de la documentación abarcadora. La colaboración con el cliente por encima de la negociación contractual. La respuesta al cambio por encima del seguimiento de un plan. El origen de las metodologías tradicionales de programación, la declaración de la rebelión a los estándares rígidos de la absurda regla de estipular previamente la totalidad de los requerimientos de desarrollo; condujo a nuevos proyectos “ágiles”, cómo cualquier empeño humano, algunos exitosos y otros fallidos. Pero lo que llamo la atención era cómo los clientes y los programadores amaban el desarrollo de su proyecto, este era el camino que los desarrolladores de software buscaban. Sin embargo, en muchas ocasiones, es distante la dinámica con la cual se asume la creación de software, es por ello que en el presente artículo se abordara la programación extrema en pro de realizar una aproximación holística a las metodologías ágiles. I. LA PROGRAMACIÓN EXTREMA

La Programación Extrema (XP) está clasificada dentro de la rama de las metodologías ágiles; en las que se da prioridad a las tareas que dan resultados directos, reduciendo aquellos procesos a los cuales se somete el desarrollo. La XP se compone de un conjunto de prácticas que a lo largo de los años han demostrado ser las mejores prácticas de desarrollo de software, llevadas al extremo [1]. Los cambios de paradigmas y las abundantes críticas presentadas con respecto al formalismo de las metodologías tradicionales, al ser dispendiosas, engorrosas y en muchos casos inocuas, al no brindar una buena solución,

provoco la búsqueda de alternativas en el desarrollo del software como, por ejemplo, Lean Software Development (LSD), Programación Extrema (XP), Scrum y Crystal Clear [2]. Los componentes de XP como originalmente los propuso Kent Beck [3] son conocidos en el campo de la ingeniería de software desde sus inicios, sin embargo, XP pretende dar otro enfoque al desarrollo, empleando diferentes stakeholders tales como un equipo de gestión, un equipo de desarrollo y un grupo de clientes. La innovación con respecto a las metodologías tradicionales se fundamenta en la relación existente entre el desarrollador y el cliente apoyados por un grupo de gestión, enfatizando la captura y validación de requerimientos [4]. A. Objetivos de la programación extrema

Los objetivos esperados dentro de los proyectos de desarrollo de software al emplear una metodología como XP, dependen de la gestión que desee realizar el grupo de trabajo; aunque se pueden identificar algunos elementos comunes entre diferentes proyectos como los que se destacan a continuación [5]:

o Establecer las mejores prácticas de Ingeniería de Software en el desarrollo de proyectos.

o Optimizar la ejecución de los proyectos. o Garantizar la Calidad del Software

desarrollado, haciendo que este supere las expectativas del cliente.

o Potenciar al máximo el trabajo en equipo. o Satisfacer los requerimientos del cliente

brindándole el software que requiere.

B. Fases de la Metodología XP

Al implantar la metodología XP, se resaltan cuatro (4) fases, como se ilustra en la Figura 1,

3

en donde se aprecia la planificación del desarrollo como la primera fase, precediendo al diseño, la codificación y las pruebas de usuario, cabe resaltar que cada una de estas fases enmarca un conjunto de trabajos específicos [6].

A continuación se describe a groso modo el objetivo de cada fase.

1. La Planificación. Se debe alcanzar una relación entra la parte empresarial y la técnica, para esto se cuenta con varios niveles como son: la historia de usuarios, plan de entregas, velocidad de proyecto, iteraciones, rotaciones y reuniones. Aquí se pretende determinar el alcance de la siguiente versión [7]. 2. Diseño. En esta fase se encuentran varios elementos integradores que contribuyen al desarrollo del producto de software, como es el caso de las metáforas, las tarjetas CRC (clase, Responsabilidades y Colaboración), soluciones puntuales, la refactorización y el reciclaje, haciendo que cada uno de los procesos sea mejor [8]. 3. Desarrollo o Codificación. En este punto se definen las parejas de programación para realizar las diferentes versiones del proyecto. Otro elemento importante es la integración

continua; donde cada día hay que integrar o unir el código realizado y probar la versión resultante. Finalmente la propiedad colectiva, donde cualquier integrante del equipo, puede realizar cambios en el código sin restricción alguna, en caso de considerarlo conveniente, ya que nadie es dueño del código, esto con el fin de que todos los integrantes conozcan y sepan que modificaciones ha tenido.

4. Pruebas. XP define dos tipos de pruebas:

o La prueba unitaria que hace referencia a la funcionalidad del código paso a paso, evitando errores ocasionados por la modificación de este.

o La prueba de aceptación que tienen como propósito evaluar si el producto final puede adaptarse a otros ambientes, por otro lado, también resalta las funcionalidades que poseen mayor importancia desde la perspectiva del usuario [9].

C. Proceso de desarrollo Está inscrito en las cuatro (4) fases discutidas en el apartado anterior. La piedra angular de la metodología es su proceso de desarrollo centrado en el cliente, es por allí donde comenzará este análisis [10]. 1. Relación con el cliente. En XP se considera al cliente como parte del equipo, siendo un apoyo en el proceso de desarrollo, al abordar las historias de los usuarios, asistir a las reuniones de planificación y retroalimentar el proceso de desarrollo, definiendo los requisitos de una forma ordenada durante el tiempo establecido para el proyecto [11].

Este proceso se da en un escenario tal y como se muestra en la Figura 2, donde el cliente describe su trabajo a través de las llamadas

4

historias de usuario, derivando en el establecimiento de las dificultades técnicas de cada una.

2. Planificación del proyecto. Las historias de usuario planteadas por el cliente conforman el pilar que rige este proceso, al reflejar las necesidades del proyecto.

Se debe establecer un escenario de planificación como se observa en la Figura 3, que estipule los pasos del proyecto, dando los espacios para realizar las reuniones con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos en los que se hará mayor énfasis [12].

Las interacciones se afianzan en las historias de usuarios recopiladas durante los anteriores procesos, así se iniciara definiendo el orden de las tareas a cumplir por los equipos de desarrollo, escenario que se ve representado en la Figura 4.

3. Programación y pruebas. La programación se realiza en parejas, tal y como se puede apreciar en la Figura 5, teniendo en cuenta las historias de usuario recolectas y las tareas predestinadas en cada una de ellas, con esto se generara la versión que pasara a las pruebas de aceptación.

Más de una pareja puede realizar una misma tarea, inicialmente se considera redundante el proceso, pero a medida que se va avanzando en el desarrollo, se verá su utilidad, al servir cada desarrollo como elemento de contraste, garantizando la calidad de la versión del producto obtenido.

5

Una vez se programa se pasa a un escenario de prueba ilustrado en la Figura 6, el cual tiene como propósito corregir errores, para luego definir nuevas historias de usuario en el caso de ser necesarias dentro del desarrollo del proyecto.

II. VALORES DE LA XP

XP como metodología se rige por los valores declarados en el manifiesto ágil ilustrados en la Figura 7, los mismos que orientan el desarrollo de los proyectos que cada equipo lidera. Debido a la naturaleza social y humana de XP, resulta frecuente que a la lista de valores inicialmente declarada se le sumen otros intrínsecos de cada equipo de desarrollo [13].

A continuación se examinan los valores preponderantes en los proyectos desarrollados con la programación extrema.

1. La Comunicación. En el espacio de trabajo debe existir una excelente comunicación, que le permita a los equipos desarrolladores intercambiar información veraz y confiable, de manera continua, rápida y oportuna. 2. La Simplicidad. A medida que el proyecto se va desarrollando en relación al proceso y a la codificación se recomienda dar un enfoque simple, que contribuya al funcionamiento de éste en cualquier contexto [14].

3. La Retroalimentación. Como equipo de trabajo cada uno de los involucrados debe hacer parte de un todo, sin dejar a un lado las funciones que debe desempeñar como ente individual, encaminado a el objetivo del proyecto, sin descartar la importancia que posee el proceso de retroalimentación realizado por los actores que intervienen, para lo cual se exigen pruebas, integraciones, versiones y entregas frecuentes.

4. El Coraje. Las personas pertenecientes al equipo de trabajo deben dar sus opiniones si así lo consideran, expresando su punto de vista con respecto al desarrollo del proyecto, cumpliendo con su función a cabalidad al sugerir nuevas e innovadoras soluciones [15].

6

5. La Valentía. Programa para hoy y no para mañana. 6. El Respeto. Es de gran importancia trabajar como equipo, sin tomar decisiones individualistas. III. PRINCIPIOS DE LA XP

Son las prácticas o directrices que deben llevarse a cabo al implementar el modelo metodológico de XP en cualquier proyecto de desarrollo de software. Inicialmente se manejaron doce (12) principios que con el tiempo se han enriquecido con nuevos elementos [16].

1. La mayor prioridad es la satisfacción del cliente. Realizar un producto que satisfaga los requerimientos del cliente de manera que cumpla con las expectativas de él.

2. Bienvenidos los cambios, aún después del desarrollo. Los procesos ágiles entrelazan los cambios con el desarrollo como ventaja competitiva, con un diseño pequeño y flexible que se ajusta a las nuevas exigencias del cliente aun después de la entrega.

3. Entregas de software frecuentes. Al establecer prioridades se realizan entregas oportunas con períodos desde dos (2) semanas hasta dos (2) meses, teniendo en cuenta los ciclos de desarrollo, lo cual mejora la funcionalidad progresiva en tiempos de iteración cortos.

4. Se debe trabajar en equipo. La labor se debe realizar diariamente y en estrecho vínculo entre los clientes y los programadores durante todo el proyecto. Los requerimientos para un desarrollo a la medida son únicos, por ello,

requieren de la consulta permanente y directa entre los miembros del equipo de trabajo.

5. Construya los proyectos alrededor de individuos motivados. La confianza en los conocimientos que aplique cada una de las personas que integra el equipo de desarrollo, es la única alternativa viable para el logro de los resultados deseados.

6. Obtener la información de manera personalizada. Trate directamente con el cliente sobre cada requerimiento, evitará ruidos y distorsión en el flujo de la información.

7. El software que se trabaja es la mejor medida del progreso. Los resultados del proyecto están dados en función de la operación del software. Las funcionalidades requeridas y que han sido satisfechas en el tiempo estimado, son los indicadores del cliente.

8. Los procesos ágiles promueven los desarrollos sostenibles. Los objetivos del desarrollo se deben alcanzar con la ejecución del trabajo dentro de las horas definidas, en ningún caso con tiempos extra, ya que se tiene un período para realizar las tareas asignadas a cada equipo de desarrollo; como punto importante esta metodología busca realizar el proyecto en el menor tiempo posible.

9. El buen diseño mejora la agilidad. Una de las características más importantes del diseño debe ser la flexibilidad, en pro de permitir la fácil incorporación de nuevos requisitos funcionales, así se evita costos elevados y pérdida de tiempo en el proyecto.

10. La simplicidad. El arte de aumentar el volumen de trabajo sin hacer de más, es esencial. El software debe cumplir con los

7

requerimientos solicitados y con el menor esfuerzo en la programación.

11. Las mejores arquitecturas. Surgen de la organización del equipo, en donde las relaciones dinámicas entre los miembros da como resultado mejores diseños de conformidad con los requerimientos.

12. Continúa reflexión en búsqueda de la eficacia. La ventaja del método radica en la simplicidad y la flexibilidad de su estructura fácilmente modificable como consecuencia directa de los resultados de la retroalimentación iterativa de su proceso.

El enfoque de XP respecto a estas doce prácticas debe presentar sinergia entre todas ellas cuando se adoptan como un todo, ya que al implementar solamente una, todo el enfoque metodológico corre el riesgo de fracasar [17].

IV. COMPARATIVA METODOLOGÍAS TRADICIONALES Y LA XP

Aplicar una nueva metodología en un equipo de desarrollo obliga a aprender los diferentes componentes que maneja dicha metodología, haciendo que el equipo inicie un estilo diferente de trabajo, lo cual es un cambio de paradigma que implica el abandonando de técnicas usadas para el desarrollo del proyecto. La ingeniería de software distingue dos tipos de metodologías (las tradicionales y las ágiles), que dependiendo del proyecto a realizar se pueden seleccionar alternativamente, lo cual es de gran importancia para alcanzar el éxito del producto.

A continuación se presenta un paralelo resumido y enmarcado en los aspectos preponderantes de estos dos tipos de metodologías [18].

A. Metodologías Tradicionales

También nombradas bajo la denominación de metodologías pesadas o metodologías formales. La razón de este calificativo es su énfasis en el manejo de una extensa documentación muy detallada de todas y cada una de las etapas del proyecto de desarrollo de software.

No menos importante es el impacto que tienen los costos al momento de realizar un cambio en el desarrollo del plan general del proyecto debido a la deficiencia en la flexibilidad y la baja capacidad de adaptación de estas metodologías para manejar los cambios.

Uno de las principales críticas que ha tenido este tipo de metodologías es frente al nivel de satisfacción real de los clientes, debido a que en ocasiones los resultados obtenidos no se corresponden con las funcionalidades esperadas del producto final [19].

B. Metodologías Ágiles

En contraposición a las metodologías tradicionales, las metodologías ágiles, desarrollan una documentación mínima y a la medida de los requisitos de cada programa a elaborar, con lo cual, el proceso documental se hace muy liviano.

El impacto de los costos sobre el proyecto al momento de realizar un cambio es mínimo, debido a que su alcance sobre el plan general del proyecto es prácticamente nulo, esto es gracias a la alta flexibilidad y su alta capacidad de adaptación al cambio.

Finalmente, el nivel de satisfacción real de los clientes, es considerablemente alto debido a que los resultados obtenidos siempre se corresponden con las funcionalidades esperadas del producto final, dado que el desarrollo y las pruebas se hacen en conjunto entre el cliente y el equipo de desarrollo, hasta la aceptación del producto [20].

8

La Tabla 1 contiene un paralelo comparativo entre los dos tipos de metodologías:

Tabla 1. Comparativa entre metodologías tradicionales y metodologías ágiles.

METODOLOGÍAS TRADICIONALES METODOLOGÍAS ÁGILES Predictivas. Adaptativas. Orientación al proceso. Orientada a la gente. Se tiene un plan fijo inicial equivalente a un proyecto exitoso que a su vez equivale a un valor demostrable.

El valor para el cliente es cambiante, por lo tanto, el plan debe revaluarse para cambiar y ajustarse.

El cambio es visto como una desviación del plan y por lo tanto un alejamiento del éxito del proyecto.

El cambio es aceptado y tratado tan eficientemente como sea posible y teniendo en cuenta su impacto.

Prevención de cambios mediante fases de análisis y diseño muy largas. Facilita los cambios mediante fases de análisis y rediseño iterativos.

El software no está disponible al cliente hasta etapas avanzadas del proceso.

El cliente dispone del software desde el inicio del proceso, lo evalúa y usa mientras va creciendo y mejorando

Los requerimientos se obtienen de forma detallada una única vez al principio del proceso, se previenen los cambios mediante la firma del cliente de dichos requerimientos.

Los requisitos son genéricos y se acercan a las necesidades del negocio durante la continua interacción entre los desarrolladores y el cliente.

Las personas son componentes intercambiables del proceso. Las personas determinan el éxito del proceso. Las decisiones sobre el desarrollo se han tomado desde el principio por los analistas y gestores del proyecto.

Los desarrolladores toman decisiones sobre el diseño a medida que avanza el proceso, a su vez está sujeto a cambios.

Dentro del plan del proyecto el diseño es temprano, largo y detallado, normalmente no sujeto a cambios.

El diseño es corto y constante, sucede para cada interacción y presta atención a la retroalimentación de las interacciones anteriores.

El proceso es complicado y difícil de cambiar. Incluye reglas rígidas aplicables a todo tipo de proyecto.

El proceso es simple y fácil de cambiar. Incluye un conjunto de reglas mínimas necesarias para un proyecto y facilita agregar otras a la medida.

La rigidez del proceso cohíbe la creatividad y la innovación. La creatividad y la innovación se alimentan por la flexibilidad del proceso.

La comunicación con el cliente se hace por medio de interventores o terceros, con lo cual, se retrasan las comunicaciones y se distorsiona el mensaje original.

La comunicación es personal y eso agiliza el proceso de desarrollo, además, de conservar la fidelidad del mensaje original.

El cliente es un componente externo al proyecto de desarrollo y que se encarga de fijar los requerimientos y validar los resultados.

El cliente es parte integral del proyecto de desarrollo y trabaja en grupo con el equipo de desarrollo hasta su conclusión.

La entrega del proyecto es única y cuando está completamente terminado, listo para pasar a la fase de pruebas.

La entrega es frecuente y en pequeños paquetes, fáciles de evaluar e implementar de una vez en producción.

La corrección de las fallas en el período de pruebas es de hecho lenta y dispendiosa debido a los canales de comunicación y lo laxa de la entrega.

La corrección de errores es más rápida y eficiente porque se evalúan pequeñas partes funcionales con cada versión y en concurso de cliente y desarrolladores.

Se desarrollan funcionalidades que en muchas ocasiones no entraran en producción hasta mucho tiempo después de la implementación.

Se desarrollan únicamente las funcionalidades necesarias en el momento en que sean requeridas (justo a tiempo).

El diálogo entre clientes, patrocinadores y desarrolladores es complejo porque no se maneja la misma terminología entre ellos.

El diálogo entre clientes, patrocinadores y desarrolladores se simplifica porque manejan lenguaje metafórico.

Los desarrollos producen códigos complejos y difíciles de leer. Los desarrollos entregan productos más sencillos y fáciles de leer. Los desarrollos de cada programa los realiza un programador en solitario.

Los desarrollos de cada programa los realiza una pareja de programadores que se rotan.

El entrenamiento para los programadores se imparte en cursos especialmente establecidos.

El entrenamiento para los programadores es de carácter cruzado (gracias a la rotación).

Las versiones de las soluciones son intocables hasta la liberación definitiva de una nueva versión.

Las versiones de las soluciones están en permanente evolución y se alteran a cada momento durante el desarrollo.

Algunos programas pueden presentar redundancia o funcionalidades inútiles y no se pueden actualizar sus diseños oportunamente.

Los programas son actualizados permanentemente y modificados sus diseños, gracias a la refactorización.

La retroalimentación es lenta y en ocasiones está desactualizada. La retroalimentación es inmediata y siempre corresponde a lo que se está haciendo.

La prioridad es el cumplimiento del contrato. La prioridad es la satisfacción del cliente. Se involucran individuos que no están motivados con el proyecto. Solamente se involucran las personas motivadas con el proyecto.

Los proyectos se terminan y los desarrollos cesan de inmediato. Los desarrollos son sostenibles y capaces de sostener su marcha para emprender nuevos proyectos.

Las reuniones de evaluación para el proyecto se ajustan al cronograma inicial. Las reuniones son diarias y de no más de 20 minutos.

Fuente: Elaboración Propia

9

CONCLUSIONES

Los procesos de la Programación eXtrema son conocidos desde los orígenes de la ingeniería de software, la diferencia de esta metodología es que da prioridad a las tareas que dan resultados directos. De igual forma, el conjunto de prácticas de las cuales se compone el proyecto de XP, son aquellas que a lo largo de la historia han demostrado ser las mejores prácticas de desarrollo de software, la diferencia radica en que son llevadas al extremo.

En la programación extrema, la relación con el cliente se mejora sustancialmente, debido principalmente al grado de compromiso y nivel de dedicación que conllevan pertenecer al equipo; el contacto directo entre los componentes humanos del proyecto, agiliza las comunicaciones y disminuye los ruidos, permitiendo una rápida respuesta del grupo de desarrollo a los cambios de valores del cliente.

La adaptabilidad y la evolución son parte fundamental de la existencia en nuestro entorno, el enfoque simplista hacia los cambios en un modelo metodológico va en oposición a la realidad que nos rodea y es nuestra opción mantenernos inmersos en el error o corregir dicha situación.

Al utilizar metodologías ágiles como la programación extrema, los proyectos de desarrollos se hacen modulares e incrementales, haciendo que cada entrega sea el punto de partida para un nuevo proyecto de desarrollo.

AGRADECIMIENTOS

Expresamos los más profundo y sincero agradecimientos a todas las personas que con su ayuda han colaborado en la realización del presente trabajo, en especial al Ing. Luis Carlos Torres, quien nos ha inculcado de diferentes formas la razón de ser de la profesión.

Al ingeniero Pedro Forero por la orientación, el seguimiento y la supervisión continúa del presente escrito. Especial reconocimiento merece el interés mostrado por este artículo y las sugerencias recibidas del docente y amigo Néstor Forero, con el que nos encontramos en deuda. También nos gustaría agradecer la ayuda recibida del ingeniero Jairo Cortés por su amistad y colaboración, de la misma forma al ingeniero Fabián Blanco.

A nuestra alma mater por acogernos en sus instalaciones, y tomar la gran responsabilidad de formarnos como personas e íntegros profesionales. A todos ellos, muchas gracias.

10

REFERENTES

[1] Fowler. Martin. "Refactoring: Improve the Design of Existing Code". Addison-Wesley Pub Co, ISBN: 0201485672, 1a edición junio 1999

[2] Highsmith. Jim. “Extrme Programming Agile project Advisory Servervice White paper”. 37 Broadway,Arligton 2000. [3] Beck, K. (1999). “Extreme Programming Explained”. Adisson-Wesley. Capitulo 7.

[4] Calero S. Manuel. “Una explicación de la programación extrema (XP)” V Encuentro usuarios xBase 2003 MADRID. Recuperado el 19 – 09 – 2012 de http://www.willydev.net/descargas/prev/ExplicaXP.pdf

[5] Bautista M. Jose (). “Programación extrema (XP) Extreme Programming (XP)”. Recuperado el 19 – 09 – 2012 de http://www.ingenieriadesoftware.mex.tl/images/18149/PROGRAMACI%C3%93N%20EXTREMA.pdf

[6] Gómez. Daniel. Aranda. Elisabet y Fabrega. Jordi “Programación Extrema”. Recuperado el 19 – 09 – 2012 de http://eisc.univalle.edu.co/materias/WWW/material/lecturas/xp.pdf

[7] Kumar G. Pavan. “Build your Project using Extreme Programming”. (Referencia de un artículo). 2009.pp.2-3.

[8] Joskowicz. José. “Reglas y Prácticas en eXtreme Programming”. 2008.pp.11-12.

[9] Smith. Suzanne. “WHAT WE CAN LEARN FROM EXTREME PROGRAMMING”. 2011. pp.145.

[10] Tixi. Juan, Diciembre 2008. Previa a la obtención de grado. “Análisis, diseño y desarrollo de un sistema de constatación física de bienes para la dirección financiera de la ESPE usando dispositivos móviles y la plataforma .Net”. Escuela Politécnica Del Ejército.pp.20-28. Recuperado el 19 – 09 – 2012 de http://repositorio.espe.edu.ec/bitstream/21000/1054/1/T-ESPE-021868.pdf

[11] Robles. Gregorio. “Programación Extrema y Software Libre”. Universidad Rey Juan Carlos – Madrid.2002.pp.3-7.

[12]Molpeceres. Alberto. “Procesos de desarrollo: RUP, XP y FDD”. 2002.pp.1.

[13]. Berrueta. Diego. “Programación extrema y software libre”. 2006. pp.1.

[14] Cortizo P. José Carlos. “eXtreme Programming”. pp.28.

[15]Cunningham.Ward.“Extreme Programing ”. O’Reilly & Associates. 2003. pp.10

[16] M.C. Campos. “Programación Extrema: Prácticas, Aceptación y Controversia”. 2006. pp58-59.

[17] Robles. Gregorio. “Programación Extrema y Software Libre”. Universidad Rey Juan Carlos – Madrid. 2002. pp.2-3.

[18] Roberth G. Figueroa. “Metodologías Tradicionales vs. Metodologías Ágiles”. Universidad Técnica Particular de Loja, Escuela de Ciencias en Computación. pp.1-4.

[19] Laboratorio Nacional de Calidad del Software. “Ingenieria del software: Metodologias y Ciclos de vida”. 2009. [20] Reynoso, Carlos. “Métodos Heterodoxos en Desarrollo de Software”. Universidad de Buenos Aires.2004.pp.12-55.