XP (Xtreme Programming), una metodología 'agile' (Parte II)

En la Parte I se hablaba de expresar la metodología de programación extrema a través de diferentes prácticas, en concreto unas 12: (en lengua inglesa puede verlas haciendo click aquí)

Foto extraída de www.xprogramming.com

1. 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.
2. Planificación, se hacen las historias de usuario y se planifica en qué orden se van a hacer. La planificación se revisa continuamente.
3. 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 puedan ser vistas funcionando.
4. Test del cliente, el cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
5. Diseño simple, hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
6. Pareja de programadores, los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
7. 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 realicen, mejor.
8. Integración continua, se debe tener siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recopilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando fallara algo, no se sabría qué es lo que falla de todo lo que habíamos metido.
9. 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.
10. Normas de codificación, debe formalizarse un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
11. 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.
12. 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. Tampoco se debe 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.

Pese a que personalmente no he hecho uso (aún) de esta metodología que acabo de comentar, su uso y sus practicas las recomiendo encarecidamente. Su uso es recomendable, en primer lugar, por su programación organizada y satisfacción que proporciona al programador, y en segundo lugar, por su aplicación en proyectos programados a corto plazo y con condiciones de altas comisiones en caso de fallo.

¡Saludos!