h1

Kanban: de “lean” a ágil

07/06/2011

Wizdoc [Icon By Buuf]  Tips & Tricks.

Kanban es como el lechero. Mamá no le deja un calendario al lechero. Tampoco usa un MRP. Ella simplemente deja las botellas vacías en los escalones del frente [de la casa] y el lechero las rellena. Esto es la esencia del sistema.

— Ernie Smith, facilitador del Foro Empresarial Lean en la Universidad de Tennessee

Kanban es un concepto o mejor práctica salido del Método Justo a Tiempo o Just-in-time. Literalmente, significa pizarrón o tablero (看板) en idioma Japonés y se usa en la industria automotriz para definir las etiquetas que van pegadas a los componentes intermedios antes de ser ensamblados en el producto final. Dicha práctica busca minimizar el tiempo necesario para tener un producto terminado, al ajustar o sincronizar la cantidad de “trabajo en proceso” en las estaciones de trabajo, como puede verse en el siguiente video de YouTube:

Batch and Queue - One Piece Flow

Demostración de un lote de producción vs. un flujo continuo de manufactura, minimizando el tiempo de producción (Hacer click en imagen o aquí para ver el video en YouTube)

Dicho esquema muestra las tres reglas fundamentales de Kanban:

• Visualizar el flujo de trabajo en todo momento. Se debe conocer en todo momento dónde están cada uno de los componentes individuales y en qué fase de la manufactura se encuentran; por ejemplo “por hacer”, “en ejecución” o “terminado”. Aunque en el diagrama esto es bastante explícito, en la vida real muchos gerentes de manufactura no saben en qué parte del proceso se encuentran las tareas y entregables que forman parte del producto terminado.

• Limitar el “trabajo en progreso”. Uno de los aspectos más importantes de Kanban es determinar un “trabajo en progreso” (Work In Progress – WIP) fijo. Esto permite al equipo de trabajo permanecer enfocado en un número limitado de entregables o tareas, permitiendo un flujo de ejecución continuo.

• Administrar el flujo. Llevar a cabo el flujo de trabajo de manera formal, monitoreando, midiendo y reportando el avance continuamente.

Kanban está definido de manera muy general, lo que lo hace muy flexible y fácil de adaptar a una línea de producción. Sin embargo, adaptarlo a un proceso de desarrollo de software puede no parecer tan fácil a primera vista. Empero, es muy fácil visualizar cómo funciona en un ambiente IT si lo comparamos con una metodología ágil de desarrollo de software que se le parece: Scrum.

Jim: ¡Por fin, ya tenemos Scrum implementado!
Fred: ¿Cómo les va?
Jim: Bueno, es mucho mejor que lo que teníamos antes…
Fred: … ¿pero?
Jim: … pero verás, somos un equipo de soporte y mantenimiento.
Fred: ¿Y?
Jim: Bueno, nos encanta todo eso de clasificar las prioridades en un backlog de producto, equipos auto-organizados, Scrums diarios, retrospectivas, etcétera…
Fred: Entonces, ¿cuál es el problema?
Jim: Seguimos fallando en nuestros Sprints.
Fred: ¿Por qué?
Jim: Porque encontramos difícil comprometernos a un plan de dos semanas. Las iteraciones no tienen mucho sentido para nosotros, ya que trabajamos de acuerdo a lo que es más prioritario para ese día. ¿Será que necesitamos iteraciones de una semana?
Fred: ¿Podrían comprometerse a una semana de trabajo? ¿Crees que podrían permitirles enfocarse y trabajar en paz por una semana?
Jim: No en realidad, pues surgen problemas a diario. Tal vez si hiciéramos Sprints de un día…
Fred: ¿Los problemas toman menos de un día para resolver?
Jim: No, algunas veces toman varios días.
Fred: Así que Sprints de un día tampoco funcionarían. ¿Han pensado en deshacerse de los Sprints por completo?
Jim: Francamente, sí nos gustaría. Pero, ¿no va eso en contra de Scrum?
Fred: Scrum es sólo una herramienta. Tú escoges cuándo y cómo usarla. ¡No seas un esclavo de la metodología!
Jim: Entonces, ¿qué deberíamos hacer?
Fred: ¿Haz escuchado hablar de Kanban?

Kanban vs Scrum: a practical guide by Henrik Kniberg. Crisp AB. 2009.

Kanban vs. Scrum

La principal diferencia entre Scrum y Kanban es que Scrum limita el “trabajo en progreso” o WIP por cada iteración o Sprint, mientras Kanban lo limita por fase de ejecución. Es decir, en Scrum se selecciona desde un principio el trabajo a desarrollar durante el presente Sprint, luego se “congela” cualquier cambio en las tareas a realizar por la duración del Sprint y después de dos a cuatro semanas se tiene todo el trabajo terminado, como se muestra en el siguiente diagrama:

Scrum Sprint

Ciertamente, un Sprint utiliza una manera de trabajar muy parecida al proceso por lotes mostrado más arriba (Fuente: outsystems.com)

Por el contrario, en Kanban lo único que se limita es el monto de trabajo a realizar en cada cola o fase de desarrollo (por hacer, en ejecución, terminado). Esto significa que pueden cambiarse las tareas o entregables en cualquier momento y no existe un “Sprint”, permitiendo que el trabajo continúe fluyendo de manera constante:

Kanban Flow

Un flujo Kanban, con un límite de WIP para 3 actividades en las tareas “por hacer” (Todo) y un límite de 2 actividades para las tareas “en ejecución” (Ongoing). (Fuente: outsystems.com)

La posibilidad de cambiar prioridades o agregar y quitar actividades al vuelo permite una mayor flexibilidad que la encontrada en Scrum; pues mientras en aquella metodología es necesario esperar al final del Sprint por resultados, en Kanban es posible determinar día con día el avance de las tareas por realizar. Sin embargo, es necesario tener en mente dos pequeños detalles:

• En Scrum se ha definido el Sprint con la finalidad de permitir a los desarrolladores “trabajar en paz” durante un tiempo determinado, para evitar el overhead o tiempo perdido que resulta cuando hacemos un cambio de tareas (llamado cambio de contexto en multithreading). Es decir, es un hecho que los seres humanos NO somos multitarea: si estamos muy enfocados en realizar la tarea A, al cambiar nuestro contexto para realizar la tarea B requerimos un tiempo para reorganizarnos. Por otro lado, si más tarde tenemos que volver a terminar la tarea A, acabaremos con el famoso “¡Ahh! ¿en donde me quedé?” y nuevamente requeriremos un tiempo para retomar dicha actividad.

• Kanban permite reorganizar las tareas en todo momento, sin embargo es indispensable llevar un buen control de cambios y tener en cuenta que dependiendo de la tarea se darán en mayor o menor medida tiempos perdidos debido al cambio de contexto por parte de los desarrolladores. Este overhead puede ser excesivo en algunos casos – por ejemplo, pasar de programar algunos componentes en Ajax a configurar un servidor LDAP y de regreso puede tomar horas o días para reorganizarse – y en todo caso, dependerá de cada programador sin importar su experiencia o conocimientos.

Considerando estos puntos, Scrum está mejor adaptado para proyectos de desarrollo, mientras Kanban es mucho mejor para mantenimientos o proyectos de sistemas donde con frecuencia se detectan errores o se introducen historias de usuario de forma constante.

Scrum-ban

Finalmente, existe un mashup entre Scrum y Kanban, denominado Scrumban o Scrum-ban. En éste, se sigue el flujo de trabajo continuo como lo define Kanban, pero se incluyen elementos de Scrum como el backlog, las reuniones diarias de 15 minutos y pequeñas retrospectivas con el afán de mejorar el proceso. De acuerdo a algunos autores, es de hecho recomendable utilizar primero Scrumban para introducir a los equipos de desarrollo al mundo de las metodologías ágiles. Esto permite tener un periodo de transición, con el afán de que los desarrolladores y demás stakeholders se sientan cómodos con la nueva metodología. Una interesante muestra de cómo puede llevarse Scrumban se puede ver en el artículo Scrumban multiproyecto y multiperfil, del blog de Carlos Iglesias, socio y consultor tecnológico en Runroom, una pequeña consultoría de desarrollo web en Barcelona, España. Para efectos de completitud, incluyo un pequeño extracto del artículo, donde el autor menciona cómo priorizan las tareas y llevan el seguimiento del Task board:


Scrumban, por definición, se compone de un panel Scrum y un panel Kanban.

En el panel Scrum, metemos las historias priorizadas por el Product Owner (un servidor). Dichas historias se subdividen en tareas y se estiman en puntos de historia en la reunión de planificación de sprint. Además, en nuestro caso, las separamos por colores en función del proyecto, con lo que nos queda un panel ordenado verticalmente por prioridad y horizontalmente por proyecto. Las columnas, como es habitual, trazan el flujo de las tareas.

Scrumban Task board

En el panel Kanban, por contra, entran directamente las tareas sin estimar. ¿Cómo que sin estimar? Pues eso, las tareas de este panel no se estiman al inicio, sino que se cuantifican en horas al final. Eso sí, el Dueño de Producto las prioriza teniendo en cuenta las 3 filas de urgencia:

  • FIRE: Una tarea en esta fila significa “Deja todo lo que estés haciendo y atiende esta tarea!”. A esto le llamamos bala de plata, y está establecida la limitación de que sólo puede haber una a la vez. Una bala de plata es una cosa seria y por tanto en el momento de la retrospectiva se auditará.
  • PRIO: “Tan pronto como acabes lo que estás haciendo, por favor ponte a hacer esta tarea”
  • ASAP: “Deberías hacer esta tarea, pero solo si no se compromete el objetivo del sprint”

Por último, la autoasignación de tareas se ve reflejada con un avatar personalizado… :))

Cabe destacar que en aquella consultoría tienen al mismo tiempo proyectos de desarrollo así como mantenimientos que requieren atender bomberazos.

Conclusiones

En nuestra propia organización usamos Scrum en los proyectos, sin embargo de un tiempo para acá se han venido realizando pruebas piloto con Kanban para tareas de sustaining con nuestra contraparte de la India; posiblemente aquí mismo podamos hacerlo también. Especialmente interesante me pareció la combinación de Kanban y Scrum, pues de esta manera podemos saber quién está haciendo qué en todo momento, sobre todo cuando aparecen bomberazos y alguno de los desarrolladores tiene que entrarle al quite, con el posible impacto en el backlog comprometido.

De momento, estaré empezando mis propias pruebas piloto, viendo qué tanto pega el estar cambiando prioridades tan rápido como lo demanda Kanban. Me he empezado a organizar con la product owner y los desarrolladores para que hagan las cosas de tal forma que si tienen que switchearse sólo necesiten poco tiempo, al mismo tiempo que lo que dejen hecho esté listo (ready to ship) para ser revisado en forma de pruebas beta con el cliente, en lo que vuelven a retomar el proyecto.

2 comentarios

  1. Excelente artículo. Muchas gracias por la mención🙂


  2. […] Por otro lado, si esta re-priorización se vuelve la norma, es aconsejable adoptar un modelo de Scrumban, en el que se acuerda con el PO limitar el monto de trabajo por fase (por hacer, en ejecución, […]



Responder

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. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: