Kanban operaciones

Kanban en Sistemas

To get back,

Turn off ’CLASSIFICED’ via

2. Deactivate by clicking off the

¿QUÉ ES KANBAN?

• Kanban es una herramienta que permite visualizar el trabajo y optimizarlo.

• Está basado en la filosofía del Just in time.

• Y en los conceptos de mejora continua

• ricos en el sentido de que se espera que experimentes con el

proceso y lo adaptes a tu entorno. Se tiene que experimentar. Este

sistema no proporciona todas las respuestas – simplemente nos

proporcionan una serie de reglas y limitaciones a la hora de guiar la

mejora de nuestros procesos.

• Parte de la base de que el equipo es autoprganizado.

To get back,



¿QUÉ ES KANBAN?

• Visualizar el flujo de trabajo:

• Dividir el trabajo en tareas, escribir cada uno de los elementos en una

tarjeta y poner en el tablero.

• Usar el nombre o columnas para ilustrar en que estado se encuentra

cada elemento dentro del flujo de trabajo.

• Limitar WIP (Work In Progress):

• Asignar límites explícitos sobre cuantos elementos pueden estar en

cada uno de los estados del flujo de trabajo.

• Medir el tiempo (en entornos muy maduros o industrializados):

• Contar el tiempo promedio para completar una tarea “lead time”, como

es obvio, optimizar el proceso para que el tiempo tan pequeño y

previsible como sea posible.

• Reducimos variabilidad y damos previsionalidad a nuestro trabajo.

To get back,



¿QUÉ PRETENDEMOS RESOLVER?

El principal cliente de un equipo de sistemas son los desarrolladores. Pero…

Nos encontramos con falta de comunicación, falta de empatía,….

To get back,



¿QUÉ PRETENDEMOS RESOLVER?

¿Cómo nos ven los desarrolladores?

¿Y cómo vemos nosotros a los desarrolladores?

To get back,



¿KANBAN ES LA SOLUCIÓN?

• Kanban no es la solución para todo. Necesitamos un cambio de actitud

tanto en desarrolladores como en sistemas para derribar las barreras.

• Kanban ayuda en este proceso a conseguir:

• Comunicar el estado de las tareas y en que estamos

trabajando, generando confianza.

• Gestionar la repriorización diaria.

• Limitar el trabajo a la capacidad del equipo.

• Gestionando el limite de trabajo en curso.

• Identificar cuellos de botella y eliminarlos.

• Mejora el trabajo en equipo: colaboración en tareas y solución y apoyo

al que tiene un problema.

• Camino a ser más multidisciplinares y aprovechar al máximo la

capacidad del equipo.

To get back,



¿POR DÓNDE EMPEZAR?

• Comencemos reflejando nuestra actividad.

• Y sobre esto, vayamos aprendiendo y adaptándonos.

• Hasta construir NUESTRO modelo.

To get back,



CONSTRUIR EL PRIMER TABLERO

• Definir el Mapa de la Cadena de Valor:

• ¿Cómo recibo una petición?¿Cómo la clasifico? ¿Cómo la priorizo?

• O Podemos comenzar con estados muy básicos y luego darle mayor

complejidad:

• Backlog: lista de tareas pendientes de atacar y priorizadas

• Ready: Lista de tareas que podemos acometer durante el día

• Work in Progress: Tareas en las que estamos trabajando

• Done: Trabajo finalizado. Podemos hacer “reset” de forma semanal

o quincenal.

To get back,



CONSTRUIR EL PRIMER TABLERO

• Nos debemos hacer preguntas del estilo;

• ¿Qué tipo de trabajo tenemos? ¿Portales diferentes?

¿Soporte/Peticiones/Proyectos/…?

• ¿Tamaño de los tipos de trabajo? Deberíamos tener tareas con

tendencia a que no duren más de 1 día para ver avances en las tareas

y no tareas eternas. ¿Pero podemos estandarizar el tamaño de las

tareas? Tallas: XS, S, M, L, XL.

• ¿Debemos compartir responsabilidad entre los diferentes tipos de

trabajo?

To get back,



UNA IDEA

Backlog Ready WIP (3) Done

Fotocasa & Inmofactory

Segundamano

Coches

Lectiva

Sistemas comunes

FIRE!!!

PRIO

ASAP

• Podemos añadir tablas o gráficas. Por #incidencias por portal,

%disponibilidad,….

• El tablero es un radiador de información, utilicemoslo.

To get back,



CEREMONIAS

• Crear tareas

• No es necesario reflejarlo todo. P.e: podemos decidir no añadir tareas

de 5’. Queremos ser eficientes, no crear un monstruo administrativo.

• Tal como nos llega la petición, la debemos llevar al tablero y priorizarla

con el cliente.

• El cliente debe entender que si prioriza una tarea sobre otra, implica

que algo se va a retrasar.

• ¿Damos tamaño y fecha?

• Información básica:

• Descripción suficiente saber qué hay que hacer.

• Persona que trabaja en ella.

• Peticionario.

• Otros datos: Fecha entrada, Fecha fin, #repriorizaciones, Lead

Time, Tamaño,…

• Cambio de estado de una tarea

• Al momento. El tablero debe reflejar el estado del trabajo en curso de

forma fiel.

To get back,



CEREMONIAS• Daily:

• Reunión diaria de sincronización del equipo

• Cada persona explica qué hizo el día anterior y qué cosas va a hacer

hoy.

• La reunión debe durar unos 15’. Se debe hacer siempre a la misma

hora. Puntualidad.

• Se pueden/deben comentar impedimentos, pedir ayuda, comentar la

priorización, comentar la solución, posibles retrasos, pero no alargar el

debate. Si es así, se deja para el final y se habla entre los implicados.

• Reset:

• No queremos acumular meses de tareas en Done. ¿1 semana es

suficiente?

• Retrospectiva:

• ¿1 al mes? ¿semanal? ¿quincenal?

• Sinceridad, escuchar todas las opiniones.

• Sed constructivos y no os tememos nada de forma personal

• Las acciones de mejora deben tener un owner del equipo y un

deadline. Revisar en la siguiente retrospectiva.

To get back,



CONSEJOS

• Experimentad y aprender.

• Lo que no funciona, eliminadlo.

• Leer sobre el proceso y haced el vuestro.

• Personalizar el tablero.

• Celebrad los éxitos.

• Cuando tengamos el modelo dominado, pasemos a formato electrónico.

Nos facilitará el cálculo de lead time, quienes nos piden más cosas, más

FIRE,..

• Utilizad señales:

• Evitar interrupciones cuando tenéis que hacer un trabajo de

concentración: chaleco, bandera, …

• Decidir quien atiende a quien se acerca a Sistemas para realizar una

petición.

• Al momento. El tablero debe reflejar el estado del trabajo en curso de

forma fiel.

To get back,



COMENCEMOS A SER AGILE!!!

Technology

Kanban operaciones