Estimación y medición en Kanban

6 comentarios en “Estimación y medición en Kanban”

  1. Muchas gracias por tu aporte Jesús!
    Si bien la fórmula de TIEMPO= WIP/Tiempo Medio puede ofrecer una idea inicial, el resultado final podría no ser tan bueno en el mediano plazo (trataré de explicar porqué a continuación).
    Si el equipo ha sobrecalculado sus estimados o los procesos son deficientes, entonces el resultado conservará las carencias y las amplificará. La idea es que Kanban mejore la calidad y baje los costes eliminando los retrasos e indicando un WIP, y todo esto se logra formulando las políticas de forma explícitas y visibles. De lo contrario sería como instalar semáforos en una avenida sin primero analizar el tráfico y sus características.

    Esto quiere decir que por ejemplo, si se tiene un valor 5 de WIP en una columna y esto va bien para el desarrollo pero genera una cola para la parte de pruebas u otra área, entonces se debería prestar atención al flujo o equipo y buscar una adecuación al mismo. Esto podría ser por ejemplo “si en general se tienen 6 fichas en una columna pero el máximo es 5, entonces analizar la estructura del equipo, el flujo, ver el problema, buscar una solución, expresarla reglas visibles y rever WIP.”. Por ejemplo, si hay mas de 5 entonces analizar la estructura del equipo, ver que procesos llevan mas tiempo y porqué, y escribir algo que se deberá hacer siempre para poder mover una tarjeta de una columna a otra (ej. si> 5 entonces pedir ayuda a Juan y Pedro que para que ayude con tal cosa).

    El crear reglas explícitas basadas en el movimiento de las tarjetas entre columnas permite que el WIP esté relacionado con ellas y sea de mejora constante y por supuesto ello debería ser discutido con el grupo y no dictado por una jerarquía. Ésta discusión fuerza al mismo a tener una conversación sobre ello así como un crecimiento.
    Representar el flujo es entonces la parte más importante, lo que permite en sí una mejora.

    Una de las formas de transformar Kanban de un tablero a una herramienta que aumente el valor de negocio producido y disminuya el tiempo obsoleto o de espera (cuando se pasa una tarea a otro grupo o persona y ella está ocupada o demora su comienzo) es preguntarse:

    1. ¿Quién o quienes son las personas que trabajan en mejorar el flujo y cómo lo hacen?
    2. ¿Qué tiempo en total gasta la empresa en su totalidad en tiempos de espera?
    3. ¿La eliminación del tiempo de espera entre tareas se ha transformado en un incremento del valor de negocio producido?
    4. ¿Las metodologías actuales de trabajo apoyan la disminución activa de los tiempos de espera o lo contrario?

    La mayor parte de las empresas de software se apuran a instalar un tablero Kanban y definir un WIP, no obstante, al ver las reglas de LEAN, podemos apreciar que establecer WIP se encuentra último. ¿Qué se hay antes (o debería hacer previamente)?

    1. Gestionar la carga de los equipos a nivel global
    Rever si se pueden disminuir los tamaños de las tareas y la especificación de incrementos en el software de forma regular, lo que disminuirá ciertamente las pilas y tiempos de respuesta.

    2. Estructurar los equipos corréctamente.
    Ver como están compuestos los equipos y si se pueden mejorar de acuerdo a la situación actual (que puede ser diferente en unos meses o semanas).

    3. Oden del flujo de trabajo
    Analizar el flujo y ver como mejorarlo (con las posibles reglas explícitas entre columnas).

    4. WIP
    Indicar el WIP

    Seguir estos pasos en éste órden implica un cambio de mentalidad en cuanto a que se deberá asumir que la forma en la que se hacían las cosas anteriormente quizá ya no sea más válidas.

    Muchas gracias por tu aporte y la oportunidad de iniciar esta convesación.

    Me gusta

    1. Hola, lo primero gracias por el comentario. Es genial que aportes otro punto de vista a la cuestión.
      Como dices, es necesario tener a alguien en el equipo que revise el proceso productivo. Por ello es necesario que alguien chequee al equipo para conocer si esta cómodo con el Wip que se ha calculado.
      Hace tiempo realice otro post con la siguiente idea:
      Los equipos scrum deben ser multidisciplinares, aún teniendo a alguien por ejemplo que sea muy bueno maquetando, si hay un atasco en testing y el maquetador esta algo libre debe ayudar en testing. Te dejo el post por si quieres echarle un vistazo:
      https://jesuslc.com/2013/06/07/de-scrum-a-lean-kanban-una-gran-herramienta/

      Así qué resumiendo, la fórmula puede ser válida en un principio, pero si vemos que el equipo no esta cómodo, o el Wip no es fluido debemos comprobar si es el Wip calculado el que hace que el trabajo no vaya fluido.

      Un saludo y gracias por comentarios tan trabajados 😉

      Me gusta

  2. Hola Jesús,
    Interesante post! Sin embargo, tengo una duda existencial cuando dices “Si el proyecto nos va a llevar un año y entregar una tarea (de media) una semana, entonces podemos decir que WIP es 3.”. la pregunta es, como se que el proyecto me va a llevar un año? Digamos, que técnica se utiliza para estimar el tiempo que nos va a llevar el proyecto?
    ]Gracias desde ya,
    Jay

    Me gusta

Comenta la entrada

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .