Desarrollo ágil de software: Scrum o Kanban?

kanban board

Más de una vez nos hemos encontrado con la disyuntiva de decidir qué metodología de desarrollo ágil utilizar. Scrum suele ser la primera opción actualmente, pero también aparece Kanban como otra opción viable. En este post intentaré dejar un poco más claros los conceptos que son abarcados con Kanban, remarcando las diferencias existentes con Scrum.

Qué es Kanban?

Kanban está basado en la simple idea de que el Trabajo en Progreso (W.I.P. Work In Progress) debe ser limitado, y que algo nuevo solo debería empezarse recién cuando una pieza existente de trabajo es entregada o finalizada. El Kanban implica una señal visual de que un nuevo fragmento de trabajo puede ser comenzado debido a que la cantidad de trabajo en progreso está por debajo del límite acordado.

Si bien este artículo no intenta dar una definición de la metodología, podemos decir que Kanban es una herramienta que nos sirve para ordenar la forma en la que trabajamos, que sin dudas irá mejor para algunos escenarios, y peor para otros.

Esta basada en 3 Principios:

  • Visualizar el flujo de trabajo:
    • Dividir el trabajo en partes, escribir cada una de esas partes (subtareas) en una tarjeta e introducirla en el tablero Kanban
    • Usar nombres en cada columna del tablero para denotar el estado de cada ítem de trabajo
  • Limitar la cantidad de Trabajo en Progreso: hacer explícito en el tablero el límite acordado.
  • Medir el Tiempo de Ciclo: intentar optimizar el proceso para achicar el ciclo.

El Tablero Kanban

Kanban promueve que la organización del trabajo sea visible todo el tiempo, lo que da origen al tablero Kanban. El tablero puede ser una pared acondicionada para esto, un pizarrón, o un tablero digital online accesible por los miembros del equipo. Existen numerosas aplicaciones que brindan este soporte, por ejemplo:

Trello

Kanbanize

Lo importante es que el flujo de trabajo sea visible todo el tiempo, ya sea online o físicamente. Y también es importante adaptar el tablero al flujo de trabajo que reine en el ambiente donde se va a utilizar Kanban. Frecuentemente, el tablero Kanban cuenta con las siguientes columnas:

– Backlog: un conjunto priorizado de tareas a hacer por el equipo. Quién prioriza las tareas? El product owner, el jefe del departamento, el miembro del equipo que conozca más a fondo el dominio, etc. Kanban no impone un rol para esto.

– In Progress: con las tareas actualmente siendo trabajadas.

– Done: los ítems que fueron terminados.

– Etcétera: el tablero Kanban puede contar con más columnas, dependiendo del flujo de trabajo en particular. Por ejemplo, si la validación del código es realizada por una porción del equipo, puede haber otra columna llamada «In Review / QA».

Limitar el Trabajo en Progreso

El límite del trabajo en progreso es uno de los principales aspectos de Kanban, a la hora de producir cambios en los tiempos de respuesta. Como muchas metodologías ágiles, la mejor manera de encontrar el límite óptimo es experimentar con uno, medir los resultados, y cambiarlo si es necesario.

El tiempo de ciclo (o Lead time) es el tiempo que demora un ítem desde que ingresa al tablero kanban, por ejemplo, a la columna de «Backlog», hasta que se da por finalizado. El objetivo es minimizar este tiempo, que es el tiempo que demora el equipo en responder y solucionar un determinado ítem de trabajo. El límite del trabajo en progreso ayuda en este tiempo al limitar la cantidad de ítems que pueden estar en progreso. Por ejemplo, con un límite de 2, supongamos que hay un ítem en progreso y el equipo queda bloqueado por alguna razón. Entonces el equipo comienza a trabajar en otro ítem. Este nuevo ítem les lleva dos días para terminarlo. Estos dos días también se ven reflejado en el tiempo de ciclo del ítem 1, que sigue bloqueado. Entonces, si el límite hubiese sido de 1, el equipo podría haber detectado el bloqueo y haber trabajado en ello para poder reducir el tiempo de respuesta para este ítem.

Generalmente la manera más efectiva de mejorar el tiempo de respuesta es hacer que el flujo de trabajo sea más suave, ajustando el trabajo a la capacidad, en vez de agregar capacidad (es decir, agregar gente). Cabe destacar lo siguiente:

  • un límite muy bajo lleva a que haya gente desocupada, por ende hay baja productividad.
  • un límite muy alto lleva a que haya tareas en espera, por ende aumenta el tiempo de respuesta total, lo que lleva a que el equipo demore más tiempo en terminar las tareas.

Scrum es más prescriptiva que Kanban

Scrum, si bien es una metodología ágil, tiene más reglas para seguir que Kanban.

Scrum prescribe roles (Dueño del producto, Equipo y Scrum Master). Kanban no tiene roles prescriptos. Esto no significa que no se puedan especificar roles.

Scrum prescribe iteraciones de tiempo fijo, pero Kanban no. En Kanban uno decide cuando hacer planning, retrospectives, etc.

Ambas prescriben el Trabajo en Progreso (o W.I.P. en inglés – Work In Progress)

Este es un punto en común para ambas metodologías, la diferencia radica en el cómo es limitado el trabajo.

En Scrum, el trabajo en progreso se limita por la iteración (Sprint). El equipo Scrum es libre de comenzar con todas las tareas al mismo tiempo, pero no se pueden agregar historias de usuario a las iteraciones, una vez que ya comenzaron.

En Kanban, es común limitar el WIP mediante un número en la columna correspondiente al trabajo en progreso. Esto prohibe al equipo introducir en esta columna más items que lo que indica el límite.

Ambas metodologías son empíricas

No existe una mejor guía para obtener los mejores valores de los distintos parámetros que permiten adaptar las dos metodologías. Es necesario comenzar con valores realistas, e ir aprendiendo con el paso del tiempo.

Las mediciones en este sentido son cruciales, ya que nos brindarán una herramienta de comparación muy importante para tomar la mejor decisión. Además, el hecho de contar con mediciones permite muchas veces identificar cuellos de botella en el proceso, permitiéndonos actuar sobre ellos para mitigarlos.

Conclusiones

Lo que debe quedar claro es que Kanban es una metodología que, al igual que Scrum, priorizan la respuesta al cambio por encima del seguimiento de un plan.

Para algunos escenarios puede resultar menos atractiva que otros. En esta metodología no se prescribe el concepto de «Sprint», por ende el equipo de desarrollo esta más propenso a cambios en alcance o prioridades, lo que puede no ser bueno en ciertos casos (Scrum prohíbe al Dueño del Producto que modifique las historias que se incluyeron en el sprint).

En general Kanban se adapta mejor cuando hay un flujo contínuo de trabajo. Por ejemplo, para el mantenimiento de un sistema, donde van entrando tickets con defectos u otras solicitudes. Esto permite ordenar esos tickets de acuerdo a distintas prioridades para poder solucionarlos y evitar cuellos de botella.

Kanban es una herramienta muy potente a la hora de negociar. Por ejemplo, si un cliente envía numerosos tickets y el equipo no puede resolverlos rápidamente, se puede mostrar el tablero Kanban al cliente, para que éste vea la carga de trabajo existente, y así nos ayude a priorizar los ítems.

En mi experiencia es una metodología válida y efectiva, no solo para el desarrollo de software, sino para la gestión de todo tipo de tareas.

Tags

Access top talent now!

Related

Get in Touch