Por Félix Bragado
Actualmente se habla mucho de la cultura Agile y como gestor de cambio certificado creo firmemente en la necesidad de que el equipo tenga los valores y la cultura adecuada para trabajar bajo los frameworks Agile más conocidos. Sin embargo, en mi experiencia actual me estoy encontrando con un rol que es el gran abandonado desde que nos enfocamos en la cultura: El development team.
Es cierto que las personas que construyen los nuevos productos o servicios necesitan un cambio de cultura, sobre todo si son veteranos y llevan tiempo desarrollando bajo una mentalidad de ordeno y mando, más típica de jefaturas de proyecto de las metodologías en cascada. Decirles de pronto que van a trabajar en un marco Agile, que deben ser multidisciplinares y autorganizados porque lo dice un determinado framework con el que van a empezar a trabajar está bien, pero es necesario proporcionarles las herramientas que se lo permitan.
Comentan los psicólogos que es necesario practicar una misma rutina durante al menos 21 días seguidos para que se convierta en una práctica habitual que tengamos interiorizada. Por otro lado, hay muchos gurús que indican que para considerarte un experto en algo debes de haberlo puesto en práctica durante al menos 10.000 horas. Y nosotros cogemos a un grupo de personas, les indicamos que esta es su nueva forma de trabajar, les damos unas sesiones de formación y les decimos que el lunes que viene tienen una reunión que se llama sprint planning y que en esa reunión se decide el trabajo para las próximas semanas...
Es cierto que hay que comenzar y que no se pude dilatar el arranque. Es cierto que necesitas cambiar tu cultura para aclimatarte a una nueva forma de trabajo. Pero no es menos cierto que se tiene que proporcionar al equipo de trabajo las herramientas adecuadas para que puedan adaptarse. Lo interesante es que esas nuevas herramientas además de ayudarte a las tareas del día a día, deben servir de palanca para crear esa nueva cultura. Vamos a hablar de algunas de ellas:
Acceptance Test Driven Development
A mi modo de ver, es una de las primeras y mejores inversiones que podemos hacer en los nuevos equipos Agile. Los equipos van a desarrollar software que implemente una necesidad de negocio expresada por medio de una historia de usuario. Esa historia de usuario, si está bien escrita, tendrá asociada uno o más criterios de aceptación, que son, ni más ni menos, una definición a alto de nivel de las pruebas que nuestro validador (product owner) va a hacer de las propias historias.
¿No parece una buena idea que desarrollemos nuestro código orientándolo a satisfacer los criterios de aceptación? Es posible que esos criterios impliquen muchas cosas o incluso que sean ambiguos, pero aclarar ese contenido ya forma parte de esa nueva cultura que queremos implantar.... Aumenta la colaboración entre los developers y el product owner, que aprenden juntos a definir el tamaño y el grado de definición necesario en las historias de usuario para poder trabajar con ellas. Añadimos los criterios de aceptación a nuestras historias de usuario y a partir de ellos construimos las pruebas de aceptación con las que validar la necesidad de negocio contenida en la historia de usuario.
Y, ¿por qué parar ahí? Continuemos aplicando la misma filosofía para desarrollar pruebas más técnicas desde la definición de nuestras pruebas de aceptación, construyendo a partir de ellas las de rendimiento, funcionales, de integración, hasta llegar a las unitarias, construyendo primero las pruebas y luego el código. Partiendo de las pruebas que validan que nuestro código hace lo correcto, podemos ir escalando por las diferentes pruebas hasta lograr el objetivo que indican los criterios de aceptación, creando un software que da respuesta a esas pruebas y, por tanto, a las necesidades del cliente. Además, el grado de cobertura de nuestro código será muy alto y aumentaremos la calidad del software que entregamos.
Además, hay otros dos conceptos que lo hacen interesante: la deuda técnica y la entrega en incrementos. La deuda técnica consiste en aquellas concesiones que vamos haciendo a la hora de desarrollar el código que hace que no sea óptimo. Por ejemplo, tener que usar Mocks durante el desarrollo o ir definiendo la arquitectura conforme vamos avanzando puede hacer que nuestro código luego requiera una "refactorización". ¿Cómo sabemos si afecta esa "refactorización" a otras partes de nuestro código? Por medio de una prueba de regresión que valide de forma rápida si las modificaciones han impactado en otras partes de forma incontrolada.
Esa misma conclusión se puede aplicar cuando vamos aumentando la cantidad de software desarrollado en cada incremento. ¿Cómo sé que el nuevo software o los cambios que haya hecho sobre el software desarrollado en este sprint no conllevan comportamientos inesperados? Si tengo un alto grado de cobertura de código, podré lanzar las pruebas de regresión que me permitan validar que realmente tengo un incremento integrado y no piezas de software inconexo... Por cierto, ¿cómo podemos ejecutar las pruebas de regresión sin que cada vez tengamos que invertir más tiempo de los developers? Eso nos lleva al siguiente paso...
Integración Continua
Es necesario disponer de un sistema que nos permita lanzar las pruebas de forma automatizada, es decir, que los developers puedan ejecutar las pruebas de forma que les consuman el menor tiempo posible. ¿Cómo logramos eso? Bien por medio de una herramienta, bien por medio de scripts realizados a mano que se puedan ejecutar de forma desasistida. ¿Qué tipo de pruebas podemos automatizar? Todos los tipos de prueba se pueden automatizar, comenzando por las más cercanas al código (pruebas unitarias), las que verifican que nuestras piezas de código independiente se comunican correctamente (pruebas de Integración), las que verifican que nuestro sistema hace lo que debe hacer (pruebas funcionales) y las que verifican que nuestro sistema mantiene un rendimiento dentro de unos límites aceptables (pruebas de carga).
Es necesario que los developers realicen pruebas y que vean la forma de automatizarlas para poder hacer muchas pruebas en poco tiempo. También es importante hablar de la calidad de las pruebas (¿De qué me sirve probar tres casos sencillos que sé que van a funcionar? Prueba uno sencillo y luego ve a los extremos, provocando situaciones de error y que el sistema falle cuando deba fallar), de grado de cobertura, de hacer "peer review" en que cada miembro del equipo revise el código de otro, que no sean siempre las mismas personas, que poco a poco todos puedan ser revisores de código y este esfuerzo se tenga en cuenta en cada sprint.
Además, tenemos que contar con un sistema que permita compartir código en remoto y que el equipo sepa cómo queremos crear las ramas y su unificación en ramas troncales como "master" o "develop", definir cómo y cuando se crean las ramas, cómo hacer una pull request... A lo mejor tú, que nos estás leyendo, crees que todo esto es obvio para todos los equipos. Nuestra experiencia nos dice que no es tan obvio y que hay personas que cometen estos errores simplemente porque nadie pregunta al iniciar el proyecto si todos son capaces de entender y llevar a cabo estas prácticas.
De nuevo, trabajar con integración continua es una palanca que nos permite crear esa cultura Agile que todos queremos en nuestros equipos: Dar transparencia al trabajo que estamos haciendo, tener inspecciones frecuentes tanto manuales como automatizadas, mejorar nuestro código adaptándolo a los defectos encontrados, aumentar nuestras pruebas para dotar de más calidad al código...
¿Suena de algo? Transparencia, inspección, adaptación...
Por último nos queda un detalle más: ¿Y si a nuestro proceso de integración continua le añadimos algo que nos permita hacer despliegues al mismo ritmo?
Despliegue Continuo
Uno de los errores más habituales cuando se trabaja con varios entornos (local, desarrollo, integración, pruebas, producción, por poner un ejemplo) es pasar de un entorno a otro sin actualizar las referencias a sistemas externos a los que nos conectamos, como puede ser una cadena de conexión a una base de datos o un sistema LDAP.
Es cierto que, desde hace muchos años, hay herramientas en el mercado que nos permiten configurar nuestras aplicaciones por medio de ficheros de configuración, simplificando la promoción entre entornos y controlando las dependencias de nuestro código. ¿Y si disponemos de un sistema automatizado que nos asegure que no nos equivocamos al decir qué fichero hay que usar al pasar de un entorno a otro? ¿Y si podemos disponer de infraestructura como un servicio y no depender de otras áreas para hacer despliegues? En este punto se ve el buen encaje que tiene DevOps (si le añadimos seguridad con DevSecOps ya sí que damos la campanada) con el desarrollo Agile de productos.
El despliegue continuo encaja muy bien con la necesidad de hacer entregas continuas y constantes que requiere trabajar en equipos Ágiles. Pasos pequeños, firmes, seguros y completos.
Dudo que haya alguien a quien no guste o no encaje este discurso... Pero es necesario tener en cuenta cuando montamos un equipo nuevo que queremos que trabaje de modo Agile, que no basta con una formación en Scrum de cuatro horas y lanzar al equipo a las fieras. Es necesario asegurar que el equipo dispone de todas estas capacidades o, en un escenario realista, que se les permita adquirirlas en los primeros meses de funcionamiento del equipo.
En los valores del manifesto Agile se indica "Individuos e Interacciones por encima de procesos y herramientas". Cierto, pero eso no implica eliminar las herramientas. Es necesario proporcionar herramientas adecuadas que permitan que los equipos trabajen de forma eficaz y eficiente, para poder entregar un incremento de valor al finalizar cada sprint.
Conclusión
El desarrollo de productos bajo frameworks Agile tiene muchas ventajas, pero estas se deben aprovechar en los contextos adecuados (complejos, cambiantes...) y con los equipos con los conocimientos adecuados, los cuales implican mucho más que sólo la tecnología de desarrollo.
Para que los equipos dispongan de los conocimientos adecuados o se dispone de personas muy expertas o se dota a esas personas de conocimientos... No con una simple formación, sino permitiendo al equipo practicar, equivocarse, inspeccionar, adaptarse y dar lo mejor de sí mismos. El resultado merece la pena, invirtiendo el tiempo adecuado y apoyando a los developers... Creando una cultura Agile dentro del equipo y unas palancas que permitan hacer realidad esos beneficios.
Siempre podemos seguir haciendo lo mismo, pero como dijo Einstein:
