La calidad es un elemento que se considera un pilar en la agilidad. En el Manifiesto Ágil está incluido como uno de sus principios: La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. Este principio lo que viene a decir es que estar atento a crear software de calidad ayuda a cumplir uno de los propósitos de la agilidad, software funcionando que cubra las necesidades de los usuarios. No es posible entregar valor y es posible cubrir las necesidades de los usuarios si un software falla repetidas veces.
Por otro lado, si conseguimos que el software funcione adecuadamente a la primera, ahorraremos muchísimo tiempo en la búsqueda y resolución de defectos. Esto nos trae 2 consecuencias: mayor producción de nuevas características para los usuarios (con los beneficios que ello conlleva) y una mayor motivación por parte de los desarrolladores (como se indica en “State of Technical Debt 2021”).
Otra muestra de la importancia que tiene la calidad técnica para la agilidad es que una de las prácticas más recomendadas para la codificación de pruebas, TDD (Test Driven Development) que sigue la filosofía de Test-First , fue propuesta dentro del marco del método ágil de desarrollo eXtreme Programming (Kent Beck, 2002).
Test-First es una línea de pensamiento que da un paso más allá sobre la manera de probar que había hasta el momento y propone programar primero los tests antes que la propia funcionalidad. Esta práctica hace que el programador se pare a pensar qué pruebas a de superar la funcionalidad que va a codificar, situando de esta manera los casos de uso y creando directamente un código que las supere.
La calidad en Agilidad va más allá de las propias pruebas de los programadores y propone realizar pruebas automatizadas directamente sobre los requisitos ágiles siguiendo la filosofía Test-First. Esta técnica, llamada BDD (Behaviour Driven Development), propone que las personas de negocio escriban, utilizando un lenguaje casi natural, pruebas que después, con ayuda de los programadores, se ejecuten de forma automática.
BDD tiene 2 objetivos: el primero es facilitar la verificación, por parte de los desarrolladores, de los requisitos indicados por negocio; el segundo es algo que persigue siempre la agilidad, promover el trabajo colaborativo. Negocio y los desarrolladores deberán trabajar de manera conjunta, al menos, durante la escritura de las primeras pruebas, esto va a crear un espacio de colaboración y un lenguaje común que facilitará la comunicación en el futuro.
De manera paralela a la agilidad y con algunos valores y principios muy cercanos nace DevOps. DevOps, al igual que la Agilidad, se considera una forma de pensar, es decir, una cultura. DevOps promueve acercar los mundos de los desarrolladores que quiere ofrecer lo último al usuario con el mundo de Operaciones que busca la estabilidad para una buena experiencia por parte de los usuarios. Para ello diseñan un conjunto de herramientas que básicamente tratan de evitar el error humano.
Estos errores humanos incluyen los defectos del software y para ello se configuran sistemas que, cada cierto tiempo o incluso cada día, ejecutan pruebas automatizadas que garantizan que los nuevos desarrollos no modifican el comportamiento de los ya existentes.
Cuando escalamos la agilidad la importancia de la calidad aumenta de manera exponencial al igual que la relevancia de la filosofía DevOps. Tal es así, que la base de conocimiento más utilizada en el mercado para escalar la agilidad, SAFe (37% de la cuota de mercado en 2021), la contempla como uno de sus valores clave “Build in Quality”.
Build in Quality incorpora diferentes aspectos en busca de que cada elemento e incremento tenga la calidad adecuada. Para ello contempla 5 dimensiones.
Establecer un Flujo que persiga la eliminación de errores es la primera dimensión. Para ello se propone utilizar técnicas Test-First, como las explicadas anteriormente, junto con técnicas DevOps que automaticen tareas y garanticen el nivel de pruebas necesario para el producto.
La Arquitectura y Diseño de calidad (segunda dimensión) no pretende dar una arquitectura y diseño de las soluciones completamente definidas. Otro de los principios del manifiesto ágil nos dice: “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados”. Hasta que no conocemos, con bastante profundidad, las necesidades reales de los usuarios no podremos definir completamente la solución. Sin embargo, y sobre todo si hablamos de productos muy grandes donde intervienen varios equipos, es necesario tener un marco de trabajo, conjunto de reglas y posibles soluciones en base a diferentes escenarios (patrones de diseño) que aseguren la calidad del software.
Tener un código de calidad es otro de los pilares necesarios para conseguir Build in Quality. El código debe ser legible, fácilmente modificable y extendible con comodidad. Para ello se propone la integración de diferentes prácticas, en su mayoría extraidas de eXtreme Programming como: TDD, pair programming, propiedad colectiva del código, etc.
Tener una arquitectura, diseño y código de calidad no es suficiente, necesitamos asegurar que el software hace lo que se espera y que al integrarlo, con lo ya existente, no aparezcan anomalías de comportamiento. En otras palabras, necesitamos calidad en el sistema completo. Para ello se propone, por un lado, una técnica que alinea lo que negocio o el usuario ha solicitado con el código implementado, BDD (la cuál ya hemos comentado más arriba); y por otro la integración continua y frecuente de los nuevos desarrollos en un flujo automatizado que ejecute todas las pruebas y así garantice el correcto funcionamiento del sistema al completo.
Cualquier nuevo desarrollo realizado o requisito en realidad es una hipótesis de una manera de cubrir una necesidad del usuario. Por tanto, cuanto antes la validemos o descartemos mejor. Para ello es necesario disponer de una liberación de calidad que nos permita poner una hipotética solución en manos del usuario rápidamente y, si fuera necesario, también quitarla rápidamente para hacer alguna modificación o descartarla. No es posible hacer esto si no tenemos arquitecturas, diseños y códigos de calidad que nos facilite hacer pequeñas modificaciones de manera sencilla y estable, así como entornos automatizados que nos permita puestas en producción y vuelta atrás rápidas (infraestructura inmutable).
Existe otro punto imprescindible, y muchas veces olvidado, que nos va a permitir una liberación de calidad y es la consecución de requisitos normativos o de seguridad que sean de obligado cumplimiento. Si estos requisitos no se cumplen, aunque la solución esté construida, no se podrá ponerla en manos de los usuarios. Para ello, lo que se propone es incluir estas restricciones como parte de las validaciones que se realizan para dar el trabajo por terminado (Definición de hecho).
En conclusión, sin calidad nunca podrá existir la agilidad, ya que es el único camino para obtener la satisfacción del cliente y validar las hipótesis lo más rápidamente posible al aumentar la frecuencia de entrega de nuevas funcionalidades debido a la poca necesidad de ocupar la capacidad del equipo corrigiendo defectos, la automatización de procesos, la “infraestructura inmutable” y la calidad en la arquitectura, diseño y código que favorece y soporta todo lo anterior garantizando la mantenibilidad, expansión, entendimiento y testeabilidad del software.