Kanban

Kanban es un método de organización  visual en el que las tareas a realizar se muestran en un tablero también llamado Kanban 

Podemos decir que no es un framework ni una metodología ágil para el desarrollo de software, pero cada vez es más común que se utilice para esto. Surgio en una metodología llamada Lean  creada  para mejorar la producción usando técnicas just-in-time (JIT).

Uno de los principios de Kanban es "empieza con lo que tengas" pero para poner en marcha Kanban hay que seguir unas reglas minimas, son las siguientes:

1. Visualizar el flujo de trabajo: Todos los miembros del equipo deben tener a la vista el trabajo que se está desarrollando, para ello se utilizan los tableros Kanban, formados por columnas que serán las fases por las que van a ir pasando las tareas (que son las funcionalidades y características que debe tener el proyecto) que se representan mediante tarjetas o post-its colocados en el tablero.
2. Limitar el trabajo en proceso (WIP): Es decir, fijar un número máximo de tareas que pueden estar a la vez en cada fase del tablero Kanban. Lo que se consigue limitando este WIP es que los miembros del equipo no abran demasiadas tareas y pasen demasiado tiempo en el estado de “DOING” consiguiendo que se centren en finalizar tareas lo antes posible ya que en Kanban no se limita el tiempo de trabajo en iteraciones o sprints como en otras metodologías. Además, gracias a limitar el WIP podemos detectar rápidamente los problemas en el desarrollo y evitar cuellos de botella. Pero ¿cómo comenzamos a limitar el WIP? Kanban sólo nos indica que tenemos que limitarlo, pero no nos indica ese límite ya que cada organización debe buscar el límite con el que mejor trabajen y consigan ser más eficaces.Existe el riesgo elegir un WIP demasiado bajo, esto tiene unos pros y unos contras, por ejemplo, las tareas se realizarán más rápido ya que un mayor número de miembros trabajan en pocas tareas, por tanto, el equipo será más colaborativo y comunicativo, y cuando aparezca un problema se resolverá cuanto antes ya que sino no podrán continuar con su trabajo. Una contra puede ser que haya miembros del equipo que estén de más sin tareas que realizar mucho tiempo.Si ponemos un WIP alto corremos el riesgo de tener muchas tareas empezadas y no acabar ninguna a corto plazo por tanto el “Cycle time” como veremos a continuación será elevado.Normalmente los equipos nuevos siguen esta regla para elegir el WIP para comenzar: 2*(número de miembros del equipo)-1, lo que se consigue restando 1 es que haya una colaboración entre los miembros del equipo
3.   Medir el Lead Time: Medir el tiempo que tarda en completarse una tarea. Como ya hemos visto en Kanban no es necesario tener iteraciones o sprints para terminar las tareas, pero tenemos que medir los tiempos que tardan en      realizarse las tareas, para ello utilizamos estas métricas, suelen medirse en días de trabajo.:

• Lead Time: Es el tiempo desde que se define una tarea hasta que se termina su realización y se entrega. Se puede decir que es lo que esperan los clientes y ven cuando se finaliza.
• Cycle Time: El tiempo desde que se comienza a desarrollar una tarea hasta que está completa. Con el Cycle Time me mediremos el rendimiento de trabajo del equipo.

Kanban no limita el tiempo ni en sprint ni iteraciones, pero es importante que se midan los ciclos de trabajo para tener un seguimiento del proyecto. Al no tener sprints ni iteraciones no tenemos que limpiar el tablero cuando estos acaben y además los cambios en Kanban se pueden introducir en cualquier momento, siempre y cuando la columna de “Doing” o “en proceso” tenga capacidad para una nueva tarea.

Las tareas que componen un proyecto estarán colocadas en la columna más a la izquierda del tablero, normalmente llamada “pendiente” o “to do”, no existe ninguna pila de producto o Product Backlog. Estas tareas no tienen por qué ser priorizadas ni ordenadas, se deja a elección del equipo la manera de escoger cuales se realizarán primero, lo que si se recomienda es que todos los miembros del equipo acuerden un orden, como, por ejemplo: la primera de la columna, la más antigua…

Kanban a diferencia de otras metodologías o métodos especifica roles a los miembros de su equipo, da la libertad, para que si lo consideras oportuno se puedan asignar, pero no es obligatorio, tampoco es necesario que los equipos sean multifuncionales, pueden ser especializados ya que los tableros no se asignan a un equipo si no a un flujo de trabajo, por tanto, varios equipos o personas pueden compartir un mismo tablero Kanban.

Muchos de los equipos Kanban con el paso del tiempo han ido poniendo en práctica la utilización de unos roles para facilitar su trabajo, estos roles comúnmente son:

• Gestor de peticiones de servicio (Service Request Manager): en algunas metodologías o métodos es conocido como Product Owner, es el encargado de estar en contacto con el cliente y conocer y entender todas las características y funcionalidades del producto a desarrollar.

Como el Product Owner también puede tener la responsabilidad de crear las tareas y ordenarlas para su realización.

• El Gestor de Prestación de Servicio (Service Delivery Manager): Este rol existe si se decide realizar reuniones en nuestra organización, será el encargado de facilitarlas y de entregar el resultado de la realización de las tareas al cliente.

Lo mismo ocurre con las reuniones muy importantes en otros métodos de organización y metodologías pero que en Kanban no es imprescindible que se realicen, con la práctica, muchas organizaciones acaban adoptando una serie de reuniones que los aporten feedback e información del avance del proyecto, como pueden ser reuniones diarias de seguimiento de avance del proyecto (Daily Kanban), reuniones semanales para organizar el trabajo semanal (Replenishment Meeting),reuniones después de la entrega del software a los clientes para analizar los problemas surgidos y encontrar mejoras (Service Delivery Meeting) entre otras.

Un buen libro para aprender las características de Kanban si ya conoces Scrum es “Scrum vs Kanban” de Herriqk Kniberg y Mattias Skarin, en este libro se realiza una buena comparación de estos dos métodos de trabajo, muy rápida de leer y con un lenguaje sencillo de comprender, además una vez explicadas las diferencias se centra en contar la experiencia de los autores utilizando Kanban durante un tiempo donde podemos ver cómo iban introduciendo cambios para ajustarse a las necesidades de su equipo y así tener éxito.

Otro libro recomendable para adquirir conocimientos sobre Kanban es el libro “Kanban Essencial condensado” escrito por David J Anderson y Andy Carmichael, este centrado en Kanban donde tenemos los principios y las prácticas comunes que se introducen en Kanban.