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:
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.
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:
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
Pruebas
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:
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 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]
{{cite book}}: |work=ignorado ( ayuda )
