Kanban for Free. Una evaluación informal de 5 herramientas totalmente gratuitas

El propósito de este post es compartir el resultado de lo que fue mi búsqueda de una herramienta para dar soporte a un tablero Kanban. Me impuse la condición que se tratara de herramientas totalmente gratuitas (sin restricciones de tiempo, colaboradores, tableros, etc.) y que ofrecieran acceso en su servidor, es decir, que no requieran instalación en un servidor propio. Aclaro que no se trata de una evaluación formal.

NOTA: este post es de 2012, como es lógico las herramientas pueden haber evolucionado pero lo  comentado aquí debería seguir siendo válido. En caso contrario hacédmelo saber :).

Ya he abordado en otro post los desafíos que presenta un tablero físico (o software) para implantar un sistema  que combine Scrum + Kanban. Sin embargo, desde el punto de vista de formación e incluso para comenzar con el enfoque ágil reconozco que un sistema Kanban puro o mezclado con Scrum puede ser un buen primer paso. Estos fueron precisamente mis motivos, encontrar una herramienta muy sencilla para explicar Kanban mediante una actividad docente, y además, aplicar Kanban en un equipo que comenzaba a introducir prácticas ágiles.

Las herramientas que encontré que cumplían las restricciones señaladas fueron:

• Kanbanpad, parece haber desaparecido :-(
• Kanbanize, http://kanbanize.com
• KanbanFlow, https://kanbanflow.com
• YouKan, parece haber desaparecido :-(
• Trello,  https://trello.com/

Kanbanpad, https://www.kanbanpad.com

• Aunque no tiene subcolumnas configurables, por defecto divide cada columna en dos lo cual puede usarse para TO DO y DOING o para DOING y DONE, lo cual es suficiente.
• Ofrece muy pocos atributos para los ítems. No tiene tareas, ni histórico, ni campos para estimación o esfuerzo invertido
• Las notificaciones no son muy configurables, y no pueden desactivarse del todo.
• Ofrece una visualización completa del tablero.
• Interfaz amigable. Con sólo arrastrar un color o un colaborador sobre el ítem, éste cambia dicho valor. Creación directa de un ítem con sólo introducir su nombre.

Kanbanize, http://kanbanize.com

• Ofrece el conjunto más interesante de atributos para el ítem. Subtareas con agentes asignados, Histórico, Prioridad, Tamaño, etc.
• Buena gestión de subcolumnas, con lo cual bajo una columna de actividad puede fácilmente ponerse un par de columnas TO DO y DOING, o DOING y DONE. Sin embargo, no permite cambiar las tres columnas que vienen por defecto (Request, In Progress y Done)
• Cuando el número de columnas aumenta el tablero no se visualiza completo, no se redimensiona.

KanbanFlow, https://kanbanflow.com

• Buena visualización completa del tablero.
• Interfaz de usuario muy amigable. Creación muy sencilla y rápida de ítems.
• Tiene subtareas pero no se puede asignar colaborador responsable a ellas.
• Pocos atributos asociados al ítem.

YouKan, http://www.youkan.eu

 

• Sólo YouKan incorpora el concepto de Sprint, es decir, un Proyecto/Producto con varios tableros (uno para cada Sprint) con un Product Backlog común desde el cual pueden cogerse ítems y pasarlos a un Sprint.
• La interfaz de usuario es muy amigable. 
• El principal inconveniente es que en YouKan se hace un tratamiento diferenciado para él ítem del Product Backlog (Story) y para el trabajo asociado a él durante el Sprint en el cual se implementa. Dicho trabajo debe descomponerse en otros ítems llamados (Tasks). Así, sólo estas Tasks pueden moverse entre columnas (no así la Story). Esto obliga a que en la práctica las tareas se refieran a:

1. Actividades de desarrollo (tales como programación, integración, testeo) y las columnas simplemente sean DOING y DONE.
2. Partes funcionales de la Story, es decir, que la Story se descomponga funcionalmente y que las columnas correspondan (como suele ser) con actividades de desarrollo.
3. Elementos de la arquitectura del producto que deben crearse o modificarse según la Story, es decir, que la Story se descomponga en dichos elementos y que las columnas correspondan (como suele ser) con actividades de desarrollo.

• Otro inconveniente es que tiene una fila obligatoria y única para los Bugs. Es decir, aunque el bug esté asociado con el trabajo de una Story (o sea el Bug en sí mismo la Story), no queda asociado a la Story sino que se trata aparte en dicha fila (que por cierto compartiría las columnas del Sprint).
• Finalmente, no contempla la asignación de responsables a cada Task o Story.

Trello, https://trello.com/

• Interfaz de usuario muy amigable. Muy sencilla gestión de columnas e ítems.
• No tiene subtareas pero incluye checklist muy fáciles de manejar.
• Facilidades para asociar ficheros al ítem

Conclusiones

Salvo YouKan, en la cual se imponen ciertas restricciones asociadas a los ítems, las otras tres herramientas podrían soportar sin mayor problema un sistema Kanban esencial. Sin embargo, mi interés se centraban en el desarrollo iterativo e incremental de un producto software, lo cual requería a priori funcionalidad más allá de dicho Kanban esencial.

Si bien ninguna de las herramientas probadas me dejó satisfecho en todos los aspectos, mi elección final está entre KanbanFlow y Trello. Ninguna de las dos tiene el concepto de Sprint, con lo cual debería  mantener en un mismo tablero todos los Sprints, el Backlog sería una columna y en DONE se irían acumulando los ítems finalizados del Sprint actual y de todos los Sprints terminados. Como no hay forma de pasar ítems de un tablero a otro no sería convendría tener el Backlog y cada Sprint en un tablero separado.

Esta breve evaluación me ha confirmado que existe una interpretación muy variada de los conceptos de Kanban. En todas las herramientas vistas lo que se ofrece es una mezcla de funcionalidades que va más allá del método Kanban puro (lo cual es razonable por las necesidades que podrían requerirse al aplicar la herramienta), pero que no hacen obvio el uso y configuración de la herramienta. 

La desilusión me la he llevado con YouKan pues es en mi opinión la que ofrece la interfaz más amigable, además de ser la única que da soporte al concepto de Sprint. Kanbanpad también es muy intuitiva y fácil de usar pero en comparación con KanbanFlow, tiene muy pocos atributos asociados a un ítem. Kanbanize puede que sea la más completa de las cuatro herramientas en cuanto a funcionalidad, sin embargo, su interfaz no es la más amigable, particularmente porque por defecto no se visualiza todo el tablero.

Sólo Kanbanize y YouKan ofrecen funcionalidad para seguimiento mediante Gráficas Burndown, dado que mi interés en este caso era sólo la visualización de los ítems, no puse atención en dichas funcionalidades.

Sólo Kanbanpad ofrece notificaciones para los colaboradores y asociadas a los tableros en los cuales participan. Sin embargo, esta tampoco fue considerada por mí una funcionalidad imprescindible.

Por último, a continuación una lista de inconvenientes de Trello si queremos aplicarlo en desarrollo de software (algunos de ellos son inconvenientes heredados de cualquier tablero kanban físico):

• Trello trabaja con "Boards", lo cual equivale a un tablero kanban. Lo natural es tener un board para cada línea de trabajo (producto o servicio, o agrupación de trabajo en general), lo cual implica acceder uno a uno para gestionar el correspondiente trabajo. Se podría llevar la gestión conjunta de varias líneas de trabajo en un solo Board si tienen el mismo workflow, es decir, si tienen las mismas columnas, diferenciando los ítems con etiquetas de colores.
• Si NO se trabaja con Sprints un inconveniente es que en la columna que represente el término de los ítems se irá acumulando todo el trabajo terminado, a menos que se cree cada cierto tiempo un nuevo Board. Sin embargo, cada Board es independiente de otro, no se pueden traspasar ítems de un Board a otro.
• De forma similar a lo anterior, si se trabaja con Sprints, lo natural sería utilizar un Board para cada Sprint, pero el problema es que el Backlog debería ser visible para todos los Sprints, cosa que no se permite en Trello, es decir, cada board en sus primeras columnas tendría su Backlog (el trabajo pendiente que debe circular por el tablero), pero no se puede tener un Backlog visible a todos los Sprints, desde el cual se puedan ir cogiendo ítems para incluirlos en el Sprint.
• Los responsables son asignados al ítem, no a la actividad (a la columna específica). Con lo cual no podremos identificar quién trabaja en cada columna (actividad del workflow).
• No se considera el concepto de rol asociado a cada columna.
• No se pueden reflejar dependencias entre ítems.
• Cada tablero lleva implícito un workflow. Si quisiéramos sintetizar diferentes workflows y/o diferentes tipos de ítems en un mismo tablero estaríamos reuniendo columnas que no serán aplicables a todos los ítems. Esto podría complicar bastante la gestión de los ítems y habría mayor probabilidad de cometer errores en la posición de los ítems en el tablero ya que los miembros del equipo deberían manualmente saltar actividades que no son aplicables en ciertos ítems.
• No se permite tener actividades en paralelo. Si bien podríamos decorar de alguna forma que varias columnas se pueden realizar en paralelo, un mismo ítem no puede estar a la vez en dos o más columnas. 
• Si bien es muy sencillo y atractivo el mover los ítems en una columna o entre columnas haciendo drag and drop, es fácil también cometer errores al respecto.
• No hay una fácil explotación de la información contenida en un ítem una vez terminado, para responder , por ejemplo: ¿Qué parte del producto se ha modificado en un cierto período? ¿Qué ítems han modificado una cierta parte del producto? ¿En qué ítems y/o actividades ha trabajado una persona?

Patricio Letelier

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