Desde hace tiempo, la cultura Agile cada vez está más presente, ya sean empresas que trabajan con frameworks Agile, como Scrum o Kanban, otras que están en etapa de transformación y algunas que están empezando proyectos piloto. La única conclusión asegurada es que, en un futuro muy próximo, el desarrollo en cascada terminará desapareciendo.
¿Pero qué pasa con la calidad?
Lo que está claro es que la Calidad de Software no está siguiendo el ritmo a la transformación Agile. Embaucados por el ritmo frenético de entrega cada dos semanas, que por ejemplo garantiza Scrum, en muchos casos hace que la Calidad se abandone por completo. Excusas para este suceso he oído muchas y todas muy parecidas:
- «Es que vamos muy apretados con el Sprint»
- «Nunca nos lo han pedido y si lo hacemos ahora, no llegaremos al Goal»
- «Es que no aporta valor en la entrega». Bueno, la calidad parece que no aporta valor ahora mismo, pero cuando tengas un sprint repleto de bugs, comprenderás que al final siempre resulta lo comido por lo servido.
- «En mi bonus, tenemos que entregar X incremento». De todas las excusas, es la única que entiendo y respeto, a fin de cuentas todos trabajamos por dinero. Eso sí, también hay que ser consecuente con que el bug al que llamas software no funcione bien.
Al final el resultado de abandonar la calidad completamente es que el producto entregado empieza a ser inmantenible e intestable. Poco a poco los Sprints se empiezan a llenar de bugs y desaparecen las nuevas funcionalidades o mejoras del incremento.
Lo peor de todo es que, cuando se quiere revertir esta situación y retomar el proceso de Calidad, existen muchas reticencias, por ejemplo el equipo de negocio sigue exigiendo el mismo ritmo de entrega o el equipo de desarrollo no tiene los conocimientos para abordar la deuda técnica o no existen procesos automáticos y todo se está realizando a mano. Entonces la labor ya parece mucho más difícil de abordar y el resultado de no incluir la calidad en el proceso de transformación, hace que tengas procesos ágiles conviviendo con procesos en cascada, que claramente no casan.
Lanzo una pregunta:
un proyecto Scrum de entrega cada dos semanas al cual no ha acompañado un proceso de transformación de Calidad ¿cómo se está afrontando?
Por lo que he podido ver, la Calidad se convierte en una etapa aislada del desarrollo y la mayoría de proyectos se convierten en proyectos similares a este:
- Product owners y analistas diseñan las tareas para completar el backlog.
- El equipo de desarrollo trabaja en las dos o tres semanas que dura el Sprint.
- El equipo de Testing Funcional valida el nuevo desarrollo y ejecuta las pruebas de regresión del software. Generalmente se le suele dar un tiempo de una a dos semanas para probar.
Personalmente, lo que veo aquí es un proceso en cascada que se realiza cada dos semanas. Si el software sigue creciendo con ese ritmo de entrega, pero el equipo de Testing Funcional no crece, llegará un momento en el que no puedan abarcar ni las regresiones y la oleada de incidencias productivas harán tambalear el proyecto.
En este punto vienen las preguntas:
- Equipo: –”¿No tenemos nada automatizado?”
- Yo: – “Es que vais muy apretados con el Sprint”
- Equipo: –”Pero ¿por qué están llegando tantas incidencias?”
- Yo: –”Pues porque los test automáticos como los Test Unitarios, no aportan valor.”
- Equipo: –”¿Y los testers no prueban?”
- Yo: –”Pues con el ritmo de entrega sin control que estamos haciendo en etapas inferiores para poder llegar al bonus, los testers están desbordados.”
Entonces ¿qué podemos hacer?
En Qualtio somos especialistas en adaptar la calidad a todo el proceso de desarrollo de software con Agile. Porque el desarrollo de software no solo implica desarrollar y entregar lo que hago cada dos semanas sin control, esperando que todo salga bien y tiritar de miedo cada vez que se sube algo a producción.
La calidad de software tiene que llegar a todas las fases, desde el análisis y diseño de software hasta la entrega del mismo. La calidad aporta seguridad a todos los miembros del equipo, a los clientes y sobretodo a la empresa.
Si el Análisis y Diseño se lleva a cabo realizando unas buenas prácticas como los 3 amigos, BDD y respetando el DoR, se evitan las pérdidas de tiempo ocasionadas por Criterios de Aceptación que no se entienden bien por parte del equipo de Desarrollo.
Si en la etapa de Desarrollo se sigue correctamente el flujo de trabajo elegido, ya sea Gitflow o Github Flow, se realizan todas las pruebas que dictamina la Pirámide de Testing y se hace caso a las herramientas de Calidad Estática, tendremos un Software mantenible, testable y validado.
Si en la etapa de Entrega, se envuelve el Software con un buen versionado como el Semver, una documentación eficaz con un Readme y un Changelog; y se automatizan los procesos con una herramienta de Integración Continua, dejarás de tiritar de miedo y rezarle a todos los dioses que conoces.
Si acompañas la transformación Agile con una buena transformación de QA, la calidad de todo el proceso de desarrollo está garantizada y empezarás a vivir bien.
