(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)
El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.
Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:
- La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
- La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar por el Product Owner.
- La calidad interna no suele poder ser verificable directamente por el Product Owner.
Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.
Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.
Según se indica en la guía oficial de Scrum, “el Scrum Master entrena y guía al equipo para que sea más productivo y entregue productos de mayor calidad”. Al ser el responsable de la calidad en el proceso, el Scrum Master guía al Product Owner y al equipo para conseguir que:
- El Product Owner (re)priorice en función del valor aportado al negocio (y el coste de implementación).
- El equipo cumpla con la definición de hecho que ha sido consensuada con el cliente.
- El Product Owner revise el producto al final de cada iteración, en la reunión de Demostración de los requisitos completados.
- El equipo tome consciencia del producto que está entregando (si cumple con las expectativas del Product Owner, si se está degradando la calidad externa e interna y se está introduciendo “deuda técnica” que dificulte su crecimiento sostenido) y guiarlo para que reaccione si hay problemas (como menciona Xavier Quesada), especialmente en las reuniones de retrospectiva al final de cada iteración.
- Similarmente, el Scrum Master debe hacer recapacitar al Product Owner si quiere rebajar la calidad a cambio de conseguir objetivos en fechas determinadas (lo cual produciría defectos en el producto una vez entregado, ralentizaría después la velocidad del equipo y tiene el riesgo de mala imagen respecto a los consumidores/clientes/usuarios). Si finalmente es necesario hacer esto, el Scrum Master tiene que hacer que esta decisión se tome al nivel más alto posible y que sea visible. Con posterioridad a la toma de esta decisión, el Scrum Master debe ser capaz de demostrar, si es necesario, las consecuencias de haber rebajado la calidad mediante gráficos de tendencias de velocidad y defectos, así como explicar sus causas objetivas (menos testing, menos refactoring, …) [1].
Agilidad es reaccionar ante los impedimentos, problemas, equivocaciones o errores y tomar acciones correctoras, no “mirar a otro lado”, como diría Ángel Medinilla.
Enlaces relacionados
Referencias
[1] Succeeding with Agile: Software Development Using Scrum – Mike Cohn.
Proyectos Ágiles 