Kanban o cómo ser flexibles, pero poniendo límites

Seamos cada vez más ágiles

Hace unos días, cuando me surgió la idea de hacer este artículo, y en búsqueda de un soporte en el que basarme, hice una encuesta rápida entre algunos de mis colegas de profesión para que me dijeran si habían participado, de manera activa o pasiva, en un cambio de paradigma de desarrollo de software. De este sondeo ‘express’ saqué dos claras conclusiones, muy relacionadas entre ellas:

1. Existe una tendencia creciente y mayoritaria en la evolución hacia metodologías de desarrollo ágiles.
2. Dentro de la adopción de Agile en muchas organizaciones, hay una clara predisposición hacía la utilización de la metodología SCRUM.

¿Cuáles son las razones que sostienen ambas afirmaciones? Primero de todo, estaría la incuestionable ventaja de adaptación al ‘faster time to market’. Por otro lado, podríamos nombrar el beneficio ‘organizativo’ de tener equipos auto-organizados,  auto-gestionados y muy adaptativos y flexibles. No obstante, fue este último concepto, el de la flexibilidad, el que me llevó a formularme la siguiente pregunta: ¿Cómo casa esto con las limitaciones de cantidad de trabajo que es posible asumir por una organización? Por supuesto que todo dependerá del entorno bajo el que trabajemos, pero una buena respuesta a esta cuestión nos la podría dar la utilización de Kanban.

¿Por qué Kanban?

Kanban es una metodología originada en las factorías japonesas de Toyota, y que en el momento de su nacimiento fue un proceso de los denominados “just in time” para la gestión eficiente de las cadenas de producción. No obstante, con los años ha ido evolucionando, pasando a formar parte de las metodologías de desarrollo de software ágiles.

De todas sus ventajas y características, y tras experimentar con ellas de manera práctica, cabría destacar las siguientes:

1. Limitación de las tareas en ‘Work in progress’ (WIP). O simplemente, no asumamos más lo que realmente podemos. Para QA, este es un factor especialmente crítico, ya que intentar hacer más de lo posible repercutirá directamente en nuestro trabajo por la gran probabilidad de no poder dedicar el tiempo necesario a cada una de las actividades de test. Para solventar este inconveniente, Kanban propone establecer un límite (fijado por el propio equipo ágil) a las tareas que pueden estar en progreso. Esto quiere decir que no podremos pasar más tareas a un estado, si este previamente ha llegado a su límite de capacidad.

Como vemos en la figura, la columna de ‘Test’ ha llegado a su ‘tope’, y a pesar de que hay varias tareas de desarrollo finalizadas (y que por lo tanto pueden continuar su progresión), estas no podrán pasar al siguiente estado debido a que Test no puede asumir más de lo que tiene en ese momento. Esto nos ayudará a invertir el tiempo realmente necesario en cada grupo de pruebas a realizar.

2. Localización de cuellos de botella. Directamente relacionado con el anterior, poner un máximo al número de tareas en cada proceso, nos permite identificar que debemos mejorar, siempre que haya algún estado que llega con frecuencia a su límite de WIP, ya que hará que el resto de grupos no puedan avanzar a la velocidad deseada (e.j: en la figura anterior podría haber un cuello de botella en Test que bloquea los estados de Análisis y Desarrollo). En caso de que el problema esté en test, podremos contemplar alternativas (¿más automatización?, ¿más recursos en test?, ¿priorización diferente?…) que serían más difíciles de ver si no tuviéramos esa limitación tan ‘visible’. Por otro lado, si el cuello de botella no está en test, también podemos sufrir de los efectos colaterales en otros niveles (e.j: defectos o correcciones en user stories que no vuelven a test por limitaciones WIP en estados de desarrollo, al considerar únicamente la generación de nueva funcionalidad y no su correspondiente bugfixing). 

3. La task board de Kanban es ‘persistente’. ¿Qué quiere decir esto? En Kanban, el tablero de tareas puede ser compartido durante varias iteraciones, de manera que tengan un flujo continuado entre ellos y no necesita ser limpiado después de cada sprint. Esto ayudará a una mejor visualización de las tareas de gran tamaño, cosa que puede resultar de ayuda en la elaboración de estrategias de test. 

4. Se pueden añadir tareas en mitad de una iteración. Esto nos lleva a ampliar todavía más la flexibilidad de nuestra organización. Si en métodos clásicos es una quimera cambiar el scope a mitad de camino, en Kanban es posible realizarlo, siempre que tengamos en cuenta las limitaciones de esfuerzo.

¿Quiere decir esto que Kanban es la metodología ágil perfecta y que se adapta a todo tipo de condiciones? Claramente, la respuesta es ‘No’. Las propias restricciones que propone Kanban y que se adaptan como anillo al dedo en algunas organizaciones, pueden resultar inasumibles para muchas otras. Sin embargo, sus características la convierten en una opción más que realista a poner en el ramillete de opciones a valorar.

Referencias

http://kanbantool.com/es/metodologia-kanban

Haz clic para acceder a KanbanVsScrum_Castellano_FINAL-printed.pdf

https://technology.med.virginia.edu/project-management/how-we-do-it/kanban/

SOGETI cuenta con metodologías propias de testing, descúbrelas en la web.

Isaac Álvarez Diz

Test Manager en SOGETI España