¿Cuánta muda transaccional puede ahorrarse en un proyecto desarrollado bajo Scrum?

Uno de las mudas o desperdicios que nos hacen ser menos productivos en nuestro trabajo y que mencionan Tom y Mary Poppendieck en su libro Lean Software Development, es el código o funcionalidad innecesarias o no solicitadas por el cliente.

Situando el foco del desarrollo en aquello que da valor al cliente se aplica un primer filtro al no incluir en la pila de producto funcionalidades que este no solicita, y un segundo filtro al poner funcionalidades con escaso o nulo valor al final de pila de producto. La pila de producto se reconstruye constantemente en función del mercado, y esto provoca que funcionalidades innecesarias siempre permanezcan al final de la pila. Una manera de decidir si vale la pena desarrollar elementos de la pila de producto es aplicar el ROI (Return Of Investment), cuando lleguemos cerca del final de la pila y si el ROI fuera negativo deberíamos de plantearnos si seguimos desarrollando las siguientes funcionalidades.

Para ilustrar la cantidad de desperdicio en funcionalidades he analizado el uso de una aplicación de gestión en cuyo desarrollo participé. El análisis abarca el uso de más de mil quinientas transacciones (páginas) en las que se han producido durante cinco años casi tres millones de clicks de acceso a las mismas.

Si nos fijamos en el siguiente gráfico, en concreto en las páginas que han tenido menos de 50 clicks, podemos ver en el gráfico de tarta de la derecha que ¡casi la mitad de las páginas son puro desperdicio! En el gráfico de tarta de la izquierda vemos que ¡el área que representa su uso casi no se puede distinguir! Tenemos casi un 50% de transacciones innecesarias. Resaltar que estamos hablando de número de transacciones, no de costes, posiblemente el coste represente entre un 10% y un 20% del producto.

Análisis desperdicio en transacciones (páginas)

Entre todo este desperdicio hay todo un sistema gestión de incidencias que nunca se ha llegado a utilizar. La mayoría son páginas de mantenimientos maestros de tablas paramétricas, lo que nos lleva a la conclusión de para tablas que se modifican raramente vale la pena mantenerlas directamente desde SQL/Server u Oracle.

Resaltar que no hay negocio, excepto TI, que acepte un 50% de desperdicio...