Metodologías de desarrollo ágil: Programación Extrema

Continuando con la serie de artículos en la que hablo de los principales métodos de desarrollo ágil, hoy le toca el turno a la Programación Extrema , conocida comunmente como XP.

Detrás de este nombre tan rimbombante que parece sacado de un programa de la MTV, se esconde la que probablemente sea la metodología de desarrollo de software ágil más sencilla y fácil de implantar sobre la que se ha teorizado, pero también la que conlleva más estrés y desorganización.

Su formulación formal es relativamente reciente y data sólo de 1999, pero sus raíces y forma de trabajo han sido empleadas desde los inicios de la programación.

Sus planteamientos son, como he citado antes, muy sencillos. Hay que desarrollar un proyecto lo más rápido posible para que guste a un cliente final. Lo mejor en este caso es que el cliente opine sobre que le gusta y que no a medida que avanza el proyecto. Para conseguirlo, se diseña una forma de trabajar fundamentada en un modelo de desarrollo incremental con entregas extremadamente rápidas y esperando feedback diario por parte del cliente. En cada una de las iteraciones del desarrollo incremental se programa de un día para otro, reflexionando, diseñando y documentando el código a medida que se escribe.

Evidentemente bajo estas circunstancias la calidad del trabajo, tanto de análisis como de programación, dependen directamente de la calidad del programador y la claridad de ideas del cliente, lo que hace que sea un método muy arriesgado: o sale todo muy bien o sale todo muy mal. La empresa debe ser consciente, comprender que algunos desarrollos se atascarán más que otros y ponderar su resultados en base a esto.

Es el famoso modelo que empleamos casi sin darnos cuenta la mayoría de programadores web, en el que sueles disponer de un entorno público de desarrollo que permite que los clientes opinen a medida que vas construyendo sus proyectos y unos equipos de desarrollo bastante pequeños.

Para conseguir que aplicar una Programación Extrema correctamente, es fundamental que se den una serie de circunstancias:

• Es muy importante que los programadores trabajen en parejas para evitar que las tareas de diseño se atasquen por falta de ideas y para mejorar la calidad de la arquitectura de la aplicación.
• Los programadores deben capturar, analizar, diseñar programar y probar en un espacio muy corto de tiempo, por lo que deben ser programadores de perfil alto y con mucha experiencia.
• El equipo debe llevarse especialmente bien y ser capaz de comunicarse entre sí con fluidez. Apenas existe documentación en XP, por lo que ser capaz de entenderse rápidamente adquiere una dimensión capital.
• El cliente debe ser capaz de integrarse completamente en la metodología de trabajo: un feedback recibido a destiempo o un cambio radical de parecer pueden crear retrasos indeseados.

Es una metodología de la que no soy muy fan por muchos motivos que derivan curiosamente de las que considero ventajas de este sistema. Las propias fortalezas del sistema son sus puntos débiles:

• Cada incorporación nueva al equipo de desarrolladores tiene más incidencia en la productividad que en otros procesos de desarrollo porque la producción de código depende directamente de la integración entre sí de los miembros del equipo. Una incorporación siempre tiene a romper un poco la dinámica de grupo y, al tener iteraciones de los procesos de desarrollo tan cortas, afecta radicalmente a las fechas de entrega.
• Es realmente difícil integrar a programadores sin experiencia o becarios en proyectos reales de cierta exigencia.
• Como ya hemos comentado, las habilidades sociales y de comunicación de los programadores son muy importantes. Y hablando con sinceridad, los programadores no somos el gremio que más destaca por sus habilidades sociales por regla general. Debes elegir cuidadosamente a desarrolladores con cierto don de gentes o cuyo caracter propicie el trabajar con el compañero.
• Necesitas un tipo de programador muy específico: con capacidad de análisis, que trabaje rápido, experiencia, que soporte bien el estrés, con habilidades de organización y comunicación, autónomo… Contratar a un programador con un perfil tan específico suele resultar difícil y caro.
• XP es un entorno de trabajo que somete a los programadores a mucha presión. Se delega en el equipo muchas responsabilidades que deben satisfacer con rapidez y efectividad. Esto hace que las empresas que utilizan Programación Extrema como única metodología de trabajo tengan mucha rotación de empleados.
• Cuando todo va bien es un entorno exigente. Cuando algo ha salido mal, se produce una reacción en cadena que hace que todo se retrase, afecta al ánimo y al clima social del equipo, lo que afecta directamente a los resultados. Los problemas generan una onda expansiva que hay que saber atajar rápidamente.
• El cliente debe tener cierta comprensión de como alcanzar el objetivo y debe ser un actor más en el proceso de desarrollo. Esto es sencillo cuando se producen software in-house, pero puede resultar muy complicado cuando se trabaja para un cliente externo.

Creo que XP tiene muchas ventajas, pero no creo que sea un sistema de trabajo entorno al cual pueda girar una empresa. Considero que es muy útil para ejecutar proyectos cortos y sin mucha profundidad de código (una página web por ejemplo) pero hay que ser conscientes del importante esfuerzo que exige a un programador.

Un programador que trabaje con XP deberá tener descansos regulares, ya sean días libres, permitiéndole periodos de investigación o asignándole de vez en cuando a proyectos basados en procesos más relajados.

A mí por ejemplo, en una empresa en la que trabajábamos bajo XP los viernes teníamos que is a trabajar, pero teníamos prohibido trabajar en el proyecto principal y nos animaban a desarrollar nuestros propios proyectos personales. Con ello mantenían la motivación, el interés, nos daban un respiro y nos daban espacio para crecer.

¿Qué opinais vosotros? ¿Cual es vuestra experiencia con Programación Extrema?