X de Extreme Programming
Entre los diferentes frameworks de los que se nutrió el Manifiesto Ágil, Extreme Programming destaca por ser uno de los más influyentes. No solo en el nacimiento de Agile, sino por su énfasis en unas prácticas técnicas que han ido incorporándose, con mayor o menor fortuna, en los equipos de desarrollo.
Kanban o Scrum, siendo también metodologías ágiles, podría decirse que están más orientadas a la gestión de proyectos en general. De hecho el Kanban que usamos en desarrollo de software es una adaptación de un proceso industrial.
Puedes aplicar ambas metodologías en entornos distintos a la programación y, de hecho, es relativamente habitual ver como equipos de otras áreas de una empresa adoptan alguna de ellas. Además, encajan bastante bien con estructuras organizativas con una cierta jerarquía y que buscan definir procesos, algo que satisface a algunas visiones más tradicionales de la dirección de proyectos.
La gran difusión de Scrum, para qué nos vamos a engañar, es gracias a que permite un cierto grado de supervisión a las capas de management, lo que resulta tranquilizador para estas, aunque puede redundar, precisamente, en una pérdida de agilidad.
Extreme programming, por su parte, nace específicamente para equipos de desarrollo de software. No solo porque lo indica su nombre, sino porque pone el énfasis en aspectos y prácticas técnicas y en la búsqueda de la excelencia en las mismas. Así, cuestiones como la integración contínua, test driven development, pair programming, uso de estándares de escritura de código, diseño simple, propiedad colectiva, refactoring, etc., nacen en este enfoque o son prácticas primarias del mismo.
Un aspecto llamativo de Extreme Programming es que no postula una guía de procedimientos al estilo de Scrum, sino que habla de Actividades, Valores y Prácticas. También usa el concepto de Whole Team, que debería resultar obvio: todo el equipo contribuye al proyecto.
Así todo, observando ambas metodologías de forma superficial podríamos encontrar muchas similitudes. En las dos se busca un desarrollo iterativo e incremental, existe una planificación de lo que debe hacerse, se persigue entrega de valor y se reflexiona sobre el proceso seguido para mejorarlo. Es cuando profundizamos cuando encontramos las diferencias.
La gran mayoría de veces los equipos que se autodefinen como ágiles utilizan una mezcla de elementos de Scrum y de Extreme Programming, lo que puede resultar confuso. Scrum pone foco en un proceso bastante reglamentado, con roles y momentos definidos, algo en lo que Extreme Programming no pone tanto acento. Pero Scrum es más management friendly, y tiene una guía de implementación muy precisa.
Así, por ejemplo, Scrum tiende a favorecer una aproximación al desarrollo basada en tareas y en la distribución de la carga de trabajo para alcanzar el objetivo previsto en el sprint o plazo de la iteración. Extreme programming prefiere trabajar a partir de las Historias de Usuario, y el equipo se organiza para contribuir a completarlas, haciendo uso de diferentes prácticas técnicas. Estas prácticas buscan generar software de calidad de forma sostenida y sostenible.
Posiblemente, sea el énfasis en las prácticas técnicas lo que hace resaltar las diferencias. Ambos frameworks giran en torno a definir qué hacer, por qué y cuándo, pero solo Extreme Programming enfatiza el cómo. Para ello, propone un conjunto de prácticas que, de alguna manera, materializan eso. Veamos algunos ejemplos:
Test Driven Development hace describir los requisitos de una historia de usuario con una representación formal y ejecutable (tests) que nos permiten saber, en todo momento, si estamos desarrollando el software que deseamos, pues proporciona feedback inmediato. Además, define el límite de lo que es necesario desarrollar, contribuyendo a reducir la cantidad de trabajo en progreso.
Pair programming y Mob programming, permiten que las contribuciones de código tengan una revisión instantánea, garantizando que las soluciones propuestas sean las mejores que el equipo puede aportar. Además, contribuyen a que el equipo disemine el conocimiento necesario, no solo de las soluciones técnicas, sino la comprensión del negocio en el que se está trabajando. Esto es lo que permite desarrollar la propiedad colectiva, reduciendo el riesgo de fugas de conocimiento cuando una persona sale del equipo por la razón que sea.
Integración contínua, ayuda a mantener una alta velocidad de desarrollo al eliminar los cuellos de botella provocados por conflictos cuando se están desarrollando diferentes partes del código en paralelo. Cuanto antes integramos los cambios, menos posibilidades hay de conflictos, más fácil es reutilizar soluciones, etc. Si los cambios son pequeños, se reduce tanto el riesgo de defectos como el riesgo de conflictos. En consecuencia, son necesarias menos acciones de mantenimiento. Y en caso de que aparezcan problemas, son más fáciles de diagnosticar.
Spikes. En XP los spikes son experimentos en código para tratar de valor la incertidumbre asociada a una solución. Esto es, se prueban ideas para tratar de anticipar su coste y las dificultades de implementación. Cuando se han obtenido conclusiones, se tira ese código y se hace la implementación real.
Extreme programming pone el acento en que no es posible un desarrollo ágil de software sin incidir en estas prácticas técnicas. Un framework ágil, sea cual sea, no puede obviar la excelencia técnica como requisito para lograr la entrega sostenida de valor