Pensamientos de otro más

Desde mi punto de vista, lo ideal es que la calidad quede automatizada e integrada en el propio proceso. Si algo falla, que pasará, algún tipo de alarma o aviso debe de saltar para que pueda ser corregido por alguien. Si algo falla y no se detecta, ya no es solo un problema, sino que es un problema del proceso y habrá que modificarlo para solucionar ese fallo de detección. Si alguien tiene que estar supervisando un proceso para controlar la calidad, es que dicho proceso no produce calidad solamente, sino que también produce defectos o desperdicios. Teniendo en cuenta que en la actualidad esto llevado al extremo es casi imposible, lo que nos tendremos que quedar es algo intermedio. Para lograr una excelente calidad en un proyecto necesitamos automatización y supervisión humana, lo mínimo indispensable en este último punto.
En Japón esta filosofía se denomina “Jidoka”, que podríamos traducirla como medio-automatización o automatización con ayuda humana. 

Este termino, “Jidoka” viene de Toyota, en concreto del telar que desarrolló Sakichi Toyoda, fundador de la empresa “Toyota” (Como no :P), que permitía parar la máquina, cuando esta rompía el hilo que utilizaba y así no terminaba desencadenando todos los problemas que esto ocasionaba.

De aquí, transladándolo al desarrollo de software, un ejemplo de auto-calidad dentro del proceso podría ser, el utilizar una buena herramienta de gestión de tareas como Jira, junto a sus plugings Greenhoper, FishEye, Crucible y Bamboo. Habituando al equipo a utilizar este tipo de herramientas, podremos llegar a tener un sistema totalmente integrado, que nos proporcione un buen nivel de calidad.

Un ejemplo simple de su uso prodría ser el siguiente:

1º Alta de nueva funcionalidad a implementar en el proyecto dentro de Jira (Historia de usuario).
2º Implementación de la funcionalidad en el Sprint actual suponiendo que utilicemos Scrum (Greenhoper)
3º Trazabilidad desde los requisitos introducidos en la tarea de Jira hasta los cambios que estos han ocasionado en el repositorio de código en su desarrollo (FishEye)
4º Revisión del código de esta tarea (Crucible)
5º Auto-build del proyecto completo con estos cambios de código (Bamboo)
6º Auto ejecución de test (Bamboo)

Si podemos conseguir que todo el equipo implicado en el proyecto siga estos pasos, habremos conseguido tener un mínimo control semi-automatizado de calidad, que ya quisieran muchos proyectos.
También quiero dejar muy claro, que la calidad no es responsabilidad de un único grupo o departamento. La calidad es responsabilidad de todo el equipo, desde la persona encargada en la toma y redacción de requisitos, hasta el programador más junior que tiene que esforzarse por escribir un buen “Clean Code”.

Otro buen ejemplo de prácticas que nos aseguran un mínimo de calidad en el proyecto siguiendo el proceso, sería TDD. Pero no de una forma de inspección después de la codificación, ni una etapa final o intermedia. Sino, como una disciplina de trabajo, una disciplina compartida por todo el equipo y todos los equipos de desarrolladores. Cada uno, debe de responsabilizarse de crear, ejecutar y mantener un conjunto de pruebas unitarias de todo el código que escribe, y estas deben ser automatizadas y ejecutarse en un tiempo moderado. Además de las pruebas, TDD define una refactorización del código continua, en la que el programador debe buscar en su propio código la forma de mejorarlo, dejarlo limpio, mantenible y así ahorrar tiempo futuro en su comprensión, con un gran ahorro también en deuda técnica.

Aunque parezca mentira, aquí lo difícil de su implantación no es la técnica, ni los medios, ni si quiera el tiempo de desarrollo, sino el que cada miembro de cada equipo asuma esta forma de trabajo como su responsabilidad. Cada miembro debe asimilar y comprender que el resultado del proyecto depende en gran parte de él y que si utiliza estas técnicas, llegará a tener un gran control de calidad, un código realmente mantenible y será finalmente más productivo. Algo duro y difícil de conseguir en una empresa.

Por desgracia, la calidad ha acabado siendo víctima de su propio éxito. Ha sido convertida en un fetiche del marketing, donde no importa tanto mejorar la calidad del proceso productivo, como obtener y galardonarte con una certificación de tal o de cual organización de moda. La pena, es que esto está empezando a pasarle también a las Metodologías Ágiles. Así que entendamos bien los conceptos básicos de calidad para que esto no nos ocurra a nosotros