La metodología que nos ocupa hoy es la de Extreme Programming (XP). Probablemente sea una de las metodologías de las que más hayáis oído hablar ya que sin duda alguna es una de las más conocidas.

Como todas las metodologías anteriores, esta también pone más interés en la adaptación que en la previsión. Si esto es bueno o malo daría para llenar libros y libros, de hecho lo hace. Los defensores de este método lo defienden apoyándose en la idea de que los requisitos y especificaciones de los sistemas que se están desarrollando habitualmente son cambiantes, ya sea por unas razones o por otras, y opinan que la aproximación de adaptación es mejor o al menos más realista que la de tratar de predecir todo de antemano.

La metodología XP se centra en potenciar las relaciones interpersonales considerando estas clave para el éxito de un proyecto. De esta forma, promueve el trabajo en equipo, el aprendizaje y el buen ambiente de trabajo. Otro de los factores más importantes es esta metodología es la comunicación tanto entre los participantes en un proyecto con el cliente. Y por supuesto, la preparación técnica del equipo involucrado en el desarrollo.

En general, la metodología XP se considera especialmente adecuada para proyectos con requisitos imprecisos y/o muy cambiantes.

Los elementos de la metodología serían los siguientes:

– Historias de usuario: Se trataría de “tarjetas” donde el cliente especifica requisitos funcionales o no.  Dichos requisitos deberán ser entendibles e implementables en unas pocas semanas. Cada tarea, terminará siendo una tarea de programación asignada a un desarrollador durante una iteración.

– Roles XP: Los roles habituales que componen un equipo XP serían:

· Programador: Escribe código y realiza pruebas unitarias.

· Cliente: Obvio, encarga el trabajo, escribe las historias de usuario y prioriza tareas.

· Tester: Escribe pruebas funcionales junto al cliente y, ejecuta y difunde los resultado de las pruebas regularmente.

· Tracker: Realiza el seguimiento de las distintas iteraciones, estimaciones frente a tiempo real, para poder afinar las estimaciones.

· Coach: Es el responsable del equipo XP, se encarga de que este siga el proceso correctamente.

· Consultor: Miembro externo experto en algún tema concreto al que acudir en caso de problemas.

· Gestor: Unión entre el cliente y el equipo de desarrollo. Sus labores son de coordinación principalmente.

Proceso XP:

El proceso XP consta de las diferentes fases que se deben ejecutar en cada iteración.

1. Definición de requisitos a implementar

2. Estimación del programador.

3. Desarrollo del requisito.

4. Vuelta al paso 1.

Por otra parte, se considera que un ciclo de vida XP ideal son 6 fases: exploración, planificación de la entrega, iteraciones, producción, mantenimiento y muerte del proyecto.

Elementos  a poner en práctica:

– Jugando con la planificación: La comunicación frecuente entre el cliente y el equipo hace que el equipo produzca estimaciones de requisitos y que el cliente elija el ámbito y tiempo de entrega de cada iteración.

– Entregas pequeñas: Menores en todo caso a 3 meses. No tiene por que ser una funcionalidad completa, pueden ser pequeñas versiones operativas que formarán un todo después.

– Metáfora: Yo puse la misma cara al leerlo la primera vez. A mi entender sería algo como un diccionario de datos que comparten cliente y equipo para asegurarse de hablar el mismo idioma.

– Diseño simple: Se apostará siempre por la solución más simple.

– Refactorización: Se harán continuas refactorizaciones de código para evitar duplicidad, mejorar legibilidad, hacer más fácil futuros cambios, etc…

– Programación por parejas: El desarrollo por parejas evita errores y produce un mejor diseño. Ya sabéis, aquello de “cuatro ojos ven más que dos”.

– El código es de todos: No hay partes que solo toque uno u otro desarrollador, todo el mundo puede tocar todo.

– Integración continua: Cada parte de código terminada se integrará en el sistema, con lo cual será integrado, construido y probado varias veces al día con toda probabilidad.

– 40 horas semanales: Si necesitamos trabajar más horas, algo está yendo mal.

– Cliente accesible: El cliente tiene que estar disponible y a ser posible presente para que el equipo pueda resolver sus dudas.

– Seguimiento de estándares: Debido a la poca documentación que se genera, el código debe servir de comunicación, por lo cual, es muy importante seguir estándares definidos.

Principios:

Lista de principios básicos que persigue la programación extrema:

– Simplicidad: Un diseño simple, un código simple y unas soluciones simples. Esto ayudará a facilitar el mantenimiento, las modificaciones y el desarrollo de nuevas funcionalidades. Esto se consigue a través de los estándares, la programación por parejas y las auditorias de código colectivo, permitiendo que todos los desarrolladores conozcan y puedan entender de forma fácil el código.

– Comunicación: La comunicación entre los desarrolladores se realiza a través del código ya que los comentarios pueden quedar rápidamente desfasados. Ojo, esto no implica no poner comentarios. Los casos de pruebas también sirven como forma de comunicación. Además, los desarrolladores se comunican de forma constante gracias a la programación por parejas. Por otra parte, como el cliente forma parte del equipo, también existe una comunicación fluida con él.

– Feedback: Tanto por parte del cliente como por parte de los desarrolladores. Del cliente sobre el estado del proyecto. De los desarrolladores sobre los resultados y estimaciones. Una parte importante de este feedback nos lo dan también los casos de pruebas que nos ayudan a mantener nuestro código en forma.

– Coraje o valentía: Para ceñirse al proceso y no caer en tentaciones o malas prácticas, y sobre todo para ponerlo en práctica.

Actividades:

En la metodología XP se describen cuatro actividades que se llevan a cabo dentro del proceso de desarrollo:

– Codificar: La mayoría de defensores de esta metodología defiendes que el código es al final lo que importa, que sin él no hay nada. El código sirve para comunicar, discutir, en caso de duda implementar varias versiones para decidir y además, cualquier desarrollador puede proponer sus ideas con una pequeña modificación sobre el código de otro. En definitiva, el código es claro, conciso y no da lugar a interpretaciones.

– Probar: Nadie implementa nada a la primera y todo funciona perfectamente, ¿o si? Y en ese caso, ¿cómo lo demuestra? Mediante las pruebas. De tipo unitario para probar el funcionamiento de nuestro código en particular, y de tipo funcional para validar la correcta implementación de los requisitos del cliente. Vamos, lo que viene siendo “Validación y Verificación”.

– Escuchar: Escuchar al cliente para entender sus necesidades e implementar un software adecuado a su negocio, no a lo que creemos entender de su negocio. Por mucho que un desarrollador sepa, raro es que sepa más que el propio cliente sobre su negocio.

– Diseñar: Una parte muy importante es el diseño, ya que a medida que el sistema crece se pierde visibilidad sobre dependencias y sobre las diferentes partes del sistema. Para evitar esto, lo mejor es un buen diseño.

Bueno, y hasta aquí XP. Si tenéis alguna duda o algo no ha quedado claro animaros a preguntar. Nos vemos.