PDF de programación - Que es Kanban y cómo usarlo en el desarrollo de software

Juan Ignacio Rodriguez de león ~ @jileon
euribates [at] gmail.com



KANBAN



Taiichi Ohno
TOYOTA



Kanban Aplicado al software

● David J. Anderson

– @djaa_dja
– Adaptación de las

técnicas
industriales al
desarrollo del
software



http://www.djaa.com/

Principios de Kanban
●Visualizar
●Limitar el WIP
●Gestionar y optimizar el
flujo



Principios de Kanban
●Visualizar
●Limitar el WIP
●Gestionar el flujo



Visualizar significa ...
● Hacer que toda la información necesaria

sea visible cuando la gente la necesite.

● Y, además:

– Representar la información de forma visual,

fácil de entender, simbólica

– Difícil de no-ver
– Transparencia
– Compartición de la información



Tablero Kanban (ejemplo)



Otro ejempo



Carácterísticas del tablero

● El tablero debe ser bien visible, en una posición

central, no obviable

● Toda tarea debe estar reflejada en el tablero
● Fácil acceso y modificación
● Diseñado por el equipo
● ¿Tablero físico o digital? El equipo decide.

(Pero hay muchas ventajas en empezar físico)



Fridge vs Radiator



Hacér las políticas explícitas

● ¿Cómo pasa una tarea de una columna a la

otra?

● ¿Hay prioridades en las tareas? (Por ejemplo,

escoger siempre la tarea superior)

● ¿Cómo se tratan las urgencias?

En general, las políticas deben permitir tomar
una decisión rápido y sin consultar.



Información en la nota























Otra información que pueden ir
● ¿Está la tarea bloqueada?
● Tamaño de la tarea
● Fechas límite
● Tipo de trabajo y/o prioridad
● Progreso

Cualquier cosa que facilite decidir en
qué tarea vamos a trabajar



Principios de Kanban
●Visualizar
●Limitar el WIP
●Gestionar el flujo



Pero ¿Qué es WIP?
● Significa “trabajo en curso” (Work in process)
● Todo tarea que se ha empezado y no se ha terminado
● Pero hay tareas y factores “invisibles” que suman al WIP:

– Especificaciones no implementadas
– Código no testeado o no integrado
– Deuda técnica
– Cualquier tarea que requiera context-switching: reuniones, papeleo

administrativo, etc...



Aun hay más...
● Retrasos → Trabajo extra → Más WIP
● Un WIP grande produce por si mismo una

mayor coordinación, es decir, más WIP
● Código de mala calidad, que producirá

bugs, que añade más WIP



Limitar el WIP
● Limitar el WIP normalmente aumenta el flujo

de trabajo

● Limitar el WIP no significa hacer menos cosas,

significa: Hacer menos cosas a la vez

● A mayor WIP, menor Lead-time o plazo de

entrega

● Normalmente, con sólo bajar o limitar el WIP

se produce una mejora notable.



Ley de Little



Ley de Little



Ley de little

● WIP = 16
● Throughput = 2

16
2

= 8

días



Ley de little

● WIP = 8
● Throughput = 2

8
2

= 4

días

Sólo se ha cambiado el WIP, todo lo demás: capacidad del
equipo, tamaño del mismo, carga de trabajo, etc... sigue igual



El objetivo

● El objetivo final no es establecer el WIP
● El objetivo final es reducir el lead-time
● Limitar el WIP Reduce el lead-time por

varias razones:
– Ley de Little
– Menos tiempo gastado en context-switching
– Menos retrasos
– Mejor flujo



Límites de WIP



Estrategias elegir WIP global

● Entre 1 y 3 tareas por miembro del equipo
● 2/3 del tamaño del equipo (Fuerza la cooperación)
● Sube y baja 20: Empieza con un número grande (p.e. 2 x la

carga actual) y baja un 20% cada vez

● Técnica AODBC (A Ojo de Buen Cubero): elige un número y

tira pa'lante

Tendrás que ir ajustando hasta llegar al WIP adecuado al equipo.
No se debe perder tiempo intentado acertar a la primera.



Principios de Kanban
●Visualizar
●Limitar el WIP
●Gestionar el flujo



Flujo

Para aumentar el flujo, a veces
hay que reducir el tráfico



Colas
● Facilitan el paso de tareas y suavizan el

flujo del trabajo

● Señal visual de que un trabajo está listo

para continuar

● Dividor una columna, por ejemplo

Development, en dos, doing y done.
● Las tareas en la cola cuentan para el

límite del WIP de la columna



El desarrolador termina

Development

(4)

Doing

Done

Test
(2)



Pasa la tarea a la cola

Development

(4)

Doing

Done

Test
(2)



El tester acepta la tarea (pull)

Development

(4)

Doing

Done

Test
(2)



Si no podemos continuar ...

● No nos quedamos de brazos cruzados:

– Ayudamos a otro desarrollador a terminar su tarea,

si es posible

– Ayudamos a desbloquear la siguiente columna,

para poder hacer un hueco y seguir con otra tarea
– Cualquier otra cosa que contribuya a solucionar el

atasco.

● NO podemos continuar hasta que el problema

se resuelve



¿Qué conseguimos con esto?

● Enterarnos antes de los problemas
● Detectar los cuellos de botella
● Fomentar el trabajo cooperativo
● Enterarnos antes de los problemas (Si, está

repetido, porque es muy importante)



Reunión diaria
Parecida a la de Scrum, con algunas
diferencias
– Frente al tablero
– Se comentan las tareas empezando por la

derecha (Las que más cerca están de
terminar)

– Hora fija (A determinar por el equipo)
– Cortas. 15 min máximo



Métricas

● Concentrarse en las más fáciles de obtener
● Fundamentales:

– Lead Time
– Througput

Predictibilidad

● Anotar la fecha de entrada (in) y sálida (out) de

cada tarea



Otras métricas

● Due Date Performance

– Para tareas de fecha tope, cuantas han terminado

en la fecha acordada y cuantas no

● Tareas bloqueadas

– Días perdidos por tarea bloqueada (Histograma)
● Diagrama de Flujo Acumulado (Cumulative

Flow Diagram – CFD)
– Se anota cada día el nº de tareas en cada columna



Lectura de un CFD



Kaizen (Mejora continua)

● Usando la retroalimentacion que nos dan:

– El flujo del trabajo tal y como se ve en el tablero
– Las métricas
– Las reuniones diarias

● Intentamos hacer mejoras pequeñas

– Médimos antes y después, para ver si la hipótesis es

correcta

– Eliminamos un cuello de botella (Automáticamente

aparecerá otro)



Para terminar

● Ventajas de Kanban
● Temas no cubiertos
● Bibliografía
● Herramientas software



Ventajas de Kanban

● Empieza donde estás. No especifica roles
● Fácil de implementar, low-tech & low-cost
● Fácil de cambiar

– (Pero resiste el impulso de cambiar al crear el

tablero: pon “lo que hay ahora”)

● Permite obtener métricas útiles sin demasiado

esfuerzo

● Mejora continua



Temas no cubiertos

● Clases de servicio
● Planificación y estimación
● Scrum + Kanban = Scrumban
● Análisis raiz-causa
● Retrospectivas
● Personal Kanban
● Seguramente un montón de cosas más...



Bibliografía

● Kanban. Successful Evolutionary

Change for Your Technology Bussiness

David J. Anderson

● Kanban in Action

Marcus Hammarberg and Joakim Sundén
● Kanban and Scrum - making the most

of both

Henrik Kniberg and Mattias Skarin



Herramientas software

● LeanKit Kanban (http://leankit.com)
● AgileZen (http://www.agilezen.com)
● Trello (https://trello.com)
● KanbanFlow (https://kanbanflow.com/)
● Kanbanize (http://kanbanize.com/)
● Kanbanery (https://kanbanery.com/)



Añadidos a otras herramientas

● JIRA Agile es la herramienta Kanban de Atlassian

para su sistema JIRA
– http://www.atlassian.com/software/jira/agile

● Team Foundation Service (TFS) de MS incluye

Kanban
– http://mng.bz/4vd0

● HuBoard es un sistema Kanban añadido al sistema

de gestión de tareas de GitHub
– http://huboard.com/



Gracias por su tiempo :-)

http://www.meetup.com/Agile-Canarias/



@Agile-Canarias