Calidad durante el ciclo de vida de un producto en entornos ágiles.

Si en un anterior post hacíamos un repaso a las herramientas y tecnologías favoritas para nuestros equipos de desarrollo y calidad, en esta nueva entrega referente al Quality Assurance (QA) nos centraremos en la calidad durante el ciclo de vida de un producto. La vida de un producto software dura hasta que éste deja de usarse. Pero en el entretanto, se está en continuo proceso evolutivo y correctivo. Para conseguir un estándar de calidad superior, ésta tiene que estar presente en todas sus fases.

Estos son los pasos que atraviesa un producto, de manera simplificada y sin que ellos sean secuenciales:

• La idea en la que se basa: Debe ser una buena idea, porque si la idea ya es errónea el producto será erróneo (útil, simple, manejable, escalable...).
• Requerimientos: Deben estar limitados para que sean consistentes. La mente del desarrollador debe ser capaz de abarcarlo de manera sencilla para que la idea no pierda consistencia (Los ítems superiores o más importantes deben estar bien detallados y los medios o inferiores apenas detallados).
• Desarrollo y Testing: Para conseguir la calidad máxima en el desarrollo ha habido que combinar buenas prácticas de Lean y XP (TDD, Pair Programming, Commit Reviews, Code Reviews, Clean Code, Continuous Integration…). Todas estas técnicas contribuyen a elevar los niveles de calidad, pero no todas pueden ser automatizadas, como las Exploratory Testing (el que realiza la prueba va aprendiendo a manejar el sistema mientras se prueba el software y, según su destreza y creatividad, indicará nuevas pruebas a ejecutar).
• Documentación y skills: También es importante que la documentación del producto se corresponda con el código testado y las validaciones aprobadas por el cliente, que los equipos de trabajo sean multifuncionales (nunca sobra el ingeniero de calidad sino que, al contrario, es fundamental), que haya usuarios externos en las pruebas, etc.
• Producción: Es importante tener el feedback del usuario lo más rápido posible, a ser posible al final de cada sprint. Si no, al final habrá muchos errores, habrá pasado tiempo desde que se desarrolló el código y costará mucho más modificarlo.

Calidad objetiva y subjetiva

La calidad objetiva afecta a los requisitos pactados: o se cumplen o no se cumplen. La calidad subjetiva depende de los usuarios, es más difícil de consensuar y establecer. Es muy útil tener en mente el concepto de objeto físico que se puede manipular con las manos, pese a que la inmensa mayoría de nuestro trabajo sean programas binarios que funcionan sobre corriente eléctrica. La idea de un entregable en un paquete, o por poner una fácil analogía, el trabajo musical de un grupo de rock encerrado en un disco con su carátula artística, las letras, información de estudio, fotos, etc. pueden ayudar a esta conceptualización.

Desde un principio, el equipo tiene que definir el producto que va a desarrollar en categorías de calidad objetivas y subjetivas y, para conseguir beneficios en la planificación, debe hacer una aproximación iterativa e incremental. De esa manera, en cualquier iteración se podría entregar siempre un producto funcional, aunque fuese en versiones básicas.

De esta manera, si pasamos de la idea a la "cosa", en cada iteración se pueden definir diversas cualidades o atributos que dependiendo del tiempo, el presupuesto y la lista de deseos del cliente, podrán ir o no incluidos. En general, existen tres dimensiones a tener en cuenta en el prototipado:

1. Must-haves: Son los que tiene que tener sí o sí. No son necesariamente los que más impresionen al cliente, pero son necesarios, constituyen la base del producto.
2. Unidimensionales: Definen la calidad del producto, son variables y aportan satisfacción al usuario: ergonomía, usabilidad, engagement, curva de aprendizaje.
3. Los requisitos atractivos: No son fundamentales, pero sí son los que más satisfacción aportan al cliente: diferenciación, novedad, diseño, apariencia, solidez, prestigio.

Luego, existen otros muchos factores indirectos que van a condicionar el resultado final: incumplimiento de los plazos pactados, errores de estimación en las horas de trabajo/hombre requeridas (desviaciones tanto a favor como en contra), costes ocultos de fabricación y distribución (subida a producción), soporte y mantenimiento ajenos (hosting, etc)... Dependiendo de todos ellos, el producto estará mejor o peor logrado.

La calidad no se negocia nunca

Y habrá otros factores como el coste o el tiempo de elaboración que pueden variarse, pero nunca la calidad. Y esto, por supuesto, requiere un entrenamiento en las técnicas del agilismo por parte del equipo de trabajo que no se improvisan de un día para otro.