La programación extrema (XP) es una metodología de desarrollo, si puede ser considerada como tal, pues se caracteriza por ser un conjunto de prácticas y no está considerada como metodología por una extensa mayoría de ingenieros del software.

No obstante, es de extendido uso en proyectos software y sus prácticas han sido de amplia aceptación en muchos casos, sobre todo proyectos pequeños o medianos debido a su curva de aprendizaje suave, a producir código de calidad, completamente funcional, sin fallos ni sorpresas para el cliente, que, siempre percibirá un producto final adecuado a sus necesidades, no a lo que creen los analistas o desarrolladores que necesita el cliente.

En contraposición, en mi opinión y experiencia, muchos clientes acostumbrados a la tradicional metodología de análisis y desarrollo (ciclo de vida en cascada) y a los presupuestos cerrados, ponen excesivas trabas a la implantanción de dicha metodología en sus proyectos.

Dicho sea de paso, que el modelo de presupuesto cerrado, no garantiza la consecución óptima en cuanto a lo que realmente el cliente quiere y necesita, si no interfiere enormemente ecorsetando excesivamente al equipo de desarrollo que se ve obligado a realizar estimaciones que en la mayoría de los casos no son realistas, con los problemas que ésto acarrea. En programación extrema, el cliente, sabrá aproximadamente cuanto costará su software tras el "Planning Game" y se definirá una hoja de ruta prevista y pactada con el cliente, lo cual no es determinante ni obligatorio seguir a rajatabla en ningún caso, pues sirve como referencia.

Las prácticas que han sido de ámplia aceptación dentro del colectivo de desarrolladores de software y que la programación extrema ha adoptado son principalmente los siguientes:

• Planning Game o fase de planificación del proyecto, con prácticas poco ortodoxas y muy válidas como la formación del cliente en sus lagunas dentro del trabajo a realizar
• Iteraciones cortas en la liberación de versiones del software completamente funcionales e integración contínua
• Tests automatizados en el desarrollo de software para obtener un código libre de errores
• Refactoring o refactorización, que permite obtener código de alta calidad
• Programación por parejas y propiedad colectiva del código, lo cual permite avanzar a los desarrolladores en formación y conocimientos
• Modelo sostenible de horario de trabajo. Reducción de la jornada laboral a 40 horas semanales de trabajo para evitar el síndrome del quemado, que tantos problemas acarrea a los proyectos software pues está demostrado que se produce infinitamente más, cuanto más descansado y motivado se está.
• Trabajo en estrecha colaboración contínua con el cliente, que debe implicarse en el proyecto *realmente* para obtener de verdad lo que *necesita*.
• Adopción de estándares de código como debería ser en cualquier proyecto serio de desarrollo software.

Algunas de éstas prácticas están ámpliamente aceptadas en metodologías consideradas más serias como Rational Unified Process (RUP), que está demostrado que es mucho más eficiente en proyectos más grandes ya que Extreme Programming (XP) está limitado en cuanto al número de desarrolladores concurrentes y el equipo de trabajo. No obstante, XP tiene público y escenarios en los que resulta de gran utilidad en proyectos para los que resulta mucho más cómodo de seguir y con resultados óptimos para el cliente y el equipo de trabajo.