1. IOPLANTO. Mejorando nuestra
forma de trabajar con Kanban
Agueda Vega
IEBS
Caso Práctico: Modulo 9 (Metodologías)

2. El equipo de desarrollo da su
opinión:
Luis Tallo (desarrollador): “Estoy muy contento con Kanban aunque tengo la sensación de que
todavía no le sacamos el partido que podríamos. A veces nos cuesta decidir sobre qué tareas
tenemos que sacar adelante y al no contar con todo el equipo en la oficina el 100% del tiempo a
veces me bloqueo por no saber por donde avanzar.”.
Clara Flora (experiencia de usuario): “El trabajo con Luis se ha vuelto más fluido y tenemos una
sensación de control mayor. Estamos desarrollando más y mejor. Sin embargo creo que la
corrección de errores en la plataforma nos dificulta la gestión de las tareas. Tenemos que avanzar a
la vez con nuevos desarrollos y con corrección de errores que a veces son prioritarios y otras no. No
siempre es fácil conjugar esto y seguir avanzando a buen ritmo.”.
Carlos Verdes (departamento comercial): “Estoy viendo como Kanban ha ayudado al equipo de
desarrollo pero me sigue preocupando la coordinación de las tareas. Sé que es fundamental la
corrección de errores y seguir avanzando con las funcionalidades pero para mí es crítico que las
acciones y patrocinios que vendemos (banners y secciones de contenido patrocinado) aunque
normalmente sean sencillos de implementar estén desarrollados en el plazo que nos piden los
clientes.”
Mario Redes (analítica y redes sociales): “No he terminado de encontrar mi sitio, mi trabajo
transcurre de manera paralela al equipo y no he terminado de sentirme cómodo en los flujos que se
han planteado. Me gusta el tablero y lo veo útil, sólo creo que falta un poco de especificidad para mi
puesto.”

3. Introducción
● A continuación se expone las mejoras teniendo en cuenta la
opinión de los miembros del equipo.
– Se ha definido la priorización de los inputs en nuestro tablero.
– Se ha mejorado el tablón dividiendo por proyecto. Se ha añadido
más información a la tarea para el proyecto de mantenimiento.
– Se ha añadido políticas de priorización.
– Se ha incrementado el límite por fase de proyecto y se ha
especificado cuantas tareas a la vez pueden estar “ongoing”
por fase y por proyecto.
Nota: Todo lo marcado en rojo es nuevo respecto a la primera fase de
Kanban.

4. Los inputs del
tablero y su
priorización

5. Inputs en el tablero
● Nuestros imputs
● Departamento comercial (Banners y secciones de contenido patrocinado) y Redes
sociales.
– EL número de tarjetas que debemos tener en el tablón será de 10 tarjetas
(incluye los dos proyectos de desarrollo).
● Mhweb tool (Herramienta dónde aparecen las incidencias de los clientes)
– El número de tarjetas que debemos tener en el tablón será las que marque la
herramienta con incidencias abiertas por los clientes.
● ¿Como priorizar nuestras tarjetas/tareas de entrada del tablón?
Informaremos cada dos semanas al departamento comercial y al responsable
de las redes sociales (Mario Redes) del número de slots libres que tenemos
para recibir ordenes de trabajo.

6. Clases de servicios
y sus políticas

7. Políticas de visualización.
– Como diferenciar los tres proyectos (servicios) en el tablón:
● Mantenimiento (con su propio código).
– Post-it naranja
● Renovación de gestión interna (con el código REN-xxx)
– Post-it azul
● Nueva funcionalidad (con el código NEW-yyy)
– Post-it verde
Los proyectos estarán separados en el tablón para que se vea de un vistazo la carga de
trabajo de cada parte del proyecto, la estructura del formato de la tarea sufre una
pequeña modificación para tener en cuenta si las incidencias de mantenimiento son High,
Medium, Low o emergency. (ver siguientes slides)
– Dependencias entre tareas: En el área de descripción indicar si se depende o no de otra
tarea haciendo referencia solo a su código.
– Tarea bloqueada: Usaremos un bandera roja para indicar que la tarea esta bloqueada
y que no puede avanzar.
– Tarea retrasada o a punto de cumplir el “lead time”: Usaremos una bandera
amarilla para indicar que la tarea está retrasada sobre su fecha límite.

8. Políticas de visualización II
Diseño del tablero
Tareas Análisis Diseño Implementación Verificación Finalizado
ongoing done ongoing done ongoing done ongoing done
Solo proyectos de nueva funcionalidad
Proyectos de renovación de gestión

9. Políticas de visualización III
Decisiones para el manejo del tablero
● Se entiende que este equipo pasará las tareas por las siguientes fases;
– Análisis del problema o nueva funcionalidad.
– Diseño de como implementar dicho análisis.
– Implementación del diseño estudiado.
– Verificar si lo que se ha implementado es lo que se espera.
– Finalizar la tarea tras verificar que lo implementado es lo esperado.
● Las fases análisis, diseño, implementación y verificación estarán divididas en dos columnas.
– Ongoing: Tarea empezada.
– Done: Tarea finalizada. Será el buffer de tareas finalizadas de cada fase, de tal
forma, que se puedan ir cogiendo (dichas tareas) en las siguientes fases..
● La columna Tarea contendrá la lista de tareas que que no están empezadas.
● La columna Finalizado contendrán las tareas finalizadas.

10. Políticas de visualización IV
Diseño de tarjetas.
Titulo proyecto
Código Nivel de severidad
Descripción general
¿Depende de otra tarea?
fecha entrada fecha límite
Tres opciones:
● Mantenimiento
● Renovación de gestión interna
● Nueva funcionalidad
Breve descripción de la tarea para
saber de que se trata.
E indicar si la tarea depende de
otra tarea
Solo válido para las tareas tipo
“Mantenimiento”
Debe corresponder con el día
que se añade la tarea al tablero
Mantenimiento
● Código incidencia
Renovación
● REN-XXX
Nueva funcionalidad
● NEW-YYY
Indicar el nivel de severidad de la incidencia
de mantenimiento. (High, Medium, Low,
Emergency)

11. Límites
● Número de tareas empezadas simultaneas en la fase Análisis. (Deben estar escritas en el tablón)
● 2 tareas simultáneas en “ongoing” (solo está Carlos Verde para esta fase pero no a tiempo
completo)
– 1 tarea para el proyecto “nuevas funcionalidades”
– 1 tarea para el proyecto de “mantenimiento” o renovación gestión interna.
● Número de tareas empezadas simultaneas en la fase Diseño. (Deben estar escritas en el tablón)
● 4 tareas simultáneas en “ongoing” (está Carlos Verde y Clara Flora para esta fase pero no a
tiempo completo)
– 2 tareas para el proyecto “nuevas funcionalidades”
– 1 tarea para el proyecto de “mantenimiento”
– 1 tarea para el proyecto “renovación gestión interna”.
● Número de tareas empezadas simultaneas en la fase Implementación. (Deben estar escritas en el tablón)
● 4 tareas simultáneas en “ongoing” (esta Clara Flora y Luis Tallo. Clara Flora no esta a tiempo
completo)
– 2 tareas para el proyecto “nuevas funcionalidades”
– 1 tarea para el proyecto de “mantenimiento”
– 1 tarea para el proyecto “renovación gestión interna”.
● Número de tareas empezadas simultaneas en la fase verificación. (Deben estar escritas en el tablón)
● 2 tareas simultaneas en “ongoing” (esta Luis Tallo con esta fase)
– 1 tarea para el proyecto “nuevas funcionalidades”
– 1 tarea para el proyecto de “mantenimiento” o renovación gestión interna.

12. Límites II
Conclusión:
– Cada miembro del equipo solo podrá estar como mucho con tres tareas simultáneas por
tanto solo 3 avatares por persona.
– La columna de tareas será completada de la siguiente forma;
● Si aparece una incidencia, deberá ser colocada en el tablón de forma inmediata por
cualquier miembro del equipo.
● Las tareas de nueva funcionalidad o renovación deberán ser colocadas por Mario
Redes.

13. Límites III
Diseño del tablero
Tareas Análisis Diseño Implementación Verificación Finalizado
(2) (4) (4) (2)
ongoing done ongoing done ongoing done ongoing done
(1) (2) (2) (1) Nueva funcionalidad
(0/1) (1) (1) (0/1) Renovación

14. Políticas de priorización
● Dentro del proyecto Mantenimiento.
– Cada semana será uno de los miembros el responsable de
sincronizar el tablero con nuevas incidencias aparecidas en la
aplicación “mhweb” siguiendo la nomenclatura especificada en
la slide 9 y puestas en el tablón justo en el área de tareas y
tercera fila.
– Los miembros deberán escoger las tareas en función del nivel de
severidad escrito en la tarjeta. De mayor prioridad
(Emergency) a menor prioridad (Low).

15. Políticas de priorización II
● Dentro del proyecto de nueva funcionalidad.
– Las tareas son escritas por “Mario Redes” siguiendo la
nomenclatura especificada en la slide 9 y puestas en el tablón
justo en el área de tareas y primera fila pero en orden de
prioridad de tal forma que el resto de miembros coja las tareas
siguiendo la política FIFO (first input, first output).
– Cada vez que cada miembro termine su tarea, deberá dejarla en
“done” pero colocada en el orden de prioridad inicial para que
el siguiente miembro del equipo sepa que tarea coger.
– “Mario Redes” deberá estar controlando estas prioridades para
saber si se van ejecutando cada fase en el orden indicado
inicialmente.

16. Políticas de priorización III
● Dentro del proyecto de renovación gestión interna.
– Las tareas son escritas por “Mario Redes” siguiendo la
nomenclatura especificada en la slide 9 y puestas en el tablón
justo en el área de tareas y segunda fila pero en orden de
prioridad de tal forma que el resto de miembros coja las tareas
siguiendo la política FIFO (first input, first output).
– Cada vez que cada miembro termine su tarea, deberá dejarla en
“done” pero colocada en el orden de prioridad inicial para que
el siguiente miembro del equipo sepa que tarea coger.
– “Mario Redes” deberá estar controlando estas prioridades para
saber si se van ejecutando cada fase en el orden indicado
inicialmente.

17. Políticas de priorización IV
● Priorización entre clases de servicio diferentes.
Aplicaríamos Round Robin entre todos proyectos con algunas
excepciones.
– Una incidencia tipo “Emergency” tiene prioridad sobre todas las demás
tareas (de todos los proyectos) y por tanto deberá ser atendida de
inmediato.
– Una incidencia tipo “High” o “medium” con fecha de entrega a menos de
2 días laborables tendrá prioridad sobre el resto de tareas (pasa a ser
una incidencia de tipo “Emergency”).
– Si no hay tareas en uno de los proyectos entonces nos saltamos ese
proyecto y cogemos tarea nueva del siguiente proyecto aplicandose
Round Robin.