Las 4 cosas que hay que saber para usar kanban en nuestro proyecto

La gestión visual kanban ayuda a mantener un flujo de avance continuo del trabajo.

Los factores que determinan cómo personalizar las prácticas kanban para las características nuestro proyecto y nuestro equipo son cuatro: Trabajo secuencial o libre, y equipo polivalente o especializado.

Vamos a verlo con más detalle.

La principal carácterística del ciclo estándar de Scrum es el uso de tiempo prefijado (timeboxing) para mantener el avance continuo del trabajo marcando «pulsos» de sprints.

El timeboxing obliga de forma pragmática al mantenimiento de un ritmo de avance, reduciendo la tendencia natural a la dilatación los tiempos de entrega previstos.

Los equipos que desarrollaron Scrum, observados y descritos por Nonaka y Takeuchi (Nonaka & Takeuchi, The New New Product Development Game, 1986) y los principios del manifiesto ágil no prescriben que deba emplearse tiempo prefijado o «timeboxing» para mantener el avance en el incremento continuo del producto.

El equipo puede también sostener un flujo constante de las tareas una tras otra, sin empaquetar en incrementos cerrados para cada pulso de timeboxing (sprint).

Pero mantener un flujo continuo de tareas no es fácil porque suelen formarse zonas de cuellos de botella que taponan el avance, y producen en otras tiempos muertos sin tareas que realizar.

La gestión visual kanban es la técnica más empleada actualmente para regular un flujo continuo de tareas en proyectos TIC y de servicios del conocimiento con gestión evolutiva.

Trabajando con tableros kanban: conceptos

Las prácticas de gestión visual con kanban son útiles para:

Trazar la gestión de un procedimiento y mantener el flujo de ejecución.
Radiar información.

Un tablero kanban puede emplearse con uno de estos fines, o con los dos a la vez, aunque en realidad si se usa para mantener el flujo del trabajo, siempre acompaña el hecho de mostrar la información de avance del trabajo.

1.- Kanban para trazar la Gestión y Mantener el flujo.

Monitorización y regulación del flujo y la carga de trabajo

La posición de cada tarjeta sobre el tablero refleja el estado en el que se encuentra el trabajo correspondiente.
Los estados básicos que se suelen representar en un tablero kanban son “pendiente”, “en curso” y “terminado”.

En algunos casos puede resultar conveniente marcar sub estados (por ejemplo: Testeado, Validado).

El orden de los trabajos desde el área “pendiente”, indica ya en el inicio, la secuencia de las tareas según sus prioridades.

Los trabajos monitorizados puede ser del tamaño de tareas, historias de usuario o epics, según el uso que interese en cada tablero.

Secuencia y polivalencia

Al diseñar la estructura y el funcionamiento de un tablero kanban adecuado a un entorno determinado, dos son las variables de ese entorno a las que debe dar respuesta:

Secuencia (del trabajo).
Polivalencia (de las personas).

Secuencia.

¿Los trabajos reflejados en las tarjetas del tablero tienen que ejecutarse en un orden determinado o pueden realizarse en cualquier orden?

No es lo mismo diseñar un tablero para el equipo de programadores de una aplicación, que para el de mantenimiento de los sistemas informáticos de una empresa. Para los primeros los trabajos se deben completar en un orden de secuencia determinado. Así por ejemplo, no es posible realizar la tarea de pruebas si antes no se ha hecho la de programación.

Sin embargo las siguientes podrían ser las tareas de un equipo de mantenimiento: “instalación de nueva impresora en el equipo de dirección”, “actualización del sistema operativo en el servidor web”, etc. Este tipo de tareas se pueden realizar en cualquier orden. No hay una relación de dependencia entre ellas de forma que no se pueda realizar una si la otra no se ha completado..

Polivalencia

¿Es un equipo polivalente o de especialistas? ¿Por el tipo de trabajo y el perfil de los integrantes del equipo, cualquier miembro puede realizar cualquier tarea?

Siguiendo con los ejemplos anteriores, es posible que en el equipo de mantenimiento la misma persona pueda indistintamente instalar una impresora, o un sistema operativo; o es posible que no: que haya técnicos de hardware y técnicos de software. De forma similar un proyecto de programación puede incluir tareas específicas de diseño gráfico, o programación integración testing, etc que pueden realizar sólo determinados miembros del equipo.

Trabajando con tableros kanban: operativa

Cuatro son los patrones posibles según se combinen tareas secuenciales o libres, con un equipo polivalente o de especialistas:

1.- Equipo polivalente para tareas que no requieren secuenciamiento.

Este es el entorno más fácil de gestionar: cualquier persona del equipo puede realizar cualquier tipo de tarea, y las tareas se pueden tomar en cualquier orden.
Si presenta problemas de saturación de trabajo o tiempos muertos son: la dimensión del equipo y / o la optimización del sistema las áreas que se deben ajustar y mejorar.

2.- Equipo de especialistas para tareas que no requieren secuenciamiento.

El hecho de que los miembros del equipo estén especializados en determinadas tareas aporta un factor de complejidad para solucionar los posibles problemas de cuellos de botella y tiempos muertos.

Si se producen cuellos de botella, la estrategia con el tipo de tareas que los provocan debe encaminarse en una o en ambas de las siguientes líneas:

Dimensionamiento: bien del número de personas capacitadas para realizar ese tipo de tareas, bien en el número de tareas de ese tipo que se pueden comprometer, o en el tiempo de respuesta al cliente.
Optimización del proceso de ejecución de ese tipo de tareas.
La presencia de tiempos muertos debe cuestionar el dimensionamiento, de la demanda o si la distribución no homogénea.

3.- Equipo polivalente y tareas secuenciales

En este caso la dependencia que unas tareas tienen de otras tiende a generar tensiones en el flujo y producir cuellos de botella en puntos determinados de la secuencia.
La primera línea de mejora en estos casos es el ajuste del WIP de cada fase, antes de antes de analizar el dimensionamiento del equipo y el compromiso.

WIP es un término inglés que en el campo de la manufactura lean, de donde proviene, se emplea para designar la cantidad de productos a medio fabricar que aún no están terminados.

En el uso de tableros kanban, por analogía se emplea este término para indicar las tareas que se encuentran en una fase del proyecto pendientes de pasar a la siguiente o de completarse, y en este entorno el término WIP se suele emplear con la acepción de límite o número máximo de tareas que pueden llegar a acumularse en un área determinada. Así por ejemplo, decir que en un tablero kanban para programación de software el área de testing o pruebas “tiene un WIP de 3” quiere decir que no puede haber más de tres tareas simultáneamente en esa fase.

4.- Equipo de especialistas y trabajo que requiere un orden secuenciado.

Este es el entorno más complejo porque requiere el ajuste y revisión en todas las líneas de mejora posible: dimensión y equilibrio de especialistas en el equipo, dimensión o equilibrio de tiempos de respuesta en el compromiso, y ajuste de límites WIP en cada fase.

En cada una de estas cuatro situaciones posibles el tablero saca en la superficie los problemas, y el equipo o gestor puede realizar los ajustes en las líneas de trabajo posibles según cada caso y en función de su criterio y las circunstancias de su organización.

Ejemplos de posibles configuraciones de tableros kanban.

Ejemplo de tablero para ofrecer información relativa al estado de desarrollo del producto.

El ejemplo muestra un posible tablero instalado en la oficina de responsable de producto para reflejar el estado en el que se encuentra la construcción del producto.

En este caso no se emplea la faceta de herramienta para gestinar el mantenimiento del flujo de las tareasl, sino solamente la de “radiador” de información visual.

Tablero para mostrar visualmente la siguiente información relativa al estado de desarrollo del producto:

Posibles historias de usuario sugeridas, que se encuentran en evaluación sin determinar aún si se incorporarán al producto.
Historias de usuario aprobadas: se incorporarán al producto.
Historias de usuario ya valoradas y priorizadas, previstas para ser programadas.
Historias de usuario que se están programando actualmente.
Historias de usuario ya programadas que se pueden evaluar en el servidor de pruebas.
Historias de usuario ya evaluadas, pendientes de desplegar.
Historias de usuario desplegadas en las dos últimas versiones.

Ejemplos de tableros para desarrollo evolutivo, en incremento continuo y en incremento iterativo.

Este es un buen ejemplo del principio de flexibilidad o adecuación de las prácticas a la organización y no al revés. Kanban, además de ofrecer información visual, permite aplicar técnicas como limitación del wip y muestra las líneas de mejora para ajustar la cadencia del flujo. Resulta por tanto útil, como ya hemos visto para trabajar con incremento continuo.

¿Pero puede emplear kanban un equipo que haga scrum con incremento iterativo para emplear la representación visual del avance de las tareas en lugar de usar un gráfico de avance? (por ejemplo)?.

Por supuesto. Este apartado muestra ejemplos de tableros para ambos casos.

Caso 1: Incremento continuo

Las siguientes imágenes representan posibles tableros para guiar la gestión de trabajo de un equipo que está desarrollando un producto en incremento continuo y en el que se refleja la siguiente información:

Pila de tareas.
Tareas ya estimadas y preparadas para entrar a desarrollo.
Tareas en análisis.
Tareas en codificación.
Tareas terminadas.
Tareas integradas en el servidor de desarrollo (labs).
Tareas integradas en producción.

Caso 2: Incremento iterativo.

Tablero configurado para representar y guiar la gestión de trabajo de un equipo que trabaja en incrementos iterativo (sprints) y que muestra:

Pila de tareas.
Tareas ya estimadas y preparadas para entrar en desarrollo.
Tareas en análisis.
Tareas en codificación.
Tareas terminadas.
Tareas integradas en el servidor de desarrollo (labs)
Tareas integradas en producción.

Ejemplo de tableros para un equipo de operación y mantenimiento

Tablero que representa y guía la gestión de un equipo de operación y mantenimiento que refleja:

Estado de las tareas programadas para la semana y persona que está trabajando con cada una.
Estado de incidencias no previstas y urgentes, y personas que están trabajando en cada una