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 de los clientes. 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 pueden adoptar nuevos requisitos de los clientes.
Otros elementos de la programación extrema incluyen programación en pares o revisión exhaustiva del código , pruebas unitarias de todo el código, no programar funciones 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 comprende mejor el problema y 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". 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 en pares ).
Kent Beck desarrolló programación extrema durante su trabajo en el proyecto de nómina del Sistema de Compensación Integral (C3) de Chrysler . [5] Beck se convirtió en 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 Objectives , 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 influencia importante 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 desarrollar, planificar y escribir pruebas primero en la prueba antes de cada microincremento" se utilizó ya en el Proyecto Mercurio de la NASA , a principios de la década de 1960. [7] Para acortar el tiempo total de desarrollo, algunos documentos de prueba formales (como las pruebas de aceptación ) se han desarrollado en paralelo (o poco antes) de que el software esté listo para las pruebas. 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 incluso de secciones pequeñas de codificación de software, en lugar de solo probar las características más importantes.
Dos influencias principales dieron forma al desarrollo del software en la década de 1990:
Los requisitos que cambiaban rápidamente exigían ciclos de vida de producto más cortos y, a menudo, chocaban con los métodos tradicionales de desarrollo de software.
El Sistema Integral de Compensación de Chrysler (C3) comenzó con el fin de determinar la mejor forma de utilizar las tecnologías de objetos, utilizando como objeto de investigación los sistemas de nómina de Chrysler, con Smalltalk como lenguaje y GemStone como capa de acceso a datos . Chrysler contrató a Kent Beck , [5] 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 frecuente, Ward Cunningham . Beck describe la concepción temprana de los métodos: [8]
La primera vez que me pidieron que liderara un equipo, les pedí que hicieran algunas de las cosas que consideraba sensatas, como pruebas y revisiones. La segunda vez había mucho más en juego. Pensé: "Malditos torpedos, al menos esto será un buen artículo", [y] pedí al equipo que subiera todas las perillas a 10 en las cosas que pensaba que eran esenciales y dejara de lado 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.
Información sobre los principios y prácticas detrás de XP difundida a todo el mundo a través de discusiones en la wiki original, WikiWikiWeb de Cunningham . Varios contribuyentes discutieron y ampliaron las ideas, y dieron como resultado algunas metodologías derivadas (ver desarrollo ágil de software ). Además, los conceptos de XP han sido explicados [ ¿por quién? ] , durante varios años, utilizando un mapa del 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 Objectives (1999, ISBN 0-201-61641-6 ), difundiendo sus ideas a una audiencia mucho más amplia. Los autores de la serie repasaron varios aspectos relacionados con XP y sus prácticas. La serie incluyó un libro crítico con las prácticas.
XP generó un interés significativo entre las comunidades de software a finales de los años 1990 y principios de los años 2000, viendo su adopción en una serie de entornos radicalmente diferentes a sus orígenes.
La alta disciplina requerida por las prácticas originales a menudo quedó en el camino, causando que algunas de estas prácticas, como aquellas consideradas demasiado rígidas, fueran desaprobadas o reducidas, o incluso dejadas sin terminar, en sitios individuales. Por ejemplo, la práctica de 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 mutuamente acordadas. Un cronograma más relajado podría evitar que las personas se sientan apuradas a generar talones artificiales sólo para pasar las pruebas al final del día. En cambio, un cronograma menos rígido permite el desarrollo de funciones complejas durante un período de varios días.
Mientras tanto, otras prácticas de desarrollo ágil no se han quedado quietas y, a partir de 2019, [update]XP continúa evolucionando, asimilando más lecciones de experiencias en el campo, para utilizar otras prácticas. En la segunda edición de Extreme Programming Objectives (noviembre de 2004), cinco años después de la primera edición, Beck añadió más valores y prácticas y diferenció entre prácticas primarias y corolarias.
La programación extrema explicada 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 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 de la metodología ágil.
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.
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 ideas sobre problemas de programación. Un programador que se enfrenta a un problema de programación complejo, o le resulta difícil explicar la solución a otros programadores, podría codificarlo de forma simplificada y utilizar el código para demostrar lo que quiere decir. El código, dicen los defensores de esta posición, es siempre claro y conciso y no puede interpretarse de más de una manera. Otros programadores pueden dar su opinión sobre este código codificando también sus pensamientos.
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 defectos, muchas pruebas pueden eliminar muchos más defectos.
Inicialmente, se alentaron las pruebas de integración en todo el sistema como una actividad diaria al final del día, para la detección temprana de interfaces incompatibles, para reconectarse antes de que las secciones separadas se separaran ampliamente de una funcionalidad coherente. Sin embargo, las pruebas de integración en todo el sistema se han reducido a semanalmente o con menos frecuencia, dependiendo de la estabilidad de las interfaces generales del sistema. [ cita necesaria ]
Los programadores deben escuchar qué necesitan los clientes que haga el sistema, qué " lógica empresarial " se necesita. Deben comprender estas necesidades lo suficientemente bien como para brindarle al cliente comentarios 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 con más detalle en el juego de planificación .
Desde el punto de vista de la simplicidad, por supuesto, se podría decir que el desarrollo de un sistema 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á. Uno puede recorrer un largo camino sin diseñar, pero en un momento dado se quedará estancado. El sistema se vuelve demasiado complejo y las dependencias dentro del sistema dejan de ser claras. Esto se puede evitar creando una estructura de diseño que organice la lógica del 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 necesaria ]
La programación extrema reconoció inicialmente cuatro valores en 1999: comunicación, sencillez, retroalimentación y coraje. Un nuevo valor, el respeto, se agregó en la segunda edición de Extreme Programming Explicated . Esos 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 logra mediante la documentación. Las técnicas de programación extrema pueden verse como métodos para construir y difundir rápidamente 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. Con este fin, la programación extrema favorece diseños simples, metáforas comunes, colaboración de usuarios y programadores, comunicación verbal frecuente y retroalimentación.
La programación extrema anima a empezar con la solución más sencilla. Luego se pueden agregar funciones adicionales más adelante. La diferencia entre este enfoque y los métodos de desarrollo de sistemas más convencionales es el enfoque en diseñar y codificar 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). [10] Los defensores de XP reconocen la desventaja de que esto a veces puede implicar más esfuerzos 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 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, y tal vez retrasar 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.
Dentro de la programación extrema, la retroalimentación se relaciona con diferentes dimensiones del desarrollo del sistema:
La retroalimentación está estrechamente relacionada con la comunicación y la simplicidad. Los fallos en el sistema se comunican fácilmente escribiendo una prueba unitaria que demuestre que un determinado fragmento de código se romperá. La retroalimentación directa del sistema les dice a los programadores que recodifican esta parte. Un cliente puede probar el sistema periódicamente según 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 valentía. Uno es el mandamiento de diseñar y codificar siempre para hoy y no para mañana. Este es un esfuerzo para evitar estancarse 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. [5] Esto significa revisar el sistema existente y modificarlo para que los cambios futuros puedan implementarse más fácilmente. Otro ejemplo de valentía es saber cuándo desechar el código: valentía 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, coraje significa perseverancia: un programador puede quedarse atrapado 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 de otro modo 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 mediante la refactorización.
La adopción de los cuatro valores anteriores genera el respeto de los demás miembros del equipo. Nadie en el equipo debería 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 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 respalda esas actividades.
Ken Auer [13] 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 llevarse a cabo 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
Los principios que forman la base de XP se basan en los valores que acabamos de describir y están destinados a fomentar decisiones en un proyecto de desarrollo de sistemas. Se pretende que los principios sean más concretos que los valores y se traduzcan más fácilmente en orientación en una situación práctica.
La programación extrema considera que la retroalimentación es más útil si se realiza con frecuencia y prontitud. Destaca 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 comentarios frecuentes del cliente, una decisión de diseño equivocada tomada por el desarrollador se notará 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 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 automatizado de pruebas unitarias revelará la falla inmediatamente, 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 integral y automatizado significaba que dicho cambio de código, que el desarrollador consideraba inofensivo, se habría dejado en su lugar y habría aparecido sólo durante las pruebas de integración (o peor aún, sólo 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.
Se trata de tratar cada problema como si su solución fuera "extremadamente sencilla". Los métodos tradicionales de desarrollo de sistemas exigen planificar el futuro y codificar para que sea reutilizable. La programación extrema rechaza estas ideas.
Los defensores de la programación extrema dicen que hacer grandes cambios todos a la vez no funciona. La programación extrema aplica cambios incrementales: por ejemplo, un sistema puede tener pequeñas versiones cada tres semanas. Cuando se dan muchos pequeños pasos, el cliente tiene más control sobre el proceso de desarrollo y el sistema que se está desarrollando.
El principio de aceptar el cambio consiste en no trabajar en contra de los cambios, sino 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 tiene 12 prácticas, agrupadas en cuatro áreas:
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 los gastos generales formales. Los críticos de XP afirman que esto puede conducir a costosas reelaboraciones y al alcance del proyecto más allá de lo acordado o financiado previamente. [ cita necesaria ]
Los tableros de control de cambios son una señal de que existen posibles conflictos en los objetivos del proyecto y limitaciones entre múltiples usuarios. Los métodos acelerados de XP dependen en cierta medida 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 documentar los objetivos y limitaciones del compromiso. [14] Esto también se aplica cuando participan varias organizaciones de programación, en particular organizaciones que compiten por partes de proyectos. [ cita necesaria ]
Otros aspectos potencialmente controvertidos de la programación extrema incluyen:
Los críticos han notado varios inconvenientes potenciales, [5] incluidos problemas con requisitos inestables, compromisos no documentados de conflictos de usuarios y falta de una especificación o documento de diseño general.
Thoughtworks ha afirmado un éxito razonable en proyectos XP distribuidos con hasta sesenta personas. [ cita necesaria ]
En 2004, se introdujo la programación industrial extrema (IXP) [15] como una evolución de XP. Su objetivo es brindar la capacidad de trabajar en equipos grandes y distribuidos. Ahora cuenta con 23 prácticas y valores flexibles.
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. [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 o son capaces de adoptar todas las prácticas; por lo tanto, todo el proceso falla. El libro también hace otras críticas y traza una semejanza del modelo de "propiedad colectiva" de XP con el socialismo de manera negativa.
Ciertos aspectos de XP han cambiado desde la publicación de Extreme Programming Refactored ; en particular, XP ahora admite modificaciones de 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 sostienen 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 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 del modelo de madurez de capacidad (CMMI) y Six Sigma . Descubrieron que los tres sistemas se refuerzan mutuamente, conducen a un mejor desarrollo y no se contradicen entre sí. [dieciséis]
El revuelo inicial de la programación extrema y los principios controvertidos, como la programación en pares y el diseño continuo , han atraído críticas particulares, como las provenientes 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 sobre el 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]
{{cite book}}: |work=ignorado ( ayuda )
