El agilismo es una respuesta a los fracasos y las frustraciones del modelo en cascada. A día de hoy, las metodologías ágiles de desarrollo de software están en boca de todos y adquieren cada vez más presencia en el mundo hispano, si bien llevan siendo usadas más de una década en otros países. El abanico de metodologías ágiles es amplio, existiendo métodos para organizar equipos y técnicas para escribir y mantener el software. Personalmente, me inclino hacia la Programación Extrema (eXtreme Programming, XP) como forma de atacar la implementación del producto y hacia Scrum como forma de gestionar el proyecto, pero el estudio de ambas en su totalidad queda fuera del alcance de este libro.
Por ilustrarlo a modo de alternativa al modelo en cascada: podemos gestionar el proyecto con Scrum y codificar con técnicas de XP; concretamente TDD (Test Driven Development o Desarrollo Dirigido por Test) y Programación por Parejas (Pair Programming o Programación por Parejas, es otra de las técnicas que componen XP y que no vamos a estudiar en detalle en este), sin olvidar la propiedad colectiva del código y la Integración Continua (Véase el apéndice sobre Integración Continua al final del libro).
Agilismo no es perfeccionismo, es más, el agilista reconoce que el software es propenso a errores por la naturaleza de quienes lo fabrican y lo que hace es tomar medidas para minimizar sus efectos nocivos desde el principio. No busca desarrolladores perfectos sino que reconoce que los humanos nos equivocamos con frecuencia y propone técnicas que nos aportan confianza a pesar ello. La automatización de procesos es uno de sus pilares. La finalidad de los distintos métodos que componen el agilismo es reducir los problemas clásicos de los programas de ordenador, a la par que dar más valor a las personas que componen el equipo de desarrollo del proyecto, satisfaciendo al cliente, al desarrollador y al analista de negocio.
El viejo modelo en cascada se transforma en una noria que, a cada vuelta (iteración), se alimenta con nuevos requerimientos o aproximaciones más refinadas de los ya abordados en iteraciones anteriores, puliendo además los detalles técnicos (no resolviendo defectos sino puliendo). Al igual que en el modelo tradicional, existen fases de análisis, desarrollo y pruebas pero, en lugar de ser consecutivas, están solapadas. Esta combinación de etapas se ejecuta repetidas veces en lo que se denominan iteraciones. Las iteraciones suelen durar de dos a seis semanas y en cada una de ellas se habla con el cliente para analizar requerimientos, se escriben pruebas automatizadas, se escriben líneas de código nuevas y se mejora código existente. Al cliente se le enseñan los resultados después de cada iteración para comprobar su aceptación e incidir sobre los detalles que se estimen oportunos o incluso reajustar la planificación. No es casual que hayamos situado las pruebas automáticas antes de la escritura de nuevo código ya que, como veremos en este libro, dentro del agilismo se contempla una técnica en la que las pruebas son una herramienta de diseño del código (TDD) y, por tanto, se escriben antes que el mismo. Llegado el caso las pruebas se consideran ejemplos, requerimientos que pueden ser confirmados (o validados) por una máquina (validación automatizada).
Todo el equipo trabaja unido, formando una piña (de ahí el nombre de Scrum, que se traduce por Melé, palabra del argot del Rugby usada para designar la unión de los jugadores en bloque) y el cliente es parte de ella, ya no se le considera un oponente. La estrategia de juego ya no es el control sino la colaboración y la confianza. Del control se encargarán los procesos automáticos que nos avisarán de posibles problemas o puntos a mejorar. La jerarquía clásica (director técnico, analista de negocio, arquitecto, programador senior, junior ...) pierde sentido y los roles se disponen sobre un eje horizontal en lugar de vertical, donde cada cual cumple su cometido pero sin estar por encima ni por debajo de los demás. En lugar de trabajar por horas, trabajamos por objetivos y usamos el tiempo como un recurso más y no como un fin en sí mismo (lo cual no quiere decir que no existan fechas de entrega para cada iteración).
La esencia del agilismo es la habilidad para adaptarse a los cambios. Ejecutando las diversas técnicas que engloba, con la debida disciplina, se obtienen resultados satisfactorios sin lugar para el caos.
En cualquier método ágil, los equipos deben ser pequeños, típicamente menores de siete personas. Cuando los proyectos son muy grandes y hace falta más personal, se crean varios equipos. Nos encontramos ante el famoso divide y vencerás.
El análisis no es exhaustivo ni se dilata indefinidamente antes de empezar la codificación, sino que se acota en el tiempo y se encuadra dentro de cada iteración y es el propio progreso de la implementación el que nos ayuda a terminar de descubrir los “pormenores”. En el análisis buscamos cuáles son las historias de usuario y, las ambigüedades que puedan surgir, se deshacen con ejemplos concisos en forma de tests automáticos. Hablaremos sobre las historias de usuario en el capítulo de ATDD. Dichas historias contienen los requisitos de negocio y se ordenan por prioridad según las necesidades del cliente, a fin de desarrollar antes unas u otras.
Cada requisito debe implementarse en un máximo de una semana para que, al final de la iteración, el cliente pueda ver funcionalidad con valor de negocio.
El analista de negocio adoptará el rol de dueño del producto cuando el cliente no pueda participar tan frecuentemente como nos gustaría y cambiará los cientos de páginas de documentación en prosa por tests de aceptación (en el capítulo sobre ATDD se describe este proceso) lo suficientemente claros como para que el cliente los apruebe y la máquina los valide. También se encargará de priorizar el orden de implementación de los requisitos acorde a lo que se hable en las reuniones con el cliente. Los desarrolladores estarán en contacto diario con los analistas para resolver cualquier duda del ámbito de negocio lo antes posible. La experiencia ha demostrado que una buena proporción podría ser 1:4, esto es, al menos un analista de negocio por cada cuatro desarrolladores. Esta cifra puede ser relativa a las personas por grupo de trabajo, en los cuales los analistas estarán asignados con tiempo más reducido, es decir, estarán en más grupos. Por ejemplo con 16 desarrolladores y 2 analistas pueden hacerse 4 grupos de 4 desarrolladores y un analista pero cada analista en 2 grupos
Los cambios en los requisitos se suman a la planificación de las iteraciones siguientes y se priorizan junto con las demás tareas pendientes.
Los planes se hacen frecuentemente y se reajustan si hace falta. Siempre son planes de corta duración, menores de seis meses, aunque la empresa pueda tener una planificación a muy alto nivel que cubra más tiempo.
El código pertenece a todo el equipo (propiedad colectiva) y cualquier desarrollador está en condiciones de modificar código escrito por otro. Evitamos las situaciones del tipo... esto sólo lo sabe tocar Manolo que lleva meses trabajando en ello.
Todo el equipo se reúne periódicamente, incluidos usuarios y analistas de negocio, a ser posible diariamente y si no, al menos una vez a la semana. Por norma general, se admite que sólo los desarrolladores se reúnan diariamente y que la reunión con el cliente/analista sea sólo una vez a la semana, ya se sabe que no vivimos en un mundo ideal. De hecho, nos contentaremos con que el cliente acuda a las reuniones de comienzo de iteración.
Las reuniones tienen hora de comienzo y de final y son breves. Cuando suena la alarma de fin de la reunión, es como si sonase la campana de incendio en la central de bomberos: cada uno de vuelta a su puesto de trabajo inmediatamente.
La superación de obstáculos imprevistos tiene prioridad sobre las convenciones o reglas generales de trabajo preestablecidas.Es decir, si hay que saltarse el protocolo de la empresa para resolver un problema que se nos ha atravesado, se hace. Por protocolo nos referimos a la forma en que habitualmente cooperan unas personas con otras, o tal vez la manera en que se lanzan nuevas versiones,...
Las grandes decisiones de arquitectura las toma todo el equipo, no son impuestas por el arquitecto. Sigue siendo recomendable utilizar patrones de diseño y otras buenas prácticas pero siempre dando máxima importancia y prioridad a los requisitos de negocio. Las arquitecturas ágiles son evolutivas, no se diseñan al completo antes de escribir el código de negocio. Este libro defiende particularmente las arquitecturas que emergen de los requisitos; TDD habla de que la arquitectura se forja a base de iterar y refactorizar, en lugar de diseñarla completamente de antemano.
La aplicación se ensambla y se despliega en entornos de preproducción a diario, de forma automatizada. Las baterías de tests se ejecutan varias veces al día. La cobertura de los tests (que mide el porcentaje de código que tiene tests asociados, considerando todos los cauces que puede tomar el flujo de ejecución) debe ser en torno al 60 % o mayor. En realidad, se trata de tener en cada iteración una cobertura aún mayor que en la anterior, no hay que ser demasiado precisos con el porcentaje.
Los desarrolladores envían sus cambios al repositorio de código fuente al menos una vez al día (commit). Cada vez que se termina de desarrollar una nueva función, esta pasa al equipo de calidad para que la valide aunque el resto todavía no estén listas.
Partiendo de estas premisas, cada metodología o técnica ágil detalla con exactitud cómo se gestiona el proyecto y cómo es el proceso de desarrollo del código. A veces se pueden combinar varias metodologías aunque algunos autores recomiendan seguir al pie de la letra la metodología en cuestión sin mezclar ni salirse del camino en ningún momento.
No podemos negar que las metodologías son a menudo disciplinas y que implantarlas no es sencillo, todo tiene su coste y tenemos que poner en la balanza las dificultades y los beneficios para determinar qué decisión tomamos frente a cada problema. En el libro de Roberto Canales se habla precisamente de la implantación y puesta en marcha de metodologías en la empresa.
Esperemos que en el futuro cercano contemos con literatura en castellano sobre cada una de las metodologías ágiles más populares.