Metodología ágil: Programación extrema o eXtreme Programming (XP)

Post date: Jun 07, 2010 6:38:25 PM

A Methodology is "A documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner." - Treasure EA Framework. (Una Metodología es un abordaje documentado para la realización de actividades de una manera coherente, sólida, fiable y repetible.)

Extreme Programming o metodología de la programación extrema fue ideada por Kent Beck, a partir de un

conjunto de buenas prácticas y un modo de realizar el desarrollo de software, fundamentado en entregar constantemente, el mayor valor al cliente.

El furor de las metodologías ágiles, a fines del década del '90, tuvo como una de sus mayores protagonistas a XP.

XP tuvo su origen a finales de 1980. A partir de entonces, sus prácticas fueron perfeccionadas y sus ideas se centraron en el desarrollo de un software que fuera, a la vez, adaptativo y orientado a las personas.

Kent profundizó estos temas en sus trabajos como consultor y desarrolló lo que se considera el primer proyecto de Extreme Programming en el "Proyecto Chrysler C3".

Así comenzaron a difundirse las ideas y generarse debates, con publicación de diverso material y libros que fueron abordando con más detalle el tema.

Se editaron numerosas publicaciones, basándose en el Libro Blanco de Kent Beckde 1999, que fue tenido como la "Biblia" de XP.

El Libro Blanco de Kent tuvo una segunda edición en 2004, donde realizó una re-articulación significativa del enfoque, que se describe con un estilo diferente. La primera edición describe cuatro valores, doce prácticas y algunos principios importantes a veces, ignorados) tuvo una enorme influencia en la industria del software, por eso la mayoría de las descripciones de la programación extrema se escribieron basadas en la primera edición. Esto se debe tener en cuenta al leer el material sobre XP, especialmente lo que fue escrito antes de 2005.

En la segunda edición del libro blanco, Kent Beck explica en apenas 160 paginas, los antecedentes y las prácticas de XP. Luego, también publicó una serie de múltiples colores de los libros sobre la programación extrema, entre éstos, se destaca el púrpura.

Esta segunda edición constituye una revisión crítica de lo que pasó en esos cinco años, casi una refundación de XP, aunque sigue apegado a los principios originales, fiel a ellos.

En la primera edición, Windows XP se ha definido con cuatro valores, quince principios básicos y doce prácticas.

La mayoría del material acerca de XP en la web está basado en la primera edición del Libro blanco.

Ahora, los doce prácticas han desaparecido. En el nuevo XP, hay cinco valores, catorce principios, trece prácticas primarias y once prácticas como corolario.

Las nuevas 24 prácticas apenas son un reflejo de las 12 originales.

Dos de ellos, es decir, la metáfora y las normas de codificación, son abandonados.

Dos de ellos, es decir, la metáfora y las normas de codificación, son abandonados.

Esta es una somera descripción de los nuevos conceptos introducidos en la segunda edición del Libro Blanco -( Kent Beck, con Cynthia Andrés, "Extreme Programming explicada - Aceptar el Cambio ", Segunda Edición, Addison Wesley 2005.

Valores XP

En la nueva versión, XP se basa en cinco valores, los elementos básicos que Beck considera realmente importantes para desarrollar software exitosamente.

Estos valores son la guía para el desarrollo en sí mismo y la inspiración de toda la metodología.

Cuatro de ellos son los mismos que en XP original, y se agrega el respeto se agrega como el quinto valor.

Los valores según la segunda edición de XP son los siguientes:

Comunicación:

La mayoría de los problemas y los errores son causados por la falta de comunicación.

Por esta razón, la comunicación entre los miembros del equipo y entre el equipo y los clientes se debe desplegar al máximo.

Por otra parte, la comunicación interpersonal más efectiva es la comunicación directa, cara a cara.

La otra comunicación es la que se establece entre los artefactos y las personas que los leen: deben ser fácil de leer y debe estar actualizada.

Simplicidad:

este es el más intelectual de los valores XP.

Se dice: "Haz la cosa más simple que pueda funcionar". Sin embargo, la simplicidad - no simplista - es muy difícil.

Se requiere experiencia, ideas y trabajo duro.

La simplicidad favorece la comunicación, reduce la cantidad de código y mejora de la calidad.

La directriz principal es: no planificar la posible reutilización en el futura - las nuevas características, se pueden agregar fácilmente, en un sistema sencillo, cuando realmente sean necesarias.

Feedback o retroalimentación:

siempre se debe ser capaz de medir el sistema y saber qué tan lejos está de las características necesarias.

Las herramientas de feedback fundamentales son el contacto cercano con el cliente y la disponibilidad de un conjunto de pruebas automatizadas o testeos, que se desarrollan al mismo tiempo que se desarrolla el sistema mismo.

El feedback es un componente importante de la comunicación - ya que es necesario comunicarse para obtener una devolución o feedback, y a su vez, los comentarios recibidos como feedback, deben estar listos para una nueva comunicación.

También contribuye a la simplicidad. La simplicidad a menudo se obtiene mediante una práctica de tipo "prueba y error" o " try-and-error".

Por otra parte, cuanto más simple es un sistema, más fácil es obtener retroalimentación o feedback sobre él.

Coraje:

todas las metodologías y los procesos son herramientas para manejar y reducir nuestros miedos. Cuanto más miedo tenemos por un proyecto de software, son más grande y más pesadas las metodologías que necesitamos.

La comunicación, la sencillez y la retroalimentación permiten hacer frente con coraje, incluso grandes cambios en los requisitos aunque conlleven la reconstrucción profunda del sistema.

Es un valor que, por sí solo, es peligroso, pero con otros valores, es una poderosa herramienta para hacer frente a los cambios.

Respeto:

los últimos cuatro valores implican un quinto: el respeto.

Si los miembros de un equipo no se preocupan por los demás y su trabajo, no existe una metodología puede funcionar.

Se debe ser respetuoso con los colegas y sus contribuciones, con la organización, y con las personas cuya vida se ve afectada por el sistema que se está codificando.

Los cinco valores no dan asesoramiento específico sobre cómo gestionar un proyecto, ni sobre cómo codificar software.

Para ello, se necesita práctica, pero antes de las práctica, se necesitan principios.

XP se aferra a los principios del desarrollo ágil con un sólido conjunto de técnicas para llevarlos a cabo eficientemente.

XP brinda las herramientas necesarias para poder concretar el agilismo.

Principios XP

En la nueva versión de XP, los principios son el puente entre los valores, que son sintéticos y abstractos, y las prácticas, que indican la forma de desarrollar software.

Los catorce principios de XP son los siguientes:

1- Humanidad: (Humanity)

el software es desarrollado por personas, por tal motivo, el factor humano es la clave principal para entregar software de calidad. XP tiene como objetivo abordar los objetivos de la gente y sus organizaciones, por lo que puede beneficiar a ambos. Por supuesto, es necesario encontrar un equilibrio entre los objetivos. Si se sobreestiman las necesidades de la gente, ellos no van a trabajar correctamente, con la consecuente baja productividad y pérdidas empresariales.

Hasta podría provocar el cierre de la empresa ocasionando gran perjuicio a los trabajadores.

Si se sobreestiman las necesidades de la organización, habrá ansiedad, exceso de trabajo y conflictos. Esto tampoco es bueno para los negocios.

En este libro, las necesidades de las personas son:

• Básicas de seguridad (basic safety)- la necesidad de mantener el trabajo;

• Realización personal (accomplishment)- el sentido de utilidad para su propio trabajo;

• Pertenencia (belonging) - la capacidad de identificarse con un grupo;

• Crecimiento (growth)- la oportunidad de ampliar sus conocimientos y perspectivas;

• Intimidad (intimacy)- la capacidad de entender y ser entendido por otros.

2- Economía: (Economics)

Al producir software, también se debe producir valor para el negocio.

Dos aspectos de la economía son la clave para XP: valor actual y el valor de las opciones. La primera dice que un dólar hoy, vale más que un dólar mañana, por lo que el desarrollo de software más temprano, hace ganar dinero y hacerlo más tarde hace gastar dinero, cuanto más pronto sea, mayor será la ganancia que dará. Esto está relacionado con el valor de las opciones. Si usted puede aplazar las inversiones de diseño hasta que su necesidad sea obvia, es valioso para el negocio. Prácticas de XP, como el diseño incremental, se centran en el valor de negocio para el cliente, y el pago por uso (pay-per-use) facilita aplazar o diferir las decisiones.

3- Beneficio mutuo: (Mutual benefit)

cada actividad debe beneficiar a todas las personas y organizaciones interesadas. Este es, quizás, el principio más importante de XP, y el más difícil de cumplir. siempre hay soluciones fáciles para cualquier problema, donde algunos ganan y otros pierden. A menudo, estas soluciones son atajos tentadores. Sin embargo, son siempre una pérdida neta, debido a que derriba las relaciones y deteriora el medio ambiente de trabajo. Es necesario que se resuelvan más problemas de los que sean creados. Por lo tanto, se necesitan prácticas que sean beneficiosas tanto para la empresa como para el cliente, actualmente y en el futuro.

4- Auto-similitud: (Self-Similarity)

la naturaleza continuamente utiliza estructuras fractales (fractal structures), que son similares a sí mismas, pero en varias escalas. El mismo principio debe aplicarse al desarrollo de software: debemos ser capaces de volver a utilizar soluciones similares, en diferentes contextos. Por ejemplo, un patrón básico de XP es escribir pruebas que fallan, y luego escribir el código que pasa exitosamente el testeo. Esto es cierto en escalas de tiempo diferentes: en un trimestre, se listan los temas a resolver, y luego escribir las historias (stories) que los describen; en una semana, se listan historias para poner en práctica, se escriben los tests de aprobación, y, finalmente, escribir el código para que el testeo funcione, en pocas horas, ya se escribieron los tests (pruebas) unitarios, y luego el código capaz de hacer que funcionen.

5- Mejora: (Improvement)

la mejora continua es la clave para XP. La perfección no existe, pero debe esforzarse continuamente por la perfección. Todos los días usted debe esforzarse para actuar de la mejor manera posible, también en pensar qué hacer para realizarlo aún mejor, mañana. En la práctica, en cada iteración del sistema se mejora en calidad y funcionalidades, utilizando la información (feedback) del cliente, a partir de pruebas (testeos) automatizadas y del propio equipo.

6- Diversidad: (Diversity)

Es muy cómodo cuando,en un equipo son todos iguales, pero estos equipos no son eficaces. Los equipos deben incluir diferentes saberes, habilidades y personalidades, para poder descubrir y resolver problemas.

Por supuesto, ser diferentes conduce a potenciales conflictos, que deben ser gestionados y resueltos.

Tener diferentes opiniones y proponer soluciones diferentes es muy útil en el desarrollo de software, siempre y cuando, sean capaces de gestionar los conflictos y elegir la mejor alternativa.

7- Reflexión: (Reflection)

un equipo eficaz no se limita a hacer su trabajo. Se preguntan cómo están trabajando, y por qué están trabajando de esa manera. Tienen que analizar las razones del éxito - o el fracaso - sin ocultar los errores, hacerlas explícitas y tratando de aprender de ellas. Durante iteraciones trimestral y semanales, se debe tomar tiempo para reflexionar acerca de cómo se está ejecutando el proyecto, y cuáles son las posibles mejoras. Sin embargo, no se debe pensar demasiado.

La ingeniería de software tiene una larga tradición de gente tan ocupada pensando sobre la mejora de procesos, que ya no son capaces de codificar software. La reflexión debe venir después de la acción, y antes de la siguiente acción.

8- Flujo: (Flow)

flujo significa desarrollar constantemente software útil, realizando todas las actividades de desarrollo juntas. Las prácticas de XP suponen un flujo continuo de actividades, no una secuencia de fases diferentes, con el lanzamiento del software sólo después de la última. Sólo el flujo continuo permite la retroalimentación (feedback) para asegurar que el sistema está evolucionando hacia la dirección correcta, y evita los problemas relacionados con la integración final de "big-bang".

9- Oportunidad: (Opportunity)

los problemas deben ser vistos como una oportunidad de mejora. Siempre se presentan problemas, pero para alcanzar la excelencia, no se puede solamente corregir los problemas. Es necesario convertirlos en oportunidades de aprendizaje y mejora. Por ejemplo, si no se pueden hacer planes a largo plazo, Una solución sería el uso de ciclos de planificación trimestrales, y revisar los planes a largo plazo, cada tres meses. Otro ejemplo, si el trabajo individual producido por un desarrollador presenta muchos errores. En ese caso una solución posible es programar de a pares. Las prácticas de XP son eficaces precisamente porque le dan rumbo a problemas viejos, siempre presentes durante el desarrollo de software.

10- Redundancia: (Redundancy)

problemas críticos y difíciles deben resolverse de varias maneras diferentes. Así, si una solución falla, las otras van a prevenir un desastre. En estos casos, el costo de la redundancia es fácilmente pagado. Los defectos de software deben ser buscados, encontrados y corregidos de muchas maneras, (programación en parejas, las pruebas (testeos) automatizadas, sentarse juntos, la participación real de los clientes, etc.) Esto es redundante, ya que, muchas veces se encuantran muchos defectos. Sin embargo, la calidad no tiene precio. Por supuesto, la adición de una práctica que sistemáticamente encuentra defectos que ya se encuentran por otras prácticas es una redundancia inútil, que debe ser evitada.

11- Fallo: (Failure)

No ser capaces de lograr un éxito, es un fallo. Si no se sabe cómo poner en práctica una historia (story), se debe tratar de implementar de tres o cuatro maneras diferentes. Incluso si todas fallan, se habrá aprendido mucho. ¿Es útil el fracaso?

Sí, si enseña algo. Por lo tanto, no se debe temer al fracaso. Es mejor probar algo y fallar, en lugar de demorar demasiado tiempo para una acción, tratando de hacer lo correcto desde el principio.

12- Calidad: (Quality)

La calidad debe ser siempre la máxima posible. Aceptar una menor calidad no produce un ahorro, ni un desarrollo más rápido. Por el contrario, la mejora de la calidad produce necesariamente una mejora de otras características del sistema, como la productividad y la eficiencia. Por otra parte, la calidad no es sólo un factor económico. Los miembros del equipo deben estar orgullosos de su trabajo porque mejora la auto-estima del equipo y la eficacia. No se debe confundir la calidad con el perfeccionismo, sin embargo. Si se demora la acción en búsqueda de la máxima calidad, eso no es promover realmente la calidad. Es mucho mejor intentar y fallar, y luego perfeccionar aquellas soluciones imperfectas encontradas.

13- Pasos de Bebé: (Baby Steps)

grandes cambios, preparados en un largo período de tiempo y hechos de una vez, son peligrosos. Para proceder de manera iterativa, es mucho mejor hacerlo en pasos de bebé - el menor paso que se puede apreciar en la dirección correcta. Por otra parte, pasos de bebé no significa avanzar lentamente. Un equipo capaz de avanzar con pasos de bebé puede dar un montón de ellos en poco tiempo, volviéndose rápido y con alta capacidad de respuesta. Una de las razones detrás de los pasos del bebé es que un pequeño paso en la dirección equivocada ocasiona pequeños daños, mientras que un gran paso puede dañar severamente el proyecto.

14- Aceptación de la responsabilidad: (Accepted Responsibility)

la responsabilidad sólo puede ser aceptada. Es fácil ordenar a los desarrolladores "Haz esto", o "Haz aquello", pero no funciona. Inevitablemente, se le pedirá menos de lo que podría lograrse o, probablemente, más de lo que puede ser logrado. De todos modos, la persona que recibe la orden decidirá si tomará la responsabilidad y aceptará la orden, o no aceptar la responsabilidad y empezar a pasar la pelota.

Prácticas de XP

El nuevo XP se basa en trece prácticas primarias, y once prácticas finales o corolario.

Las prácticas primarias deben ser aplicadas primero, y cada una de ellas puede producir una mejora en el proceso de desarrollo de software.

Las prácticas finales o corolario, por el contrario, requieren tener habilidad (expertise) con las prácticas primarias, y son difíciles de aplicar sin haber aplicado las primarias.

Las 24 prácticas son muy importantes, y se deben aplicar en su totalidad a fin de obtener todos los beneficios posibles gracias a XP.

Kent Beck no clasifica las prácticas. Michele Marchesi, en su trabajo sobre el nuevo XP, describe cuatro categorías:

• Análisis de Requerimientos y Planificación;

• Equipo y factores humanos;

• Diseño;

• Codificación de software y liberación.

Se debe tener en cuenta que muchas prácticas podrían ser asignados a más de una categoría. Por ejemplo, la programación en parejas, se incluye en "Equipo y factores humanos", y también podría pertenecer a "Codificación de software y liberación".

En lo sucesivo, se clasifica cada práctica dentro de la categoría que se considera más adecuada.

Prácticas Primarias

Análisis de Requerimientos y Planificación:

• Historias: (Stories)

las funcionalidades del sistema se describen mediante historias, breves descripciones de funcionalidad visibles al cliente (customer-visible functionalities). Las historias también dirigen el desarrollo del sistema.

• Ciclo semanal: (Weekly Cycle) el desarrollo de software se realiza en ciclos de una semana. Al principio de cada semana hay una reunión en la que las historias a desarrollar en esa semana son elegidas por el cliente.

• Ciclo trimestral: (Quarterly Cycle) en una escala de tiempo mayor, el desarrollo se prevee en ciclos de tres meses cada uno.

Este se compone de reflexiones sobre el equipo, el proyecto y el progreso.

• Holgado: (Slack) evita hacer promesas que no se puedan cumplir. En cualquier plan, se incluyen algunas tareas que se pueden quitar si ocurre un retraso. De esta manera, se mantendrá un margen de seguridad, que se utilizará en el caso de problemas imprevistos.

Equipo y Factores Humanos:

• Sentarse juntos: (Sit Together) los equipos de desarrollo deben trabajar en un espacio abierto, capaz de albergar a todo el equipo, para maximizar la comunicación.

• Equipo completo: (Whole Team) el equipo debe estar compuesto por miembros con todas las habilidades y las perspectivas necesarias para el éxito del proyecto. Deben tener un fuerte sentido de pertenencia, y deben ayudarse unos a otros.

•Área informativa:(Whole Team) el área de trabajo debe tener carteles informativos y otras cosas que brinden información sobre el estado del proyecto y sobre las tareas a realizarse.

• Energización del trabajo: (Energized Work) los desarrolladores deben ser refrescados (refreshed), de modo que puedan concentrarse en su trabajo y ser productivos. En consecuencia, se deben limitar las horas extra de trabajo para que todos puedan tener tiempo para su vida privada. Esta práctica en la antigua versión de XP se denomina "ritmo sostenible"

• Programación de a pares: (Pair Programming) el código se escribe siempre de a dos programadores en una máquina. Esta práctica ya existía en el XP original.

Diseño

• Diseño incremental: (Incremental Design) XP se opone a producir un diseño completo por adelantado. El equipo de desarrollo produce el código tan pronto como sea posible con el fin de obtener la retroalimentación (feedback) y mejorar el sistema continuamente. El diseño es indispensable para obtener un buen código. La pregunta es cuándo diseñar. XP sugiere hacerlo de forma incremental durante la codificación. La forma positiva de lograr esto es la eliminación de duplicaciones en el código.

• Testear Antes de Programar: (Test-First Programming) antes de actualizar y agregar el código, es necesario escribir el testeo a los fines de verificar el código. Esto resuelve cuatro problemas:

(...)

• Cowboy coding: It is easy to get carried away to program quickly and put everything in mind in the code. If we write tests and you have to run them, the tests help us focus on the problem at hand, and can prove that our design is correct.

• Coupling and cohesion: if it isn't easy to write a test, this means that you have a problem of design, not of testing or coding. If your code is loosely coupled and highly cohesive, you can test it easily.

• Trust: if you write code that works and you document it with automated tests, your teammates will trust you.

• Rhythm: it is easy to get lost and wander for hours when you are coding. If you accustom yourself to the rhythm: test, code, refactor, test, code, refactor, it will not happen.

Software Coding and Releasing:

• Ten-Minute Build: System should be built and all of the tests should be finished in ten minutes, in order to execute it often and obtain feedback .

• Continuous Integration: Developers should be integrating changes every two hours in order to ease integration headaches.

Corollary Practices

Requirement Analysis and Planning:

• Real Customer Involvement: people whose lives are affected by your system must became a part of the team and they can contribute to quarterly and weekly planning.

• Incremental Deployment: when replacing a legacy system, start to replace some functionalities right away and gradually replace all system. Avoid the approach of “All or nothing.”

• Negotiated Scope Contract: contracts for software development would have fixed time, costs, and quality, but the precise scope of the system would have to be negotiated during the same realization. Eventually it is better to have a sequence of short contracts in order to reduce risks.

• Pay-Per-Use: customer usually pays for each release of the software. This creates a conflict between the supplier and the customer, who would want fewer releases each containing a lot of functionalities. Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.

Team and Human Factors:

• Team Continuity: the development teams must remain the same in several projects. The relationship they share in a project are precious and they do not have to be dispersed.

• Shrinking Teams: as the team becomes more capable and productive, keep its load constant but gradually reduce its size, send free members to form more teams.

Design:

• Root-Cause Analysis:every time you find a defect, eliminate it and its causes. In this away, not just you will eliminate the defect, but also you will prevent making the same mistake again.

Software Coding and Releasing:

• Code and Tests: only code and tests are permanent artifacts and they have to be preserved. The other documents can be generated from code and tests.

• Shared Code: anyone in the development team must be able to change any part of system at any time. This practice was called “collective code ownership” in the original XP.

• Single Code Base: there is only one official version of system. You can develop a temporary branch, but it doesn't live longer than a few hours.• Daily Deployment: every night you must put new software into production. It is risky and costly to have a gap between the version of software released into production and ones you have in your computer.

You must note that in the new XP we cannot find original practices of coding standards, that is considered obvious and not more essential thing, and metaphor which was the most complex to define and understand and the most difficult to implement among the twelve original practices.

After this shortly list of twenty-four practices, we can analyze the link between them and the twelve original practices. Indeed, only a few practices correspond with original ones. Some practices expand original ones and some are really new. For example, “planning game,” which was the practice describing the XP process planning, is divided into four new practices (“stories”, “weekly cycle”, “quarterly cycle” and “slack”.

The following table lists the new and old practices. They are divided into categories. The table shows the relationship between new practices and old ones. It shows easily the difference between old and new XP.

New practices(columna izquierda) Old practices (columna derecha)

In conclusion, I have shown clearly, as Beck' s new book proposes, an agile way to produce software. The new XP is very different from the one in the original book. Surely, any original principle is negated and the second edition of the book is an evolution from the first one. It includes the lessons learned in these five years since the first book. However, many new things are introduced. We can find many new practices and principles we cannot find in the first edition. I don't know whether some supporters of original XP will accuse Beck of the heresy versus his same method or they will be faithful and consider to try and apply the new ideas. Anyway I think that Beck' s goal is not to give a solution “by the book,” to which you must adhere rigorously. He is opening a deep discussion about the way to develop software and suggest new ideas for each company to develop its own XP process with their own experience and context.

Sobre los Valores, principios y prácticas.

XP comienza con cinco valores (Comunicación, Feedback o reciprocidad, Simplicidad, Coraje y Respeto).

A partir de estos, se desarrollaron catorce principios y luego veiticuatro prácticas.

Las prácticas son las cosas concretas que un equipo puede hacer día a día, mientras que los valores son el conocimiento fundamental y la comprensión en que se basa el enfoque.

Los valores sin las prácticas son difíciles de aplicar y pueden ser llevados a cabo de tantas formas, que hacen difícil saber por dónde empezar.

Las prácticas sin los valores son, tan sólo, actividades de rutina sin un propósito.

Tanto los valores como las prácticas son necesarios, pero hay una gran diferencia entre ellos y son los Principios los que ayudan a cerrar esa brecha.

Muchas de las prácticas de XP son técnicas viejas y probadas aunque, a menudo, olvidadas, inclusive en los procesos de planificación.

Además de rescatar estas técnicas, XP propicia una sinergia donde cada uno es reforzado por el otro y son los valores dan el sentido.

Uno de los Principios más fuertes es su insistencia en las pruebas o testeos.

Hace gran énfasis en el testeo y lo pone en la base del desarrollo, siendo todos los programadores encargados, tanto de escribir el código, como de escribir los test cases o casos de testeo del código que producen.

Las pruebas o testeos se suman a una integración continua y a un proceso de construcción que brinda una plataforma muy estable para el desarrollo futuro.

Este enfoque de XP habitulmente se describe como "Test Driven Development" (TDD) y ha sido de gran influencia, y de práctica frecuente, aun en lugares donde no han adoptado mucho más de XP.

continuar.....

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software. Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Características fundamentales

• • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

  • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación (Test Driven Development). Se pueden utilizar herramientas para PruebaUnitaria como [JUnit].

  • Programación En Pareja: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

  • Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.

  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

http://es.wikipedia.org/wiki/Programación_Extrema

Fragmentos basados en la publicación en inglés: "The New XP" de Michele Marchesi