EL KANBAN EN FDSÄ

UNA HERRAMIENTA INDISPENSABLE

El Kanban ha sido y es, a día de hoy, esencial en FDSA. Permite tener un control de las tareas que realiza nuestro equipo de principio a fin y día a día.

Según nuestra estructura, las tareas, elementos que cuelgan del kanban en forma de post-it, se mueven siempre en la misma dirección según avanza el tiempo, reflejando el progreso diario en el trabajo que realizamos. Salvo casos especiales, no hay lugar para el retroceso en el Kanban. En este artículo lo explicaremos con detalle.

En nuestro Kanban existen dos tipos de tareas: análisis y desarrollo. El primer tipo se corresponde con aquellas tareas realizadas para analizar los requerimientos que el cliente precisa. A partir de ellos, hacemos una estimación del tiempo que nos puede llevar la tarea y, finalmente, le comunicamos al cliente dicha estimación. 

El segundo tipo, las tareas de desarrollo, hacen referencia al proceso de programación en sí, donde implementamos los requerimientos estudiados, hacemos las pruebas, nos comunicamos con el cliente según los imprevistos y, al final del proceso, entregamos la tarea.

El ciclo de vida de nuestras tareas consta de cinco fases. Estas son, por orden, las explicadas a continuación. 

Backlog: en esta fase colocamos todas aquellas tareas que nos acaban de encomendar. Es el inicio del desarrollo. Para una mayor organización, dividimos las tareas en espacios por cliente y éstas se ordenan de mayor a menor prioridad.

Pendiente: los lunes de cada semana, los equipos de programación deciden qué tareas van a avanzar desde backlog.  Intentamos y acordamos que todas las tareas que se sitúan en pendiente se puedan asignar durante el transcurso de la semana. Si vemos que se avanzan demasiadas tareas, para la siguiente semana se reduce el número; si, de lo contrario, nos quedamos sin trabajo, lo comunicamos al equipo y traemos más tareas desde backlog. Así, nivelamos los picos y valles de trabajo y conseguimos un flujo constante del mismo. Hay casos en los que, incluso, un integrante de un hipotético “equipo A”, se ocupa de tareas de otro hipotético “equipo B” para mantener el flujo.

En progreso: una tarea pasa a estar en progreso cuando un integrante se asigna una tarea. En este estado se encuentran todas las tareas que los equipos están desarrollando actualmente. La columna de “en progreso” se divide, además, en carriles. Hay un carril para cada desarrollador y cada uno abarca cuatro estados temporales:

• • Tarea atrasada: la fecha de finalización es de la semana anterior pero no se pudo finalizar. Cuando se da esta situación, la tarea en cuestión tiene prioridad y debe ser terminada lo antes posible.
  • Tarea en un día concreto: día en que la tarea, cuando no está atrasada, se debe terminar.
  • Tarea en un día concreto de la semana posterior: día en que la tarea, cuando no está atrasada, se debe terminar a más de una semana vista.
  • Tarea en futuro: ocurre cuando la fecha de finalización de la tarea es superior a dos semanas vista.

Bloqueado: supone un “caso/estado especial”, ya que es el único momento del proceso en que una tarea permite ir “hacia atrás”, aunque no supone un retroceso, sino más bien un estancamiento. Cuando sucede un bloqueo es debido a un factor externo al equipo (imposibilidad de conexión al sistema el cliente, en espera de que nos contesten una duda, ha salido una tarea que tiene prioridad por encima de la que bloqueamos, etc.) Una vez que una tarea se ha desbloqueado, pasa de nuevo a estado pendiente.

Listo pendiente de respuesta: cuando una tarea finaliza su desarrollo, notificamos al cliente de que ha terminado y adjuntamos la documentación pertinente. En este momento pasamos la tarea a listo pendiente de respuesta hasta que el cliente confirme la recepción y conformidad (entonces, en ese momento, pasaría a listo). 

• • Este estado se divide en 4 partes que representan 4 semanas desde la finalización de la tarea. Cada semana, la tarea avanza 1 casilla. En la semana 3 tenemos un indicador y cuando sabemos que estamos en él, preguntamos al cliente por el estado de la tarea. Cuando una tarea llega a la semana 5 y el cliente no ha contestado, la tarea pasa automáticamente a listo.

Listo: Es el estado final de una tarea. Las tareas llegan a este estado por varios motivos: 

• Porque el desarrollo ha terminado ya que así nos lo ha notificado el cliente.
• Porque se requiere realizar otro ajuste a la tarea así que tendremos que crear una nueva.
• Porque hemos tenido un error y tenemos que  crear una tarea de incidencia nueva
• Porque nos han aceptado un análisis, haciendo que tengamos que crear una nueva tarea de desarrollo

Por último, están los indicadores visuales que hemos ido añadiendo al Kanban que nos ayudan a la gestión del mismo. Estos indicadores son:

• Una pegatina con la cara del desarrollador. Este avatar nos indica qué desarrollador tiene asignada la tarea y por lo tanto es el responsable de ella
• Gomets de colores para indicar tanto el estado del desarrollador como el estado de la tarea. El primer caso nos ayuda a monitorizar el ánimo del desarrollador y el segundo caso nos sirve para indicar 3 variables: alcance, recursos y tiempo de que disponemos. El color de estos gomets nos indica la gravedad yendo de verde (bien), a amarillo (regular) y finalmente rojo (mal). Estos indicadores se actualizan de forma diaria en la reunión matutina, nuestro Stand-up meeting.
• Indicador de semana en tareas bloqueadas: un post-it con las semanas que lleva una tarea bloqueada. Así tenemos más control del tiempo
• Cuando un desarrollador ha planificado una visita al cliente, pone un imán con el logo de la empresa en la columna en desarrollo, en el día que va a asistir. Con esto, el resto del equipo sabe dónde se encuentra un desarrollador sin tener que preguntar o buscarlo

Esta herramienta evolucionará con el paso del tiempo. Estad seguros de que habrá muchas más mejoras a introducir.

De hecho, puede que incluso ahora, mientras estáis leyendo este artículo, estemos implementando alguna.

Juan Manuel Plaza y Silvia Menéndez