XP (PROGRAMACIÓN EXTREMA)

1. DEFINICIÓN
La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada
para la gestión de proyectos.
Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de
desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y
el buen clima de trabajo.
Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el equipo
de desarrollo y es idónea para proyectos con requisitos imprecisos y muy cambiantes.
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.
1.1 OBJETIVO
Es aumentar la productividad al desarrollar software.
1.2ORIGEN
Nace de la mano de Kent Beck en el verano de 1996, cuando trabajaba para Chrysler
Corporation.
Él tenía varias ideas de metodologías para la realización de programas que eran cruciales
para el buen desarrollo de cualquier sistema.
Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una
entrevista que esta le hizo el año 1999.

1.3VENTAJAS Y DESVENTAJAS
A) Ventajas
 Programación organizada.
 Menor taza de errores.
 Satisfacción del programador.
 Solución de errores de programas
 Versiones nuevas
 Implementa una forma de trabajo donde se adapte fácilmente a las
circunstancias

B) Desventajas
 Es recomendable emplearlo solo en proyectos a corto plazo
 Altas comisiones en caso de fallar
 Imposible prever todo antes de programar
 Demasiado costoso e innecesario
 1.4 ESQUEMA DE LA FASE DE LA PROGRAMACIÓN EXTREMA

1.5VALORES
Los valores originales de la programación extrema son: simplicidad, comunicación,
retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda
edición de Extreme Programming Explained. Los cinco valores se detallan a
continuación:
A) Simplicidad
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar
el desarrollo y facilitar el mantenimiento.
Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera
de mantener el código simple a medida que crece.
Aplicando la simplicidad junto con la autoría colectiva del código y la programación por
parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá
más y mejor el sistema completo.
B) Comunicación
La comunicación se realiza de diferentes formas. Para los programadores el código
comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para
hacerlo inteligible. Debe comentarse sólo aquello que no va a variar, por ejemplo, el
objetivo de una clase o la funcionalidad de un método.
Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las
clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los
programadores se comunican constantemente gracias a la programación por parejas. La
comunicación con el cliente es fluida ya que el cliente forma parte del equipo de
desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar
disponible para solucionar dudas.
C) Retroalimentación (feedback)
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se
conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran
resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y
ayuda a los programadores a centrarse en lo que es más importante.
Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo
pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos
por parte del equipo de desarrollo. El código también es una fuente de retroalimentación
gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre
el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite
descubrir fallos debidos a cambios recientes en el código.
D) Coraje o valentía
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar
para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y
requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía
le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando
sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los
cambios futuros se implementarán más fácilmente.
E) Respeto
El respeto se manifiesta de varias formas. Los miembros respetan su trabajo porque
siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o
más eficiente para la solución a través de la refactorización del código. Los miembros del
equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en
el equipo eleva su ritmo de producción.
1.6 CARACTERÍSTICAS FUNDAMENTALES
Las características fundamentales del método son:
 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.
 Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a
cabo por dos personas en un mismo puesto. 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. Cuanto
más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una
comunicación más completa, especialmente si se puede reducir el equipo de
programadores.
1.7 ROLES
 Cliente: responsable de definir y conducir el proyecto, así como sus objetivos. Escribe
las historias de usuario y las pruebas funcionales para validar su implementación.
 Programadores: Produce el código del sistema. Es la esencia del equipo. Es decir,
estiman tiempos de desarrollo de cada actividad y programan el proyecto.
 Tester: Encargado de Pruebas. Interpreta el pedido del cliente y ayuda al equipo de
desarrollo a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
 Test Developer: Produce el código de los test unitarios del sistema. Es uno de los roles
más importantes.
 Tracker: Encargado de Seguimiento. Proporciona realimentación al equipo. Debe
verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado,
comunicando los resultados para mejorar futuras estimaciones.
 Coach: Entrenador. Su papel es guiar y orientar al equipo. Es decir, es el responsable
del proceso global. Guía a los miembros del equipo para seguir el proceso
correctamente.
 Consultor: Es un miembro externo del equipo con un conocimiento específico en
algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema
específico. Además, este tiene que investigar según los requerimientos.
 Gestor (Big Boss): Gestor del proyecto, gerente del proyecto, debe tener una idea
general del proyecto y estar familiarizado con su estado. Es el dueño de la tienda y el
vínculo entre clientes y programadores. Su labor esencial es la coordinación.

1.8 LAS CUATRO ACTIVIDADES BASICAS

Ahora que tenemos nuestros cuatro valores estamos preparados para construir una
Disciplina de Desarrollo de software. ¿Qué tareas debemos de llevar a cabo para
desarrollar un buen software?

a) Codificar: Es la única actividad de la que no podremos prescindir. Sin

código fuente no hay programa. Por tanto, necesitamos codificar y plasmar
nuestras ideas a través del código. En una programación en XP en pareja
el código expresa tu interpretación del problema, así podemos utilizarlo
para comunicar, así como también para aprender y mejorar.

b) Hacer pruebas: Las pruebas me dan la oportunidad de saber si lo que

implementé es lo que en realidad yo pensaba que había implementado. Las
pruebas nos indican que nuestro trabajo funciona, cuando no podemos
pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema
entonces has acabado por completo. Tendrás menos errores, te costará
menos localizar los errores, perderás menos tiempo escuchado como tus
 clientes te dicen que no funciona. Las pruebas deben de ser sensatas y
valientes.

c) Escuchar: Tenemos que escuchar a nuestros clientes cuales son los

problemas de su negocio, debemos de tener una escucha activa explicando
lo que es fácil y difícil de obtener, y la Realimentación entre ambos nos
ayudan a todos a entender los problemas.

d) Diseñar: El Diseño crea una estructura que organiza la lógica del sistema,
un buen diseño permite que el sistema crezca con cambios en un solo
lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de
desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos
diseños, estos deben de ser corregidos cuanto antes.

NOTA:

Tenemos que codificar, porque sin código no hay programas, tenemos que hacer pruebas
porque sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar,
porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para
poder Codificar, probar y escuchar indefinidamente.

2. MAPA CONCEPTUAL
3. Ejemplos

• Una empresa que aplico Extreme Programming es ONess, cuyo objetivo es un

proyecto open source para el negocio textil mayorista desarrollado con
tecnologías open source innovadoras.

• Un ejemplo puede ser si una empresa es pequeña y quiere lanzar un producto al

mercado, no hecho a la medida, entonces emplear esta metodología sería una
buena opción, ya que probablemente el presupuesto no dé para realizar los
estudios necesarios para la elicitación de requisitos correspondiente.