El otro día ya empezamos a traducir el artículo “De Scrum a Lean” publicado aquí: http://net.tutsplus.com/articles/editorials/from-scrum-to-lean/. En él se habla de los principios de Lean y de cómo con esos principios podemos adaptarlos al desarrollo de software, en este caso vamos a comentar los principios del Kanban y cómo aplicar esta técnica al desarrollo software y sobre todo cuando tenemos como base una metodología Scrum y un equipo que congenia bien.

Kanban una gran herramienta

Hay varias técnicas y herramientas para hacer el trabajo de Lean. Prefiero Kanban, una herramienta basada en tableros, similar al tablero de planificación de Scrum. Podemos imaginar kanban como un embudo doble

A la izquierda está la lista de historias que quedan por resolver.  Todas las historias terminadas están a la derecha, el dueño del producto (o el gerente) determina el momento de publicar una nueva versión basándose en esta lista.

En el medio está nuestro proceso Kanban. El producto debe estar en un estado estable y listo para liberarse siempre que terminemos una historia. Esto no significa necesariamente que el producto tenga todas las características completas, el producto puede tener características parcialmente implementadas. Pero la estabilidad, robustez y seguridad del producto deben ser de calidad para producción.

El tablero Kanban

Un tablero Kanban es similar a un tablero Scrum, pero con algunas columnas adicionales con el fin de acomodarnos mejor al proceso Lean.

La primera columna de la izquierda es el backlog completo: todo lo que tenemos que hacer en algún momento. En el extremo derecho, tenemos el otro embudo, contiene todas las historias completadas (no liberadas).

En el medio esta nuestro proceso. Estas columnas pueden variar dependiendo de cada equipo. Por lo general es recomendable tener al menos una columna para las próximas tareas, y otra columna para las tareas en desarrollo. En la imagen podemos ver más columnas con el fin de presentar mejor el proceso de desarrollo.

La columna To-Do contiene las tareas que se deben realizar. Entonces tenemos diseño, donde los desarrolladores trabajan en el diseño de las historias actuales. La cuarta columna es desarrollo, la codificación en sí.  Finalmente, la columna Test donde están las tareas que esperan la revisión de otro compañero del equipo.

Limitar work in progress

Si se compara este tablero Kanban, con el tablero Scrum, se notan a simple vista algunas diferencias. En primer lugar cada columna tiene  un número, que representa el número máximo de tareas abiertas que pueden esta en esta columna. Podemos tener 4 tareas en To-do,  4 en diseño, 3 en desarrollo y 2 en pruebas. Los pedidos y las tareas pendientes no tienen ese límite.

Nadie lo sabe todo

El valor de cada columna está definido por el equipo.

Asignar recursos dinámicamente

Una de las mayores fortalezas de Kanban y Lean es la importancia de la colaboración y el esfuerzo de reasignación. Como puede verse en la imagen,  cada columna de nuestro proceso tiene tarjetas/persona.

Mirando nuestro tablero, hay 3 personan que trabajan en diseño, 2 pares que trabajan en desarrollo y las pruebas las realiza un desarrollador. Las historias pasan a la siguiente columna siempre que se hayan completado. Si un diseñador termina una historia, la historia se mueve hacia desarrollo y el diseñador coge una nueva tarea para seguir trabajando.

Este es el proceso normal,  pero ¿qué pasa si llegamos al máximo de historias por columna? Si un diseñador termina una historia, pero en desarrollo todavía no han terminado tenemos 4 historias en el equipo de desarrollo: una situación no deseada.

Definiendo un proceso “Lean” podemos intentar evitar la congestión.  Por eso hemos definido una serie de reglas. En este caso está prohibido mover una historia a la siguiente columna si se supera el máximo de la columna. En este caso debemos reasignar los recursos. Lo primero que intentará realizar el diseñador es mover coger una nueva historia, pero no puede hacerlo porque tiene que pasar la tarea que acaba de terminar a desarrollo (que esta al máximo de tareas). Su única opción es trabajar en una de las historias de desarrollo. Puede que no sea el mejor desarrollador, pero sus esfuerzos ayudaran a mantener el flujo de proceso.

Si el tester termina la última historia de su columna podría ayudar al desarrollador en su tarea de desarrollo

¡Esto es genial! El equipo puede reorganizarse sobre la marcha ¿hay desperdicio? ¿Existen cuellos de botella? ¡Hay que ir a la acción!

Una vez que una historia en la columna de desarrollo se haya completado, podemos volver a una situación de normalidad (el tester se cambiará de columna para poder probar la nueva tarea desarrollada). Debemos tener en cuenta que esto no es una receta exacta, cada uno puede elegir que hacer en estos casos.

Bienvenido Scrum-ban

Ví con nostalgia como nuestro Scrum Master desmontó nuestro tablero. En ese momento otro colega entró en la habitación con un nuevo y enorme tablero. Nuestro tablero estaba renaciendo en uno nuevo, algo más adaptado a nuestras necesidades. Después de montar el tablero empezamos a discutir sobre cuantas columnas necesitábamos en nuestro proceso, cuantas historias como máximo por columnas,…

Llegados a este punto hicimos algo que mucha gente llama Scrum-ban. Hemos mantenido muchos conceptos de Scrum (scrum master, product owner, estimas historias…), pero ahora nos centramos en Lean y kanban. Preservamos el flujo de trabajo atacando a los cuellos de botella e intentando minimizar los residuos.

El cambio de Scrum a Lean hizo que nuestro equipo se comunicara mucho más, que debemos ofrecer ayuda en el momento en el que estemos con nuestra columna vacía. Ahora pensamos en el proyecto como un todo, nos preocupamos más por el conjunto del proyecto que antes.

Consideraciones finales

Lean no siempre se consideró Agile. Incluso hoy en día muchos agilistas no ven con buenos ojos eso de Lean. Pero lo más importante es que con Lean y Kanban permiten construir una manera de trabajar o “metodología” (llámalo como quieras) que te premitan hacer tu vida más fácil.

Existen muchas herramientas para trabajar con Kanban, en el blog hay algún post sobre esto, aunque puedes echarle un ojo a agileZen.

En esta serie de artículos revisamos Lean y Kanban como una evolución de Scrum. Pero esto no significa que Lean sea mejor que Scrum, depende de los proyectos y sobre todo de las personas. Debemos elegir una metodología con la que nos sintamos cómodos y “funcionemos” bien.