Вы находитесь на странице: 1из 4

¿QUÉ ES PROGRAMACIÓN EXTREMA O XP?

ü Metodología liviana de desarrollo de software


ü Conjunto de prácticas y reglas empleadas para desarrollar software
ü Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes
ü Originada en el proyecto C3 para Chrysler
ü En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada
vez, a través de todo el proceso de desarrollo

OBJETIVOS.
ü Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.
ü Mejorar la productividad de los proyectos.
ü Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas
del cliente.

CONTEXTO XP
ü Cliente bien definido
ü Los requisitos pueden (y van a) cambiar
ü Grupo pequeño y muy integrado (máximo 12 personas
ü Equipo con formación elevada y capacidad de aprender

CARACTERÍSTICAS XP
ü Metodología basada en prueba y error
ü Fundamentada en Valores y Prácticas
ü Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas a otras–Son
conocidas desde hace tiempo. La novedad es juntarlas

EL ESTILO XP
ü Esta orientada hacia quien produce y usa el software
ü Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.
ü Combina las que han demostrado ser las mejores practicas para desarrollar software, y las
lleva al extremo.

PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA


Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas" que
deben seguirse al pie de la letra. Dichas prácticas están definidas (en perfecto inglés) en
www.xprogramming.com/xpmag/whatisxp.htm. Aquí tienes un pequeño resumen de ellas.

ü Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el
proyecto, incluido el cliente y el responsable del proyecto.

ü Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las
mini-versiones. La planificación se revisa continuamente.

ü Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas
para validar las mini-versiones.

ü Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para
poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final
y no trozos de código que no pueda ver funcionando.

ü Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible.
Mantener siempre sencillo el código.
ü Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo
ordenador) y se intercambian las parejas con frecuencia (un cambio diario).

ü Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba
automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.

ü Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en
cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error
mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas
de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.

ü El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código.
Para eso se hacen las pruebas automáticas.

ü Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de
forma que parezca que ha sido realizado por una única persona.

ü Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas
partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué
es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java.
Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no
haya mal entendidos.

ü Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto
quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben
hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay
que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario
o mini-versión.

MANEJO COLECTIVO DEL CÓDIGO


VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING

Ventajas:
ü Programación organizada.
ü Menor taza de errores.
ü Satisfacción del programador.

Desventajas:
ü Es recomendable emplearlo solo en proyectos a corto plazo.
ü Altas comisiones en caso de fallar.

La programación extrema, o Extreme Programming (XP), es una metodología de desarrollo ágil,


una de las más exitosas en tiempo reciente. Su autor principal es Kent Beck, quien eligió algunas
características de otras metodologías y las relacionó de forma que cada una complementara a
la otra.
Así, la XP se puede definir como un conjunto de pasos de diversas metodologías, acopladas de
manera que sean pasos flexibles a seguir utilizadas con el uso común, para realizar un desarrollo
más agradable y sencillo.
Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del
cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales:

Comunicación
Es muy importante que haya una comunicación constante con el cliente y dentro de todo el
equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo de una manera sencilla,
entendible y que se entregue al cliente lo que necesita.

Simplicidad
En la XP se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su
sistema, éste debe ser fácil. El diseño debe ser sencillo y amigable al usuario, el código debe ser
simple y entendible, programando sólo lo necesario y lo que se utilizará.

Retroalimentación
Es la comunicación constante entre el desarrollador y el usuario.

Coraje
Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con
tanto esfuerzo; el desarrollador debe saber cuándo el código que desarrolló no es útil en el
sistema y, por lo mismo, debe ser eliminado. También se refiere a tener la persistencia para
resolver los errores en la programación.

Dentro de la programación extrema se tiene 12 principios que llevan o guían el desarrollo con
esta metodología:
1. El principio de pruebas
2. Proceso de planificación
3. El cliente en el lugar
4. Programación en parejas
5. Integración continua
6. Refactorización
7. Entregas pequeñas
8. Diseño simple
9. Metáfora
10. Propiedad colectiva del código
11. Estándar de codificación
12. La semana de 40 horas

Herramientas de la XP
Historias de usuarios
Son tarjetas físicas en las cuales se anota una descripción de una funcionalidad del sistema, en
una oración, se le da un número y un título para ser identificada.

Casos de prueba de aceptación


Son tarjetas que se elaboran para realizar las pruebas de cada historia de usuario.

Tarea de ingeniería
Son tarjetas que se elaboran para ayudar y simplificar la programación de una historia de
usuario.

Tarjetas CRC
Describen las clases utilizadas en la programación de una historia.

Ventajas y desventajas
Una de las ventajas de la programación extrema es que se adapta al desarrollo de sistemas
pequeños y grandes; optimiza el tiempo de desarrollo; permite realizar el desarrollo del sistema
en parejas para complementar los conocimientos; el código es sencillo y entendible, además de
la poca documentación a elaborar para el desarrollo del sistema.
Las desventajas son que no se tiene la definición del costo y el tiempo de desarrollo; el sistema
va creciendo después de cada entrega al cliente y nadie puede decir que el cliente no querrá
una función más; se necesita de la presencia constante del usuario, lo cual en la realidad es muy
difícil de lograr.
Otra desventaja es la programación en parejas, algunos desarrolladores son celosos del código
que escriben y no les es grato que alguien más modifique las funciones que realizó o que su
código sea desechado por no cubrir el estándar.

Вам также может понравиться