Programación extrema - Extreme programming

Bucles de planificación y retroalimentación en la programación extrema

La programación extrema ( XP ) es una metodología de desarrollo de software que tiene como objetivo mejorar la calidad del software y la capacidad de respuesta a los requisitos cambiantes del cliente. Como un tipo de desarrollo de software ágil , aboga por "lanzamientos" frecuentes en ciclos de desarrollo cortos, con el objetivo de mejorar la productividad e introducir puntos de control en los que se pueden adoptar nuevos requisitos del cliente.

Otros elementos de la programación extrema incluyen: programar en pares o hacer una revisión exhaustiva del código , pruebas unitarias de todo el código, no programar funciones hasta que sean realmente necesarias , una estructura de gestión plana, simplicidad y claridad del código, esperando cambios en los requisitos del cliente a medida que pasa el tiempo y el problema se comprende mejor, y la comunicación frecuente con el cliente y entre los programadores. La metodología toma su nombre de la idea de que los elementos beneficiosos de las prácticas tradicionales de ingeniería de software se llevan a niveles "extremos". Por ejemplo, las revisiones de código se consideran una práctica beneficiosa; llevado al extremo, el código se puede revisar continuamente (es decir, la práctica de la programación por pares ).

Historia

Kent Beck desarrolló una programación extrema durante su trabajo en el proyecto de nómina Chrysler Comprehensive Compensation System (C3) . Beck se convirtió en el líder del proyecto C3 en marzo de 1996. Comenzó a refinar la metodología de desarrollo utilizada en el proyecto y escribió un libro sobre la metodología ( Extreme Programming Explained , publicado en octubre de 1999). Chrysler canceló el proyecto C3 en febrero de 2000, después de siete años, cuando Daimler-Benz adquirió la empresa. Ward Cunningham fue otra gran influencia en XP.

Muchas prácticas de programación extrema existen desde hace algún tiempo; la metodología lleva las " mejores prácticas " a niveles extremos. Por ejemplo, la "práctica de desarrollo de pruebas primero, planificación y redacción de pruebas antes de cada microincremento" se utilizó ya en el Proyecto Mercurio de la NASA , a principios de la década de 1960. Para acortar el tiempo total de desarrollo, se han desarrollado algunos documentos de prueba formales (como para las pruebas de aceptación ) en paralelo con (o poco antes) que el software esté listo para la prueba. Un grupo de prueba independiente de la NASA puede escribir los procedimientos de prueba, basados ​​en requisitos formales y límites lógicos, antes de que los programadores escriban el software y lo integren con el hardware. XP lleva este concepto al nivel extremo, escribiendo pruebas automatizadas (a veces dentro de módulos de software) que validan el funcionamiento de incluso pequeñas secciones de codificación de software, en lugar de solo probar las funciones más grandes.

Orígenes

Dos influencias importantes dieron forma al desarrollo de software en la década de 1990:

Los requisitos rápidamente cambiantes exigían ciclos de vida más cortos del producto y , a menudo, chocaban con los métodos tradicionales de desarrollo de software.

El Sistema de Compensación Integral de Chrysler (C3) se inició con el fin de determinar la mejor manera de utilizar las tecnologías de objetos, utilizando los sistemas de nómina de Chrysler como objeto de investigación, con Smalltalk como lenguaje y GemStone como capa de acceso a los datos . Chrysler contrató a Kent Beck , un destacado practicante de Smalltalk, para ajustar el rendimiento del sistema, pero su función se amplió cuando notó varios problemas con el proceso de desarrollo. Aprovechó esta oportunidad para proponer e implementar algunos cambios en las prácticas de desarrollo, basándose en su trabajo con su colaborador habitual, Ward Cunningham . Beck describe la concepción temprana de los métodos:

La primera vez que me pidieron que liderara un equipo, les pedí que hicieran algunas de las cosas que pensaba que eran sensatas, como pruebas y revisiones. La segunda vez había mucho más en juego. Pensé: "Al diablo con los torpedos, al menos esto será un buen artículo", [y] le pedí al equipo que subiera todas las perillas a 10 en las cosas que pensaba que eran esenciales y omitiera todo lo demás.

Beck invitó a Ron Jeffries al proyecto para ayudar a desarrollar y perfeccionar estos métodos. A partir de entonces, Jeffries actuó como entrenador para inculcar las prácticas como hábitos en el equipo C3.

La información sobre los principios y las prácticas detrás de XP se difundió al resto del mundo a través de discusiones en la wiki original , WikiWikiWeb de Cunningham . Varios colaboradores discutieron y ampliaron las ideas, y resultaron algunas metodologías derivadas (ver desarrollo de software ágil ). Además, los conceptos de XP se han explicado, durante varios años, utilizando un mapa del sistema de hipertexto en el sitio web de XP en http://www.extremeprogramming.org alrededor de 1999.

Beck editó una serie de libros sobre XP, comenzando con su propio Extreme Programming Explained (1999, ISBN  0-201-61641-6 ), difundiendo sus ideas a una audiencia mucho más amplia. Los autores de la serie pasaron por varios aspectos relacionados con XP y sus prácticas. La serie incluyó un libro crítico de las prácticas.

Estado actual

XP generó un interés significativo entre las comunidades de software a fines de la década de 1990 y principios de la de 2000, al ver la adopción en varios entornos radicalmente diferentes de sus orígenes.

La alta disciplina requerida por las prácticas originales a menudo se quedó en el camino, lo que provocó que algunas de estas prácticas, como las que se consideraban demasiado rígidas, fueran desaprobadas o reducidas, o incluso dejadas sin terminar, en sitios individuales. Por ejemplo, la práctica de las pruebas de integración al final del día para un proyecto en particular podría cambiarse a un programa de fin de semana, o simplemente reducirse a pruebas en fechas mutuamente acordadas. Un horario tan relajado podría evitar que las personas se sientan apresuradas a generar talones artificiales solo para pasar la prueba del final del día. Un programa menos rígido permite, en cambio, el desarrollo de funciones complejas durante un período de varios días.

Mientras tanto, otras prácticas de desarrollo ágil no se han detenido y, a partir de 2019, XP continúa evolucionando, asimilando más lecciones de las experiencias en el campo, para utilizar otras prácticas. En la segunda edición de Extreme Programming Explained (noviembre de 2004), cinco años después de la primera edición, Beck agregó más valores y prácticas y distinguió entre prácticas primarias y secundarias.

Concepto

Metas

Extreme Programming Explained describe la programación extrema como una disciplina de desarrollo de software que organiza a las personas para producir software de mayor calidad de manera más productiva.

XP intenta reducir el costo de los cambios en los requisitos al tener varios ciclos de desarrollo cortos, en lugar de uno largo. En esta doctrina, los cambios son un aspecto natural, ineludible y deseable de los proyectos de desarrollo de software, y deben planificarse, en lugar de intentar definir un conjunto estable de requisitos.

La programación extrema también introduce una serie de valores, principios y prácticas básicos además del marco de programación ágil.

Ocupaciones

XP describe cuatro actividades básicas que se realizan dentro del proceso de desarrollo de software: codificación, prueba, escucha y diseño. Cada una de esas actividades se describe a continuación.

Codificación

Los defensores de XP argumentan que el único producto verdaderamente importante del proceso de desarrollo del sistema es el código: instrucciones de software que una computadora puede interpretar. Sin código, no hay producto que funcione.

La codificación se puede utilizar para encontrar la solución más adecuada. La codificación también puede ayudar a comunicar pensamientos sobre problemas de programación. Un programador que se enfrente a un problema de programación complejo, o que le resulte difícil explicar la solución a otros programadores, podría codificarlo de manera simplificada y utilizar el código para demostrar lo que significan. El código, dicen los defensores de esta posición, es siempre claro y conciso y no se puede interpretar de más de una manera. Otros programadores pueden dar su opinión sobre este código codificando también sus pensamientos.

Pruebas

Las pruebas son fundamentales para la programación extrema. El enfoque de la programación extrema es que si una pequeña prueba puede eliminar algunas fallas, muchas pruebas pueden eliminar muchas más fallas.

  • Las pruebas unitarias determinan si una característica determinada funciona según lo previsto. Los programadores escriben tantas pruebas automatizadas como pueden pensar que podrían "romper" el código; si todas las pruebas se ejecutan correctamente, la codificación está completa. Cada fragmento de código que se escribe se prueba antes de pasar a la siguiente función.
  • Las pruebas de aceptación verifican que los requisitos entendidos por los programadores satisfacen los requisitos reales del cliente.

Las pruebas de integración en todo el sistema se alentaron, inicialmente, como una actividad diaria al final del día, para la detección temprana de interfaces incompatibles, para volver a conectar antes de que las secciones separadas divergieran ampliamente de la funcionalidad coherente. Sin embargo, las pruebas de integración en todo el sistema se han reducido a semanalmente o con menos frecuencia, según la estabilidad de las interfaces generales del sistema.

Escuchando

Los programadores deben escuchar lo que los clientes necesitan que haga el sistema, qué " lógica empresarial " se necesita. Deben comprender estas necesidades lo suficientemente bien como para dar retroalimentación al cliente sobre los aspectos técnicos de cómo el problema podría resolverse o no. La comunicación entre el cliente y el programador se aborda en mayor profundidad en el juego de planificación .

Diseño

Desde el punto de vista de la simplicidad, por supuesto, se podría decir que el desarrollo de sistemas no necesita más que codificar, probar y escuchar. Si esas actividades se realizan bien, el resultado siempre debe ser un sistema que funcione. En la práctica, esto no funcionará. Uno puede recorrer un largo camino sin diseñar, pero en un momento dado, uno se atasca. El sistema se vuelve demasiado complejo y las dependencias dentro del sistema dejan de ser claras. Se puede evitar esto creando una estructura de diseño que organice la lógica en el sistema. Un buen diseño evitará muchas dependencias dentro de un sistema; esto significa que cambiar una parte del sistema no afectará a otras partes del sistema.

Valores

La programación extrema reconoció inicialmente cuatro valores en 1999: comunicación, simplicidad, retroalimentación y coraje. Un nuevo valor, el respeto, se agregó en la segunda edición de Extreme Programming Explained . Estos cinco valores se describen a continuación.

Comunicación

La construcción de sistemas de software requiere comunicar los requisitos del sistema a los desarrolladores del sistema. En las metodologías formales de desarrollo de software, esta tarea se logra a través de la documentación. Las técnicas de programación extremas pueden verse como métodos para construir y difundir rápidamente el conocimiento institucional entre los miembros de un equipo de desarrollo. El objetivo es brindar a todos los desarrolladores una vista compartida del sistema que coincida con la vista que tienen los usuarios del sistema. Para ello, la programación extrema favorece los diseños simples, las metáforas comunes, la colaboración de usuarios y programadores, la comunicación verbal frecuente y la retroalimentación.

Sencillez

La programación extrema alienta a comenzar con la solución más simple. Posteriormente, se pueden agregar funciones adicionales. La diferencia entre este enfoque y los métodos de desarrollo de sistemas más convencionales es el enfoque en el diseño y la codificación para las necesidades de hoy en lugar de las de mañana, la próxima semana o el próximo mes. Esto a veces se resume como el enfoque " No lo vas a necesitar " (YAGNI). Los defensores de XP reconocen la desventaja de que esto a veces puede implicar más esfuerzo mañana para cambiar el sistema; su afirmación es que esto está más que compensado por la ventaja de no invertir en posibles requisitos futuros que podrían cambiar antes de que sean relevantes. Codificar y diseñar para requisitos futuros inciertos implica el riesgo de gastar recursos en algo que podría no ser necesario, mientras que quizás retrase características cruciales. En relación con el valor de la "comunicación", la simplicidad en el diseño y la codificación debería mejorar la calidad de la comunicación. La mayoría de los programadores del equipo podrían entender fácilmente un diseño simple con un código muy simple.

Realimentación

Dentro de la programación extrema, la retroalimentación se relaciona con diferentes dimensiones del desarrollo del sistema:

  • Comentarios del sistema: escribiendo pruebas unitarias o ejecutando pruebas de integración periódicas, los programadores obtienen comentarios directos del estado del sistema después de implementar los cambios.
  • Comentarios del cliente: las pruebas funcionales (también conocidas como pruebas de aceptación ) las escriben el cliente y los evaluadores. Recibirán comentarios concretos sobre el estado actual de su sistema. Esta revisión se planifica una vez cada dos o tres semanas para que el cliente pueda dirigir fácilmente el desarrollo.
  • Comentarios del equipo: cuando los clientes plantean nuevos requisitos en el juego de planificación, el equipo proporciona directamente una estimación del tiempo que llevará implementarlos.

La retroalimentación está estrechamente relacionada con la comunicación y la simplicidad. Las fallas en el sistema se comunican fácilmente escribiendo una prueba unitaria que demuestre que cierto fragmento de código se romperá. La retroalimentación directa del sistema le dice a los programadores que recodifiquen esta parte. Un cliente puede probar el sistema periódicamente de acuerdo con los requisitos funcionales, conocidos como historias de usuario . Para citar a Kent Beck , "el optimismo es un riesgo ocupacional de la programación. La retroalimentación es el tratamiento".

Coraje

Varias prácticas encarnan el coraje. Uno es el mandamiento de diseñar y codificar siempre para hoy y no para mañana. Este es un esfuerzo para evitar atascarse en el diseño y requerir mucho esfuerzo para implementar cualquier otra cosa. Courage permite a los desarrolladores sentirse cómodos refactorizando su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo para que los cambios futuros se puedan implementar más fácilmente. Otro ejemplo de coraje es saber cuándo desechar el código: coraje para eliminar el código fuente que está obsoleto, sin importar cuánto esfuerzo se haya utilizado para crear ese código fuente. Además, el coraje significa persistencia: un programador puede estar atrapado en un problema complejo durante todo un día y luego resolver el problema rápidamente al día siguiente, pero solo si es persistente.

El respeto

El valor del respeto incluye el respeto por los demás y el respeto por uno mismo. Los programadores nunca deben realizar cambios que rompan la compilación, que hagan fallar las pruebas unitarias existentes o que retrasen el trabajo de sus pares. Los miembros respetan su propio trabajo esforzándose siempre por lograr una alta calidad y buscando el mejor diseño para la solución en cuestión a través de la refactorización.

Adoptar los cuatro valores anteriores conduce a que se gane el respeto de los demás en el equipo. Nadie en el equipo debe sentirse despreciado o ignorado. Esto asegura un alto nivel de motivación y fomenta la lealtad hacia el equipo y hacia el objetivo del proyecto. Este valor depende de los otros valores y está orientado al trabajo en equipo.

Normas

La primera versión de las reglas para XP fue publicada en 1999 por Don Wells en el sitio web de XP. Se dan 29 reglas en las categorías de planificación, gestión, diseño, codificación y prueba. La planificación, la gestión y el diseño se denominan explícitamente para contrarrestar las afirmaciones de que XP no admite esas actividades.

Ken Auer propuso otra versión de las reglas de XP en XP / Agile Universe 2003. Sintió que XP se definía por sus reglas, no por sus prácticas (que están sujetas a más variaciones y ambigüedades). Definió dos categorías: "Reglas de participación", que dictan el entorno en el que el desarrollo de software puede tener lugar de manera efectiva, y "Reglas de juego", que definen las actividades y reglas minuto a minuto dentro del marco de las Reglas de participación.

Estas son algunas de las reglas (incompletas):

Codificación

Pruebas

  • Todo el código debe tener pruebas unitarias
  • Todo el código debe pasar todas las pruebas unitarias antes de que se pueda publicar.
  • Cuando se encuentra un error , las pruebas se crean antes de que se solucione el error (un error no es un error de lógica; es una prueba que no se escribió)
  • Las pruebas de aceptación se realizan con frecuencia y los resultados se publican.

Principios

Los principios que forman la base de XP se basan en los valores que se acaban de describir y están destinados a fomentar las decisiones en un proyecto de desarrollo de sistemas. Se pretende que los principios sean más concretos que los valores y que se traduzcan más fácilmente en orientación en una situación práctica.

Realimentación

La programación extrema considera que la retroalimentación es más útil si se realiza con frecuencia y rapidez. Enfatiza que un retraso mínimo entre una acción y su retroalimentación es fundamental para aprender y realizar cambios. A diferencia de los métodos tradicionales de desarrollo de sistemas, el contacto con el cliente se produce en iteraciones más frecuentes. El cliente tiene una visión clara del sistema que se está desarrollando y puede dar su opinión y dirigir el desarrollo según sea necesario. Con la retroalimentación frecuente del cliente, una decisión de diseño errónea tomada por el desarrollador se notará y corregirá rápidamente, antes de que el desarrollador dedique mucho tiempo a implementarla.

Las pruebas unitarias contribuyen al principio de retroalimentación rápida. Al escribir código, ejecutar la prueba unitaria proporciona información directa sobre cómo reacciona el sistema a los cambios realizados. Esto incluye ejecutar no solo las pruebas unitarias que prueban el código del desarrollador, sino también ejecutar todas las pruebas unitarias contra todo el software, utilizando un proceso automatizado que puede iniciarse con un solo comando. De esa manera, si los cambios del desarrollador causan una falla en alguna otra parte del sistema de la que el desarrollador sabe poco o nada, el conjunto de pruebas automatizadas de todas las unidades revelará la falla de inmediato, alertando al desarrollador de la incompatibilidad de su cambio con otras partes del sistema y la necesidad de eliminar o modificar su cambio. Según las prácticas de desarrollo tradicionales, la ausencia de un conjunto de pruebas unitarias completo y automatizado significaba que dicho cambio de código, asumido como inofensivo por el desarrollador, se habría dejado en su lugar, apareciendo solo durante las pruebas de integración, o peor aún, solo en producción; y determinar qué cambio de código causó el problema, entre todos los cambios realizados por todos los desarrolladores durante las semanas o incluso meses previos a las pruebas de integración, fue una tarea formidable.

Asumiendo simplicidad

Se trata de tratar cada problema como si su solución fuera "extremadamente simple". Los métodos tradicionales de desarrollo de sistemas dicen planificar para el futuro y codificar para la reutilización. La programación extrema rechaza estas ideas.

Los defensores de la programación extrema dicen que hacer grandes cambios de una vez no funciona. La programación extrema aplica cambios incrementales: por ejemplo, un sistema puede tener pequeñas versiones cada tres semanas. Cuando se realizan muchos pequeños pasos, el cliente tiene más control sobre el proceso de desarrollo y el sistema que se está desarrollando.

Abrazar el cambio

El principio de abrazar el cambio no consiste en trabajar contra los cambios, sino en abrazarlos. Por ejemplo, si en una de las reuniones iterativas parece que los requisitos del cliente han cambiado drásticamente, los programadores deben aceptar esto y planificar los nuevos requisitos para la próxima iteración.

Practicas

Se ha descrito que la programación extrema tiene 12 prácticas, agrupadas en cuatro áreas:

Retroalimentación a escala fina

Proceso continuo

Entendimiento compartido

Bienestar del programador

Aspectos controvertidos

Las prácticas en XP se han debatido mucho. Los defensores de la programación extrema afirman que al hacer que la solicitud del cliente en el sitio cambie de manera informal, el proceso se vuelve flexible y ahorra el costo de los gastos generales formales. Los críticos de XP afirman que esto puede conducir a una revisión costosa y al alcance del proyecto más allá de lo que se acordó o financió previamente.

Los tableros de control de cambios son una señal de que existen conflictos potenciales en los objetivos del proyecto y restricciones entre múltiples usuarios. Los métodos acelerados de XP dependen en cierto modo de que los programadores puedan asumir un punto de vista unificado del cliente para que el programador pueda concentrarse en la codificación, en lugar de en la documentación de los objetivos y las limitaciones de compromiso. Esto también se aplica cuando están involucradas múltiples organizaciones de programación, particularmente organizaciones que compiten por acciones de proyectos.

Otros aspectos potencialmente controvertidos de la programación extrema incluyen:

  • Los requisitos se expresan como pruebas de aceptación automatizadas en lugar de documentos de especificación.
  • Los requisitos se definen de forma incremental, en lugar de intentar obtenerlos todos por adelantado.
  • Por lo general, se requiere que los desarrolladores de software trabajen en parejas.
  • No hay un gran diseño por adelantado . La mayor parte de la actividad de diseño se lleva a cabo sobre la marcha y de forma incremental, comenzando con"la cosa más simple que podría funcionar" y agregar complejidad solo cuando sea requerido por las pruebas fallidas. Los críticos comparan esto con " depurar un sistema en apariencia" y temen que esto resulte en más esfuerzos de rediseño que solo rediseñar cuando cambian los requisitos.
  • Un representante del cliente está adjunto al proyecto. Este rol puede convertirse en un punto único de falla para el proyecto, y algunas personas lo han encontrado como una fuente de estrés. Además, existe el peligro de una microgestión por parte de un representante no técnico que intente imponer el uso de las características técnicas y la arquitectura del software.

Los críticos han notado varios inconvenientes potenciales, incluidos problemas con requisitos inestables, sin compromisos documentados de los conflictos del usuario y la falta de una especificación o documento de diseño general.

Escalabilidad

ThoughtWorks ha tenido un éxito razonable en proyectos XP distribuidos con hasta sesenta personas.

En 2004, se introdujo la programación industrial extrema (IXP) como una evolución de XP. Su objetivo es brindar la capacidad de trabajar en equipos grandes y distribuidos. Ahora tiene 23 prácticas y valores flexibles.

Divisibilidad y respuestas

En 2003, Matt Stephens y Doug Rosenberg publicaron Extreme Programming Refactored: The Case Against XP , que cuestionó el valor del proceso XP y sugirió formas en las que podría mejorarse. Esto desencadenó un largo debate en artículos, grupos de noticias de Internet y áreas de chat en sitios web. El argumento central del libro es que las prácticas de XP son interdependientes pero que pocas organizaciones prácticas están dispuestas / son capaces de adoptar todas las prácticas; por lo tanto, todo el proceso falla. El libro también hace otras críticas, y dibuja una semejanza del modelo de "propiedad colectiva" de XP con el socialismo de una manera negativa.

Ciertos aspectos de XP han cambiado desde la publicación de Extreme Programming Refactored ; en particular, XP ahora acomoda modificaciones a las prácticas siempre que se sigan cumpliendo los objetivos requeridos. XP también utiliza términos cada vez más genéricos para los procesos. Algunos argumentan que estos cambios invalidan críticas anteriores; otros afirman que esto simplemente está diluyendo el proceso.

Otros autores han intentado reconciliar XP con las metodologías más antiguas para formar una metodología unificada. Algunos de estos XP buscaron reemplazar, como la metodología de cascada ; ejemplo: Ciclos de vida del proyecto: cascada, desarrollo rápido de aplicaciones (RAD) y todo eso. JPMorgan Chase & Co. intentó combinar XP con los métodos de programación informática de integración de modelos de madurez de capacidad (CMMI) y Six Sigma . Descubrieron que los tres sistemas se reforzaban bien entre sí, lo que conducía a un mejor desarrollo y no se contradecían mutuamente.

Crítica

El zumbido inicial de la programación extrema y los principios controvertidos, como la programación en pareja y el diseño continuo , han atraído críticas particulares, como las de McBreen y Boehm y Turner, Matt Stephens y Doug Rosenberg. Sin embargo, los practicantes de Agile creen que muchas de las críticas son malentendidos del desarrollo ágil.

En particular, la programación extrema ha sido revisada y criticada por Extreme Programming Refactored de Matt Stephens y Doug Rosenberg .

Ver también

Referencias

Otras lecturas

  • Ken Auer y Roy Miller. Programación extrema aplicada: Jugando para ganar , Addison – Wesley.
  • Ken Auer; Ron Jeffries ; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). "¿Son los testers eXtinct? ¿Cómo pueden contribuir los testers a los equipos XP?". Programación extrema y métodos ágiles - XP / Agile Universe 2002 . Apuntes de conferencias en Ciencias de la Computación. 2418 . Springer-Verlag. pag. 287. doi : 10.1007 / 3-540-45672-4_50 . ISBN 978-3-540-44024-6.
  • Kent Beck : Explicación de la programación extrema: Adoptar el cambio , Addison – Wesley.
  • Kent Beck y Martin Fowler : Planificación de programación extrema , Addison – Wesley.
  • Kent Beck y Cynthia Andres. Explicación de la programación extrema: Adoptar el cambio, segunda edición , Addison-Wesley.
  • Alistair Cockburn : Desarrollo de software ágil , Addison – Wesley.
  • Martin Fowler : Refactorización: Mejora del diseño del código existente , Addison – Wesley.
  • Harvey Herela (2005). Estudio de caso: El sistema de compensación integral de Chrysler . Laboratorio Galen, UC Irvine.
  • Jim Highsmith . Ecosistemas de desarrollo de software ágil , Addison – Wesley.
  • Ron Jeffries , Ann Anderson y Chet Hendrickson (2000), Programación extrema instalada , Addison – Wesley.
  • Craig Larman y V. Basili (2003). "Desarrollo iterativo e incremental: una breve historia", Computadora (IEEE Computer Society) 36 (6): 47–56.
  • Matt Stephens y Doug Rosenberg (2003). Programación extrema refactorizada: el caso en contra de XP , Apress.
  • Waldner, JB. (2008). "Nanocomputadoras e inteligencia de enjambre". En: ISTE, 225–256.

enlaces externos