viernes, 27 de enero de 2012

Mis primeras experiencias con Kanban: lecciones aprendidas

Hace varios meses comencé a usar Kanban en un proyecto doméstico. Contento con los resultados, decidí intentarlo en la oficina para experimentar en un entorno mas complejo. La cara de duda de algunos que me observaban cortar y garabatear un cartón para prepararlo como pizarra no se hizo esperar... y las dificultades para aplicar Kanban, tampoco.

El principio: motivado por la desmotivación

Trabajar en solitario tiene sus pros y sus contras. Las ventajas seguro que podrían ser enumeradas y disfrutadas por cualquiera pero... ¿cómo aminorar los inconvenientes si no tienes a tu lado a nadie que pueda ayudarte?

En la primavera del 2010 comencé a trabajar en un pequeño proyecto -en mi casa- que se suponía debía terminar en un par de meses; pero por gestionar mal el proyecto y permitir que los requisitos del sistema aumentaran descontroladamente el verano terminó y el proyecto no hacía más que crecer. Llegó el otoño y con la caída de las hojas se me cayeron a mí las ganas de trabajar en el desarrollo: los incentivos iniciales parecían escabullirse y la soledad del cuarto de estudio no ayudaba, así que mi dedicación y motivación estaban en los mínimos.

La gestión de los requisitos del sistema la estaba haciendo con Scrumpy, que es un software para gestionar al estilo Scrum; de modo que tenía una larga lista de historias de usuario sin hacer y unas estadísticas de velocidad y puntos de historias de usuario por sprint que solo podían estimar una entrega aún lejana. En otras palabras tenía justo lo que un desarrollador desmotivado necesita para que desee invertir el tiempo en leer en lugar de programar.

Y fue leyendo que reencontré a Kanban.

Necesitaba algo más visual que una lista ordenada de trabajo pendiente y unas estadísticas negativas. Necesitaba algo que me motivara, que me dijera: "Te falta por hacer esto; pero haz hecho todo esto... ¡Ya falta menos!" Así que al releer los principios de Kanban y la simplicidad del método me decidí a utilizarlo.

Busqué una pizarra, la preparé y coloqué en la columna de to-do un post-it por cada historia de usuario del sprint en curso; tomé una de tamaño S, la pasé a la columna in progress y me puse a programar.

La rápida aglomeración de las historias cortas terminadas en la columna done! fue el combustible que necesitaba para reemprender con ganas el proyecto. Entraba en el estudio desorientado y la pizarra me le ponía claro: "estás trabajando en esto (y solo en esto) que ves en in progress". Levantaba la vista del ordenador y ahí estaba la pizarra de Kanban mostrándome cuánto había hecho y, sobre todo... ¡cuán poco me faltaba!

Definitivamente Kanban me ayudó con aquél proyecto, lo terminé, la pizarra permanece ahí, esperando el siguiente proyecto para organizarme el trabajo y darme el ánimo que necesite. Sin embargo, la experiencia fue demasiado buena para dejarla en casa, así que decidí probar en el trabajo.

Llevando Kanban a la oficina

En el departamento de desarrollo tenemos una pared de cristal que hace la mayoría de las veces de pizarra colectiva pero, debido a su carácter comunitario tuve que improvisarme el tablero con un trozo de cartón. Así que entre risitas y chistes de "una cerveza y una ración de calamares para la mesa 1", monté mi pizarrita con los primeros post-it.

Las primeras impresiones fueron positivas: cada vez que venían a preguntarme cómo estaba de trabajo o en qué estado estaba un proyecto, con un par de explicaciones y una mirada rápida a la pizarra eran suficientes para que se formaran una idea rápida de lo que querían saber.

Mi pizarra Kanban en la oficina


Sin embargo los problemas comenzaron pronto, con la priorización de tareas, pues resulta que en la empresa suelo llevar más de un proyecto a la vez, de modo que el trabajo planificado respondía a 2 niveles de prioridades: prioridad entre proyectos y prioridad entre las tareas de cada proyecto. Esto obligaba a hacer una reorganización engorrosa que rápidamente pasó a ser una división imaginaria de la pizarra con una fila para cada proyecto, lo cual ya deformaba la visión global de la prioridad real de las tareas y cambiaba el alto de las "filas", con su consiguiente reorganización, cada vez que aumentaba una tarea en un proyecto.

El experimento perduró durante unas semanas, hasta que el número de proyectos en paralelo y la necesidad de compartir el tiempo de trabajo entre proyectos terminaron haciendo insostenible el mantenimiento de la pizarra.

De modo que la experiencia de Kanban en la oficina no dio los frutos que esperaba pero me sirvió para algo:
  1. Corroborar que Kanban es una herramienta magnífica para visualizar rápidamente el estado de un proyecto (o una etapa del proyecto).
  2. Concluir que una pizarra Kanban no es útil para llevar más de un proyecto a la vez.

¿Entonces es o no es útil Kanban en el desarrollo de software?

Bueno, la experiencia del proyecto doméstico sugiere que Kamban sí es útil para gestionar el trabajo en un proyecto con tareas estables, bien definidas y con prioridades poco cambiantes; por ejemplo, en un ciclo corto de desarrollo como los sprint de Scrum. Sin embargo, la experiencia en la oficina sugiere que Kanban no es útil si intentamos aplicarlo a varios proyectos a la vez o con tareas muy variables y con prioridades en constante cambio.

Todo esto, claro está, debido al carácter material de una pizarra Kanban física. Si tuviéramos los recursos para dedicar una pizarra electrónica y montar un sistema de e-Kanban, otro gallo cantaría.

Entonces... ¿es útil Kanban? Si, es útil; aunque todo depende de las características del proyecto y el entorno.