XP (Extreme Programming)
La metodología XP fue desarrollada por Kent Beck, uno de los principales precursores del Manifiesto Ágil. eXtreme Programming es la metodología de desarrollo de software más sencilla y fácil de implantar, aunque a su vez fue de las menos utilizadas por las compañías en 2017. Es una metodología basada en la “retroalimentación continua entre cliente y equipo de desarrollo”.
Por ello, lo más aconsejable es que el cliente de su opinión sobre qué le gusta y qué no a medida que el proyecto avanza. Es muy recomendada para aquellos proyectos cuyas condiciones son ambiguas o muy variables. De manera que la planificación ha de ser altamente flexible y basarse en un desarrollo iterativo, o desarrollo en cascada, con entregas muy rápidas “esperando feedback diario por parte del cliente”
Dentro de la metodología XP, en cada una de las interacciones del desarrollo, se programa de un día para otro, reflexionando, diseñando y documentando el código a medida que se escribe.
Factores de XP
eXtreme Programming es una metodología muy arriesgada, pues el éxito o fracaso del proyecto depende inmediatamente de las cualidades del equipo de programadores y cómo de precisas sean las ideas del cliente. Para una correcta aplicación de la metodología XP deben darse ciertos factores:
- Los programadores deben trabajar en parejas para impedir que ciertas partes del proyecto se queden estancadas.
- Los programadores deben ser profesionales con gran experiencia, ya que han de programar, analizar y probar con el tiempo en su contra.
- Es de gran importancia que el equipo de programadores se lleve bien entre sí, para así poder mantener flujos de conversación ligeros.
- El cliente debe poder incorporarse como uno más a la metodología de trabajo. De este modo, se evita que la retroalimentación llegue tarde y se tengan que modificar aspectos que produzcan retrasos no deseados.
Valores XP
XP define un conjunto de valores que establecen el fundamento para todo trabajo realizado como parte de XP. Cada uno de estos valores se usa como un motor para actividades, acciones y tareas específicas de XP.
- Simplicidad: XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo mañana.
- Comunicación: Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de comunicación.
- Realimentación Retralimentación: Concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.
- Coraje: El coraje (valor) existe en el contexto de los otros 3 valores.(si funciona…mejóralo).
Ciclo de vida XP
Al igual que otras metodologías de gestión de proyectos, tanto Ágiles como tradicionales, el ciclo XP incluye:
- Entender lo que el cliente necesita > Fase de Exploración
- Estimar el esfuerzo > Fase de Planificación
- Crear la solución > Fase de Iteraciones
- Entregar el producto final al cliente > Fase de puesta en producción
Lo que caracteriza a XP, al igual que al resto de métodos Ágiles es un ciclo de vida dinámico. ¿Cómo lo logra XP? Ciclo XP Mediante ciclos de desarrollo cortos (llamados iteraciones), al fin de los cuales se generan unos entregables funcionales.
En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas especificas de XP. Un proyecto con XP, implica de entre a 10 a 15 iteraciones habitualmente.
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. 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. Generalmente los equipos están conformados por al menos 12 personas.
- 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.
Reforcemos esta información con los siguientes recursos:
