Las metodologías ágiles en el desarrollo de software son términos bastante de moda hoy en día, y no por nada. De hecho, te pueden resultar familiares términos como Extreme Programming (XP), Scrum, Crystal, Evolutionary Project Management (Evo) o Feature Driven Development (FDD).

En esta ocasión, quiero compartir un breve resumen de un texto acerca de Extreme Programming. Exceptuando la parte histórica, XP se basa en llevar al extremo las buenas prácticas de desarrollo de software, y así bajar el riesgo, permitir cambios de especificaciones durante el desarrollo y favorecer la comunicación con el cliente.

Lo más interesante radica en la enumeración de las prácticas que son llevadas a un extremo:

• Como probar programas es bueno, entonces se hacen pruebas unitarias y funcionales todo el tiempo.
• Como hacer pruebas de integración es importante, la integración sigue inmediatamente después de las pruebas unitarias
• Como revisar la calidad del código es recomendable, se revisa código todo el tiempo y se hacen refactorizaciones, que implican cambios de diseño para hacerlo más simple, pero que no afectan la funcionalidad.
• Como los estándares de codificación permiten una mejor comunicación y reducen los errores, se fijan estándares precisos y estrictos.
• Como es bueno que el sistema sea simple, se busca la simplicidad siempre, diseñando solo lo que se necesita en el momento.
• Como los requerimientos de la arquitectura pueden ser cambiantes, se van refinando constantemente.
• Como el desarrollo incremental es positivo, se hacen iteraciones lo más cortas posibles: se diseña una pequeña porción, se la codifica y se la prueba.
• Como suele suceder que un proyecto se suspenda en un momento determinado (por ejemplo por falta de presupuesto) se implementa primero lo que tiene mayor valor para el cliente.
• Como es importante tener una comunicación frecuente con el cliente, siempre debe haber un cliente acompañando el desarrollo. Además éste es fundamental para escribir pruebas funcionales y establecer prioridades.
• Como dos cabezas piensan mejor que una, y cómo refuerzo a las prácticas anteriores, los programadores trabaja de a dos: uno escribe y el otro piensa en mayor escala, buscando simplicidad, errores y formas alternativas de solución del problema. Estas parejas pueden intercambiarse a lo largo del desarrollo, de todas formas cada pareja es responsable de una tarea, y hasta no terminar esta no hay intercambio.

Extraído de: Orientación a objetos con Java y UML, de Carlos Fontela.