En los últimos años he utilizado Trello como herramienta para la gestión de mis proyectos, siempre que he podido involucrar al cliente y en aquellos proyectos en que no he trabajado como contractor, en cuyo caso he utilizado las herramientas que mi cliente disponía para la gestión del proyecto.

Además de Trello combino mi forma de trabajar con Kanbanflow, lo cual me permite controlar mis tiempos, las tareas, ser más productivo y estar enfocado en el trabajo a realizar. Alguno puede pensar que es duplicar trabajo, pero ahora explicaré cómo cada herramienta tiene su sentido, al menos para mi.

Durante el tiempo que estuve participando en proyectos con Becodemyfriend, Xavi Gost me mostró la manera en que utilizaba él Trello para los proyectos, como entrada para el cliente y tener toda la información del proyecto visible tanto para los miembros del equipo como para el cliente. Total transpariencia como siempre nos ha caracterizado.

Posteriormente he visto cómo utliizaba Harry Roberts Trello para gestionar sus proyectos, explicando su workflow y me ha parecido muy válido y muy similar a la manera en que yo lo estaba empleando, con lo que tras algunos cambios y revisiones del workflow he actualizado el mio con una mezcla de los dos.

Partimos de que trabajo siguiendo metodologías ágiles (principalmente Kanban) y lo que ello conlleva. Los tableros tienen que ser un reflejo del estado del proyecto y marcar el ritmo de trabajo.

Trello de Harry Roberts

Paso a explicar las diferentes columnas que empleo en un tablero de Trello.

Las columnas

Lo primero que llama la atención cuando empiezas con Trello es su simplicidad: una serie de columnas, donde puedes agrupar distintas tarjetas dentro de cada una de las mismas. Como estamos hablando de metodologías ágiles y Kanban en concreto cada columna representa un estado de este proceso.

No me gusta tener muchas columnas, lo mejor serían 3, una para definir las tareas en una pila (To-Do), otra columna con las que están realizándose (Doing) y finalmente la columna con las tareas finalizadas (Done). Esto sería lo más simple, e ir moviendo tareas de una columna a otra. Con la experiencia de varios proyectos el workflow lo he transformado un poco más allá.

Parto siempre de una plantilla de proyecto que "copio" y adapto a las necesidades del proyecto en sí.

Las columnas de esta plantilla son las siguientes:

• Product backlog
• Sprint backlog
• Preparación
• En Desarrollo
• Done
• UAT (Aceptación por cliente)
• Preparado para release
• Released

Product backlog

El Product backlog contiene todas las historias de usuario del cliente. Su lista de deseos, lo que quiere que tenga la aplicación.

El cliente puede añadir, quitar, reordenar esta columna según su criterio, que para eso es el dueño del producto. Hay que tener especial cuidado con las tarjetas que añade, porque podemos tener el problema de salirnos del alcance del proyecto, con lo que todo aquello que no se haya definido previamente habrá que analizarlo y estimarlo oportunamente.

Las tareas de esta columna no están en el Sprint, en la iteración en la que estamos trabajando pero es la fuente de la que tiraremos al empezar el siguiente sprint.

Sprint backlog

En esta columna incluimos aquellas tarjetas de la columna de * Product Backlog * que me comprometo a entregar en el Sprint que vamos a empezar.

Las tarjetas incluidas son consensuadas con el cliente y priorizadas conjuntamente.

Preparación

A veces hay tareas que necesitan algo de preparación por parte del cliente antes de empezar a implementarlas. O incluso spikes que definimos para estudiar una tecnología o APIs que vamos a incorporar al proyecto o que queremos validar.

Estas tareas se añaden en esta columna para ser gestionadas de manera especial (pueden ser tareas técnicas o bloqueantes por falta de información).

En Desarrollo

Esta columna sería la correspondiente a Doing, las tareas que estoy implementando, en las que estoy trabajando en ese momento.

Estas tareas pueden ser suficientes en sí o estar compuestas de subtareas que las hagan más atómicas. Es en este punto donde hago un salto para usar Kanbanflow. Copio las tareas que voy a desarrollar a mi tablero de Kanbanflow del proyecto.

Para que la tarea la considere terminada debe estar completada con los tests correspondientes, y si la he desarrollado con TDD perfecto, ya tengo los tests.

Done

En esta columna vamos moviendo las tareas finalizadas desde la columna anterior. Simplemente indicamos que está finalizada y podemos pasar a trabajar en otra tarea.

Si estoy trabajando con más gente en esta columna vemos las tareas que se han ido completando entre todos.

Si quisiéramos podríamos incorporar una nueva columna para hacer code reviews a partir de las tareas que están en esta columna, antes de pasar a la siguiente columna que voy a explicar a continuación.

UAT (Aceptación por cliente)

En esta columna hacemos un depliegue en un entorno de preproducción para que el cliente pueda validar lo que se ha implementado. Si las pruebas del cliente dan luz verde las tareas pasan a estar preparadas para un despliegue, en caso contrario, aquellas tareas que no satisfacen los criterios de aceptación del cliente vuelven a la columna de Sprint backlog junto con un comentario o nota del cliente justificando el rechazo de esa tarea, para que pueda ser abordada de nuevo.

Preparado para release

Lo importante de esta columna es que el trabajo de este sprint ha finalizado y ha sido validado por el cliente. Normalmente significará esperar la fecha decidida para el pase a producción.

Released

Esta sería la columna de Done. El Sprint ha terminado (o el conjunto de Sprints que conforman una release) y ha pasado a producción.

Las etiquetas

Me encanta usar etiquetas de colores, tanto en tableros físicos como en los virtuales. lo hago en Trello y en Kanbanflow de una manera que rápidamente puedo entender lo que señalan en una tarea.

En Trello tenemos 6 etiquetas, de colores diferentes y estos son los colores que empleo junto con su significado, "copiando" la idea de Harry Roberts:

• Verde: Feature/mejora
• Amarillo: Copy/contenido
• Naranja: Producto
• Rojo: Bug
• Púrpura: Diseño/Maquetación
• Azul: Desarrollo

En una misma tarea podemos usar varias etiquetas, el ejemplo típico es la roja de bug junto con el área al que se asigna (Desarrollo o Diseño, por ejemplo).

Feature/mejora

Las tarjetas con esta etiqueta indican aquellas funcionalidades que queremos añadir a la aplicación.

Copy/contenido

Normalmente las tareas con esta etiqueta se suelen asignar al cliente, ya que es quien debe darme estos datos para incorporar a la aplicación.

Producto

Esta etiqueta es un poco especial, porque suele estar asociada a tareas que no son de desarrollo pero que hacen hay que completar para poder hacer finalmente un despliegue del producto.
Ejemplo: que el cliente nos dé los datos de acceso a la pasarela de pago o enlaces a la zona de prensa.
Evidentemente también están asociadas al cliente.

Bug / Deuda técnica / Bloqueada

El rojo siempre es el color que nos debe llamar la atención. Si hay una tarea en rojo hay que parar y atender esa tarea antes de seguir avanzando. Sería un "Para las máquinas!!!".

Si hay algo roto en la aplicación, es un bug y hay que resolver inmediatamente y si es posible hacer un despliegue con el hotfix que soluciona el bug.

Respecto a la deuda técnica, es ese código que sabemos que es mejorable, que puede estar ahí pero que no deberíamos que siguiera porque puede dar lugar a errores.

Diseño/Maquetación

Esta etiqueta es para lo que indica, las tareas propias del diseñador o maquetador. Trabajando con alguien que lleva esta parte a veces queda fuera del equipo de trabajo y son colaboraciones puntuales.

Desarrollo

Al final esta etiqueta es la que me asigno siempre a mi, que para eso soy el desarrollador del equipo ;)

Kanbanflow

Utilizo Kanbanflow para poder asignar mis pomodoros a las tareas y hacer una gestión del tiempo dedicado a cada tarea. Me ayuda a mejorar mis estimaciones y poder explicar el tiempo invertido.

Puede parecer que duplico trabajo o gestión, pero tener las tareas de Trello copiadas en Kanbanflow y ahí extenderlas con las tareas técnicas correspondientes me permiten esconder al cliente conceptos puramente técnicos que no entendería.

En el tablero de Kanbanflow también empleo etiquetas de colores para las tareas, ya técnicas todas ellas y en paralelo con las de Trello tengo definidas:

• Amarilla: Tarea
• Azul: Deuda Técnica
• Rojo: Bug
• Naranja: Mejora
• Blanco: Feature/User Story

El uso del Pomodoro Timer de Kanbanflow lo tengo configurado a 35 minutos de trabajo, descansos de 5 minutos y tras 4 pomodoros de trabajo hago el descando largo de 15 minutos. Así gestiono bien los tiempos, tras adaptar el tiempo de trabajo ya que inicialmente los 25 minutos se me hacían demasiado cortos.

Seguramente este flujo de trabajo es mejorable, al final he juntado varias ideas y las estoy adaptando a mi forma de trabajar, y cada proyecto tiene sus particularidades y normalmente esta plantilla tiene más cosas de las que puedo necesitar, en ese caso lo elimino para no tener ruido.

Espero que te ayude a tu forma de trabajar o incluso si estas interesado podemos comentarlo en más detalle.