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 físico (usualmente puesto en una pared) usando post-it es un excelente medio para ilustrar y aprender la mecánica de trabajo incremental. Además, para un equipo que se inicia en el enfoque ágil es un elemento socializador y entretenido que refuerza la motivación por adquirir nuevos hábitos de trabajo.  En internet abundan ejemplos de tableros kanban físicos. Su utilización en desarrollo de productos industriales transmite quizás demasiado 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 físicos son:
  1. Un tablero físico tiene los problemas obvios asociados a su mantenimiento en una pared y con post-it, especialmente si el volumen de ítems es alto. La granuralidad recomendada para cada ítem debería ser tal que permitiera su implementación en no más de una semana de trabajo, con lo cual en productos de gran envergadura y/o con una alta tasa de cambios es normal enfrentarse a la gestión de cientos de ítems.
  2. Otro inconveniente obvio es que el equipo esté distribuido y/o tenga que desplazarse para estar frente al tablero físico. Aunque el tablero kanban se puede fotografiar o filmar, no es lo mismo verlo presencialmente e interactuar con él.
  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 externos al tablero.
  4. Un encargado de trabajar en 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. Habría que copiarlo o fotografiarlo si tiene información necesaria para trabajar en él. 
  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 recorrer diferentes tableros. Algo similar ocurre trabajando varios equipos sobre el mismo producto (“Scrum de Scrums”), se usarían varios tableros o un tablero con decoraciones para diferenciar los ítems de un equipo.
  6. ¿Qué se hace con los ítems ya terminados?, por defecto se desecharían todos los post-it una vez terminados, con lo cual dicha información no estaría disponible para retrospectivas futuras, estudio de tendencias, o simplemente para conocer cómo se gestionó un determinado cambio del producto.
  7. Cuando se trabaja con Sprints, si bien no es lo más recomendable, podría darse la situación en la cual la finalización de un  Sprint se solapa 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 si no tienen otro trabajo más prioritario podrían empezar a implementar ítems del siguiente Sprint. Esta situación obligaría a tener ítems de más de un Sprint en el tablero, y de ser así habría que poder distinguirlos fácilmente. 
  8. Si las actividades de un ítem son realizadas por diferentes participantes, es útil conocer quién ha trabajado en cada actividad asociada al ítem. En un tablero físico se suelen poner un 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 quienes han trabajado en el ítem y en cuál actividad (columna del tablero). 
  9. El tablero físico 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 deberí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 ciertas 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-requerido-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 ejecutar su implementación (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 del producto (ver Gestión efectiva del Product Backlog). El Backlog está en constante cambio; se añaden ítems, 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 resultado gracias a la experiencia o especialización requerida. En un kanban físico es difícil de representar pre-asignaciones. Normalmente en los kanban físicos solo se indica con un avatar los que están o han participado en un ítem, pero no se suele indicar quienes participarán en cierta actividad (columna) a la cual el ítem aun no ha llegado.
  14. El tablero físico 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 pruebas 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 debería indicarse que tiene un re-trabajo pendiente. Además, habría que evaluar si una vez terminado el re-trabajo en la actividad anterior (a la que se ha devuelto el ítem) debería también 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. 
  15. Similar a la situación de re-trabajo en cuanto a que el ítem podría estar en más de una actividad a la vez es cuando se puede ir adelantando trabajo de cierta actividad (por ejemplo adelantar algo de programación o de diseño de pruebas), 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. El Multi-kanban de TUNE-UP sintetiza múltiples tableros kanbans. En el Multi-kanban de TUNE-UP, gracias a filtros, puede además ofrecer una vista del kanban de cada 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 físico, 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

www.tuneupprocess.com 


No hay comentarios:

Publicar un comentario