¿La calidad es negociable?

En Scrum la calidad es build-in, no es una variable - cortesía de Pixabay

Un proyecto no puede ser un éxito sin un alto nivel de "contento" por parte del cliente con el producto que le hayamos entregado. En un proyecto gestionado por metodologías tradicionales es factible negociar bajar la calidad con el objetivo de cumplir con los hitos y la fecha de entrega. Al cliente no le sirve lo perfecto, sino tener el producto a tiempo.

En Agilidad la calidad no puede ser una variable, los métodos ágiles priorizan los objetivos del proyecto en función del valor de negocio. A diferencia de las metodologías tradicionales siempre se trabaja con calidad, y para llegar a fechas se prescinde de funcionalidades que aporten poco valor de negocio, de aquellas que están al final de la pila de producto.

Recordemos el noveno principio del Manifiesto Ágil:

La atención continua a la excelencia técnica enaltece la Agilidad

Una técnica que nos garantiza la calidad es la comprobación continua, cuanto más nos ayudemos de este tipo de técnicas menos costoso será garantizar la calidad. Por ejemplo, es mucho más barato llevar las pruebas automatizables a un sistema de pruebas automatizadas y focalizar a los testers en las pruebas más complejas, que hacer que todas las pruebas las ejecuten personas. Con este ejemplo ganamos en dos aspectos, lo automatizable siempre resulta más barato y los testers aplicaran sus habilidades allí donde de verdad hay valor que lo haga una persona.

Otras técnicas para construir productos con calidad interna, necesarias para poder tener un ritmo sostenible de construcción iterativa e incremental, para evitar la deuda técnica y construir con escalabilidad y mantenibilidad nos las traen las prácticas de ingeniería de XP (eXtreme Programming):

• Estándares de codificación
• Pair programming
• Peer review
• Arquitecturas flexibles
• TDD (Test Driven Development)
• BDD (Behavior Driven Development)
• ATDD (Acceptance Test Driven Development)
• Refactorización
• Pruebas automatizadas
• Integración continua

Pero lo que realmente hace que construyamos productos excelentes y con gran calidad, es el marco de Scrum en si. Sus ciclos, los sprints, hacen que entre sprint y sprint tengamos inspección y adaptación, lo que quiere decir que tenemos puntos de feedback, puntos de aprendizaje y puntos mejora en cada sprint. La calidad es un resultado natural del marco, no hay que hacer una gestión específica, sólo aplicar correctamente el marco.

Me gusta dar como ejemplo el móvil actual y las prestaciones que da, este es el resultado de un centenar de iteraciones y, si lo pensamos bien el, móvil es un producto más que excelente, es increíble y alucinante. Con el software y Scrum pasa los mismo, a base de iteraciones bien guiadas por negocio llegamos al mejor producto posible en tiempos y costes establecidos.