viernes, 28 de octubre de 2011

Tableros kanban: ¿por qué recomiendo utilizar una herramienta en lugar de un "tablero kanban manual" y qué funcionalidades debería ofrecer?


Un tablero kanban manual (usualmente puesto en una pared) usando post-it es un excelente medio para ilustrar y aprender la mecánica de trabajo incremental (yo lo utilizo en mis cursos para explicar conceptos de los métodos Scrum y Kanban). Además, para un equipo que se inicia en agilismo es un mecanismo muy socializador y entretenido que refuerza la motivación de la iniciativa de implantación del agilismo.  En internet abundan ejemplos de tableros kanban manuales. Asociado a su utilización en desarrollo de productos industriales se transmite mucho triunfalismo en cuanto a los resultados conseguidos con esta técnica. A continuación expongo mis razones para ser escéptico en cuanto a dicho triunfalismo, llegando a la conclusión que para hacer una eficaz implantación de esta técnica, y particularmente hacerla sostenible (que no decaiga su uso) se debe contar con una herramienta software de apoyo. Los principales inconvenientes que he detectado en los tableros kanban manuales son:
  1. Un tablero manual tiene los problemas obvios asociados a su mantenimiento en una pared y con post-its, especialmente si el volumen de ítems es alto. En la mayoría de los ejemplos se muestran muy pocos ítems en el sprint, lo cual también se asocia a la recomendación de limitar el trabajo en curso (WIP - Work in Process) en cada actividad. Sin embargo, incluso para productos y equipos relativamente pequeños, si en un sprint, además de los nuevos requisitos, se consideran como ítems las correcciones de fallos y todas las pequeñas mejoras, el resultado suele ser varias decenas de ítems. Además, la granuralidad recomendada para cada ítem debería ser tal que permitiera su implementación en no más de una semana de trabajo.
  2. Otro inconveniente obvio es que el equipo esté distribuido y/o tenga que desplazarse para estar frente al tablero físico.
  3. Un post-it ofrece un espacio demasiado limitado para gestionar la información asociada a un ítem. El ítem suele necesitar una breve descripción, bocetos de interfaz de usuario, ideas para pruebas de aceptación, notas, etc. Si el post-it sólo contiene el nombre del ítem y poco más, el resto de información no estará centralizada y disponible para todo el equipo, o lo estará pero en soportes alternativos al propio tablero.
  4. El desarrollador encargado de un ítem no lo debería coger desde el tablero para llevárselo a su puesto de trabajo, ya que el resto del equipo no visualizaría dicho ítem. 
  5. En caso de trabajar con varios productos a la vez, se tendría que mantener un tablero por cada producto (si no se quiere complicar los post-it con más decoraciones adicionales) y los participantes que trabajen en más de un producto a la vez deberían ir a diferentes tableros cuando corresponda. Algo similar ocurre trabajando varios equipos sobre el mismo producto (“Scrum de Scrums”).
  6. ¿Qué se hace con los ítems ya terminados?, por defecto se desecharían todos los post-it una vez terminado el sprint, con lo cual dicha información no estaría disponible para retrospectivas futuras, estudio de tendencias, o simplemente para conocer en qué sprint y cómo se gestionó un determinado cambio del producto.
  7. Cuando se trabaja con Sprints, el hacer coincidir de forma exacta la finalización de un sprint con el comienzo del siguiente (para evitar tiempos no aprovechados por los miembros del equipo) es muy difícil. Normalmente la finalización de un sprint se solapará con el trabajo del siguiente sprint, si bien el foco debería ser terminar el trabajo del sprint actual, dicho trabajo se irá extinguiendo y los miembros del equipo o bien trabajarán en la preparación de ítems para el próximo sprint (sólo si no hay ya suficientes ítems preparados) o bien ya empezarán a implementar el siguiente sprint. Esta situación obligaría a tener ítems de dos sprints en el tablero, uno para la versión actual y otro para la siguiente, o bien, tener al menos dos tableros para cada producto.
  8. Si las actividades de un ítem son realizadas por diferentes participantes, es necesario tener el registro de quién ha trabajado en ítem para poder contactar con él en caso de dudas. Esto en el tablero manual se resuelve poniendo el avatar de quien está trabajando en un ítem. Sin embargo, para saber quien ha trabajado en el ítem deberíamos dejar registrado en el post-it quien ha trabajado en el ítem y en cuál actividad. Además, esto se complica cuando dos o más miembros del equipo trabajan en paralelo en la misma actividad de un ítem (por ejemplo programación en paralelo), pues cada uno de los involucrados debería ver dicho ítem como asignado a él.
  9. El tablero manual no soporta adecuadamente actividades en paralelo o actividades alternativas. Normalmente un tablero sólo representa una secuencia de actividades (columnas) ordenadas de izquierda a derecha en el tablero. Sería complicado en una pared poder reflejar actividades en paralelo o alternativas. Además, en el caso de actividades en paralelo el ítem debería clonarse para fluir por dos caminos en paralelo, y luego los clones debrían fusionarse cuando se llegue a un punto de sincronización (cuando debe terminarse el trabajo en paralelo).
  10. Cada producto, tipo de ítem o incluso cada ítem podría requerir un workflow específico. Un tablero físico no ofrece apoyo adecuado para un tratamiento específico para los ítems, normalmente el tablero kanban representa solo un workflow aplicable a todos los ítems. Tener un solo tablero para diferentes procesamientos (según el tipo de ítem) conllevaría a que ciartas columnas (actividades) no serían aplicables a un determinado ítem, es decir, tendrían que saltarse. Esto podría ser complicado de gestionar y sería fácil cometer errores en el desplazamiento de los ítems en el tablero. 
  11. Las dependencias entre ítems son difíciles de representar en un tablero kanban físico. Se deberían reflejar adecuadamente relaciones tales como: "continua-en"/"es-continuación-de", "requiere-a"/"es-requerida-por", "es-parte-de"/"está-compuesto-por", etc. 
  12. El Backlog de un producto está representado por unas o varias columnas del tablero (ubicadas en su parte izquierda). En estas columnas se realizan las actividades de preparación de un ítem antes de implementarlo (por ejemplo, definición, validación, estimación, etc.) El Backlog de un producto puede contener cientos de ítems. La gestión efectiva del trabajo pendiente y su priorización para ser implementados son la clave para el éxito (ver Gestión efectiva del Product Backlog). El Backlog está en constante cambio; se añaden item, se reordenan, se definen y estiman, se particionan, se agrupan, etc. Todo este trabajo realizado con post-it puede llegar a ser inviable.
  13. Si bien, en general no es una práctica recomendada, si se quisiera organizar el trabajo dando importancia a balancear la carga entre los miembros del equipo, debería existir una forma de representar pre-asignación de responsables a ítems, es decir, que cuando el ítem llegue a cierta actividad que ya se sepa de antemano cuál es la persona que se ocupará de dicha actividad. Esto también obligaría a registrar dichas pre-asignaciones en el ítem. La pre-asignación puntualmente puede ser interesante cuando se prevé en un ítem un cierto desafío en cuanto a alguna actividad, decidiendo de antemano quién(nes) debería(n) encargarse de dichas actividades para garantizar un buen resutado gracias a la esperiencia o especialización requerida. Esto en un kanban manual es difícil de representar. Normalmente en los kanban manuales solo se indica con un avatar los que están participando en un ítem, o a lo más los que están o han participado, pero no se suele indicar quienes participarán en cierta actividad (columna) a la cual el ítem aun no ha llegado.
  14. El tablero manual no responde adecuadamente a situaciones de re-trabajo, es decir, cuando una actividad se debe volver a realizar debido a la detección de un defecto. Una de las situaciones más típicas de re-trabajo es cuando en testeo se detecta un fallo asociado a un defecto de programación o de análisis. En general si el defecto no impide continuar con la actividad actual lo aconsejable sería que el ítem se mantuviera en ella hasta completarla y luego devolver el ítem a la actividad donde deben resolverse los defectos detectados. Cuando el ítem se mantiene en la actividad actual debe indicarse que tiene un re-trabajo pendiente y que el encargado de hacerlo debería, en general, darle prioridad. En cualquiera de los casos, habría que evaluar si una vez terminado el re-trabajo en la actividad anterior también debería hacerse re-trabajo en otras actividades intermedias. En un post-it se pueden poner decoraciones para indicar que el ítem tiene algún defecto por resolver y también para indicar con uno o varios avatares quienes están trabajando en él, sin embargo, todo el registro asociado a los fallos y defectos detectados, o respecto a los datos históricos no suele considerarse. Una situación similar de trabajo en paralelo de varios participantes sobre un ítem es cuando se puede ir adelantando cierta actividad (por ejemplo adelantar algo de programación o de diseño de tests), en este caso el ítem se mantiene en una actividad pero a la vez se está trabajando en otra actividad posterior.
Estos argumentos dejan en evidencia la necesidad de contar con una herramienta software que apoye la gestión del tablero kanban. Sin embargo, el desafío es que dicha herramienta resuelva cada uno de los inconvenientes indicados. Modestias aparte, hasta donde llega nuestro conocimiento sólo TUNE-UP Process (www.tuneupprocess.com) considera todos los aspectos mencionados. La siguiente imagen muestra el Multi-kanban de TUNE-UP. WU es la abreviación de Work Unit (unidad de trabajo) el nombre dado en TUNE-UP a los ítems. El Multi-kanban de TUNE-UP sintetiza múltiples tableros kanbans. El kanban básico es uno en el cual se ven las WUs de todos los agentes participantes en un determinado sprint. En el Multi-kanban de TUNE-UP, gracias a filtros, puede además ofrecer una vista del kanban de cada agente participante, de un producto, del sprint de un producto, del backlog de un producto o una vista de un proyecto. Desde el kanban de TUNE-UP existen diversas formas para acceder a las unidades de trabajo y visualizarlas en otro formulario denominado Gestor de Unidades de Trabajo el cual correspondería a un post-it del kanban de pared, pero siendo un contenedor muchísimo más potente de toda la información relacionada con la unidad de trabajo. Lectura recomendada: Multi-kanban, un tablero kanban para contextos multiproyecto.




Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com



No hay comentarios:

Publicar un comentario