Muda, Mura y Muri: algunos consejos para ajustar el flujo

From Scrum Manager BoK
Revision as of 10:35, 26 April 2021 by Smanager (talk | contribs)

Muda, Mura y Muri son tres conceptos claves de la mejora continua Kaizen, que la producción Lean incorpora como variables protagonistas para incrementar la eficiencia.

Muda: Desperdicio Mura: Discrepancia. Variabilidad del flujo de trabajo. Interrupciones en el flujo de trabajo. Tiempo muerto. Muri: Tensión. Sobrecarga de trabajo que produce cuellos de botella.

Mudas

Las mudas o razones de desperdicio más habituales en los proyectos TIC son:

  • Burocracia: Procedimientos, documentación y papeleo innecesario que no aportan valor al resultado.
  • Sobreproducción: Desarrollar más características de las necesarias.
  • Multiproyecto: Alternar el tiempo de trabajo entre varios proyectos e interrupciones del flujo de trabajo.
  • Esperas: Tiempos de espera por falta de cadencia en el flujo de trabajo.
  • “Ir haciendo”: Encargar trabajo para ir avanzando algo no definido y así no tener paradas a las personas.
  • Desajustes de capacidad: Personas de gran talento asignadas a tareas rutinarias, y viceversa.
  • Errores: Retrabajo por bugs.

Los tableros kanban resultan especialmente útiles para detectar y gestionar las otras dos variables kaizen: Mura y Muri.


Factores determinantes de Mura y Muri

Cada organización tiene sus propias características en cuanto a:

  • Secuencia de las tareas.
  • Polivalencia de los miembros del equipo.


Y estos son los factores que en cada caso determinan la dificultad o no para lograr un flujo continuo de desarrollo. Como ya se ha visto, los equipos que trabajan con tareas no secuenciales y en proyectos en los que pueden trabajar de forma polivalente, son los que más fácilmente pueden conseguir un flujo de entrega constante. Cuando surgen las dificultades las variables que se deben combinar, según las posibilidades en cada caso, son:


  • Volumen de demanda.
  • Orden del backlog o pila de historias de usuario: si se va a producir un cuello de botella en una fase, procurar que la próxima historia que va a entrar al tablero requiera poco esfuerzo de esa fase.
  • WIP o límite de tareas en una determinada fase.
  • Staffing: Tamaño del equipo y especialización o polivalencia.


Muri

Analicemos cómo el WIP se convierte en un método para ajustar los cuellos de botella (Muri): Al emplear kanban como técnica con la que regular un incremento continuo desaparece el concepto de sprint. El incremento no es en este caso el resultado de un sprint, sino cada historia de usuario que se termina y entrega. Para lograr un flujo continuo de funcionalidades que, una a una van aportando incrementos de forma sostenida, es necesario evitar la aparición de cuellos de botella (Muri): la acumulación de tareas en una determinada fase del proceso. Una técnica muy útil es limitar la cantidad de trabajo que puede acumularse en las fases y generan cuellos de botella.


Al parámetro que indica el número máximo de tareas en un área del tablero kanban se le denomina WIP: Work In Process, o bien “in-process inventory” (inventario en el proceso). No se debe confundir con Work in progress (trabajo en progreso) término que designa un trabajo que ha comenzado pero aún no está terminado. Un valor “WIP” demasiado bajo puede producir cuellos de botella en otras fases, en especial si el sistema es demasiado rígido (tareas secuenciales y equipo de especialistas).


La experiencia ayuda al equipo a ir ajustándolo para lograr un flujo continuo, o lo más continuo posible. Si no se cuenta con experiencia previa, y considerando que las tareas no deberían tener tamaños mayores de 4 horas ideales, el equipo debe establecer un criterio de inicio, y a partir de él ir ajustando. En este sentido una recomendación general¬mente útil (en equipos de personas polivalentes) es empezar con un WIP igual al nº de miembros del equipo x 1.5, redondeando el resultado por exceso, ó x 2.

No es aconsejable trabajar con tareas de tamaño que se prevea superior a un día de trabajo, y si esto ocurre lo aconsejable es dividirlas en otras de menor tamaño. Ejemplo: La figura siguiente presenta una implementación kanban con límite de trabajo en los estados “Producto analizado” y “En curso”.