domingo, 2 de julio de 2017

¿Cómo se complementan eXtreme Programming y Scrum?

XP, eXtreme Programming, se considera una metodología de desarrollo de software formulada por Kent Beck en 1996, que hace hincapié en el trabajo en equipo autoorganizado y la colaboración, y pone más énfasis en la adaptabilidad que en la previsibilidad. Estando preparando un curso técnico CSD me he inspirado para este post en el artículo "Extreme Programming and Agile Software Development Methodologies" de Lowell Lindstrom y Ron Jeffries.

Con XP los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. La habilidad de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista para obtener un excelente solución a los problemas de negocio, antes que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después para gestionar los cambios en los mismos.

Si profundizamos en XP descubriremos que en esencia tiene muchos paralelismos con Scrum, la diferencia principal radica en que XP está pensado exclusivamente para la construcción de software, y Scrum es aplicable a la construcción iterativa de cualquier naturaleza en un entorno de incertidumbre y complejidad.
Modelo de practicas XP - Thanks to Ron Jeffries
Desde dentro a afuera los niveles de las diferentes prácticas de XP:
  • En el circulo azul las que se aplican "n" veces al día
  • En el circulo verde las que se realizan diariamente
  • En el circulo rojo las prácticas que se realizan una vez por iteración (sprint) / release

Forman parte del equipo todas las personas que tienen algo que ver con el proyecto XP:
Los mejores equipos no tiene especialistas, solo contribuyentes generales con aptitudes especiales.

Planning Game (planificación):

La planificación en XP aborda dos cuestiones: planificar lo que es posible para una fecha de entrega y determinar qué hacer a continuación. La planificación se realiza en dos eventos:
Customer Tests (tests de cliente):

El cliente con la ayuda de los desarrolladores define para cada historia pruebas de aceptación que guiarán al equipo en la construcción y mostrarán al final de la iteración que la historia ha sido implementada correctamente. Se automatizarán todas las pruebas posibles para maximizar la calidad.

Small Releases (releases pequeñas):

Las releases deben de ser pequeñas y desplegables en producción en ciclos lo más cortos posibles; diaria, semanal, bisemanal, mensualmente... Deben de ser releases que ofrezcan valor de negocio al usuario final y hagan visible el software y su progreso al cliente.

Simple Design (diseño simple):

Los equipos XP siempre mantienen el código y el diseño lo más sencillo y claro posible, trabajan para que el diseño sea el adecuado para la funcionalidad actual del sistema. Siempre construyen lo mínimo imprescindible de la forma más sencilla posible, no construyen cosas que el cliente no haya pedido, no crean desperdicio.

El diseño en XP no es algo que ocurra una sola vez, se producen sesiones de diseño y de rediseño a través de refactorización a lo largo de todo el proyecto.

Pair Programming (programación por parejas):

Los programadores trabajan por parejas, dos delante del mismo ordenador, en las historias de usuario asegurando que todo código esté revisado por lo menos por otro programador, lo que redunda en un código y tests de mayor calidad. Las parejas se intercambian con frecuencia, a veces diariamente, para construir una base de conocimiento compartida y mejorar sus habilidades.


Los mejores equipos de XP practican TDD, trabajando en ciclos muy cortos escribiendo primero las pruebas para luego codificar el código SUT (System Under Test). De esta manera los equipos producen un código con casi el 100% de cobertura de pruebas unitarias. El código se debe de comprometer en el repositorio de código fuente una o dos veces al día, incluidas pruebas unitarias y estas deben de haberse ejecutado antes correctamente al 100%. Así los programadores reciben información inmediata sobre cómo lo están haciendo a través de esta red de seguridad de las pruebas unitarias.


Extreme Programming se centra en ofrecer valor de negocio en cada iteración. Para lograr entrega a negocio a lo largo de todo el proyecto el software debe estar bien diseñado. XP utiliza un proceso de mejora continua del diseño llamado refactorización.

El proceso de refactorización se centra en la eliminación de la duplicados, en el aumento de la "cohesión" del código y la reducción del "acoplamiento".


Con XP el software se mantiene integrado en todo momento, cada vez que se obtenga una nueva pequeña historia de usuario debe recompilarse todo el software y debe de probarse. Son puntos de integración que que garantizan que el las funcionalidades funcionan correctamente juntas y sobre la infraestructura (arquitectura) existente.

Es mala práctica mantener una versión congelada, durante por ejemplo dos meses, mientras se hacen mejoras para luego integrarlas todas de golpe. Cuando falle algo será costoso encontrar el problema y ya no estaremos calientes para resolverlo rápidamente.

Collective Code Ownership (propiedad del código compartida):

Cualquiera miembro del equipo puede y debe poder conocer, mejorar y tocar cualquier parte del código. Por ello se hacen las pruebas automatizadas que resultan en una red de seguridad que hace posible la propiedad compartida al generar confianza y seguridad en los programadores, si provocan un bug este salta a la vista inmediatamente.

Coding Standard (estándares de código):

Debe de haber un estilo común en todo el código, no importa cual, de forma que parezca que haya sido realizado por una única persona.

Metaphor (metáfora):

Los equipos XP desarrollan una visión común de forma que cada uno pueda hacerse una idea de qué es lo que hace cada parte del software. Debe de estar formulado tan simple y claramente como si fuéramos a explicárselo a nuestra madre o abuela, un ejemplo claro es el "recolector de basura" de java.

Sustainable Pace (ritmo sostenido):

XP está concebido a largo plazo, se debe de trabajar a un ritmo que se pueda mantener indefinidamente, sin días muertos en que no se sabe qué hacer, ni días con sobrecarga y excesos de horas. Al tener claro semana a semana lo que debe de hacerse, el equipo se focaliza en el objetivo cercano de terminar una historia de usuario o release.

No hay comentarios:

Publicar un comentario