ENTRADA SOBRE EXTREMING PROGRAMMING (XP)

ELEMENTOS EN EL PROCESO DE DESARROLLO DE LA METODOLOGIA XP.

Los pasos fundamentales inmersos en las fases del método son:

1.- Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.

2.- Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.

3.- Programación en parejas: 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.

4.- 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.

5.- 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.

6.- Propiedad del código compartido: 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.

7.- Simplicidad del 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.