Enfócate en la calidad
Primer paso de la receta para tener éxito
Enfocarse en la calidad es el primer paso de la receta para tener éxito adoptando un nuevo equipo que David J. Anderson propone en su libro Kanban. David basa esta propuesta en su experiencia y en la de otros que, como él, han tenido que adoptar equipos disfuncionales y transformarlos en equipos funcionales. Enfocarse en la calidad parece lógico, pero, ¿por qué?
El problema con las cosas que parecen lógicas es que rara vez son cuestionadas. Lo malo de no cuestionar algo es que es fácil quedarse en la superficie. Para poder entender qué significa enfocarse en la calidad hay que entender primero por qué es importante enfocarse en la calidad.
Una de las formas más comunes de desperdicio es el número de defectos que introducimos inadvertidamente en nuestro producto. Nos obligan a volver a trabajar en algo que creíamos que estaba terminado y afecta a la predictibilidad de nuestro sistema. Sobre todo si no hemos dejado ninguna holgura. Cuando el número de defectos es excesivo, no solo afecta a la entrega. Afecta a la moral del equipo, a su productividad, a la confianza y a la reputación de nuestro producto y nuestra compañía. De hecho, el ratio de fallos por despliegue es una de las métricas clave de DORA. No solo por su alto impacto, sino porque sin una mínima calidad en el sistema no podemos mejorar. Básicamente, lo urgente no dejará tiempo para lo importante.
Sin embargo, enfocarse en la calidad no es un esfuerzo que hagamos una vez en la vida de nuestro producto, sino que implica crear una cultura de equipo donde la calidad es esencial, está presente en todas nuestras decisiones y forma parte de nuestro proceso de mejora continua.
No creo en las balas de plata, aunque considero que hay prácticas, como el testing automático, que son obligatorias. En mi opinión, es mejor realizar un análisis de la causa que provoca la mayor parte de defectos en nuestro software y atacarla específicamente. No voy a darte una lista exhaustiva, pero algunos de los factores que creo que afectan a la calidad son:
Tests que no cumplen su función. Otro día escribiré sobre las cualidades de un buen test, pero un test que no es capaz de detectar regresiones no es un buen test.
Una alta carga cognitiva. Esto puede requerir cambiar cómo nos estamos organizando, pero también puede ser porque nuestro código no tiene un buen diseño o porque tenemos demasiada complejidad accidental.
Falta de conocimiento del dominio. Las soluciones que podemos implementar cuando no conocemos el dominio y, por tanto, no entendemos el problema suelen incluir una mayor carga cognitiva y mayor complejidad accidental.
Falta de colaboración o una comunicación defectuosa. Esto también puede tener que ver con la organización del equipo.
Demasiado trabajo en proceso. Demasiados focos abiertos con muchos cambios de contexto afectan a la calidad de nuestro código.
Problemas de diseño. Código muy acoplado, cambios en una parte del código generan errores en otras áreas que no esperábamos. Suele venir aparejado con la falta de una buena red de tests automáticos.
Código complejo, difícil de entender y que no expresa claramente su intención.
Seguro que tú puedes añadir algunas más a la lista. Por favor, hazlo y compártelo con todos nosotros.
Enfocarse en la calidad no es el objetivo, pero es un medio ineludible si queremos terminar este viaje y llegar a buen puerto. Sobre todo si el viaje pretende ser largo. Enfocarse en la calidad no es onanismo técnico, pero es fácil caer en la sobreingeniería y perder la perspectiva de por qué hacemos lo que hacemos. La virtud está en el punto medio, intentemos ser virtuosos.