martes, 8 de mayo de 2012

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.

Ya he comentado 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 agilismo en la práctica, 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:

Kanbanpadhttps://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.


Kanbanizehttp://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.


YouKanhttp://www.youkan.eu


 


  • Sólo YouKan incorpora el concepto de Sprint, es decir, un Proyecto/Producto con varios tableros (uno para cada Sprint) pero 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.




  • Interfaz de usuario muy amigable. Muy sencilla gestión de columnas e ítems.
  • No tiene subtareas pero inclucle 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 y mi caso de estudio se centraban en el desarrollo iterativo e incremental de un product 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 (uno solo a la vez), el Product Backlog sería una columna y en DONE se irían acumulando los ítems finalizados del Sprint actual y de todos los Sprints terminados.

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 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 que hay que hacer de la herramienta, a pesar de que éstas tengan funcionalidad tan reducida. Por otra parte, si bien Trello, probablemente por no enfocarse a desarrollo de software no se hace referencia a un sistema Kanban, pero está claro que es muy coincidente con él.

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 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 inconveneintes de Trello si queremos aplicarlo en desarrollo de software (algunos de ellos son inconvenientes heredados de cualquier tablero kanban de pared):
  • Trello trabaja con Boards, lo cual equivale a un tablero kanban. Lo natural es tener un board para cada producto o servicio, lo cual implica acceder uno a uno para gestionar el trabajo. Se podría llevar la gestión conjunta de productos o servicios en un solo Board si tienen el mismo workflow (y 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 lógico sería utilizar un board para cada sprint, pero el problema es que el Backlog debería ser visible para todos los srpints, 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 kanban), 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.
  • No se considera el concepto de rol. 
  • No se pueden reflejar dependencias entre ítems.
  • Cada board lleva implícito un workflow. Si quisiéramos sintetizar diferentes workflows y/o diferentes tipos de WUs para aplicarles diferentes columnas del tablero sería bastante complicado (por ejemplo usando etiquetas de colores). Además, los miembros del equipo deberían manualmente saltar actividades que no aplican a un ítem.
  • 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 diferentes 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. ¿Podríamos responder fácilmente preguntas tales como?: ¿Qué parte del producto se ha modificado en un cierto período? ¿Qué ítems han modificado una cierta parte del producto? ¿Cuál es el comportamiento detallado implementado en el producto (sin tener que revisar el código)?

Patricio Letelier