3.3 eXtreme Programming (XP)

27 mayo 2018

[ Estás en Unidades Didácticas / Unidad 3. Metodologías / 3.3 eXtreme Programming (XP) ]

XP se basa en valores y prácticas, definidos por Kent Beck en su libro Extreme Programming Explained. La primera edición del libro, del año 2000, definía 4 valores y 12 prácticas. Mostrando uno de los principios ágiles la metodología evolucionó y en 2005 se presentó una segunda edición del libro presentando 13 prácticas principales y 11 secundarias.

Valores

  1. Simplicidad para desarrollar sólo aquello que se necesita (compartido con Lean y Kanban)
  2. Comunicación entre todos los participantes del proyecto, trabajando todo el equipo en un lugar común si es posible y manteniendo reuniones cara a cara con los clientes para entender mejor cualquier gesto o impresión de clientes y miembros del equipo.
  3. Retroalimentación entre miembros del equipo y clientes. El cliente recibe entregas funcionales del proyecto y las usa para poder dar su opinión sobre lo que ya se ha hecho y lo que falta por hacer.
  4. Coraje para introducir mejoras en el código o rechazar el que no juzguemos adecuado. Un lema muy extendido entre desarrolladores es «Si funciona no lo toques«, en XP se busca una mejora contínua y se ha de tener coraje para modificar todo aquello que sepamos que mejorará el estado actual y futuro del proyecto en desarrollo.

Prácticas

Kent Beck expone doce principios básicos en la primera edición del libro con que presenta la metodología XP.

From the four values we derive a dozen or so basic principles to guide our new style. We will check proposed development practices to see how they measure up to these principles.

Los cuatro valores XP -comunicación, simplicidad, retroalimentación y coraje- son criterios para alcanzar una solución satisfactoria al problema del desarrollo ágil de software. Sin embargo se trata de conceptos demasiado vagos para ayudarnos a decidir qué prácticas se llevarán a cabo. Para ello se definirán una serie de principios que ayuden a cumplir con los valores de la metodología. Los principios son más concretos que los valores. Hay cinco principios fundamentales:

  1. Retroalimentación rápida El tiempo transcurrido entre una acción y su retroalimentación es crucial en el proceso de aprendizaje. Se ha de obtener retroalimentación sobre toda acción realizada, interpretarla y reflejar en el sistema lo aprendido tan rápido como sea posible.
  2. Asumir simplicidad Se ha de tratar cada problema como si pudiera ser resuelto de un modo ridículamente simple. Generalmente se desarrolla pensando en el futuro, en reusar las funcionalidades. En XP se aprende a resolver los problemas del presente, asumiendo que si en el futuro hay nuevos requisitos seremos capaces de resolverlos eficientemente.
  3. Cambio incremental Los grandes cambios hechos simultáneamente pueden derivar en un sistema que no funcione. Cualquier problema se puede resolver mediante una serie de pequeños cambios. Todo en XP debe evolucionar mediante pequeños cambios, incluso la adopción de la metodología por parte de un equipo.
  4. Abrazando el cambioLa mejor estrategia es la que preserva la mayoría de las opciones mientras que realmente soluciona el problema más apremiante.
  5. Trabajo de calidad De las cuatro variables que rigen el desarrollo de software, alcance, coste, tiempo y calidad, la calidad no es una variable totalmente libre. En XP sólo puede tomar dos valores, «excelente» o «insultantemente excelente». De otro modo los miembros del equipo no pueden disfrutar con su trabajo, no trabajarán bien y el proyecto tiende al fracaso.

#1 Sit together

#2 Whole team

#3 Informative workspace

#4 Energized work

#5 Pair programming

#6 Historias

#7 Ciclo semanal

#8 Ciclo trimestral

#9 Slack

#10 10 minutos para construir

#11 Integración continua

#12 Desarrollo guiado por pruebas (TDD)

La Wikipedia deja bastante claro qué es TDD.

Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.

El logo de la metodología es muy explícito, nos hace pensar que el código fallará por lo que he de hacer pruebas para corregir todos los fallos que provoque.

La filosofía de esta práctica está en granular los requisitos de cada bloque de código de la aplicación a desarrollar (clases, métodos…) y hacerle pruebas siguiendo siempre 3 pasos sencillos hasta lograr que el código las supere todas satisfactoriamente. El primer paso será siempre llevar a cabo una prueba nueva que ya sabemos que fallará, lo que conlleva usar otra aplicación con la que generar las pruebas. El segundo paso consistirá en modificar nuestro bloque de código para conseguir que pase satisfactoriamente la nueva prueba. El tercero es una limpieza y refactorización del código que acabamos de modificar, una vez sabemos que es correcto por haber superado la última prueba (y las restantes también).

Lo ideal sería no tener que realizar pruebas, de hecho muchos equipos de desarrollo consideran que podrían ser más eficientes si no tuvieran que emplear tiempo en el desarrollo y ejecución de pruebas (XP tiene un rol específico para «testers», lo que quita tiempo de desarrollo a los desarrolladores que adoptan ese rol). Pero la realidad es que sin pruebas, refactorización y retrospectiva documentada no se alcanzará nunca una velocidad de desarrollo conocida y sostenible, no se tendrá nunca un equipo realmente ágil.

Prueba unitaria

#13 Diseño incremental

Roles

XP define muchos roles pero el equipo es dinámico y sólo lo formarán aquellos que sean necesarios en cada momento.

  • Programador Escribe las pruebas unitarias y produce el código del sistema. Es el elemento más importante del equipo
  • Cliente Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.
  • Tester Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
  • Tracker Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
  • Entrenador Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.
  • Consultor Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico.
  • Gestor Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.

Fuentes

<– Anterior               Siguiente –>