Programación extrema (Extreme Programming)

Es una metodología ágil de desarrollo de software que se basa en la simplicidad, la comunicación y la retroalimentación. XP hace hincapié en el testeo de nuestros programas creando test antes de la implementación, durante y cuando haya terminado. Y cuando se detecte un fallo se creará un nuevo caso de testeo. A continuación una mirada sobre esta metodología.

Objetivos.

El principal objetivo de XP es la satisfacción del cliente y potenciar al máximo el trabajo en equipo.

El código es revisado continuamente, mediante la programación en pareja.

Se rediseñara todo el tiempo, dejando el código lo mas sencillo posible.

Se busca que los grupos de trabajo sean pequeños.

Las cuatro variables

XP define cuatro variables para cualquier proyecto software: coste, tiempo, calidad y alcance. Además, especifica que, de estas cuatro variables, sólo tres de ellas podrán ser fijadas por las fuerzas externas al proyecto(clientes y jefes de proyecto), mientras que el valor de la variable libre será establecido por el equipo de desarrollo.

«Nueve mujeres no pueden tener un hijo en un mes». XP hace especial énfasis en equipos de desarrollo pequeños (diez o doce personas como mucho).

Ciclo de vida

Planificación

XP plantea la planificación como un permanente diálogo entre la parte empresarial y técnica del proyecto, en la que los primeros decidirán el alcance –¿qué es lo realmente necesario del proyecto?–, la prioridad –qué debe ser hecho en primer lugar–, la composición de las versiones qué debería incluir cada una de ellas– y la fecha de las mismas. En cuanto a los técnicos, son los responsables de estimar la duración requerida para implementar las funcionalidades deseadas por el cliente, de informar sobre las consecuencias de determinadas decisiones, de organizar la cultura de trabajo y, finalmente, de realizar la planificación detallada dentro de cada versión. XP no es sólo un método centrado en el código –que lo es–,sino que sobre todo es un método de gestión de proyectos software.

1. Redactar historias de usuario: Las historias de usuario tienen el mismo propósito que los casos de uso, pero no son lo mismo. Las escriben los propios clientes, tal y como ven ellos las necesidades del sistema. Por tanto serán descripciones cortas y escritas en el lenguaje del usuario, sin terminología técnica.
2. Crear plan de entregas: El plan de entregas se usará para crear los planes de iteración para cada iteración.
3. Controlar la velocidad del proyecto: La velocidad de proyecto se usa para determinar cuántas historias de usuario pueden ser implementadas antes de una fecha dada (tiempo), o cuánto tiempo es necesario para llevar a cabo un conjunto de historias (alcance).
4. Dividir un proyecto en iteraciones.
5. Planificar cada interacción antes de comenzarla.
6. Rotar al personal.
7. Reunión de seguimiento diaria.
8. Corregir la propia metodología.

Desarrollo

Esta etapa debe reunir las siguientes características o cualidades:

1. El cliente debe estar siempre disponible.
2. Escribir código de acuerdo a estándares.
3. Desarrollar la unidad de prueba primero: la implementación será más rápida.
4. Todo código debe programarse en pareja.
5. Solo una pareja integrará el código.
6. Todo el código es común a todos: cualquiera puede contribuir al desarrollo desde cualquier parte del proyecto.
7. Dejar las optimizaciones para el final.
8. No trabajar más de 40 horas semanales.

Pruebas

1. Todo el código debe ir acompañado de una unidad de prueba.
2. Todo el código debe pasar las unidades de prueba antes de ser implementado.
3. Ante un fallo se crea una unidad de prueba.
4. Se deben ejecutar pruebas de aceptación a menudo y publicar los resultados, que son creadas a partir de las historias de usuario.

Diseño

XP establece unas recomendaciones o premisas a la hora de abordad esta etapa.

1. Simplicidad: Siempre costará menos tiempo de implementar un diseño sencillo que uno complejo.
2. Elegir una metáfora: Una metáfora para el sistema es una historia que todo el mundo puede contar a cerca de cómo el sistema funciona. Nos permitirá mantener la coherencia de nombres de todo aquello que se va a implementar.
3. Usar tarjetas CRC: Una tarjeta CRC representa un objeto. El nombre de la clase se coloca a modo de título en la tarjeta, las responsabilidades se colocan a la izquierda, y las clases que se implican en cada responsabilidad a la derecha, en la misma línea que su requerimiento correspondiente.
4. Crear soluciones puntuales para reducir riesgo.
5. No añadir funcionalidades en las primeras etapas.

Finalmente y a modo de conclusión creo que conocer varias metodologías (srcum, xp, etc.) de desarrollo es bueno, ya que nos permite captar diferentes ideas de cómo llevar un proyecto de software adelante.

Espero que les sea útil. Saludos, Gerónimo.