Un tablero kanban físico (usualmente puesto en una pared) usando pósits 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. NOTA: me referiré a Unidad de Trabajo (UT) como equivalente a Historia de Usuario, Ítem o pósit en el tablero kanban. Usar el término UT me parece más genérico para referirnos a trabajo sin importar el ámbito del que se trate.
En mi opinión, los principales inconvenientes o situaciones difíciles de gestionar en un tablero kanban físico son:
En Worki, desde estas dos vistas de tableros kanban existen diversas formas para acceder a las UT y visualizarlas en otro formulario denominado Gestor de UT, el cual correspondería a un pósit del tablero kanban físico, pero que obviamente es un contenedor muchísimo más potente de toda la información relacionada con la UT. Lectura recomendada: Multikanban, un tablero kanban para contextos multiproyecto.
Patricio Letelier
www.tuneupprocess.com
- Un tablero físico tiene los problemas obvios asociados a su mantenimiento en una pared y con pósits, especialmente si la cantidad de UT es alta. Mi recomendación respecto de la granuralidad de cada UT es que permita su implementación en no más de una semana de trabajo, con lo cual en contextos con gran volumen de trabajo y con una alta tasa de cambios sería normal enfrentarse a la gestión de cientos de UT, caso en el cual necesitaríamos una pared muy grande para instalar el tablero kanban :-), sería difícil la gestión de tantos pósits y además, la manipulación de la posición de los pósits estaría propensa a errores.
- 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, no es lo mismo verlo presencialmente e interactuar con él.
- Un pósit ofrece un espacio demasiado limitado para gestionar la información asociada a una UT. Una UT suele necesitar una breve descripción, bocetos de interfaz de usuario, ideas para pruebas de aceptación, notas, etc. Si el pósit sólo contiene el nombre de la UT y poco más, el resto de información no estará centralizada y disponible para todo el equipo, o podría estar pero en soportes externos al tablero.
- Un encargado de trabajar en una UT no la debería coger desde el tablero para llevársela a su puesto de trabajo, ya que el resto del equipo no visualizaría dicha UT. Habría que copiarla o fotografiarla para tener la información necesaria para trabajar en ella "lejos" del tablero.
- En caso se trabaje con UT que difieren significativamente en su procesamiento lo recomendable sería tener diferentes tableros. Así, cada tablero tendría las columnas que requieran las UT que se incluyan en el tablero.
- Cuando el número de UT en un tablero es alto, probablemente se querrá identificar o distinguir cuáles UT tienen una determinada característica, por ejemplo, persona que la solicitó, tipo de la UT, las que son urgentes, las más antiguas/recientes, etc. En un tablero físico se podrían añadir decoraciones a los pósit para diferenciarlos, sin embargo esto es muy rudimentario si lo comparamos con un mecanismo de filtrado y búsqueda que se ofreciera en un software para gestionar el tablero kanban.
- ¿Qué se hace con las UT ya terminados?, por defecto se desecharían todos los pósits 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ó una determinada UT.
- Cuando se trabaja con Sprints, 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 trabajar en UT del siguiente Sprint. Esta situación obligaría a gestionar UT de más de un Sprint en el tablero, y si esto ocurre convendría distinguirlas. Nuevamente, esto podría ser mucho mejor gestionado en una herramienta-software.
- Si las actividades (columnas del tablero) por las que pasa una UT son realizadas por diferentes colaboradores, es útil conocer quién ha trabajado en cada actividad asociada a al UT. En un tablero físico se suele adjuntar en el pósit un avatar representando quién está trabajando en una UT. Sin embargo, para saber quién ha trabajado en la unidad de trabajo deberíamos dejar registrado en el pósit quiénes han trabajado en él y en cuál actividad.
- El tablero físico no soporta adecuadamente actividades en paralelo o actividades alternativas. Si bien el tablero corresponde a un workflow, solo representa una secuencia de actividades (columnas) ordenadas de izquierda a derecha. Sería complicado en una pared poder reflejar actividades en paralelo o alternativas. Además, en el caso de actividades en paralelo la UT 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).
- Cada tipo de UT o incluso cada UT en particular 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 UT) conllevaría a que ciertas columnas (actividades) no serían aplicables a algunas UT, es decir, tendrían que saltarse algunas columnas. Esto podría ser complicado de gestionar y sería propenso a errores en el desplazamiento de las UT en el tablero.
- 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", etc.
- El Backlog (Product Backlog) 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 una UT (por ejemplo: definición, validación, estimación, etc.), es decir, las actividades que establecen qué debe obtenerse como resultado al terminar la UT. Correspondientemente, hacia la derecha del tablero habrá columnas de "Ejecución" del trabajo, es decir, aquellas a realizar y probar que efectivamente se ha hecho lo solicitado. El Backlog puede contener cientos de UT. La gestión efectiva del trabajo pendiente y su priorización son clave para el éxito del trabajo (ver Gestión efectiva del Product Backlog). El Backlog está en constante cambio; se añaden UT, se reordenan, se dividen, se agrupan, se eliminan, etc. Todo este trabajo realizado con pósits puede llegar a ser inviable.
- Si bien no es una práctica ágil 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 en las actividades de cada UT, es decir, que cuando la UT 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 preasignaciones en la UT. La preasignación puntualmente puede ser interesante cuando se prevé en una UT tiene 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 tablero kanban físico es difícil de representar preasignaciones. Normalmente en los tableros kanban físicos solo se indica con un avatar los que están o han participado en una UT, pero no se suele indicar quienes participarán en cierta actividad (columna) a la cual la UT aun no ha llegado.
- El tablero físico no responde adecuadamente a situaciones de retrabajo, 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 retrabajo es cuando en pruebas se detecta un fallo asociado a un defecto arrastrado desde una actividad previa (por ejemplo un fallo de programación detectado en pruebas). En general, si el defecto no impide continuar con la actividad actual lo aconsejable sería que la UT se mantuviera en ella hasta completarla y luego devolver la UT a la actividad donde deben corregirse los fallos o defectos detectados. Cuando la UT se mantiene en la actividad actual debería indicarse que tiene un retrabajo pendiente. Además, habría que evaluar si una vez terminado el retrabajo en la actividad anterior (a la que se ha devuelto la UT) debería o no hacerse retrabajo en otras actividades intermedias. En un pósit se pueden poner decoraciones para indicar que la UT tiene algún defecto por resolver y también para indicar con uno o varios avatares quienes están trabajando en ella, sin embargo, la información asociada a los fallos o defectos detectados no suele registrarse.
- Similar a la situación de retrabajo, en cuanto a que la UT 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 pruebas de la UT aunque su programación aún no está totalmente finalizada), en este caso la UT 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 Worki, la herramienta de apoyo a nuestra metodología ágil TUNE-UP Process (www.tuneupprocess.com), considera todos los aspectos mencionados. La siguiente imagen muestra la vista "Tablero multikanban" de Worki. El "Tablero multikanban" de Worki sintetiza múltiples tableros kanbans. Gracias a filtros, se puede ofrece una vista del kanban de cada participante, de una Línea de Trabajo, de un Sprint de un Proyecto, o del del Backlog.
De forma alternativa se ofrece la vista "Tablero unikanban", es decir, una visualización de un tablero a la vez, con sus columnas específicas, y nuevamente con funcionalidades de filtrado y acceso a las UT. En la siguiente figura se muestra un ejemplo de la vista "Tablero unikanban", con la misma información de la figura anterior, pero esta vez restringida además a un tablero específico (el seleccionado en el desplegable "Workflow").
Patricio Letelier
Estoy de acuerdo. Tienes razón. También prefiero utilizar una herramienta en lugar de un "tablero kanban manual". Recuerdo que una mañana, antes de un día difícil en la empresa, escribí en un papel todas las tareas, todos los detalles, hice un horario con lo que tenía que hacer y a qué hora. Cuando llegué a la empresa resultó que me había dejado la lista en casa. No había tiempo para volver a por ella. Desde ese día sólo utilizo la aplicación Kanban Tool. ¿Por qué? Porque puedo accederla desde cualquier dispositivo: teléfono, portátil, ordenador del trabajo.
ResponderEliminar