Metodologías

Qué es un tablero Kanban

Un tablero Kanban es un tablero en el cual vamos a tener una serie de tarjetas, cada una de ellas corresponderá a una tarea dentro de un proyecto software, y vamos a tener una serie de posiciones por las que las tarjetas se van a ir moviendo. Esto nos va a permitir, con una gestión muy visual, ver cómo evoluciona el proyecto.

Este sistema fue inventado por el señor Taiichi Ohno, de Toyota.

Scrum vs Kanban

En muchos casos se intenta diferenciar Kanban de lo que es la metodología Scrum en sí, por lo que vamos a ver algunas de las diferencias que existen entre ambas:

1. En Scrum existen los roles de Scrum Master, de Product Owner y del equipo, mientras que Kanban no existen roles.
2. En Scrum se trabaja con iteraciones de tiempo fijo, con unos ciclos fijos que se denominan Sprints, mientras que en Kanban tenemos un trabajo continuo y no tenemos esas interacciones o esos ciclos durante el desarrollo.
3. Scrum limita el WIP (work in process o número de tareas que se pueden tener en paralelo en una de las posiciones del tablero) por iteración, mientras que Kanban limitar ese WIP por el estado del flujo de trabajo.
4. Mientras que Scrum exige equipos multidisciplinares, para que todos los miembros del equipo puedan realizar varias tareas y sea todo más más ágil, en Kanban se permiten los equipos formados por especialistas. En este caso podemos tener algún problema a la hora de gestionar esos equipos, pero existen una serie de normas o de prácticas para llevar a cabo para solucionarlo.
5. En Scrum no se permiten cambiar las tareas del Sprint, es decir, una vez que la tarea asignada al mismo no puede ser movida, en todo caso lo que se permite es modificar la fecha de entrega del Sprint, pero no esa tarea. En Kanban, por el contrario, se puede modificar la tarea hasta que entra en flujo, hasta ese momento podemos modificar la tarea.
6. En Scrum la pila del producto, es decir, el conjunto de tareas que tenemos que realizar durante el Sprint, tiene que tener al menos el tamaño de un Sprint, ya que, lógicamente, no podemos tener menos de un Sprint. En Kanban, al tener un ritmo de trabajo continuo, lo que se hace es ir arrastrando las nuevas tareas por el panel hasta que lleguen a su estado final y finalicen. Cualquier nuevo requisito del cliente será una nueva tarjeta o post-it que se añadirá al flujo de entrada y que seguirá su flujo normal hasta la salida.
7. En Scrum se mide todo lo que sea necesario, se miden historias, es decir, cuánto nos va a llevar realizar cada historia de usuario, se mide cuánto tiempo o esfuerzo nos va a llevar realizar cada una de las tareas y se mide también la velocidad del equipo, que es la cantidad de trabajo que hemos realizado dividido por la cantidad de tiempo. En Kanban, como ya tenemos una cierta habilidad de la metodología, no se miden ni tareas ni velocidad.
8. En Scrum se necesita una pila del producto priorizada, porque como el desarrollo completo lo vamos a dividir en distintos Sprints, la necesitamos para que los primeros Sprints se encarguen de realizar las tareas de mayor prioridad. Con lo que vamos a conseguir llevar valor al cliente de una manera mucho más rápida y las tareas con menor prioridad serán realizando en los Sprints posteriores. Esta priorización la hará el Product Owner. En Kanban la historia o tarea es arrastrada directamente desde el cliente, por lo cual no necesita esa priorización.
9. En Scrum se tienen una serie de reuniones y se utilizan una serie de gráficos, como el burn down, en el que podemos ver el avance del proyecto, y el burn up, que sirve para medir la velocidad del equipo. En Kaban no se considera ni ese tipo de reuniones ni de gráficos.
10. En Scrum los tableros se van a resetear al final de cada Sprint, es decir, conforme vamos finalizando el mismo, el tablero queda vacío y comenzamos de nuevo añadir nueva nuevas historias de usuario, las siguientes en prioridad. En Kanban, como vamos a tener un flujo de entrada-salida, conforme las tarjetas van pasando por cada uno de los estados hasta llegar al estado final, cuando llegan a ese estado salen del tablero y se archivan, vamos a tener un flujo continuo.