Programación extrema

La programación extrema ( XP ) es una metodología de desarrollo de software destinada a mejorar la calidad del software y la capacidad de respuesta a los requisitos cambiantes del cliente. Como tipo de desarrollo de software ágil , ^{[1] [2] [3]} aboga por lanzamientos frecuentes en ciclos de desarrollo cortos, destinados a mejorar la productividad e introducir puntos de control en los que se puedan adoptar nuevos requisitos del cliente.

Otros elementos de la programación extrema incluyen la programación en pares o hacer una revisión extensa del código , pruebas unitarias de todo el código, no programar características hasta que realmente se necesiten , una estructura de gestión plana, simplicidad y claridad del código, esperar cambios en los requisitos del cliente a medida que pasa el tiempo y se entiende mejor el problema, y ​​una comunicación frecuente con el cliente y entre programadores. ^{[2] [3] [4]} 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". Como ejemplo, las revisiones de código se consideran una práctica beneficiosa; llevada al extremo, el código puede revisarse continuamente (es decir, la práctica de la programación en pares ).

Kent Beck desarrolló la programación extrema durante su trabajo en el proyecto de nómina del Sistema de Compensación Integral de Chrysler (C3) . ^[5] 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). ^[5] Chrysler canceló el proyecto C3 en febrero de 2000, después de siete años, cuando Daimler-Benz adquirió la empresa. ^[6] Ward Cunningham fue otra gran influencia en XP.

Muchas prácticas de programación extrema han existido 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 escritura de pruebas antes de cada microincremento" se utilizó ya en el Proyecto Mercury de la NASA , a principios de la década de 1960. ^[7] Para acortar el tiempo total de desarrollo, se han desarrollado algunos documentos de prueba formales (como para pruebas de aceptación ) en paralelo (o poco antes) con el software listo para la prueba. Un grupo de prueba independiente de la NASA puede escribir los procedimientos de prueba, en función de los requisitos formales y los 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 características más grandes.

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

• Internamente, la programación orientada a objetos reemplazó a la programación procedimental como el paradigma de programación preferido por algunos desarrolladores.
• Externamente, el auge de Internet y el boom de las punto-com enfatizaron la velocidad de comercialización y el crecimiento de la empresa como factores comerciales competitivos.

Los requisitos que cambiaban rápidamente exigían ciclos de vida de los productos más cortos y a menudo entraban en conflicto 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 datos . Chrysler contrató a Kent Beck , ^[5] un destacado practicante de Smalltalk, para realizar ajustes de rendimiento en el sistema, pero su papel se expandió 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 frecuente, Ward Cunningham . Beck describe la concepción inicial de los métodos: ^[8]

La primera vez que me pidieron que dirigiera un equipo, les pedí que hicieran algunas de las cosas que yo consideraba sensatas, como pruebas y revisiones. La segunda vez, había mucho más en juego. Pensé: "Al diablo con los torpedos, al menos esto dará para un buen artículo", [y] le pedí al equipo que pusiera todo el empeño en las cosas que yo consideraba esenciales y dejara de lado todo lo demás.

Beck invitó a Ron Jeffries al proyecto para que ayudara a desarrollar y perfeccionar estos métodos. Jeffries actuó como entrenador para inculcar las prácticas como hábitos en el equipo C3.

La información sobre los principios y prácticas detrás de XP se difundió al resto del mundo a través de discusiones en la wiki original , Cunningham's WikiWikiWeb . Varios colaboradores discutieron y ampliaron las ideas, y surgieron algunas metodologías derivadas (ver desarrollo de software ágil ). Además, los conceptos de XP se han explicado ^{[ ¿por quién? ]} durante varios años, utilizando un mapa de sistema de hipertexto en el sitio web de XP en http://www.extremeprogramming.org c.  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 un público mucho más amplio. Los autores de la serie analizaron diversos aspectos de XP y sus prácticas. La serie incluyó un libro crítico de las prácticas.

XP generó un interés significativo entre las comunidades de software a fines de la década de 1990 y principios de la década de 2000, y fue adoptado en una cantidad de entornos radicalmente diferentes a sus orígenes.

La alta disciplina que exigían las prácticas originales a menudo se dejaba de lado, lo que hacía que algunas de estas prácticas, como las que se consideraban demasiado rígidas, se desaprobaran o redujeran, o incluso se dejaran sin terminar, en sitios individuales. Por ejemplo, la práctica de realizar pruebas de integración al final del día para un proyecto en particular podría cambiarse a un cronograma de fin de semana, o simplemente reducirse a pruebas en fechas acordadas mutuamente. Un cronograma más relajado de este tipo podría evitar que las personas se sintieran apuradas a generar stubs artificiales solo para pasar las pruebas del final del día. Un cronograma menos rígido permite, en cambio, el desarrollo de características complejas durante un período de varios días.

Mientras tanto, otras prácticas de desarrollo ágil no se han quedado estancadas y, a partir de 2019, ^[update]XP sigue evolucionando, asimilando más lecciones de 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 diferenció entre prácticas primarias y corolarias.

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 múltiples 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 se deben planificar, 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 de la metodología ágil.

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

Los defensores de XP sostienen que el único producto verdaderamente importante del proceso de desarrollo de sistemas es el código, es decir, las instrucciones de software que un ordenador puede interpretar. Sin código, no hay ningún producto funcional.

La codificación puede utilizarse para determinar la solución más adecuada. También puede ayudar a comunicar ideas sobre problemas de programación. Un programador que se enfrenta a un problema de programación complejo o que tiene dificultades para explicar la solución a otros programadores puede codificarlo de forma simplificada y utilizar el código para demostrar lo que quiere decir. El código, dicen los defensores de esta postura, siempre es 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 ideas.

Las pruebas son fundamentales para la programación extrema. ^[9] El enfoque de la programación extrema es que si unas pocas pruebas pueden eliminar algunos fallos, muchas pruebas pueden eliminar muchos más fallos.

• Las pruebas unitarias determinan si una característica determinada funciona como se esperaba. Los programadores escriben tantas pruebas automatizadas como se les ocurran que puedan "romper" el código; si todas las pruebas se ejecutan correctamente, entonces la codificación está completa. Cada fragmento de código que se escribe se prueba antes de pasar a la siguiente característica.
• Las pruebas de aceptación verifican que los requisitos tal como los entienden los programadores satisfacen los requisitos reales del cliente.

Inicialmente, se recomendó que las pruebas de integración de todo el sistema se realizaran como una actividad diaria al final del día para detectar de forma temprana las interfaces incompatibles y volver a conectarlas antes de que las distintas secciones se distanciaran considerablemente de la funcionalidad coherente. Sin embargo, las pruebas de integración de todo el sistema se han reducido a una frecuencia semanal o con menor frecuencia, según la estabilidad de las interfaces generales del sistema. ^{[ cita requerida ]}

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 brindarle al cliente retroalimentación sobre los aspectos técnicos de cómo se podría resolver el problema, o no. La comunicación entre el cliente y el programador se aborda más a fondo en el juego de planificación .

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 debería ser un sistema que funcione. En la práctica, esto no funcionará. Se puede llegar muy lejos sin diseñar, pero en un momento dado uno se queda atascado. 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. ^{[ cita requerida ]}

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

La creació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 lleva a cabo mediante la documentación. Las técnicas de programación extrema pueden considerarse métodos para crear y difundir rápidamente el conocimiento institucional entre los miembros de un equipo de desarrollo. El objetivo es proporcionar a todos los desarrolladores una visión compartida del sistema que coincida con la visión 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.

La programación extrema fomenta el inicio 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 semana que viene o el mes que viene. Esto a veces se resume como el enfoque " No lo vas a necesitar " (YAGNI, por sus siglas en inglés). ^[10] Los defensores de XP reconocen la desventaja de que esto a veces puede implicar más esfuerzo mañana para cambiar el sistema; afirman que esto se compensa con creces con la ventaja de no invertir en posibles requisitos futuros que podrían cambiar antes de que se vuelvan relevantes. Codificar y diseñar para requisitos futuros inciertos implica el riesgo de gastar recursos en algo que podría no ser necesario, al tiempo que tal vez se retrase la aparición de 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. Un diseño simple con un código muy simple podría ser fácilmente comprendido por la mayoría de los programadores del equipo.

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

• Retroalimentación del sistema: al escribir pruebas unitarias , ^[5] o ejecutar pruebas de integración periódicas, los programadores tienen retroalimentación directa 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. Ellos 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 una determinada parte del código fallará. La retroalimentación directa del sistema indica a los programadores que vuelvan a codificar esta parte. Un cliente puede probar el sistema periódicamente de acuerdo con los requisitos funcionales, conocidos como historias de usuario . ^[5] Para citar a Kent Beck , "El optimismo es un riesgo laboral de la programación. La retroalimentación es el tratamiento". ^[11]

Varias prácticas encarnan el coraje. Una de ellas es el mandamiento de siempre diseñar y codificar para hoy y no para mañana. Se trata de un esfuerzo para evitar empantanarse en el diseño y requerir mucho esfuerzo para implementar cualquier otra cosa. El coraje permite a los desarrolladores sentirse cómodos con la refactorización de su código cuando sea necesario. ^[5] 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 empleado para crearlo. Además, coraje significa persistencia: un programador puede estar atascado en un problema complejo durante un día entero, y luego resolver el problema rápidamente al día siguiente, pero solo si es persistente.

El valor del respeto incluye el respeto por los demás y el respeto por uno mismo. Los programadores nunca deben realizar cambios que interrumpan la compilación, que hagan que las pruebas unitarias existentes fallen o que retrasen de algún modo el trabajo de sus compañeros. 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 mediante la refactorización.

La adopción de los cuatro valores anteriores conduce a ganarse el respeto de los demás miembros del equipo. Nadie en el equipo debe sentirse despreciado o ignorado. Esto garantiza un alto nivel de motivación y fomenta la lealtad hacia el equipo y hacia el objetivo del proyecto. Este valor depende de los demás valores y está orientado al trabajo en equipo.

La primera versión de las reglas para XP fue publicada en 1999 por Don Wells ^[12] 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 mencionan explícitamente para contrarrestar las afirmaciones de que XP no admite esas actividades.

^{Ken Auer [13]} propuso otra versión de las reglas de XP en XP/Agile Universe 2003. Consideraba que XP se definía por sus reglas, no por sus prácticas (que están sujetas a más variación y ambigüedad). Definió dos categorías: "Reglas de compromiso", 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 compromiso.

Aquí están algunas de las reglas (incompletas):

Codificación

• El cliente siempre está disponible
• Codifique primero la prueba unitaria
• Sólo un par integra código a la vez
• Deje la optimización para el final
• Sin horas extras

Pruebas

• Todo el código debe tener pruebas unitarias
• Todo el código debe pasar todas las pruebas unitarias antes de poder publicarse.
• Cuando se encuentra un error , se crean pruebas antes de solucionarlo (un error no es un error de lógica; es una prueba que no fue escrita)
• Se realizan pruebas de aceptación con frecuencia y se publican los resultados.

Los principios que forman la base de XP se basan en los valores que acabamos de describir y tienen como objetivo fomentar la toma de decisiones en un proyecto de desarrollo de sistemas. Los principios tienen como objetivo ser más concretos que los valores y traducirse más fácilmente en una guía para una situación práctica.

La programación extrema considera que la retroalimentación es más útil si se realiza con frecuencia y rapidez. Hace hincapié en que un retraso mínimo entre una acción y su retroalimentación es fundamental para aprender y hacer cambios. A diferencia de los métodos de desarrollo de sistemas tradicionales, 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 retroalimentación y dirigir el desarrollo según sea necesario. Con una retroalimentación frecuente del cliente, una decisión de diseño errónea tomada por el desarrollador se detectará y se 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 retroalimentació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 un fallo en alguna otra parte del sistema de la que el desarrollador sabe poco o nada, el conjunto de pruebas unitarias automatizadas revelará el fallo 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. Con las prácticas de desarrollo tradicionales, la ausencia de un conjunto de pruebas unitarias automatizadas y completas significaba que un cambio de código de ese tipo, que el desarrollador suponía inofensivo, 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 anteriores a las pruebas de integración, era una tarea formidable.

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

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

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

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

• Programación en pares ^[5]
• Juego de planificación
• Desarrollo basado en pruebas
• Todo el equipo

• Integración continua
• Refactorización o mejora del diseño ^[5]
• Pequeños lanzamientos

• Normas de codificación
• Propiedad colectiva del código ^[5]
• Diseño simple ^[5]
• Metáfora del sistema

• Ritmo sostenible

Las prácticas en XP han sido muy debatidas. ^[5] Los defensores de la programación extrema afirman que al hacer que el cliente en el sitio ^[5] solicite cambios de manera informal, el proceso se vuelve flexible y ahorra el costo de la sobrecarga formal. Los críticos de XP afirman que esto puede llevar a una costosa reelaboración y a una ampliación del alcance del proyecto más allá de lo acordado o financiado previamente. ^{[ cita requerida ]}

Los paneles de control de cambios son una señal de que existen conflictos potenciales en los objetivos y las limitaciones del proyecto entre varios usuarios. Los métodos acelerados de XP dependen en cierta medida de que los programadores puedan asumir un punto de vista unificado del cliente, de modo que el programador pueda concentrarse en la codificación, en lugar de en la documentación de los objetivos y las limitaciones de compromiso. ^[14] Esto también se aplica cuando participan varias organizaciones de programación, en particular organizaciones que compiten por participaciones en los proyectos. ^{[ cita requerida ]}

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 especificaciones.
• Los requisitos se definen de forma incremental, en lugar de intentar obtenerlos todos de antemano.
• Generalmente se requiere que los desarrolladores de software trabajen en parejas.
• No hay un gran diseño inicial . La mayor parte de la actividad de diseño se lleva a cabo sobre la marcha y de forma incremental, comenzando con "lo más simple que podría funcionar" y agregando complejidad solo cuando lo requieren las pruebas fallidas. Los críticos caracterizan esto como " depurar un sistema hasta lograr su apariencia" y temen que esto resulte en un mayor esfuerzo de rediseño que solo rediseñar cuando cambian los requisitos.
• Un representante del cliente está asignado al proyecto. Esta función puede convertirse en un punto único de fallo para el proyecto y algunas personas han descubierto que es una fuente de estrés. Además, existe el peligro de que un representante no técnico intente imponer el uso de las características y la arquitectura del software técnico.

Los críticos han señalado varios inconvenientes potenciales, ^[5] incluidos problemas con requisitos inestables, falta de compromisos documentados de conflictos de usuarios y una falta de una especificación o documento de diseño general.

Thoughtworks ha logrado un éxito razonable en proyectos de XP distribuidos con hasta sesenta personas. ^{[ cita requerida ]}

En 2004 se introdujo la programación industrial extrema (IXP) ^[15] como una evolución de XP. Su objetivo era brindar la capacidad de trabajar en equipos grandes y distribuidos. Actualmente cuenta con 23 prácticas y valores flexibles.

En 2003, Matt Stephens y Doug Rosenberg publicaron Extreme Programming Refactored: The Case Against XP , que cuestionaba el valor del proceso XP y sugería formas en las que podría mejorarse. ^[6] Esto desencadenó un largo debate en artículos, grupos de noticias de Internet y áreas de chat de 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/pueden adoptar todas las prácticas; por lo tanto, todo el proceso falla. El libro también hace otras críticas y establece una similitud entre el modelo de "propiedad colectiva" de XP y el socialismo de una manera negativa.

Algunos aspectos de XP han cambiado desde la publicación de Extreme Programming Refactored ; en particular, XP ahora permite modificaciones en las prácticas siempre que se cumplan los objetivos requeridos. XP también utiliza términos cada vez más genéricos para los procesos. Algunos sostienen que estos cambios invalidan las 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. Algunas de estas XP buscaron reemplazar, como la metodología en 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 . Encontraron que los tres sistemas se reforzaban bien entre sí, lo que conducía a un mejor desarrollo, y no se contradecían entre sí. ^[16]

El revuelo inicial de la programación extrema y sus controvertidos principios, como la programación en pareja y el diseño continuo , han atraído críticas particulares, como las de McBreen, ^[17] Boehm y Turner, ^[18] Matt Stephens y Doug Rosenberg. ^[19] Sin embargo, los profesionales ágiles creen que muchas de las críticas son malentendidos del desarrollo ágil. ^[20]

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

• Desarrollo de software ágil
• Obsolescencia continua
• Fabricación extrema
• Gestión de proyectos extremos
• Prácticas de programación extrema
• Kaizen
• Lista de filosofías de desarrollo de software
• Programación en pareja
• Scrum (desarrollo)
• Artesanía de software
• Reunión de pie
• Bloqueo de tiempo

• Ken Auer y Roy Miller. Programación extrema aplicada: jugar para ganar , Addison–Wesley.
• Ken Auer; Ron Jeffries ; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). "¿Los testers están extintos? ¿Cómo pueden contribuir los testers a los equipos XP?". Programación extrema y métodos ágiles: XP/Agile Universe 2002. Lecture Notes in Computer Science. Vol. 2418. Springer-Verlag. p. 287. doi :10.1007/3-540-45672-4_50. ISBN 978-3-540-44024-6.
• Kent Beck : Extreme Programming Explained: Embrace Change (Extrema programación explicada: acepte el cambio) , Addison–Wesley. Primera edición, 1999. Segunda edición, con Cynthia Andres, 2004.
• Kent Beck y Martin Fowler : Planificación de programación extrema , Addison–Wesley.
• Alistair Cockburn : Desarrollo de software ágil , Addison–Wesley.
• Martin Fowler : Refactorización: mejora del diseño del código existente . Con Kent Beck, John Brant, William Opdyke y Don Roberts (1999). Addison-Wesley.
• Harvey Herela (2005). Caso práctico: El sistema integral de compensación de Chrysler. Galen Lab, 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.
• Larman, C. ; Basili, VR (junio de 2003). "Desarrollos iterativos e incrementales. Una breve historia" (PDF) . Computer . 36 (6): 47–56. doi :10.1109/MC.2003.1204375.
• Matt Stephens y Doug Rosenberg (2003). Programación extrema refactorizada: el caso contra XP , Apress.
• Waldner, JB. (2008). "Nanocomputadoras e inteligencia de enjambre". En: ISTE, 225–256.

Wikimedia Commons tiene medios relacionados con Programación extrema .

Wikiquote tiene citas relacionadas con Programación extrema .

• Una introducción suave
• Programación Industrial Extrema
• Problemas y soluciones para la implementación de XP
• Uso de un proceso de software ágil con desarrollo offshore: experiencias de ThoughtWorks con la implementación de XP en proyectos distribuidos de gran tamaño