Kanban System Design
Cómo empezar con sistemas “Pull”
Certified Training
Entrenador (AKT):
Carlos Iván Gonzales
Arteaga
2 días
KMP I
Release 1.53
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Kanban Systems Design
How to get started with pull systems
All material in this document copyright © 2015 Lean Kanban, Inc.
Certified Training
Este material se distribuye solamente a los asistentes registrados de
las clases de entrenamiento de Lean Kanban Inc.
No se permite redistribuir este material ni utilizarlo en otras clases
o talleres de capacitación, con o sin cargo.
No está permitido reutilizar partes de este material de capacitación
en sus propias presentaciones o publicaciones sin permiso.
Si desea licenciar este material para su uso en sesiones de
capacitación, póngase en contacto con Lean Kanban Inc.
Correo electrónico: info@leankanban.com
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Día 1
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Introducción
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
leankanban.com
conf.leankanban.com
edu.leankanban.com
services.leankanban.com
Moviendo la conversación lejos de la “mejora del proceso” y hacia los
“marcos de gerencia y decisión”
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Esencia de la marca Lean Kanban
“Poder en la Simplicidad”
¡Guía pragmática y factible basada en
evidencia!
Algo que usted puede implementar el
próximo lunes
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2010 – Kanban “blue book”
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2014 Kanban desde adentro
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Roadmap de Entrenamientos Lean Kanban
Dominio de Kanban
Esta clase…
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
La curricula del Método Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
KMP I – Kanban Systems Design
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Significado de
Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Un sistema Kanban consiste de una
cantidad de tarjetas “kanban” (かん
ばん) en circulación
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Kanban tiene dos significados
Kanban tiene dos significados en japonés. Ambos significados
se incorporan al Método Kanban
Kanban escrito en Kanji (sinogramas utilizados en la escritura
japonesa) 看板 significa “señal” o “tablero visual grande”
Kanban escrito en alfabeto Japones, hiragana,
かんばん significa tarjeta(s)
En Chino, solo existe esta versión 看板. En Chino, kanban
literalmente significa “Mirando al tablero” (e interpreta
literalmente la historieta de la portada) pero el método está
actualmente inspirado por el sistema de tarjetas usado en
Japón.
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Definición del
Método Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban no es…
Un método de gestión de proyectos
o
Un proceso de ciclo de vida de desarrollo de
software
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban es…
Un método de gestión para…
• Mejorar directamente la prestación de
servicios
• Catalizar las mejoras
• Evolucionar el negocio para ser
“adecuado al propósito” (“fit for
purpose”)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban
Principios de la Entrega de Servicios
1. Entender las necesidades y expectativas de
tus clientes y focalizarse en ellas
2. Gestionar el trabajo: dejar que la gente se
auto-organice alrededor de las tareas.
3. Su organización es un ecosistema de
servicios interdependientes dirigido por sus
políticas. Reflexione regularmente sobre su
efectividad y evolucione las políticas para
mejorar los resultados hacia el cliente
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
“Ver” los Servicios
Aprenda a ver lo que usted hace ahora como un
conjunto de servicios (que pueden ser mejorados):
▪ Paradigma de Orientación al Servicio…
• El trabajo creativo y basado en el conocimiento es
orientado al servicio
• Los servicios tienen un solicitante que requiere un
producto o servicio y acepta o reconoce la entrega del
mismo terminado o en condición
• La entrega de servicios implica un flujo de trabajo
• El flujo de trabajo implica una serie de actividades de
“descubrimiento” de conocimiento
• La forma en que se trata una solicitud define su clase
de servicio
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban
Principios de Gestión del Cambio
1. Empezar con lo que estés haciendo ahora
❑ Entender los procesos actuales tal y como están siendo
realizados en la actualidad, y
❑ Respetar los roles actuales, las responsabilidades de
cada persona y los puestos de trabajo
2. Acordar en buscar la mejora a través del
cambio evolutivo
3. Fomentar el liderazgo en cada nivel de la
organización — desde las contribuciones
individuales de cada persona hasta las
posiciones más senior de la organización
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban usa…
… usa tableros kanban para visualizar el trabajo
invisible, el flujo de trabajo y los riesgos de negocio
junto con los sistemas kanban que limitan el trabajo
en progreso
El Método Kanban logra…
… Una prestación de servicios más rápida, más
predecible y una capacidad de adaptación que le
permite responder eficazmente a los cambios de la
demanda del cliente o de su entorno empresarial
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Método Kanban
Prácticas Generales
1. Visualizar (con un tablero kanban 看板)
2. Limitar el trabajo en-progreso (con kanban かんばん)
3. Gestionar el flujo
4. Hacer las políticas explicitas
5. Implementar ciclos de retroalimentación
6. Mejorar colaborativamente, evolucionar
experimentalmente (usando modelos & el método
científico)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Kanban en acción…
“Kanbanice” su proceso existente (no imponga un nuevo
proceso)
Kanban crea el ambiente adecuado para que las mejoras
afloren. Kanban provoca cambios en los procesos
actuales y mejoras a la entrega de servicios
Cada flujo de trabajo evolucionará como una solución de
proceso única, adaptada a su contexto
La satisfacción del cliente y del empleado mejorará
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
La Esencia de Kanban en Acción
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Usando un sistema kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Kanban se puede representar con ranuras
Ideas
Listo
Desarrollo
para
ingeniería En proceso Finalizado
J
K
M
P
L
O
Listo
para
Test
B
Pull
Pull
I
Q
G
Pull
F
D
PullLos post it en el tablero no son el
kanban. Creer que los post it son el
kanban es un error común
Pull
Ivan.gonzales@performance-dev.com
Testing
Official Licensed Material Copyright Lean Kanban Inc.
C
*
I
Acept.
Usuario
Listo
para
despliegue
Kanban se puede representar con ranuras
Ideas
Listo
Desarrollo
para
ingeniería En proceso Finalizado
J
K
M
P
L
O
Listo
para
Test
G
I
Q
Usuario
despliegue
B
Pull
Pull
Una ranura vacia
señala oportunidad
Listo
de pull para
Testing
Acept.
F
Pull
D
Pull
C
La ranura física es un
kanban
*
I
Pull
Este tablero y los dos siguientes parecen
diferentes, pero todos ellos visualizan el
mismo sistema kanban idéntico
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El uso de tokens como kanban es más flexible
Ideas
K
M
F
Listo
para
ingeniería
F
J
El token físico como un
G es un kanban
imán
N
O
J
F
Leyenda
Desarrollo
Listo
para
Test
Mover los elementos
terminados por debajo de
una línea es una mejora
opcional vista en algunas
implementaciones
En progreso
Finalizado
Los colores son
usados para denotar
Bloqueado - defecto estados
Bloqueado - problema
Ivan.gonzales@performance-dev.com
Listo
para
Acept.
Testing
Usuario despliegue
Cuando un item es
B bloqueado, se supera el
límite de TEP con el
item que lo solucionará
C
D
I
La gente que
trabajaba en el
item “A” han
sido
redireccionadas a
trabajar item “I”
El uso de ranuras físicas en el
ejemplo anterior ha demostrado
crear inercia a la modificación y
mejora
Official Licensed Material Copyright Lean Kanban Inc.
El uso de tokens movibles permite que
los límites TEP sean fácilmente
modificados y proporciona un
mecanismo
de señal natural
Listo
para
Ideas
Desarrollo
ingeniería
El uso de tokens como kanban es más flexible
K
M
F
F
J
El token físico como un
G es un kanban
imán
N
O
J
F
Leyenda
Listo
para
Test
Mover los elementos
terminados por debajo de
una línea es una mejora
opcional vista en algunas
implementaciones
En progreso
Finalizado
Los colores son
usados para denotar
Bloqueado - defecto estados
Bloqueado - problema
Ivan.gonzales@performance-dev.com
Listo
para
Acept.
Testing
Usuario despliegue
Cuando un item es
B bloqueado, se supera el
límite de TEP con el
item que lo solucionará
C
D
I
La gente que
trabajaba en el
item “A” han
sido
redireccionadas a
trabajar item “I”
El uso de ranuras físicas en el
ejemplo anterior ha demostrado
crear inercia a la modificación y
mejora
Official Licensed Material Copyright Lean Kanban Inc.
Declarar una cantidad kanban es aún más simple
Ideas
Listo
para
ingeniería
5
Desarrollo
These are the virtual
kanban
J
G
J
3
Acept.
Usuario
∞
Listo
para
despliegue
Estos límites TEP sirven como lo
B los imanes o ranuras
hacían
C
Pull
Estos Fson los kanban virtuales
D
*
I
Una señal pull de “kanban virtual”
es creada al mover un item de
una columna a otra
Ivan.gonzales@performance-dev.com
∞
Finalizado
Estos son los kanbanPull
virtuales
F
F
F F
F
F
Testing
5
3
En proceso
Listo
para
Test
Este tablero tiene menos
mantenimiento que el
tablero magnético
Official Licensed Material Copyright Lean Kanban Inc.
Los sistemas Kanban son sistemas “pull”
Ideas
Listo
para
ingeniería
Desarrollo
5
3
En proceso
Pull
K
M
F
N
F
5
J
3
Acept.
Usuario
∞
B
∞
Aquí hay capacidad
G
Pull
F
D
Ahora tenemos
capacidad para reponer
nuestro amortiguador
Ivan.gonzales@performance-dev.com
Testing
Listo
para
despliegue
Finalizado
Pull
J
O
Listo
para
Test
C
*
Jalar trabajo finalizado
de desarrollo creará
I
capacidad aquí también,
¡Las señales de pull se
mueven hacia arriba!
Official Licensed Material Copyright Lean Kanban Inc.
El compromiso es diferido
Ideas
Pull
FF
F
F F
F
F
Listo
para
ingeniería
5
Desarrollo
En proceso
D
3
Finalizado
Listo
para
Test
5
E
Testing
3
Acept.
Usuario
∞
G Se desea evitar “descarte” después del compromiso
Punto de Compromiso
Ivan.gonzales@performance-dev.com
I
Official Licensed Material Copyright Lean Kanban Inc.
Listo
para
despliegue
∞
El compromiso es diferido
Ideas
Pull
FF
F
F F
F
F
Listo
para
ingeniería
5
Desarrollo
En proceso
3
Finalizado
Listo
para
Test
5
Testing
3
Acept.
Usuario
∞
Las ideas siguen siendo
opcionales y (idealmente) no
priorizadas
D
E
G Se desea evitar “descarte” después del compromiso
Nosotros estamos comprometidos
a empezar. Tenemos la certeza
que queremos tomar la orden de
entrega
Punto de Compromiso
Ivan.gonzales@performance-dev.com
I
Official Licensed Material Copyright Lean Kanban Inc.
Listo
para
despliegue
∞
Las tasas de descarte suelen ser altas
Ideas
Listo
para
ingeniería
5
Desarrollo
En proceso
3
Finalizado
Listo
para
Test
5
Testing
3
Acept.
Usuario
∞
El % de descartes vista en un equipo
de Microsoft el 2004 fue del 48%.
~ 50% (se observa comúnmente)
FF
F
F
Rechazado
DLas opciones tienen valor porque el
futuro es incierto
G
Descartadas
W
Ivan.gonzales@performance-dev.com
E
0% de tasa de descarte significa que
no hay incertidumbre sobre el
futuro
I
Official Licensed Material Copyright Lean Kanban Inc.
Listo
para
despliegue
∞
Frecuencia de Reposición
Ideas
Listo
para
ingeniería
5
Reposición
Pull
FF
F
F F
F
F
Desarrollo
3
Listo
para
Test
5
Testing
3
Acept.
Usuario
Finalizado
La reposición
frecuente es
ágil.
En proceso
∞
La reposición bajo demanda
D
es más ágil!
E
G
Discarded
W
La frecuencia de reposición del
sistema debe reflejar una tasa
de llegada de nueva información
I
y los costos de transacción
y
coordinación de una reunión de
reposición.
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Listo
para
despliegue
∞
Frecuencia de Entrega
Ideas
Listo
para
ingeniería
5
Desarrollo
En proceso
3
Finalizado
Listo
para
Test
5
Testing
3
Acept.
Usuario
∞
La entrega frecuente es ágil.
Pull
FF
F
F F
F
F
tamaños de buffer de UAT y
¡La Los
entrega
bajo demanda es
Release se pueden reducir a
Dmedida
más
queágil!
aumenta la
G
Discarded
W
Ivan.gonzales@performance-dev.com
frecuencia de entrega
E
La frecuencia de entrega debe
reflejar los costos de transacción
y coordinación del despliegue
más los costos
y la tolerancia del
I
cliente para recibir la entrega
Official Licensed Material Copyright Lean Kanban Inc.
Listo
para
entrega
∞
Entrega
La fecha de entrega de un elemento puede ser
diferido hasta más tarde
Listo
Ideas
M
5
Desarrollo
En proceso
3
Finalizado
Listo
para
Test
5
Testing
3
Acept.
Usuario
F
L
N
Listo
para
ingeniería
F
J
K
Descartadas
W
Ivan.gonzales@performance-dev.com
∞
E
G
D
Ahora estamos
comprometiéndonos a una fecha
de lanzamiento específica
* Esto puede ocurrir antes si las
I
circunstancias lo exigenSegundo
Punto
Compromiso *
Official Licensed Material Copyright Lean Kanban Inc.
para
despliegue
∞
Definiendo el Lead Time del Sistema Kanban
Ideas
Pull
FF
F
F F
F
F
Listo
para
ingeniería
5
Desarrollo
En proceso
3
Finalizado
Listo
para
Test
Testing
5
3
Acept.
Usuario
∞
Listo
para
despliegue
∞
El reloj comienza a correr
cuando aceptamos la orden de
los clientes, no cuando se coloca!
D
G
Hasta entonces, las órdenes de
los clientes son simplemente
opciones disponibles
E
Lead Time del Sistema
Descartadas
W
Ivan.gonzales@performance-dev.com
I
Official Licensed Material Copyright Lean Kanban Inc.
El tiempo de
entrega del
sistema Kanban
termina cuando
el elemento
alcanza la
primera cola
∞ ilimitada
Ley de Little & Flujo acumulativo
Ratio de Entrega
(del sistema kanban)
Pool
de
ideas
Lead Time del Sistema
Prom. Lead Time
TEP
Ivan.gonzales@performance-dev.com
=
TEP
Listo
para
entrega
Prom. Tasa de Entrega
Official Licensed Material Copyright Lean Kanban Inc.
Definiendo Lead Time del Cliente
Pool
de
Ideas
Listo
para
ingeniería
5
Pull
FF
F
F F
F
F
Desarrollo
5
3
En proceso
Listo
para
Test
Testing
3
Acept.
Usuario
∞
Finalizado
El reloj todavía comienza a
correr cuando aceptamos la
orden de los clientes, no cuando
se coloca!
D
G
Descartadas
J
Ivan.gonzales@performance-dev.com
E
Customer Lead Time
LaFrequency
frequenciaofdebatch
la transferencia
transfers
de needs
lotes necesita
to be calculated
ser calculada
and y
añadida
added to
al Ilead
kanban
time
system
del sistema
lead
time
kanban
to calculate
para calcular
customer
el lead
lead
time del
timecliente
Official Licensed Material Copyright Lean Kanban Inc.
Listo
para
entrega
∞
Done
∞
Eficiencia del Flujo
Listo
para
Desarrollo
Ideas
ingeniería
La eficiencia de5 flujo mide el 3
porcentaje de tiempo total
que Finalizado
En proceso
se gasta en realidad agregando
valor (o conocimiento) versus
la espera
F
I
D
G
GY
PB
DE
Espera
Trabajo
Listo
para
Test
5
P1
E
Testing
3
∞
∞
La Multitarea eleva el tiempo de
espera en las columnas donde de
indica “Trabajo”
MN
AB
Espera
Lead
Espera
Trabajo
Time del Cliente
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012
** Hakan Forss, Lean Kanban France, Oct 2013
Ivan.gonzales@performance-dev.com
Acept.
Usuario
Listo
para
entrega
Official Licensed Material Copyright Lean Kanban Inc.
Trabajo
Espera
Eficiencia del Flujo
Ideas
Listo
para
ingeniería
5
Listo
para
Test
Desarrollo
En proceso
3
Finalizado
5
Testing
3
Acept.
Usuario
∞
Eficiencia % = Tiempo Trabajo x
de Flujo
Lead Time
F
D
G de 1-5% son
Eficiencias de Flujo
muy comunes. *, **PB
DE
> 40% es GY
bueno!
I
Espera
Trabajo
100%
E
MN
AB
Espera
Trabajo
Time del Cliente
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012
** Hakan Forss, Lean Kanban France, Oct 2013
Ivan.gonzales@performance-dev.com
∞
P1
Espera
Lead
Listo
para
entrega
Official Licensed Material Copyright Lean Kanban Inc.
Trabajo
Espera
Histograma del Lead Time
Lead Time Distribution
3.5
3
CRs & Bugs
2.5
2
1.5
1
0.5
14
8
14
1
13
4
12
7
12
0
11
3
99
10
6
92
85
78
71
64
57
50
43
36
29
22
8
15
1
0
Days
Expectativa de SLA de
105 días con 98 % de
probabilidad en tiempo
Promedio de
31 días
Expectativa de SLA de
44 días con 85 % de probabilidad en tiempo
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Métricas para Sistemas Kanban – Resumen
El flujo acumulativo integra la demanda, el TEP, el
tiempo de entrega promedio aproximado y las
capacidades de tasa de entrega
Los histogramas de tiempo de entrega nos muestran
la capacidad real de tiempo de entrega
También son útiles: Eficiencia de flujo; Calidad
(defectos que generarán futura “failure demand”); y
el impacto de los bloqueos
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Implementando un Sistema Kanban
¡No copie un sistema kanban existente!
Cada sistema debe ser diseñado usando el enfoque
de pensamiento sistémico para implementar kanban
(STATIK)
Estudie la demanda y los riesgos empresariales.
Capacidad de estudio. Diseñe un sistema kanban
apropiado para equilibrar la demanda con la
capacidad
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Beneficios de Sistemas Kanban …
Visibilidad
Se elimina la sobrecarga
Reduce o elimina el multi-tasking
Controla o elimina interrupciones, disruptivos
cambios de tarea y variabilidad
Lead times más cortos
Mejor calidad
Difiere el compromiso
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
…y los Resultados que produce
Mejora la previsibilidad
Mejora la agilidad de entrega de servicios
▪ selección y compromiso más frecuentes, entrega más
frecuente, plazos de entrega cortos
Mejora la gobernanza y la gestión de riesgos
Capacidad de adaptación
▪ la capacidad de evolucionar procesos y flujos de trabajo en
respuesta a un entorno externo cambiante
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Día 2
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
El Enfoque de Pensamiento en Sistemas para
Introducir Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
STATIK
(Systems Thinking Approach to Introducing Kanban)
[Enfoque de Pensamiento Sistemas para introducir Kanban]
El alcance de esta clase
Identificar Servicios. Para cada servicio…
1. Entender lo que hace que el servicio sea "apto para el
propósito"
2. Comprender las fuentes de insatisfacción con respecto
a la entrega actual
3. Analizar las fuentes y la naturaleza de la demanda
Este proceso
4. Analizar la capacidad de entrega actual
es iterativo
5. Modelar el flujo de trabajo de entrega de servicios
6. Identificar y definir clases de servicio
7. Diseñar el sistema kanban
8. Socializar el diseño y negociar la implementación
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Caso de Estudio
Microsoft XIT Sustaining Eng
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Caso de Estudio Microsoft 2004/2005
•
XIT uno de los 8 dptos. TI de Microsoft
• XIT Sustained Engineering
•
•
•
•
Equipo pequeño
Atiende solicitudes de Cambio
Brinda soporte a más de 80 aplicaciones (y creciendo)
Las responsabilidades de ingeniería se trasladaron de
Redmond (Washington, EE.UU.) a Hyderabad (India) el
2004
• Hyderabad es CMMI Nivel 5 y usa TSP/PSP
• La calidad inicial es muy alta
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Fuentes de Insatisfacción
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Fuentes de Insatisfacción
• Internas
• Constantemente interrumpido para hacer estimaciones
• Se espera que las estimaciones sean muy precisas y
“toman tiempo” que debería dedicarse a desarrollar
• No pueden esperar que conozcamos la base de datos y
el código de las más de 80 aplicaciones
• Los testers ocasionalmente son inundados por PTCs y no
pueden atender a los desarrolladores
• Externas
• Pequeñas solicitudes tardan meses en desarrollarse
• La entrega es completamente impredecible
• Constantemente rompen sus promesas
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
¿Qué servicio provee?
1. ¿Quiénes son sus clientes?
(U otras partes interesadas que usted debe servir como una autoridad reguladora)
2. ¿Qué le piden?
3. ¿Cuál es la naturaleza de la demanda?
(Tasa de llegada y patrón de llegada)
4. ¿Qué hace con esas peticiones?
5. ¿A dónde va el trabajo terminado?
6. ¿Cuáles son las expectativas del cliente?
7. ¿Cómo hace frente a esas expectativas?
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Modelo del Flujo de Trabajo
Tipo de Item de Trabajo
Punto de
Compromiso
PM
Manager Ing.
Llegadas no
comprometidas
Desarrolladores
Testers
Aceptación
Del Usuario
Fila Comprometida y
secuenciada
Peticiones
de Cambio
(CR)
Gerentes de
Producto
Backlog
Mandos medios
Ivan.gonzales@performance-dev.com
Promedio 155 Días
Capacidad
Una fuente clave
de "insatisfacción"
Official Licensed Material Copyright Lean Kanban Inc.
Capacidad de Entrega vs Demanda
Demanda Sustained Engineering Supply v Demand
PM
Manager Ing.
Desarrolladores
Peticiones
de Cambio
(CR)
90
80
Testers70
Aceptanción
Del Usuario
60
Change Requests
50
40
30
20
10
0
Jan-04
Apr-04
Capacidad
Jul-04
Quarters
Supply
Gerentes de
Producto
Backlog
Ivan.gonzales@performance-dev.com
Supply
Demand
La demanda está superando la
Promedio 155 Días
capacidad y la cola está
creciendo
Official Licensed Material Copyright Lean Kanban Inc.
Calculando Eficiencia del Flujo
◼
◼
◼
Los datos históricos
PM
Manager Ing.
recogidos
Peticiones durante 9 meses
De Cambios que una solicitud
Desarrolladores
mostraron
típica de cambio tardaba 5
días hábiles en procesarse a
través del desarrollo
El menor tiempo fue de 1 día
El mayor 15 días
El tiempo total de dev & test
fue de 11 días
25
20
Change Requests
◼
Aceptanción
Del Usuario
15
10
5
0
1 to 2 3 to 5
6 to 10
11 to
15
Dev
Test
> 15
Effort in Days
Eficiencia del Flujo es 11/155 = 8%
Gerentes de
Producto
Backlog
Ivan.gonzales@performance-dev.com
Promedio 155 Días
Official Licensed Material Copyright Lean Kanban Inc.
Demanda versus Capacidad
en un CFD historico
XIT SE Cumulative Flow
600
Demanda
Change Requests
500
El pico de TEP llegó a 144
CRs en diciembre 2003
400
CR opened
300
CR closed
Doble dotación
de personal
durante el
traspaso a la
India
200
Capacidad
100
0
Mar
03
Apr
03
May
03
Jun
03
Jul 03 Aug
03
Ivan.gonzales@performance-dev.com
Sep
03
Oct
03
Nov
03
Dec
03
Jan
04
Feb
04
Official Licensed Material Copyright Lean Kanban Inc.
Mar
04
Apr
04
May
04
Jun
04
La estimación es una fuente de insatisfacción
Tipo Item de
Trabajo
PM
Peticiones
de Cambio
(CR)
Manager Ing.
Desarrolladores
Testers
Aceptación
Del Usuario
Estiman
Estiman
Clase de Servicio
Las estimaciones son tratadas
Backlog
como un “tipo
de trabajo” con
una “clase de servicio” de mayor
prioridad que una “solicitud de
cambio” (CR)
Gerentes de
Producto
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Estimación es una fuente de insatisfacción
Tipo Item de
Trabajo
Abrir y leer el código
fuente
◼
Leer la guía de
Manager Ing.
aplicación
Desarrolladores
Testers
◼
Todo el proceso
Aceptación
Del Usuario
alrededor de 1 día por
Estiman
desarrollador y probador
Estiman
◼
PM
Peticiones
de Cambio
(CR)
Clase de Servicio
◼
Las estimaciones son tratadas
Backlog
como un “tipo
de trabajo” con
una “clase de servicio” de mayor
prioridad que una “solicitud de
cambio” (CR)
Gerentes de
Producto
Ivan.gonzales@performance-dev.com
◼
◼
SLA – 48 horas para
devolver estimación
aproximada de orden de
magnitud
Todas las solicitudes de
cambio son estimadas
Las estimaciones son
atendidas con máxima
prioridad debido al SLA
Official Licensed Material Copyright Lean Kanban Inc.
Análisis de la Demanda
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Demanda & Análisis de Capacidad
PM
Peticiones
de Cambio
(CR)
Manager Ing.
Desarrolladores
Testers
Aceptación
Del Usuario
Estiman
Estiman
La demanda para estimaciones son 20-25 por mes (o 1 en promedio cada
3 días por persona en el equipo)
Gerentes de
Backlog
Producto
◼
Las solicitudes de cambio programadas son sólo 12 por mes
(normalmente). La demanda de solicitudes de cambio es ~ 12 / mes
◼
Toda la demanda es estimada.
◼
La tasa de entrega de solicitudes de cambio es ~6 por mes. Solo ~50% de
la demanda se esta cumpliendo
◼
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Casi la mitad de las solicitudes fueron
abandonadas, descartadas o abortadas
PM
Manager Ing.
Desarrolladores
Peticiones
de Cambio
(CR)
Testers
Aceptanción
Del Usuario
Estiman
Estiman
◼
◼
Gerentes de
Producto
52% de las solicitudes son completadas
El otro 48%
◼
Backlog
◼
Ivan.gonzales@performance-dev.com
Descartadas
◼ Muy grandes (más grandes que 15 días)
◼ Muy caras (bajo valor versus costo)
Abandonadas
◼ Superado por eventos, p. Solicitud desmantelada
antes de procesar la solicitud
Official Licensed Material Copyright Lean Kanban Inc.
Pero espera, hay otro tipo de trabajo ...
PTC
PM
Manager Ing.
Desarrolladores
Peticiones
de Cambio
(CR)
Testers
Estiman
Estiman
◼
User Acceptance Test
Cambios de Textos en Producción
(PTC)
◼
Gerentes de
Producto
◼
Backlog
◼
◼
Ivan.gonzales@performance-dev.com
P.ej. Cambios gráficos, cambios de datos,
cualquier cosa que no requiera un desarrollador
Prioridad máxima
No requiere desarrollo
Pueden no verse por semanas o meses, de pronto
llegan todos en una explosión
◼
Fuerte indicación de la demanda estacional /
regulatoria y fecha de entrega fija
Official Licensed Material Copyright Lean Kanban Inc.
Pero espera, hay otro tipo de trabajo ...
PTC
Tipo Item de trabajo
PM
Manager Ing.
Diferente
workflow
Peticiones
Desarrolladores
Testers
Clase de Servicio
de Cambio
(CR)
Estiman
Estiman
PTCs son
disruptivas y el
trabajo de
desarrollo
puede
Gerentes
de
Backlog
Producto
acumularse e
incurrir en demoras
mientras testers
procesan PTCs
Ivan.gonzales@performance-dev.com
◼
User Acceptance Test
Cambios de Textos en Producción
◼
◼
◼
◼
Patrón de Demanda
P.ej. Cambios gráficos, cambios de datos,
cualquier cosa que no requiera un desarrollador
Prioridad máxima
No requiere desarrollo
Pueden no verse por semanas o meses, de pronto
llegan todos en una explosión
◼
Fuerte indicación de la demanda estacional /
regulatoria y fecha de entrega fija
Official Licensed Material Copyright Lean Kanban Inc.
Microsoft XIT Análisis de Demanda
Describir clientes y analizar la demanda
▪ Solicitudes de cambio, estimaciones y PTCs
▪ ~ 20-25 Estimaciones / mes
▪ ~ 12 Solicitudes de cambio / mes
▪ Ráfagas estacionales PTCs
Describa las Fuentes de Insatisfacción Interna
▪ Tasa de llegada PTC
▪ Constantemente interrumpido para hacer estimaciones
Describa las Fuentes de Insatisfacción del Cliente
▪ Lead time demasiado largo
▪ Totalmente impredecible
▪ Nada se entrega a tiempo
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
¡Espere!...???
▪ PTC significa Cambio de Texto de Producción
▪ Pero, los PTC son estacionales y llegan en ráfagas
▪ ¡Los PTC deben ser acelerados!
¡Algo está mal con esta imagen!
▪ Todo trabajo que sigue el mismo flujo ha sido
descrito como PTC para la conveniencia del
seguimiento electrónico!
¡Investigue!
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Análisis más profundo
Los Gerentes de Producto representan a 4 departamentos
▪ Finanzas
▪ Recursos Humanos
▪ Instalaciones
▪ Seguridad
PTCs incluyen …
▪ Actualizaciones de la tabla de impuestos para el sistema de nómina
▪ Tales solicitudes son de naturaleza estacional
▪ Actualizaciones de las aplicaciones de administración de instalaciones
▪ Tienden a alinearse con la entrega de nuevos edificios y proyectos de
construcción en el campus
Las actualizaciones de la tabla de impuestos llegan a finales de
septiembre con entrega de fecha fija a principios de enero
▪ “Expedito” es la clase de servicio incorrecta, pero los gerentes de
productos la demandan así porque el sistema presenta una capacidad
tan pobre
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Análisis de la Capacidad
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Recordar: Capacidad de entrega vs Demanda
Demanda Sustained Engineering Supply v Demand
PM
Manager Ing.
90
80
Desarrolladores
Peticiones
de Cambio
(CR)
Testers 70
User
Acceptance
60
Change Requests
50
40
30
20
10
0
Jan-04
Apr-04
Capacidad
Jul-04
Quarters
Supply
Gerentes de
Producto
Backlog
Ivan.gonzales@performance-dev.com
Supply
Demand
La demanda está superando la
Promedio 155 Días
capacidad y la cola está
creciendo
Official Licensed Material Copyright Lean Kanban Inc.
Recordar: Eficiencia de Flujo
◼
◼
◼
Los datos históricos
PM
recogidos durante
9 meses
Peticiones que una solicitud
mostraron
de Cambio
típica(CR)
de cambio tardaba 5
días hábiles en procesarse a
través del desarrollo
El menor tiempo fue de 1 día
El mayor 15 días
El tiempo total de dev & test
fue de 11 días
Manager Ing.
25
20
Change Requests
◼
15
10
5
0
1 to 2 3 to 5
6 to 10
11 to
15
Dev
Test
> 15
Effort in Days
User Acceptance Test
Eficiencia de Flujo 11/155 = 8%
Product
Managers
Backlog
Ivan.gonzales@performance-dev.com
Promedio 155 Días
Official Licensed Material Copyright Lean Kanban Inc.
Recordar: Demanda versus Capacidad
XIT SE Cumulative Flow
600
Demanda
Change Requests
500
El pico de TEP llegó a 144
CRs en diciembre 2003
400
CR opened
300
CR closed
Doble dotación
de personal
durante el
traspaso a la
India
200
Capacidad
100
0
Mar
03
Apr
03
May
03
Jun
03
Jul 03 Aug
03
Ivan.gonzales@performance-dev.com
Sep
03
Oct
03
Nov
03
Dec
03
Jan
04
Feb
04
Official Licensed Material Copyright Lean Kanban Inc.
Mar
04
Apr
04
May
04
Jun
04
Ejercicio – Análisis de Capacidad (homework)
Para cada tipo de trabajo recopilar
▪ Tasa de entrega en el tiempo
▪ Diagrama de lead time (control chart e histograma)
▪ Calcule la eficiencia del flujo
▪ Tasa de defectos
Análisis de Capacidad
▪ ¿Cuál es la dispersión de los plazos de entrega? ¿Hay clusters o
modas en la data?
▪ ¿Cuál es la tendencia? ¿La predictibilidad (dispersión de la
variación) mejora o disminuye (divergencia)?
▪ ¿Cuál es la dispersión de la variación en la eficiencia del flujo?
¿Proporciona esto evidencia de clases implícitas de servicio?
Demanda vs Capacidad
▪ Compare demanda vs capacidad: ¿Cuál es la brecha?
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Modelando el Flujo de Trabajo
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Recordar: ¿Qué servicio provee?
1. ¿Quiénes son sus clientes?
(U otras partes interesadas que usted debe servir como una autoridad reguladora)
2. ¿Qué le piden?
3. ¿Cuál es la naturaleza de la demanda?
(Tasa de llegada y patrón de llegada)
4. ¿Qué hace con esas peticiones?
5. ¿A dónde va el trabajo terminado?
6. ¿Cuáles son las expectativas del cliente?
7. ¿Cómo hace frente a esas expectativas?
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Recuerde: Modelo de Flujo de Trabajo
Tipo de Item de Trabajo
PM
Manager Ing.
Llegadas no
comprometidas
Desarrolladores
Testers
Aceptación
Del Usuario
Fila Comprometida y
secuenciada
Peticiones
de Cambio
(CR)
Gerentes de
Producto
Backlog
Mandos medios
Ivan.gonzales@performance-dev.com
Promedio 155 Días
Capacidad
Una fuente clave
de "insatisfacción"
Official Licensed Material Copyright Lean Kanban Inc.
Actualizando nuestro Modelo de Flujo de Trabajo
PTCs
- actualizar tasas
- etc
Manager Ing.
PM
Peticiones
de Cambio
(CR)
Desearrolladores
Acceptación
Usuario
Finanza
Comprometido
y Cola secuenciada
Uncommitted
Arrivals
HR
Instalaciones
Plan
Priorizado
Seguridad
Gerentes de
Producto
Testers
Backlogs
separados
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Elementos Clave del diseño de un Sistema Kanban
Tipos de trabajo
Estados del flujo de trabajo
Fuentes de variabilidad (que interrumpen los trabajos y compromisos
planeados) que se diseñarán durante la implementación inicial
Limitaciones de TEP y política de reposición de colas
Clases de Servicio
Puntos de compromiso *
Frecuencias de reabastecimiento y liberación
Visualización - diseño de tablero y del item
Métricas e informes *
Mecanismos de retroalimentación **
* Sólo cobertura genérica en esta clase, ** Incluido en Kanban Management Professional (KMP II)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
XIT Tipos de trabajo
• Peticiones de cambio (change request CR)
• PTC Cambio de Texto en Producción
• Las estimaciones se diseñarán afuera ya que son
una fuente de variabilidad e insatisfacción
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
PTC
Expedite
Manager Ing.
Buffer
Buffer
PM
Developers
Peticiones
de Cambio
(CR)
TEP = 5
Testers
Aceptación
Usuario
TEP = 5
Uncommitted Arrivals
Supermarket
TEP = 3
TEP = 3
Punto de
Compromiso
Gerentes
De Producto
30 Días o menos
Pool
de
Opciones
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Los mejores sistemas kanban organizan el trabajo,
no personas
Los estados del item de trabajo deben reflejar la actividad
dominante para descubrir Nuevo conocimiento en cada etapa
en el workflow
▪ e.g. análisis, diseño, testing, desarrollo, pruebas usuario, etc…
Los estados de los tipos de trabajo y sus transiciones tienden
a ser mucho más simples que la red de valor de traspasos
entre las personas que participan en la creación del trabajo
▪ e.g. Análisis y diseño aún continúan durante las actividades de
desarrollo o prueba. El trabajo aún se consideraría "en prueba",
aunque un analista puede haber sido requerido para proporcionar la
entrada o un desarrollador está obligado a corregir un defecto
¡Organizar el trabajo más que la
gente hace todo más sencillo!
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
PTC
Expedito
BufferManager Ing.
Buffer
PM
Developers
Peticiones
de Cambio
(CR)
TEP = 5
Testers
Aceptación
Usuario
TEP = 5
Uncommitted Arrivals
Supermarket
TEP = 3
TEP = 3
Punto de
Compromiso
Gerentes
De Producto
30 días o menos
Pool
de
Opciones
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseñando para fuentes de variabilidad
Estimaciones
▪ Estas serían reemplazadas con Service Level
Agreements
Planificar (y re-planificar)
▪ Esta sería reemplazada con reposición de cola
del sistema kanban
Tasa de llegada de PTC
▪ Esto será mitigado por el límite TEP del sistema
kanban y el reabastecimiento de la cola "justin-time" para solicitudes de cambio
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
PTC
Expedito
BufferManager Ing.
Buffer
PM
Desarroladores
Peticiones
de Cambio
(CR)
TEP = 5
Testers
Aceptación
Usuario
TEP = 5
Uncommitted Arrivals
Supermarket
TEP = 3
TEP = 3
Punto de
Compromiso
Gerentes
De Producto
30 Días o menos
Backlog
De
Opciones
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Determinar la expectativa de la
entrega de servicios
• Esfuerzo de ingeniería
• Un histograma del tiempo de ciclo local que muestra el desarrollo
y el esfuerzo de Test reveló que el tiempo promedio de ingeniería
era de 11 días con valores atípicos mayores a 24 días
• Estimación de la tasa de entrega
• Sin interrupciones de estimación, debería ser posible aumentar la
tasa de entrega a 10-12 por mes (~ 3 por semana)
• Estimaciones tiempo de cola y de búfer
• El tiempo de espera del búfer de entrada es probable que sea un
máximo de ~ 8 días basado en una tasa de rendimiento de ~ 3 por
semana
• El tiempo de búfer entre dev & test es probable que sea casi cero
excepto durante los tiempos de demanda de PTC
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
PTC
Expedito
Manager Ing.
PM
Peticiones
de Cambio
(CR)
Desarroladores
TEP = 5
Product
Managers
Testers
Aceptación
Usuario
TEP = 5
TEP = 3
Service Level
Expectation
(SLE)
TEP = 3
30 Días o menos
se ve razonable
Backlog
De
Opciones
Ivan.gonzales@performance-dev.com
~8 días
~6 días Normalmente ~6 días
Solo
Unos pocos
días
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
PTC
Expedito
Service Level
Expectation
(SLE)
Manager Ing.
PM
Desarroladores
Peticiones
de Cambio
(CR)
TEP = 5
Aceptación
Usuario
TEP = 5
TEP = 3
Product
Managers
Testers
TEP = 3
30 Días o menos
se ve razonable
Backlog
Of
Options
~6 días Normalmente ~6 días
Solo
Unos pocos
Este nivel de predictibilidad
sólo es alcanzable si
días
~8 días
limitamos el TEP en el sistema
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Clases de Servicio
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Clases de Servicio
• Tan Pronto como sea posible
• Transparencia total
• Limite TEP de 1
• PTCs
• Fecha de entrega fija
• Con un preaviso de 12 días
• CRs (Peticiones de servicio)
• Normalmente FIFO en cola
• Hasta 30 días
• 98% de garantía a tiempo
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
Es posible que
algunas PTCs no
sean urgentes?
PTC
Manager Ing.
Peticiones
de Cambio
(CR)
Developers
PM
TEP = 5
Aceptación
Usuario
TEP = 5
TEP = 3
Product
Managers
Testers
TEP = 3
30 días puede
Ser un riesgo
Backlog
de
Opciones
Ivan.gonzales@performance-dev.com
~8 días
~6 días Normalmente ~6 días
solo
unos pocos
días
Official Licensed Material Copyright Lean Kanban Inc.
Tiempo para Completar
UAT es desconocido
Una clase de service emerge
• Tan Pronto como sea posible
• Transparencia total
• Limite TEP de 1
• PTCs
• Fecha de entrega fija
• Con un preaviso de 12 días
• CRs (Peticiones de servicio)
• Normalmente FIFO en cola
• Hasta 30 días
• 98% de garantía a tiempo
• Cambios de Texto & Grafico (PTC workflow)
• Hasta 30 días
• 98% de garantía a tiempo
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Eventos Recurrentes
(y Cadencia)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Eventos Recurrentes
Eventos recurrentes generalmente deben ocurrir con
una frecuencia regular. La frecuencia específica es
una opción de diseño contextual
Elija las frecuencias para
▪ Reposición del sistema
▪ Entrega (o lanzamiento)
▪ Ciclos de retroalimentación
• Reunión standup
• Revisión de Entrega de Servicios
• Revisión de Operaciones
• …
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Bajo-demanda (On-demand)
Las organizaciones de menor madurez luchan con el
reabastecimiento bajo demanda. Ellos son ayudados por
eventos predecibles y programados regularmente
La reposición del sistema bajo demanda puede ser posible
cuando el esfuerzo de coordinación es bajo y los dueños de
negocios están (casi) instantáneamente disponibles
La entrega bajo demanda puede ser posible cuando la
tecnología de despliegue automatizado esté disponible y los
clientes hayan sido entrenados para recibir pequeños
incrementos con frecuencia
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Sistema Kanban
Semanal
PTC
Semanal
Manager Ing.
PM
Desarrolla
-dores
Peticiones
de Cambio
(CR)
TEP = 5
Backlog
de
Opciones
Ivan.gonzales@performance-dev.com
~8 días
Testers
Aceptación
Usuario
TEP = 5
TEP = 3
TEP = 6
(El sistema se detendrá en
aproximadamente 2 semanas si
no es servido)
~6 días Normalmente ~6 días
solo
unos pocos
días
30 días o menos suena razonable
TEP = 3
Product
Managers
Entrega
a demanda
Official Licensed Material Copyright Lean Kanban Inc.
Reposición del sistema
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Políticas de Reposición del sistema
En el ejemplo de XIT, los gerentes de producto acordaron un
mecanismo de reposición de colas redondeado ponderado
basado en la contribución del presupuesto para financiar al
equipo de ingeniería
Esto efectivamente introduce un límite de TEP por gerente de
producto (o departamento de cliente) en el sistema efectivamente una asignación de capacidad - esto es tanto
una estrategia de gestión de riesgos como una forma de
comunicar equidad y elevar el nivel de confianza en el sistema
Como la política se relaciona con "¿A quién le toca elegir
ahora?" No se consideró necesario visualizar esta política
dentro del diseño del consejo
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño del Ticket
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
información suficiente para tomar una buena
decisión de selección pull Decoraciones
(Forma & Color)
Color del ticket
Típicamente
para indicar los
riesgos técnicos
o de habilidades
Visualización
del riesgo
empresarial
destacada
en verde
req
complete
# Número
Título….
Checkboxes…
riesgo 1
riesgo 2
riesgo 3
riesgo 4
H
Inicio
dd/mm/yyyy
Fija
dd/mm/yyyy
Algunas veces se
utiliza para resaltar
dependencias
técnicas
(Letra)
Algunas veces se usa
para “artefactos de
un sistema” como
“prioridad”
Fin
Otros
Fechas
Algunas veces se usa
para registrar fechas
asociadas a estados
del workflow
Días transcurridos
Ivan.gonzales@performance-dev.com
SLA o
Objetivo (días)
Official Licensed Material Copyright Lean Kanban Inc.
Más Ejemplos de
Diseño de Tableros
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Carriles de Nado son usadas para separar tipos de
trabajo. Capacidad es fijada a cada carril
5
Capacidad
Fijada
Total = 20
4
4
Análisis
Cola
entrada En Prog Hecho
Desarrollo
Listo
En Prog Hecho Constr.
Peticiones
de cambio
12
Mantenimiento
2
Defectos
6
Ivan.gonzales@performance-dev.com
5
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
= 20 total
Listo
Entrega
Entregado
Actividades de Corta Vida
5
Capacidad
Fijada
Total = 20
4
4
Análisis
Cola
entrada En Prog Hecho
Desarrollo
Listo
En Prog Hecho Constr.
Peticiones
de cambio
12
Mantenimiento
2
Defectos
6
Ivan.gonzales@performance-dev.com
5
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
-+
Actividad de
Contrucción
“en la línea”
Listo
Entrega
Entregado
Por defecto, el color significa clase de servicio. Cubra el riesgo
con fijación de capacidad por color a través de toda la tabla
Seis opciones están disponibles porque
el búfer "Listo para la compilación" no
está lleno. Sin embargo, el búfer de
entrada no debe exceder de cinco
cuando se reponen
5
4
4
5
Análisis
Desarrollo
Buffer
Listo
entrada En Prog Hecho En Prog Hecho Compil.
2 = 20 total
Test
Listo
Release
...
Fijación/asign.
+1 = +5%
Se
permite
exceder
los límites
de TEP
Ivan.gonzales@performance-dev.com
4 = 20%
kanbans
libres
Official Licensed Material Copyright Lean Kanban Inc.
10 = 50%
6 = 30%
Tiempo en Proceso (TiP) visualizado con dots
5
4
4
5
Análisis
Desarrollo
Buffer
Listo
entrada En Prog Hecho En Prog Hecho Compil.
2 = 20 total
Test
Listo
Release
...
Fijación/asign.
Expedito
Fecha Fija
Estándar
Dots
Intangible
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Las políticas de criterios de pull fomentan un enfoque en
la calidad
5
4
Análisis
Buffer
entrada En Prog Hecho
3
4
2
Desarrollo
Listo
Listo
Desarr. En Prog Hecho Compil.
Políticas
~~~~~~
~~~~
Ivan.gonzales@performance-dev.com
Políticas
~~~~~~
~~~~
2
Test
Políticas
~~~~~~
~~~~
Official Licensed Material Copyright Lean Kanban Inc.
Listo
Release
Etapa
Políticas
~~~~~~
~~~~
Prod.
Bloqueo de problemas y defectos
5
4
8
2
Actividades Concurrentes
Análisis
Buffer
Listo
entrada En Prog Hecho
En Prog
Hecho Compil.
Bloqueo
Problema
(Issue)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Defecto
Listo
Release
...
Actividades Concurrentes Equipo Generalista
“Abrir columna para
actividades concurrentes”
5
4
8
2
Actividades Concurrentes
Análisis
Buffer
Listo
entrada En Prog Hecho
En Prog
Hecho Compil.
Avatars
muestran
quién
trabaja
en qué
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Listo
Release
...
Actividades no ordenadas múltiples, equipo Generalista
“Abrir columna para múltiples
Actividades no ordenadas”
5
4
8
2
Actividades no ordenadas
Análisis
Buffer
Listo
entrada En Prog Hecho
En Prog
Hecho Compil.
UI Design
Security
Persistence
Biz Logic
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Listo
Release
...
Actividades múltiples no ordenadas opcionales,
Generalistas
“Abrir la columna para multiples
actividades no ordenadas”
5
4
8
2
Actividades no ordenadas
Análisis
Buffer
Listo
entrada En Prog Hecho
En Prog
Hecho Compil.
Req Done
UI Design
Security
Persistence
Biz Logic
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Listo
Release
...
Activitidades Concurrentes, Equipos Especialistas
“Columna dividida para
actividades concurrentes”
5
2
4
4
2
4
Activitidades Concurrentes
Análisis
Desarrollo
Buffer
Listo
entrada En Prog Hecho
En Prog
Hecho Compil.
Combina
4
Separa
Test Desarrollo
En Prog
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Test
Listo
Release
...
Múltiples actividades no ordenadas, especialistas
“Dividir Columna para Multiples Activities
no ordenadas”
5
4
4
2
Actividades no ordenadas
Análisis
Buffer
En Prog
Hecho Listo
UI Design
entrada En Prog Hecho
Compil.
Seguridad
Persistencia
Lógica de
Negocio
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Listo
Release
...
Múltiples actividades no ordenadas, especialistas
“Dividir Columna para Multiples Activities
no ordenadas”
5
4
4
2
Actividades no ordenadas
Análisis
Buffer
En Prog
Hecho Listo
UI Design
entrada En Prog Hecho
Compil.
Seguridad
Persistencia
UI Design
Security
Persistence
Biz Logic
Ivan.gonzales@performance-dev.com
Lógica de
Negocio
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Listo
Release
...
Actividades múltiples no ordenadas opcionales,
especialistas
“Columna dividida para múltiples
actividades no ordenadas opcionales”
5
4
4
2
Actividades no ordenadas
Análisis
Buffer
En Prog
Hecho Listo
UI Design
entrada En Prog Hecho
Compil.
Seguridad
Req Done
UI Design
Security
Persistence
Biz Logic
Ivan.gonzales@performance-dev.com
Persistencia
Lógica de
Negocio
Official Licensed Material Copyright Lean Kanban Inc.
2
Test
Listo
Release
...
Múltiples Opcionales Actividades no ordenadas simultáneas
“Abrir columna para
múltiples actividades no
ordenadas”
5
8
4
Análisis
Buffer
entrada En Prog Hecho
En Prog
2
Hecho
Avatars
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Listo
Compil.
2
Test
Listo
Release
...
Demarcar área(s) de espera para dependencias
externas
5
4
3
Análisis
Buffer
entrada En Prog Hecho
4
2
Desarrollo
Listo
Listo
Desarr. En Prog Hecho Compil.
2
Test
Listo
Release
Esperando a
un grupo
externo
Dots denotan
tiempo
Ivan.gonzales@performance-dev.com
Tarde respecto a SLA
Official Licensed Material Copyright Lean Kanban Inc.
...
Carriles de nado para múltiples tipos
(diferente governance y workflow)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Actividad ascendente compartida (análisis de negocio) con división de
tickets para diferentes plataformas de destino, sin recombinación
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Proyecto principal con un tablero kanban de dos niveles usando
TEP = 5 carriles de nado para conjuntos de features
Los carriles de nado controlan el
limite de TEP– Requerimientos TEP
(verde) controlado por el número de
carriles
User Stories (yellow) solo limitado el
TEP en test. Test era un servicio
localizado fuera (Chennai, India)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Hacer las políticas explícitas. Mostrar Criterios de Pull arriba
Cinta de precisión
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Victorias
Recientes (para
retrospectiva)
Kanban Físico
Perdidas recientes
(para
retrospectiva)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Expectativa de
nivel de
servicio local
Diseño del Tablero Visual
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Diseño de ejemplo para XIT
5
3
Desarrollo
Cola
entrada En Prog Hecho
5
3
2
Listo
Test
Test
En Prog Hecho
Listo
UAT
PTCs
14
Petición
Cambio
22
Expedito
1
Expedito
Estándar
Ivan.gonzales@performance-dev.com
Fecha Fija
Official Licensed Material Copyright Lean Kanban Inc.
Intangible
4
UAT
= 22 total
Listo
Release
...
TEP limitado para flujo de
trabajo de entrega de servicio
completo
Diseño de ejemplo para XIT
Columnas para
estados de workflow
5
3
5
Carriles para tipos
de
trabajo
Desarrollo
Cola
Listo
entrada En Prog Hecho
Test
3
2
4
Color para clases de
servicio
Test
En Prog Hecho
Listo
UAT
PTCs
14
Petición
Cambio
22
Expedito
1
Expedito
Estándar
Ivan.gonzales@performance-dev.com
Fecha Fija
Official Licensed Material Copyright Lean Kanban Inc.
Intangible
UAT
= 22 total
Listo
Release
...
Revisando STATIK
(Systems Thinking Approach to Introducing Kanban)
[Enfoque de Pensamiento Sistemas para introducir Kanban]
Identificar Servicios. Para cada servicio…
1. Entender lo que hace que el servicio sea "apto para el
propósito"
2. Comprender las fuentes de insatisfacción con respecto
a la entrega actual
3. Analizar las fuentes y la naturaleza de la demanda
Este proceso
4. Analizar la capacidad de entrega actual
tiende a ser
iterativo
5. Modelar el flujo de trabajo de entrega de servicios
6. Identificar y definir clases de servicio
7. Diseñar el sistema kanban
8. Socializar el diseño y negociar la implementación
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Roadmap de Entrenamiento Lean Kanban
Su próxima clase…
Dominio de Kanban
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
KMP II – Kanban Management Professional
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Cadencias Kanban
Cambio
info
Revisión
Estrategica
Mensual
change
Trimetral
Hasta ESP III
Semanal
Revisión
de entrega
de Servicios
cambio
cambio
cambio
info
Mensual
info
Reunión
Kanban
info
info
cambio
info
Diario
Foco en la Entrega del Servicio
Ivan.gonzales@performance-dev.com
Revisión
de Riesgos
info
Quincenal
cambio
Reunión de
Fuera de Reabastecimiento
alcance
/ Compromiso
cambio
info
cambio
info
info
Revisión de
Operaciones
Impulsando las
Mejoras…
Official Licensed Material Copyright Lean Kanban Inc.
cambio
Reunión
Planificación
de Entregas
Por cadencia de entrega
Día 2 Reflexión – ¿Qué cambiará?
¿Qué hará diferente en su organización cuando
regrese a su oficina la próxima semana?
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Acerca
David Anderson es un
innovador en el pensamiento
gerencial para las empresas del
siglo XXI. Dirige una empresa de
formación, consultoría, eventos
y publicaciones haciendo nuevas
ideas accesibles a los directivos
de todo el mundo.
Davie tiene más de 30 años de experiencia en la industria de
alta tecnología comenzó con computer games a principios de
1980. Ha dirigido equipos de software que ofrecen
productividad y calidad superiores utilizando métodos
innovadores y ágiles en grandes empresas como Sprint y
Motorola.
David es el pionero del Método Kanban un enfoque ágil y
evolutivo para el cambio y Enterprise Service Planning. Él ha
escrito 3 libros incluyendo, Kanban - cambio evolutivo
exitosos para su negocio de la tecnología.
David es Presidente y CEO de Lean Kanban Inc., una empresa
global de formación en gestión, eventos y publicaciones
dedicada a ofrecer formación de gestión innovadora y de alta
calidad para empresas de servicios profesionales.
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Anexos
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Valores
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Ejercicio – Sistema de Valores de Kanban
Mapee los 3 principios fundamentales y 6 prácticas
básicas a los 9 valores
▪ Note: Incluye 1 principio que no ha visto antes
▪ Consejos: 3 practicas se mapean a 1 valor; 2 valores se mapean a 1
práctica
Reflexione:
▪ Escoja 3 valores que resuenen con usted personalmente
▪ Elija 3 valores que parezcan importantes o desafiantes en
su contexto organizacional actual
▪ Para cada una de estas dos categorías, elijan un top 3
para el equipo y prepárese para compartirlo
¿Cómo organizar los valores visualmente?
▪ Vea algunos diseños posibles en las láminas finales, si se queda
bloqueado
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Principios Fundamentales
(un único valor por espacio)
__________: Comiencen con lo que hace ahora
__________: Inicialmente, respeten roles existentes,
responsabilidades y puestos
__________: Convienen adoptar el cambio evolutivo
__________: Fomentar actos de liderazgo a todo
nivel en su organización – desde
contribuciones individuales hasta top
management
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Prácticas Core (principales)
(un valor por espacio; un valor se usa tres veces)
__________: Visualizar
__________: Limitar el trabajo en progreso (TEP)
__________, __________: Administrar el flujo
__________: Hacer explícitas las políticas
__________: Implementar ciclos de retroalimentación
__________: Mejorar colaborativamente, evolucionar
experimentalmente (usando modelos &
el método científico)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Valores
(en ningún orden particular)
Transparencia
Balance
Acuerdo
Respeto
Comprensión
Liderazgo
Colaboración
Enfoque en el
Cliente
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Flujo
Posible Presentación Diseño 1
 __________
 __________
 __________
 __________
 __________
 __________
 __________
 __________
 __________
(Bonus: sugiera nombres para las capas)
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Posible Presentación Diseño 2
“La Casa de Kanban”
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.
Ivan.gonzales@performance-dev.com
Official Licensed Material Copyright Lean Kanban Inc.