Kanban Implementation Guide SP 1.1

Español
KANBAN
IMPLEMENTATION
GUIDE
Guía de referencia rápida
LEO MRAK
www.pmenablers.com
Kanban Implementation Guide
Contenido
El Pensamiento Lean ........................................................................................................................... 3
El Valor en Lean ............................................................................................................................... 3
El Desperdicio en Lean .................................................................................................................... 4
Las 3 M’s de Lean ........................................................................................................................ 4
Lean en el Desarrollo de Software .................................................................................................. 5
Los 7 Desperdicios del Desarrollo de Software ........................................................................... 5
Los 7 Principios del Desarrollo de Software Lean ....................................................................... 6
Teoría de las Restricciones .................................................................................................................. 9
Manifiesto por el Desarrollo Ágil de Software .................................................................................... 9
Principios del Manifiesto Ágil ........................................................................................................ 10
Kanban............................................................................................................................................... 11
Kanban Manufacturing.................................................................................................................. 11
Kanban Virtual ............................................................................................................................... 11
Beneficios ...................................................................................................................................... 12
¿Por dónde empezar? ................................................................................................................... 12
Actividad 1 – Analizar nuestro proceso de desarrollo de software .......................................... 13
Modelar el Flujo de Valor ...................................................................................................... 13
Visualizar el Flujo de Valor .................................................................................................... 14
Definir Atributos de Tarjetas ................................................................................................. 15
Establecer Políticas de Uso del Tablero ................................................................................ 17
Actividad 2 - Establecer Clases de Servicio ............................................................................... 17
Actividad 3 - Establecer Políticas de Calidad ............................................................................. 19
Actividad 4 - Limitar el Trabajo en Progreso (WIP) ................................................................... 20
Recomendaciones al momento de establecer el WIP........................................................... 23
Actividad 5 - Preparar y priorizar el trabajo .............................................................................. 24
Actividad 6 – Planificar la Entrega ............................................................................................. 25
Actividad 7 – Establecer métricas ............................................................................................. 26
Tiempo de Ciclo ..................................................................................................................... 26
Diagrama de Flujo Acumulativo (CFD) .................................................................................. 28
Defect Rate ............................................................................................................................ 29
Otros Indicadores de utilidad ................................................................................................ 30
Actividad 8 – Administrar el Flujo ............................................................................................. 31
LEO MRAK 1
Actividad 9 – Establecer Niveles de Servicio ............................................................................. 32

Actividad 10 – Realizar Mejora Continua .................................................................................. 33
Conclusión ......................................................................................................................................... 35
Sobre el Autor ................................................................................................................................... 36
LEO MRAK 2
El Pensamiento Lean
Creemos que es de vital importancia revisar y entender tanto el Pensamiento Lean como la
Teoría de las Restricciones (ésta última la revisaremos más adelante), debido a que son los
pilares sobre los que emergió Kanban.
El Pensamiento Lean fue establecido por James P. Womack y Daniel T. Jones, quienes
utilizaron por primera vez la palabra Lean en su libro “La máquina que cambió el mundo”
relacionada al Sistema de Producción Toyota (Toyota Production System, TPS). Luego
surgiría el libro Pensamiento Lean donde se explayarían aún más sobre la filosofía.
Si quisiéramos resumir en dos palabras al Pensamiento Lean podríamos hablar
principalmente de Desperdicio y de Valor. A grandes rasgos podríamos decir que Lean se
enfoca en optimizar los tiempos (eliminando todos los Desperdicios) desde que una idea
se convierte en Valor para nuestros clientes.
El Valor en Lean
La definición del Valor es el primer principio del pensamiento Lean. Partiendo de que el
Valor debe ser creado por el fabricante en base a lo requerido por el cliente, debemos
reconocer por más que nos duela, que no es tarea fácil crear el valor de modo preciso.
Por lo tanto, el gran y primer reto al implementar las bases del Pensamiento Lean es lograr,
una definición lo más precisa posible del Valor que requieren nuestros clientes.
Esta definición deberá ser cíclica y evolutiva y todas las actividades que continúen deberán
supeditarse al “Valor” definido.
En la disciplina de ingeniería de software, el Valor cambia a una velocidad mayor que en
otras, los clientes lo van cambiando a medida que ven los incrementos del software
desarrollado y debemos estar preparados y tener procesos que nos permitan ser flexibles y
que posibiliten esta adecuación continua a los cambios del Valor.
Los cuatro principios siguientes del Pensamiento Lean son:
• El flujo de Valor: se refiere a establecer todas las partes que participan en el proceso
de construcción del producto, desde la concepción de la idea hasta la entrega al
cliente. Tanto las partes internas como externas deben ser identificadas y deben
cambiar su pensamiento para poder lograr una visualización integral de “todo” el
flujo. La transparencia interior de cada una de las partes es requerida.
Este paso es sumamente importante para identificar despilfarros de nuestro
proceso.
• Fluir: ¡necesitamos que nuestro proceso fluya! Para lograr esto, es importante dejar
de lado el pensamiento tradicional de producción por lotes y áreas, dado que
podemos ser mucho más eficientes si pensamos en un flujo continuo, evitando
tiempos de espera y colas en cada una de las etapas del proceso. Por lo tanto, es
LEO MRAK 3
importante que las empresas que implementen el pensamiento Lean se redefinan

para que cada una de las partes de su proceso permitan que el Valor fluya a través
de él y cada parte aporte lo necesario para lograrlo.
• Pull (atracción): en muchas empresas inician con la implementación de la filosofía
Lean, impulsando la transformación en una sola área, sin tener en cuenta lo crítico
que se vuelve la participación del resto de áreas que forman parte del flujo de valor.
Esto no solo impide el poder realizar una buena gestión del Flujo (como
comentábamos en el punto anterior) sino que también impide lograr la atracción
(pull) de productos o sus partes según las necesidades de nuestros clientes en lugar
de empujarlos (push) hacia ellos cuando no son necesarios.
• Perfección: al implementar los primeros 4 principios, las empresas comienzan a
experimentar elevadas disminuciones de: tiempos de ciclo, esfuerzo, espacio, costos
y fallos. Si sumamos a esto la transparencia obtenida al haber identificado el Flujo
de Valor y el feedback permanente sobre el impacto de los productos que se liberan,
se logra un terreno muy fértil para probar nuevos métodos de creación de Valor y
con esto hacer mejora continua, característica clave de Lean.
El Desperdicio en Lean
Las 3 M’s de Lean
El Sistema de Producción Toyota (TPS) contiene 3 conceptos claves surgidos de su modelo
3M.
Mura (desbalance): está relacionada con cualquier variabilidad causada por
irregularidades en el proceso. Es el enemigo número uno del flujo y su
existencia normalmente está relacionada a la presencia de los otros dos
enemigos Muri y Muda. Es decir que los tres están interrelacionados y deben
crearse estrategias que los ataquen simultáneamente.
En la disciplina de Desarrollo de Software, podríamos mencionar como ejemplos típicos a
picos de trabajo por imprevistos técnicos o debido a no utilizar buenas prácticas de
ingeniería, defectos detectados tardíamente en producción, etc.
Muri (sobrecarga): sucede cuando trabajamos a un ritmo por encima de la
capacidad de la línea de producción, provocando cansancio y/o ausentismo
del personal, y averías anticipadas de máquinas, lo que hace aumentar los
defectos. Todo esto genera normalmente cuellos de botellas.
En la disciplina de Desarrollo de Software, es la presión innecesaria sobre las personas, por
ejemplo, aquel héroe que todo equipo tiene, trabajar durante días hasta muy tarde,
depender de una sola persona para ciertos trabajos (ej. revisiones de arquitectura), entre
otros.
LEO MRAK 4
Muda (desperdicio): el utilizar recursos mayores a los necesarios (tiempo,

materiales, recursos humanos, etc.) o incluso no aprovechar al máximo el
talento de las personas, genera desperdicios.
En nuestra disciplina existen los 7 Desperdicios del Software, que revisaremos a detalle en
el siguiente punto.
Finalmente, la variación (Mura) es el principal enemigo del enfoque Lean, ésta provoca
sobrecargas (Muri) que desencadenan actividades que no aportan valor (Muda). Entonces
antes de enfocarnos en los desperdicios, debemos desarrollar un sistema de no Mura y
no Muri que vaya más allá de la observación de un sólo proceso o paso en particular, uno
que aplique un enfoque que contemple el flujo de valor completo.
Lean en el Desarrollo de Software

Los 7 Desperdicios del Desarrollo de Software
1. Trabajo parcialmente hecho: uno de los desperdicios más frecuentes. Por ejemplo,
análisis de requerimientos extensos y costosos que luego quedan sin codificar o el
caso inverso, documentos que no se actualizan a medida que el software evoluciona,
quedando obsoletos. Código sin probar, sin desplegar o ramas de código que llevan
meses sin fusionarse (merge) con el core de la aplicación, entre otros.
2. Características adicionales: desarrolladas por el equipo creyendo que le agregarán
valor al cliente o características solicitadas por las fuentes de requerimientos que
finalmente no se usan dado que ni siquiera se alinean con la visión del producto.
3. Reaprendizaje: este desperdicio también muy común dado el espíritu ermitaño que
algunos miembros de equipo tienen, se genera al no consultar posibles soluciones a
problemas con expertos u otros compañeros. Otro caso normal es el código mal
escrito o sin documentar que genera grandes volúmenes de reaprendizaje.
Finalmente, no puede quedar afuera la reasignación permanente de miembros de
equipos a nuevas funciones y las detecciones tardías de defectos, requiriendo más
tiempo al momento de quererlos solucionar.
4. Transferencia de conocimientos: el ciclo de vida cascada requería varias
transferencias, ya que los requerimientos comenzaban pasándose del usuario al
Project Manager o Analista y luego éstos eran transferidos hacia los roles de las
etapas subsiguientes. Esto requería de un gran número de transferencias y
considerando que el conocimiento se va perdiendo en cada transferencia (25%
queda después de dos transferencias) tenemos un gran desperdicio mientras más
intermediarios existan. Por lo tanto, es necesario disminuir el número de canales lo
más posible e inclusive aliviar el tiempo de transferencia utilizando técnicas de
documentación ligeras como, por ejemplo, documentar el código fuente, relacionar
la documentación funcional a la técnica, documentar script de pruebas que se
mantengan en el tiempo, etc.
5. Cambio de tarea: requerimos de tiempo para poder concentrarnos cada vez que
tomamos una nueva tarea a realizar (15 minutos aproximadamente), por lo cual
LEO MRAK 5
cada vez que cambiamos (switch) de tarea mínimamente necesitaremos de tiempo

para concentrarnos y luego comenzar a trabajar en ella. Este tiempo no solo se
necesita al cambiar de tarea sino al ser interrumpidos, si en un día llegamos a tener
32 interrupciones, ¡lo habremos perdido!
6. Retrasos: la mayor causa de este desperdicio son las esperas que muchas veces los
equipos tienen por gente que están fuera de él, por ejemplo, dependencias con
otras áreas. Por esto sugerimos a equipos que van a afrontar trabajos con
dependencias, que intenten incluir en él a todas las personas necesarias para
disminuir al máximo las mismas. Este desperdicio origina otros como trabajo parcial,
reaprendizaje y cambio de tareas.
7. Defectos: en los métodos Lean/Agile como, por ejemplo, Kanban, Scrum, XP, los
defectos pueden ser una causa que impacte directamente en el éxito o fracaso de
su implementación, más allá del impacto en la calidad y en los sobrecostes del
producto. En aquellos casos en que los equipos generan software de baja calidad
con grandes tasas de defectos, que son detectados recién cuando el software ya ha
sido liberado (y no tempranamente), el equipo tendrá que invertir mucho más
tiempo para solucionarlos, generando a su vez, un caos en el trabajo planificado y
generando una gran variabilidad en el proceso, logrando que cualquier método que
esté usando el equipo sea complicado de usar.
Los 7 Principios del Desarrollo de Software Lean

1. Eliminar el Desperdicio: como primer paso para poder eliminar el desperdicio,
necesitamos conocer aquellas cosas que agregan “Valor” a nuestro producto. Una
vez que tengamos en claro esto, podremos enfocarnos en todo aquello que no
agrega “valor” para eliminarlo.
En Lean Manufacturing, el inventario es un desperdicio, ya que requiere esfuerzos y
costos para moverlo, almacenarlo y rastrearlo. También produce obsolescencia de
productos y estanca el dinero.
En el Desarrollo de Software, el inventario es el trabajo parcialmente hecho, éste
padece los mismos problemas que el inventario en manufactura, solo que
virtualmente.
De todas maneras, el primer lugar de desperdicio en el software lo ocupa las
características adicionales. Tradicionalmente, los procesos de desarrollo contaban
con un proceso lento y tedioso de gestión de cambios, por el cual debía pasar todo
aquello que el cliente no hubiera solicitado al inicio. Esta situación generaba que los
clientes al comenzar los proyectos pidieran todo lo que necesitaban y aún más,
convirtiéndose en una de las causas más importantes de generación de
características adicionales.
Es por esto que necesitamos un mecanismo que nos permita desarrollar solo las
funcionalidades que nos den el mayor valor. Por lo tanto:
• Crear solamente requerimientos de valor (enfocar al cliente y equipo en los
requerimientos de mayor valor, no en “todos” los requerimientos).
• Escribir menos código (evitar desperdicio manteniendo código sin valor).
• Obtener código menos complejo.
LEO MRAK 6
2. Embeber calidad: como comentamos anteriormente, mientras más tardío sea el

momento en que se detecten los defectos, más desperdicio tendremos. Es por eso
que por más que contemos con un excelente proceso de detección de defectos y
gestión de ellos, mientras no hagamos nada por intentar anticiparnos a su
ocurrencia o solucionarlos apenas se produzcan (utilizando técnicas de testing como
por ejemplo testing estático, ATDD, BDD, TDD), no tendremos productos de calidad.
Actualmente existen técnicas que nos permiten mantener los defectos fuera del
código a medida que se va desarrollando.
Por ejemplo, en Test Driven Development (TDD) podemos escribir pruebas unitarias
y pruebas de aceptación antes de escribir el código asociado a ellas. Luego se
integran el código y las pruebas en el sistema tan seguido como sea posible y se
ejecutan los scripts de prueba para verificar que no se han introducido defectos. Si
las pruebas no pasan, no se agrega nuevo código hasta que el problema sea
solucionado o se retire el código que falla. De esta manera se logran disminuir
drásticamente las tasas de defectos como también el tiempo para encontrar la causa
de los defectos detectados.
3. Crear Conocimiento: partiendo de que el desarrollo de software es un proceso de
creación de conocimiento (Poppendieck, 2006) es necesario entender de que el
diseño general arquitectónico delineado al inicio del proyecto será validado a
medida que se escribe el código. Es decir que se detallará a medida que la
construcción avance debido a que no es posible establecer toda la complejidad del
trabajo por hacer hasta que se ejecute el trabajo.
Por otro lado, de nada sirve intentar presionar el trabajo para que se ajuste a un
diseño establecido, solo por el hecho de no cambiarlo, esto normalmente redunda
en la creación de productos que no soportan lo que realmente requiere nuestro
cliente.
Todos los equipos deben de contar con procesos que faciliten el aprendizaje y la
registración y consulta de él durante el ciclo de desarrollo. A la vez, estos procesos
deberán ser mejorados continuamente.
Cuando esto no sucede, nos encontramos con documentaciones obsoletas, sin
actualizar y que nadie ocupa.
4. Postergar Compromisos: necesitamos aprender a esperar para tomar decisiones,
dado que mientras más se espera mayor conocimiento sobre el dominio del
problema se tiene, esto no quiere decir que nos dejemos estar y se nos pase el
momento. En el mundo ágil existe una frase muy conocida que dice “toma las
decisiones lo más tardíamente responsable posible”. Necesitamos hacer posible que
la mayoría de las decisiones sean reversibles, para que luego puedan cambiarse
fácilmente. Es muy importante considerar esta propiedad de las decisiones debido
a que en desarrollo de software muchas veces tomamos decisiones al inicio que
luego no nos permiten cambiar. Por otro lado, necesitamos saber cuáles son las
decisiones que requieren de esta flexibilidad, ¡animémonos a crear decisiones
abiertas!
Algo que ayuda mucho es definir opciones para decisiones críticas, que nos permitan
ir probando cuales funcionan mejor.
LEO MRAK 7
5. Entregar rápido: en el desarrollo de software es todo un reto el poder liberar en el

menor tiempo posible. Esto nos permite volvernos más competitivos, tener un
feedback rápido de nuestros clientes, y reducir significativamente desperdicios del
proceso de desarrollo. Hay tres puntos que deberías considerar para lograr este
principio:
a. Dar pasos pequeños (liberar permanentemente)
b. Limitar el volumen de trabajo a la capacidad del equipo
c. Enfocarse en el tiempo de ciclo (tiempo que tarda el producto desde que
inicia su construcción hasta que se libera)
Actualmente DevOps permite contar con una serie de prácticas que hace que las
compañías liberen software en tiempos que antes eran impensables, ejemplo de
esto son compañías de servicio como Spotify, Facebook, Netflix, etc. Esto lo logra a
través de la implementación de métodos ágiles más la gestión automatizada de
repositorios, que facilita que muchas personas puedan trabajar en múltiples
funcionalidades simultáneamente evitando problemas al momento de la
integración de los incrementos.
6. Respetar a las personas: aquellas empresas que se permiten crear líderes de
excelencia crean equipos de excelencia, comprometidos y enfocados en la creación
de grandes productos. Para lograrlo mucho tiene que ver el mover la toma de
decisiones al nivel más bajo posible, dejando que los equipos analicen, propongan y
decidan por su cuenta. Claro que es necesario la formación permanente de los
líderes y sus miembros de equipo, sin recursos poco podrán hacer.
7. Optimizar el todo: la clave está en pensar en términos de flujo del producto final, es
decir desde que la solicitud se coloca hasta que sale el software construido. Al
centrarse en etapas particulares del proceso o en individuos, las decisiones que se
tomen impactarán no solo en la etapa o en el problema que requiere solucionar,
sino en el resto del flujo, produciendo variaciones en el proceso.
LEO MRAK 8
Teoría de las Restricciones

Este pilar es fundamental entenderlo debido a que como podrá ver más adelante, su uso en
el método es evidente.
La Teoría de las Restricciones (TOC) considera que en cualquier sistema representado por
una secuencia de pasos (flujo), su cadencia de producción será impactada por el “paso” más
lento, a esto se le llama Restricción y siempre existen en los sistemas de este tipo. Estas
restricciones se manifiestan como cuellos de botella.
Lo que propone la TOC para atender estas restricciones y mejorarlas, son los 5 pasos de
focalización.
1. Identificar la restricción: analizar donde se encuentra el cuello de botella en nuestro
sistema.
2. Explotar la restricción: este paso consiste en analizar el throughput esperado del
paso donde identificamos la restricción y el actual, para decidir en base a esto, las
actividades que deberíamos realizar para lograr el throughput deseado.
3. Subordinar todo a la restricción: implementar las actividades identificadas en el
paso anterior e inclusive cambiar otras partes del flujo para lograr el cambio
requerido.
4. Elevar la restricción: si una vez que ha subordinado todo a la restricción, seguimos
sin lograr el throughput necesario, entonces recién ahí aumente la capacidad del
paso que tiene la restricción, agregando recursos materiales y humanos, pero no lo
haga antes. Tenga cuidado, normalmente se tiende a evitar los pasos 2 y 3 y pasar
directamente al 4.
5. Evitar inercia: evite la ley de entropía que nos dice que todo en nuestro mundo
vuelve a su estado inicial y tiende a volverse cada vez más caótico, por esto no
pierda tiempo y vuelva a identificar la nueva restricción (recordemos que siempre
hay una) e inicie nuevamente el paso 2.
Manifiesto por el Desarrollo Ágil de Software

Creemos que es importante citar aún hoy, el manifiesto ágil ya que guarda una estrecha
relación con lo establecido por el Pensamiento Lean y porque ambos fueron la base de
todos los denominados métodos ágiles.
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia
experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a
valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
LEO MRAK 9
Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas
Principios del Manifiesto Ágil

1. Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y
continua de software valioso.
2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos
ágiles aprovechan el cambio como ventaja competitiva del cliente.
3. Entregue software funcionando con frecuencia, desde un par de semanas hasta un
par de meses, con preferencia en la escala de tiempo menor.
4. La gente de negocios y los desarrolladores deben trabajar juntos a diario durante
todo el proyecto.
5. Construir proyectos en torno a individuos motivados. Bríndeles el entorno y el
apoyo que necesitan, y confíe en ellos para hacer el trabajo.
6. El método más eficiente y efectivo para transmitir información a un equipo de
desarrollo y dentro de él, es la conversación cara a cara.
7. Software funcionando es la medida principal del progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deberían poder mantener un ritmo constante
indefinidamente.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos
autoorganizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego
afina y ajusta su comportamiento en consecuencia.
LEO MRAK 10
Kanban
Kanban Manufacturing
Es un método que se basa en el Sistema de Producción Toyota y su enfoque kaizen de
mejora continua.
El método permite limitar el trabajo en progreso. En base al throughput del proceso, se
establece una cierta cantidad de tarjetas (kanban en japonés) por fase y se van adhiriendo
a la parte del producto dependiendo de la fase por la que esté fluyendo en un determinado
momento. La parte podrá moverse de una fase a otra siempre y cuando exista una tarjeta
que pueda ser adherida a ella, sino deberá esperar en cola para continuar el flujo. Una vez
finalizado el trabajo se desprende la tarjeta que acompañaba la parte, permitiendo que una
nueva parte ingrese.
Es por esto último que a Kanban se lo denomina “sistema de arrastre” dado que el trabajo
es tomado únicamente cuando hay capacidad para poder atenderlo, esto permite que este
tipo de sistema no sea sobrecargado empujando nuevos trabajos que no puede atender.
Kanban Virtual
Al método Kanban aplicado al desarrollo de software se lo denomina Kanban Virtual. Este
método permite llevar la gestión visual del trabajo en progreso a través de un tablero sobre
el cual se establecen reglas, guías y tarjetas.
LEO MRAK 11
El nombre de Kanban Virtual surge debido a que las tarjetas no se adhieren a una parte
física del producto.
Una de las primeras descripciones del método fue realizada por David J. Anderson en su
libro “Kanban, Successful Evolutionary Change For Your Technology Business”,
convirtiéndose éste junto con el libro “Personal Kanban” de Jim Benson y Tonianne DeMaria
Barry en las bases más importantes para la promoción de Kanban a nivel mundial.
Beneficios
• Transparenta el estado del trabajo
• Fomenta la colaboración entre equipos y áreas externas
• Permite la mejora continua del proceso, se hacen muy visibles los problemas y el
impacto de las mejoras que se implementan
• En el mundo Agile, es uno de los métodos más adaptativos, que requiere muy
pocas reglas a seguir.
• Genera métricas simples de recolectar y analizar
• Genera continuamente software (valor para el cliente)
¿Por dónde empezar?

A continuación, trazamos una hoja de ruta como una alternativa a considerar en la
implementación de Kanban, si bien el orden está en base a la experiencia de los consultores
que han participado en este libro de bolsillo, podrían existir contextos y situaciones que
requirieran cambiarlo.
Lo que sí es importante tener en cuenta es que más allá de los ajustes que hagas a los pasos
dependiendo del contexto donde se implemente el método, no dejes fuera ninguna de
estas actividades dado que la ausencia de alguna de ellas podría impactar en los beneficios
que permite alcanzar Kanban o demorar su obtención.
LEO MRAK 12
Actividad 1 – Analizar nuestro proceso de desarrollo de software

Esta actividad se divide en las siguientes fases:
Modelar el Flujo de Valor
Si bien existen distintas técnicas para realizar este modelado, una de las más utilizadas en
Lean es el Mapa de Flujo de Valor (VSM).
Consiste en describir en cajas cada una de las fases actuales de tu flujo de entrega de
software. Es muy importante considerar todas las fases que abarca, no solo las del área de
desarrollo, sino desde que nace la necesidad hasta que se entrega a quien la solicita.
Los pasos para la construcción del mapa son:
1. Identificar el servicio o producto
2. Reunir un equipo de expertos con un fuerte conocimiento del proceso
3. Dibujar el mapa de flujo de valor del proceso actual, incluyendo todos los pasos,
retrasos y flujos de información requeridos para entregar el servicio o producto.
4. Evaluar el mapa y recopilar todos los datos que falten (por ejemplo, valor
agregado, tiempo de ciclo, etapas ocultas, etc.).
5. Calcular la Eficiencia del Ciclo = ∑Tiempo Valor Agregado / ∑ Tiempo Ciclo. Este
valor te permitirá establecer una línea base para poder comparar luego de un
tiempo si la eficiencia ha mejorado o no en base a las mejoras implementadas.
6.
Un error bastante común en empresas que tienen cierta madurez en mejora de procesos
es tomar la documentación de ellos y a partir de ésta realizar el modelado, ¡evita esto!
analiza el proceso real que lleva a cabo el equipo y no temas colocar lo que realmente
sucede, ya que cualquier cosa que dejemos fuera no nos permitirá realizar una buena
administración del flujo. Recuerda: no se puede administrar lo que no se puede ver…
Durante esta actividad muchos equipos caen en la tentación de cambiar el proceso debido
a que se empiezan a preguntar la intención de ciertos pasos o porque aprovechan para
LEO MRAK 13
colocar como les gustaría que se hicieran algunos, ¡evita esto también! No es el momento
aún.
Visualizar el Flujo de Valor
Ahora que hemos logrado entender como entregamos software, necesitamos plasmarlo en
un tablero para visualizarlo. Un control visual permite que los problemas no se oculten y
que la información esté disponible a cualquier persona.
Esto se puede lograr a través de una plataforma virtual o utilizando un tablero manual. Al
inicio, el uso de un tablero manual permite aumentar el nivel de colaboración de los equipos
y acelerar su madurez.
No existe un tablero básico sobre el cual empezar a trabajar, como vimos en el punto
anterior, deberás reflejar “todo” el flujo de trabajo que se realiza en el producto desde el
inicio y hasta su conclusión.
De todas maneras, seguramente contarás con columnas de actividad y de espera. Las
columnas de actividad son aquellas donde el trabajo es realizado y las de espera son donde
un trabajo espera para continuar su camino, luego hablaremos un poco más sobre éstas
últimas.
También deberás contemplar un carril para atender las urgencias (expeditos). Este tipo de
trabajo requiere un tratamiento especial, dado que normalmente consiste en situaciones
críticas que deben ser atendidas cuanto antes, es por eso que se asigna normalmente un
carril de nado que se puede colocar al inicio o a final del tablero, para poderlo visualizar de
la mejor manera posible y ayudar de esta forma a su seguimiento. El mejor ejemplo de este
tipo de trabajo son aquellos defectos bloqueantes que no permiten operar la aplicación
entre muchos otros.
Una situación común en muchas implementaciones del método es que utilizan este tipo de
trabajo para atender peticiones de clientes VIP. En la mayoría de los casos esta elección no
es buena ya que los equipos deberían de dejar de hacer lo que están haciendo para
atenderlas. Cuando se incluye en este tipo de trabajo a solicitudes de clientes VIP, comienza
a suceder que cada vez existen más clientes VIP y esto genera una gran cantidad de
expeditos generando un caos en el equipo.
LEO MRAK 14
Más allá que este paso parezca simple puede no serlo, muchas veces los equipos no quieren
representar la realidad en los tableros por miedo a que transparenten actividades que hoy
hacen, aunque sepan que no es bueno hacerlas. Evita esta situación haciéndolos sentir
seguros de que nadie saldrá lastimado con el ejercicio, reforzando la necesidad de
transparentar todas las actividades y comentando los beneficios que esto trae aparejado.
Esta actividad te permitirá:
• Visualizar todo el trabajo

• Ser transparente, todos saben lo que está sucediendo y no hay información oculta
• Identificar desperdicio.
Definir Atributos de Tarjetas
Una vez que hemos establecido nuestro tablero, necesitamos establecer la estructura que
tendrán las tarjetas que fluirán a través de él. En Kanban las tarjetas fluyen siempre hacia
adelante, nunca regresan en contra del flujo. Si un defecto se encuentra en la columna de
Test la tarjeta no se regresa a Development, sino que permanece hasta que se corrige y se
valida su corrección.
A continuación, listamos una serie de atributos básicos, aunque dependiendo el tipo de
servicio, las métricas que se requieran obtener y la plataforma de gestión utilizada, variarán.
LEO MRAK 15
• Id: permite identificar y dar trazabilidad al ítem.

• Tamaño: permite establecer la complejidad que tiene la construcción del ítem. Este
atributo permitirá definir los SLA’s.
• Descripción: narrativa que delimita el trabajo, solicitud o función a realizar. Debe ser
clara, representativa y sin ambigüedades.
• Notas: cualquier nota para aclarar lo que se debe de realizar.
• Fecha de Inicio: indica el momento en el que la tarjeta ingresó al sistema.
• Fecha de Fin: permite indicar el momento en el que la tarjeta salió del sistema. Estos
dos últimos atributos ayudan a calcular el tiempo de ciclo y medir SLA’s.
• Fecha de Inicio y Fin en atapas intermedias: esto ayuda a tener mayor granularidad
en las métricas que se obtengan.
En función del contexto del equipo, podría utilizar también la técnica de Historias de Usuario
para describir el trabajo, utilizando la sintaxis propuesta por la técnica para redactar la
descripción, y el atributo de criterios de aceptación para establecer las reglas de negocio
que debe de considerar el requerimiento. También puedes establecer diferentes atributos
asociados a la descripción (según el servicio que represente la tarjeta) para que el equipo
pueda actuar mas rápidamente en la detección de la fuente de un error, por ejemplo.
Ayuda el uso de stickers que marquen aquellos ítems que están bloqueados por alguna
razón, avatar para indicar quien tiene un ítem en un momento dado y todo lo que sea
necesario para que el tablero irradie la mayor cantidad de información posible a los
transeúntes.
LEO MRAK 16
Establecer Políticas de Uso del Tablero

Estás políticas entre otras cosas, deben establecer cómo se van a mover los ítems a través
del tablero. Deben estar visibles y consensuadas con el equipo y demás implicados.
Ejemplos de Política:
• El que soluciona un defecto es el mismo desarrollador que atendió el ítem (otra

opción podría ser que lo resuelva el primero que se desocupa y tenga capacidad).
• Multa de $XX a los que lleguen tarde a las dailys o falten sin aviso.
• El tablero debe estar actualizado en todo momento.
• Cada uno de los miembros del equipo podrá tomar una tarjeta nueva si el WIP lo
permite, NO SOBREPASAR el WIP.
• Los elementos siempre se mueven hacia adelante.
• Etc.
Actividad 2 - Establecer Clases de Servicio

Entendiendo que Kanban puede ser utilizado para visualizar el trabajo de equipos que llevan
a cabo diferentes trabajos (gestión de incidencias, mantenimiento evolutivo de
aplicaciones, desarrollo de aplicaciones nuevas, etc.) las clases de servicio podrán diferir de
un equipo a otro.
Pero ¿qué son las clases de servicio? Las clases de servicio establecen como serán tratados
en nuestro sistema los diferentes tipos de trabajo que realiza el equipo.
Es por eso que en este paso necesitas identificar antes que nada cada uno de los tipos de
trabajo que el equipo atiende para luego establecer como serán tratados.
Normalmente a cada clase de servicio se les da un color específico, esto ayuda mucho a
identificarlas claramente en el tablero, podríamos decir que el color preferido para las
expedito es el ¡rojo!
LEO MRAK 17
Así podríamos establecer clases para trabajos del tipo desarrollo (nuevo, cambio, consulta,
etc.), defectos (crítico, medio, leve, etc.), ingeniería (refactorización, tuning de base de
datos, configuración de herramientas, investigación, puesta en marcha de nuevas técnicas,
etc) y de muchos otros tipos de trabajo.
A modo de ejemplo listamos algunas muy utilizadas en gestión de solicitudes, aunque no
se deberían limitar a estas:
Clase Estándar Clase Prioritaria
• Tipos de trabajo: Bugs • Tipos de trabajo: bugs

cosméticos, historias de críticos, historias de usuarios
usuario de alta prioridad.
• Tratamiento especial: • Tratamiento especial: tiene
ninguno prioridad en cada etapa.
Clase de Fecha Fija Clase Expedito
• Tipos de trabajo: historias de • Tipos de trabajo: error

usuarios, bugs bloqueante
• Tratamiento especial: tiene • Tratamiento Especial:
prioridad en cada etapa si se romper límites WIP, dejar de
considera que corre riesgo la hacer lo que se esté
fecha compromiso, sino se haciendo y desplegar cuanto
trata como una estándar. antes.
Un ejemplo de la vida real:
Clase Apoyo para la Clasificación Tratamiento

Expedito • Defecto que bloquea la operación. Se coloca
• La aplicación completa o parte de ella inmediatamente en el
no se puede utilizar. tablero y se deja de
• La función o proceso principal no hacer lo que se está
funciona. haciendo para atenderla.
• No existe una solución inmediata que
pueda resolver el problema.
Prioritaria • Ítems que provienen de un cliente VIP Se agrega en lo más alto

• Una función principal o proceso está del Product Backlog.
siendo impactada. Se tomará cuando se
• La aplicación se puede utilizar, pero es desocupe un
muy restringida en realizar ciertas colaborador, sin dejar de
funciones. hacer lo que se está
• Un módulo no puede ser utilizado o no haciendo.
funciona correctamente.
LEO MRAK 18
Estándar • Nuevo requerimiento evolutivo a Se van atendiendo según

implementar. el orden en el que
• Defecto de severidad baja, cosmético. ingresan, los primeros en
• Una característica, función o proceso ingresar son los primeros
no está funcionando, pero el impacto en salir.
al negocio es menor.
• Normalmente una solución rápida es
identificable y fácil de aplicar.
Es muy importante en esta actividad establecer como se estimarán las clases de servicio,
utilizando alguna técnica que permita realizar estimaciones relativas como por ejemplo
Planning Poker o estableciendo su propia escala de complejidad (tamaño) que asociada a la
clase de servicio nos permita establecer un tiempo aproximado de entrega. Esto será la base
para establecer los SLA’s que revisaremos en la actividad 9.
Actividad 3 - Establecer Políticas de Calidad

En Lean la Calidad está presente desde el primer momento, en los 7 Desperdicios del
Software y/o en los 7 Principios del Desarrollo de Software Lean está referenciada, por solo
citar dos partes claves.
Su importancia requiere que se haga explicita, es decir que se especifique en nuestro
proceso lo que se va a hacer para poder generar productos de calidad, así como en Scrum
existe la Definición de Hecho (DoD) que de alguna manera debería reflejar las necesidades
de calidad que requiere la visión del producto, en Kanban requerimos tener una política de
Calidad explícita.
Si bien estas políticas de calidad deberían de estar basadas en diferentes factores que
existan en el contexto del equipo, nombraremos a continuación los factores más comunes:
Visión del producto: según la visión establecida para el producto, será necesario establecer
criterios de calidad que aseguren su cumplimiento.
Características contractuales del proyecto: multas, tolerancia a defectos, requisitos de
seguridad, requerimientos de continuidad del software, etc., son otros factores que
deberían tenerse en cuenta al momento de establecer las políticas a definir.
Aspectos Tecnológicos: las buenas prácticas de ingeniería utilizadas en la construcción del
producto, facilitará en mayor o en menor grado la implementación de más y mejores
políticas de calidad. Algunos ejemplos de éstos son el uso de plataformas de desarrollo
modernas, los métodos de testing utilizados, etc.
Las políticas pueden estar inherentes en algunas columnas del tablero del equipo, por
ejemplo columnas “Code Review”, “Test”, “User Validation”, etc. También pueden consistir
en el uso de técnicas modernas de desarrollo como ser, Peer Programming, Peer Reviews,
LEO MRAK 19
Fagan Inspection, etc. Además, el análisis colaborativo, el uso de plataformas modernas de

desarrollo que permiten análisis estático y dinámico de código, el uso de patrones de
diseño, el uso de Testing automatizado, el uso de prácticas propuestas por DevOps, etc.,
permiten asegurar la calidad de los productos. Estas son solo algunas formas con las que
podemos cumplir con el principio del desarrollo de software Lean, “Embeber Calidad”.
Inicialmente los equipos harán explícitas en políticas, las técnicas que utilizan y deberán ir
actualizándolas como parte de su evolución. Es importante que todos los miembros de
equipo estén de acuerdo con las políticas establecidas, éstas deberán estar consensuadas
por todos.
Actividad 4 - Limitar el Trabajo en Progreso (WIP)

El trabajo en progreso es el trabajo que ha ingresado a nuestro sistema y que aún no ha
salido, es la cantidad de ítems que el sistema tiene capacidad de atender en un momento
dado. Esto en un sistema Kanban Manufacturing está limitado por la cantidad de tarjetas,
como explicábamos al inicio.
En el Kanban Virtual, esta limitación está dada por un número que se coloca en las columnas
del tablero, como se muestra a continuación.
Para entender cómo impacta y la importancia que tiene el WIP en un sistema Kanban,
necesita entender la Ley de Little (Teoría de las Colas).
Lead Time = WIP / Throughput
Como se puede ver, Little estableció una relación entre el Lead Time, es decir el tiempo que
un ítem demora desde que entra a nuestro sistema hasta que sale, el WIP, o sea la cantidad
LEO MRAK 20
de ítems permitidos en el sistema y el Throughput del equipo, o sea el número de ítems que
salen del sistema en un tiempo dado (por ejemplo 10 ítems por semana).
Alguna de las conclusiones que fácilmente podríamos llegar al observar la fórmula son:
• Mientras más grande es el WIP, más grande será el Lead Time: lo que nos indica esta
primera conclusión es que antes de comenzar nuevos trabajos, culminemos el que
estamos atendiendo. Esto se relaciona con uno de los 7 Desperdicios del Desarrollo
de Software, Cambio de Tarea, como vimos anteriormente.
• Mientras más grande el Throughput, más pequeño es el Lead Time: para mejorar el
throughput del equipo, necesitamos mejorar nuestro proceso de producción. Lo
primero es quitar aquellas actividades que no agregan valor a nuestro proceso y
como ya hemos comentado anteriormente, entre las más comunes los defectos y
todas aquellas actividades orientadas a solucionarlos no son más que desperdicio,
es por eso la criticidad que tiene el establecer acciones concretas para intentar
evitarlos o generar la menor cantidad posible. Por otro lado, la mejora debe consistir
también en evolucionar actividades que agregan valor al producto.
Habiendo entendido lo anterior y teniéndolo en mente, comencemos hablando del WIP de
aquellas columnas del tipo Actividad. Estas son las columnas más críticas, ya que es donde
se realiza el trabajo como decíamos anteriormente. Podrías establecer WIP ajustados, esto
según Little y su fórmula nos permitiría disminuir el Lead Time, pero cuidado normalmente
cuando nosotros exageramos con límites muy pequeños, tenemos gente ociosa ya que no
tendrá trabajo para hacer hasta que los límites permitan ingresar más ítems al sistema.
Algunos autores hablan de una simple fórmula que establece el WIP como el producto entre
el número de personas que trabajan en la fase que se está analizando por 2 menos 1, así si
por ejemplo en la fase de Test participasen 3 personas, el WIP sería igual a 5 (3*2-1). Esta
forma permite cierta holgura para que casi todas las personas que colaboran en una fase
puedan trabajar en 2 ítems por si ocurriera una situación bloqueante en alguno de ellos.
Nosotros creemos que otra gran ventaja de ella radica en que vuelve simple algo complejo,
como lo es determinar este valor al inicio, luego con datos reales se deberán ir ajustando.
El WIP para aquellas columnas del tipo Espera es también bastante difícil de establecer al
inicio y para esto es necesario visualizar el flujo e ir ajustando estos WIP a medida que
logramos más conocimiento sobre como fluyen los ítems en nuestro sistema. Algo típico
que se suele hacer debido a esta complejidad, es agrupar el WIP de este tipo de columnas
con el WIP de su columna de Actividad, como se puede ver en la imagen anterior en la fase
de Design y sus columnas, In Progress y Done, el WIP está asignado a la fase y no a cada una
de sus columnas.
Normalmente cuando se utilizan WIP específicos para columnas del tipo Espera es para
aliviar cuellos de botella e intentar recuperar el ritmo sustentable. No temas utilizarlos con
cuidado, aunque este tipo de columnas agregará más trabajo en progreso (aumentaremos
el WIP del sistema) y atentará contra el Lead Time, debido a la relación expuesta por Little,
LEO MRAK 21
estas columnas suavizan el flujo y aumentan el throughput, entregando más cantidad de

trabajo en menos tiempo. No olvides que perseguimos un sistema lo más estable posible,
por lo tanto, anímate a experimentar con este tipo de columnas y pruebe WIP’s que eviten
en el mayor de los casos, cuellos de botella. Esto nos permitirá volvernos más predecibles
en nuestros compromisos de entrega, contando con sistemas con poca variabilidad.
Otra de las preguntas que debes hacerte en este paso es ¿Cuál debería ser el WIP para la
primera columna del sistema? (denominada muchas veces Product Backlog, Inbox,
Pendientes, Próximas, etc.). En este caso el conocimiento del Lead Time del equipo en
determinados lapsos de tiempo (por ejemplo semanal) nos permite determinar este valor,
para esto necesitaremos visualizar el flujo durante algún tiempo, recolectar métricas y
analizar si surgieron situaciones atípicas que pudieron haber generado situaciones
anormales (por ejemplo variación significativa en el tamaño de los ítems entre otras cosas).
Es por eso que estos valores como decíamos anteriormente se deberían estar ajustando
¡periódicamente!
Aclaremos con un ejemplo lo dicho: si el equipo tuviese una taza de entrega de 7 + - 2 ítems
por semana y la cadencia de priorización (entrega de ítems) por parte de la gente de negocio
fuese semanal, podríamos concluir fácilmente que se requerirá un WIP no menor a 9.
También podríamos establecer WIP por carriles de nado que represente cada uno una Clase
de Servicio. Para lograr esto, requerimos visualizar el sistema durante un tiempo y calcular
el % de demanda de cada uno de los servicios que pasan por el sistema. Esto podría quedar
como se muestra en la siguiente figura.
LEO MRAK 22
Podemos ver que de las Clase de Servicio Estándar recibimos una demanda del 60%, de las
Prioritarias un 30% y de las de Fecha Fija un 10%.
El carril de Expedito es muy importante que también tenga un WIP para limitar el trabajo
que ingresa por ahí, recordemos que estos ítems rompen los WIP’s de cada columna, es por
eso que se suele colocar +1 queriendo indicar que aumenta en 1 el WIP de la columna por
donde va pasando el ítem.
Como indica uno de los 7 Principios del Desarrollo de Software Lean “Optimizar el Todo”, es
importante que los valores del WIP para cada una de las fases surjan acordados por todas
las partes comprometidas, no solo de la fase que se está analizando, sino de las anteriores
y posteriores.
Es importante también consensuar estos valores con miembros externos, ya que estos
acuerdos sirven de mucho cuando las cosas se ponen cuesta arriba y los equipos comienzan
a tener presión desde afuera intentando que violen los WIP para ingresar mayor cantidad
de trabajo que la capacidad soportada por el sistema.
Recomendaciones al momento de establecer el WIP
Si bien no hay una única manera de establecer estos valores, lo mejor que podemos
recomendar es:
• Establezca un valor inicial, no deje columnas sin WIP
LEO MRAK 23
• Evite WIP igual a 1 (a excepción del carril Expedito), esto generaría sistemas
demasiados rígidos y personas ociosas por momentos
• Recuerde durante esta actividad y siempre la Ley de Little
• Evite WIP’s muy altos, dado que esto aumentará el Lead Time y por consiguiente los
ítems estarán más tiempo esperando ser atendidos.
• Observe cómo se comporta el sistema, para ajustar los WIP’s cuanto antes. No se
preocupe si esta necesidad de ajuste sucede apenas se inició con el sistema, estás
aprendiendo y madurando una nueva forma de administrar el trabajo.
Actividad 5 - Preparar y priorizar el trabajo

Este paso en muchos casos es subestimado, dedicarle el tiempo necesario para llevarlo a
cabo es fundamental y evitará darnos muchos golpes contra la pared una vez que comience
a ingresar trabajos al sistema.
Existen dos situaciones, una es que el equipo o gran parte de él ya venga trabajando y ya
tenga un Backlog de trabajo o la otra situación es cuando un equipo es nuevo y está por
comenzar a atender un servicio o a construir un producto.
Es obvio que la segunda situación hace las cosas un poco más fáciles, en este caso solo
necesitas establecer entre otras cosas, la periodicidad de las reuniones de priorización con
los involucrados de negocio, como serán estas sesiones, quienes deben asistir, la duración
y las condiciones que deben de cumplir las partes para asistir, por ejemplo llevar analizadas
las solicitudes o el próximo trabajo a agregar en el Backlog.
Respecto a la periodicidad, cuando estás iniciando con Kanban te recomendamos planificar
estas sesiones de priorización, luego podrás realizarlas “a demanda” pero para esto deberás
tener cierta madurez en el uso del método y en el conocimiento de tu sistema.
No dejes pasar mucho tiempo entre una sesión y otra, debido a que sería necesario
planificar más cosas y no tendríamos un feedback de negocio por largos periodos. Una
buena forma de empezar es con sesiones semanales, esto permite mantener el contacto
con los expertos en el producto, mantenerlos cerca e inclusive podría utilizarlas también
para mostrar un pequeño resumen de lo sucedido con las tarjetas desde la última vez que
se reunieron. Es muy importante considerar un tiempo lo más corto posible para ellas (hay
que evitar que la gente tenga excusas para faltar), sesiones de 1 hora suelen alcanzar,
siempre y cuando el facilitador evite distracciones con temas que no tienen que ver con el
objetivo de la sesión.
En el caso de que un equipo ya venga trabajando, a lo anterior debemos agregar (y esto es
muy importante y crítico) el ordenamiento del trabajo pendiente, el cual puede tener
cualquier forma o estructura y no necesariamente parecerse a un Backlog. Este es el
momento para hacer un análisis global de las solicitudes existentes y tamizar el Backlog para
generar una nueva versión de él. Algunas acciones que se deberán realizar entre otras son:
LEO MRAK 24
• Quitar solicitudes que llevan mucho tiempo sin atenderse y que ya no sean
requeridas
• Quitar aquellas solicitudes que nunca debieron ser registradas
• Re priorizar solicitudes que por el tiempo que ha pasado, sea necesario atenderlas
con otra prioridad
• Desglosar solicitudes de acuerdo a la granularidad necesaria para ingresar al sistema
• Categorizar solicitudes de acuerdo a lo establecido en la actividad 1 y 2 (asignar
Tamaño y Clase de Servicio)
Esta actividad será más simple o más compleja dependiendo de la sanidad que tenga la
descripción de las solicitudes existentes para el equipo.
Actividad 6 – Planificar la Entrega

Actualmente existen prácticas probadas y cada vez más maduras englobadas en DevOps
que permiten que las organizaciones lleguen a una cantidad de entregas con periodicidades
muy cortas. Esto se logra a través de la automatización de repositorios de código
distribuidos que permiten la integración continua del software como también la
automatización de liberaciones continuas.
Ahora bien, existen empresas que por los productos que ofrecen requieren realizar varias
entregas diarias y otras que no. Independientemente de esto, lo que todas necesitan es
bajar los costos de transacción y los costos de coordinación de las entregas, esto a través
de DevOps como complemento de cualquier método Lean/Agile, por ejemplo Kanban, se
puede lograr sin problemas.
Los costos de transacción son todos aquellos en lo que se incurre para poder distribuir y
liberar software desde el punto de vista técnico, mientras que los costos de coordinación
son aquellos en los que se incurre relacionados a la gestión de las liberaciones, horas
invertidas por los equipos en reuniones de planificación de la liberación y por lo tanto horas
que se dejan de invertir en la construcción, horas de managers y personas de soporte, etc.
En ciertos contextos el uso de DevOps con Kanban permite reducir a un mínimo los costos
de coordinación y transacción, pudiendo realizar entregas adhoc o a demanda sin
problemas y muy seguras.
De todas maneras, existen contextos donde las actividades de coordinación de áreas no
técnicas (marketing, comercial, financiero, etc.) pueden tener un costo elevado, a pesar de
contar con entregas automatizadas.
Por lo anterior y por más que Kanban desacopla las actividades de liberación y no las
engloba en un timebox, puede ser de mucho valor (siempre que sea posible) establecer lo
que normalmente se conoce como Cadencia de Entrega Regulares. Esta permite ordenar las
entregas, logrando que todos los interesados conozcan el momento en el que se estará
recibiendo software (Valor), creando certidumbre y permitiendo a todos planificar con
LEO MRAK 25
tiempo sus actividades en base a lo planeado. Lo anterior disminuye considerablemente los

costos de coordinación.
Actividad 7 – Establecer métricas

Llegado a este paso, ya tendrás un sistema con una serie de datos que te permitirá
comenzar a recolectar métricas.
Cuidado, las métricas no utilizadas se convertirán en desperdicio, entonces considera antes
que nada aquellas que en un inicio necesites para tomar decisiones o responder a preguntas
concretas sobre el funcionamiento del sistema. Por lo tanto, con un número reducido de
métricas analiza a medida que las utilizas si te siguen agregando valor y si no descártalas,
no tengas métricas sin usar. Finalmente genera métricas simples de calcular y recolectar y
trata en lo posible de tener un valor sobre el cual compararlas para que sea más fácil y
homogéneo su análisis.
A continuación, comentaremos una serie de métricas que son las más utilizadas en Kanban,
aunque te sugerimos no limitarte a estas.
Tiempo de Ciclo
Esta es quizás una de las métricas más utilizadas por los equipos que utilizan Kanban. Es
muy simple de calcular y nos permite establecer y dar seguimiento a los SLA’s.
Se calcula restando a la fecha de fin de una tarjeta la fecha de inicio, obteniendo de esta
manera el tiempo que la tarjeta tardó desde que entró hasta que salió del sistema.
Algunas recomendaciones:
• Diferencie el cálculo de este indicador por clase de servicio y por tamaño, sino
obtendrá valores con una gran dispersión entre ellos.
• Intente calcularla en horas, esto le dará mayor claridad (salvo que los trabajos que
ingresan sean siempre superiores a 1 día).
• Cuando tenga un sistema manual, no se olvide de revisar cada vez que ingresa o
finaliza un trabajo que esté completa la fecha de inicio y fin.
LEO MRAK 26
Como puede observar en la primera semana el promedio del tiempo de ciclo fue 4 horas
mientras que para la segunda semana fue de 3 horas. Este análisis debe hacerse
periódicamente, analizando tendencias y validando si el SLA que se está obteniendo se está
manteniendo dentro de un rango permitido por el SLA esperado.
Tomando esta métrica como base, se pueden calcular muchas otras, compartimos a
continuación algunos ejemplos:
Cycle Average Time

21:36:00
19:12:00
16:48:00
14:24:00
Very High
Hours
12:00:00
High
9:36:00
Medium
7:12:00
4:48:00 Low
2:24:00 Very Low

0:00:00
Expedite Priority Standard
Classes of Service
Esta gráfica modela el tiempo de ciclo promedio en un periodo concreto, haciendo una
diferenciación por tamaño y clase. Esta gráfica nos permite analizar si los tiempos por clase
de servicio y tamaño son coherentes, por ejemplo, el tiempo promedio de ciclo para la clase
Expedito Compleja no debería ser mayor al tiempo promedio de ciclo de la clase Expedito
Muy Compleja. El mismo análisis debería realizar entre clases, por ejemplo, los tiempos
promedios de la clase Expedito Muy Compleja no deberían ser mayores a los tiempos
promedio de la clase Prioritaria Muy Compleja.
LEO MRAK 27
SLA Compliance
Priority
Standard
Expedite
0% 20% 40% 60% 80% 100%
Lo que compara esta otra gráfica es el % de ítems del total que cumplieron con el SLA
esperado.
Te recomendamos que establezcas periodos de tiempo en los cuales calcular y hacer estos
análisis, por ejemplo, semanales. De esta manera, podrás analizar el estado de los SLA’s
para la última semana, revisando el desvío y las posibles causas de éste.
Esta métrica es muy importante en aquellas implementaciones con equipos de servicio o
soporte en los cuales el cumplimiento de SLA’s es crítico, más cuando forman parte de una
relación contractual con el cliente.
Diagrama de Flujo Acumulativo (CFD)
Este diagrama visualiza cuanto trabajo ha pasado a través de cada etapa de nuestro sistema
y la relación que ha habido entre ellas, permitiéndonos observar la magnitud de los cambios
sucedidos a través del tiempo.
Este diagrama, entre otras cosas, nos permite analizar cómo han impactado los ajustes que
hemos ido haciendo en los WIP’s en el tiempo.
LEO MRAK 28
Cumulative Flow Diagrams (CFD)

45
40
35
Next
30 Cycle Time
WIP 16
25 9 Design
Item
20 Development
15
Test
10
5 Deployed
0
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Day
Usted debería orientar su interpretación de la siguiente manera:
• La pendiente del área de Deployed representa la cantidad de ítems logrados en el

tiempo
• La distancia vertical entre el área Next y Deployed representa el WIP del sistema en
un momento dado (16 según el ejemplo)
• La distancia horizontal entre el área Deployed y Next, representa el tiempo de ciclo
logrado (9 según el ejemplo)
• Si la pendiente del área Next comienza a ser más pronunciada, podría deberse a que
se está permitiendo colocar más ítems de los soportados por el sistema.
Defect Rate
Como comentábamos anteriormente, los defectos son uno de los desperdicios más
importantes y comunes en el desarrollo de software, es por eso que necesitamos estar
pendientes de ellos para detectar proactivamente acciones ante tendencias poco
alentadoras.
A continuación, se muestra un ejemplo simple de modelado, donde muestra los nuevos
Bugs ingresados por día y los que se traían abiertos previamente. También podría decidir
realizar una gráfica por cada tipo de defecto.
LEO MRAK 29
Defect Rate
9
8
7
Bugs Quantity
6
5
4 Bugs
3 Open Bugs
2
1
0
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Day
Otros Indicadores de utilidad
Items by Service Class (weekly)

18
16
14
12
10
Items
8
6
4
2
-
Expedite Priority Standard Fixed Date
Service Class
Items by Category (weekly) Items by Service Class (weekly)

80 6%
60 14%
Items
Expedite
40
20 Priority
0
Incident Service Change Inquiry 46% Standard
34%
Request
Fixed Date
Category
LEO MRAK 30
Actividad 8 – Administrar el Flujo

Taiichi Ohno en una entrevista respondió a la pregunta ¿Qué está haciendo Toyota ahora?
“Todo lo que hacemos es mirar la línea de tiempo, desde el momento en que el cliente nos
da una orden al punto cuando recogemos el dinero en efectivo. Y estamos reduciendo esa
línea de tiempo mediante la eliminación de los residuos que no agregan valor”
A continuación, algunos puntos que deberán ser considerados:
• Revisar la calidad del tablero: el siguiente ejemplo muestra algunas situaciones

típicas que se dan cuando se comienza a utilizar el método. Claro que no son las
únicas, existen muchas más.
1. Existen 2 ítems en Expedite, lo que viola su propio WIP.

2. En la columna de Design falta un ítem para complementar el WIP.
LEO MRAK 31
3. La misma persona atiende los dos ítems del carril de expedite ¿Expedite tiene
prioridad realmente? Pareciera que no porque todo lo atiende la misma
persona.
4. La columna Done en Development tiene un cuello de botella
5. Un colaborador tiene muchos ítems en Test ¿es correcto?
6. Un colaborador trabaja en un ítem que está en la columna Deployed ¿Qué
es esto?
• Drenar los cuellos de botella: en Kanban se hacen muy evidentes los cuellos de
botella. Ante la presencia de uno, deberías drenar los procesos posteriores para
aliviarlo y recomponer de esta manera el ritmo sostenible del flujo. Algunas
opciones son:
o Buscar el trabajo innecesario que se hace en las etapas posteriores al cuello
de botella.
o Balancear el tamaño de los ítems que ingresan al sistema
o Limitar el WIP.
o Introducir una columna de tipo Espera delante del cuello de botella, esto
permitirá drenarlo.
• Optimizar el todo: forma parte de los “7 Principios del Desarrollo de Software Lean”
y es un gran reto para aquellos gerentes que se quedaron con técnicas del siglo
pasado y que siguen pensando en que la solución para muchos problemas de
productividad es utilizar la capacidad de los colaboradores al máximo posible,
inclusive sobrepasándola en ciertos momentos.
Lo que propone este punto es simple, al hacer ajustes en una etapa de su sistema,
no pierda de vista que este cambio repercutirá tanto en etapas anteriores como
posteriores a ella. Esto es uno de los pilares fundamentales de Lean y el hecho de
tenerlo siempre en cuenta, le permitirá sacarle el mayor provecho a Kanban.
• Revisar el Valor: como ya hemos comentado, el “valor” que entregamos a nuestros
clientes es de vital importancia, sin éste, todas las tareas de administración no
tendrán ningún sentido. Es importante que este principio de “valor” sea revisado
periódicamente, preguntándonos y preguntándoles a la gente de negocio si creen
que lo estamos logrando y buscando formas para medirlo e irlo ajustando para
adecuarlo a los cambios.
Actividad 9 – Establecer Niveles de Servicio

Muchas veces cuando preguntamos en organizaciones con centros de servicio ¿cómo
obtuvieron los SLA’s actuales? nadie sabe muy bien que responder, inclusive cuando
empezamos a escarbar un poco más y preguntamos, ¿Cuánto hace que no se actualizan
esos SLA’s? Desde el momento que se definieron, ¿el equipo se ha mantenido o ha
cambiado? ¿Cuál es el % de cumplimiento?, etc. la gente comienza a ponerse nerviosa.
Cuando existen compromisos de negocio que hacen referencia a estos indicadores y que
pueden penalizarnos al momento de no cumplirlos, esto se vuelve más crítico aún.
LEO MRAK 32
En Kanban en muy poco tiempo de uso, tendremos valores que nos permitirán definir SLA’s
según el throughput real del equipo y no basados en supuestos. Aparte de que su obtención
es sumamente sencilla.
Obviamente que estos niveles de servicio deberán estar definidos por clase de servicio y en
base a como se ha comportado hasta el momento cada una de ellas a través de su paso por
nuestro sistema. Para definir estos valores, se vuelve crítico el uso de la métrica Tiempo de
Ciclo y específicamente la gráfica Cumplimiento de SLA’s que comentamos en la actividad
de métricas.
Para este análisis podría utilizar el Control Estadístico de Procesos entre otros existentes. A
continuación, algunas conclusiones a las que podría arribar:
Clase Estándar Clase Prioritaria
• Promedio: 4 horas • Promedio: 3 horas

• Con una probabilidad del • Con una probabilidad del
95% entre 2 y 5 horas 95% entre 1 y 4 horas
• Todas dentro de 7 horas • Todas dentro de 6 horas
Clase de Fecha Fija Clase Expedito
• El 95% dentro de la fecha • Promedio: 2 horas

límite • Con una probabilidad del
95% entre 1 y 2 horas
• Todas dentro de 4 horas
Si tuviera una variabilidad importante entre el tamaño de los ítems podría realizar el mismo
análisis, pero considerando la escala de complejidad (tamaño), por ejemplo Muy Alta, Alta,
Media, Baja, Muy Baja.
Actividad 10 – Realizar Mejora Continua

Kanban impulsa la mejora continua y la hace mucho más evidente por ser un catalizador de
información extremadamente potente.
En Kanban se vuelven evidentes aquellas situaciones que requieren mejorar y si las mejoras
que se implementan están teniendo o no el impacto deseado. Recordemos que las mejoras
no son más que experimentos y por lo tanto existe incertidumbre sobre el impacto que ellas
tengan. En Kanban ese impacto se puede visualizar y obtener fácilmente dada la
información que el tablero irradia.
LEO MRAK 33
Eventos facilitadores de mejora continua son:
Reuniones No Reuniones Eventos Kaizen

Planeadas Diarias (retrospectivas)
Mejora Continua
Todos estos eventos permitirán a los equipos lograr implementar la cultura de mejora
continua y optimizar el uso del método, logrando resultados extraordinarios.
Una breve descripción de cada uno de ellos:
• Reuniones No Planeadas: permiten que cada vez que dos o más miembros del
equipo o gente externa y miembros del equipo detecten un problema, se reúnan en
sesiones rápidas (deben ser muy rápidas y efectivas) para establecer un plan de
acción e implementar una mejora para resolver una situación en particular.
• Reuniones Diarias: son reuniones diarias también muy rápidas (intente no superar
los 15 minutos) a la cual asisten solo los miembros del equipo con su administrador
y cada uno de ellos responde tres preguntas:
o ¿Que hizo desde la última reunión?
o ¿Qué hará hasta la próxima reunión?
o ¿Qué impedimentos no le permiten continuar con su trabajo?
Por su lado el administrador deberá informar sobre situaciones a tener en cuenta
para el nuevo periodo, por ejemplo, re-priorización de ítems, ingreso de un nuevo
ítem expedito, el estado sobre alguna tarea de su responsabilidad que involucre a
los miembros del equipo, etc.
• Eventos Kaizen (retrospectivas): estos eventos deben realizarse periódicamente y
como comentamos en los otros de manera muy rápida y efectiva, sino la gente
comienza a desmotivarse y a buscar excusas para faltar. Es importante que estén
presente todas las personas implicadas con el trabajo.
Dependiendo la periodicidad con que se lleve a cabo requerirá más o menos tiempo,
sugerimos no dejar pasar más de 4 semanas para realizarla. Respetando ese umbral
y según el contexto, establezca la periodicidad según lo crea necesario.
La técnica consiste en responder por parte de todos los participantes, las siguientes
preguntas:
LEO MRAK 34
o ¿Qué estamos haciendo bien?

o ¿Qué estamos haciendo mal?
o ¿Qué queremos mejorar?
Es sumamente importante que de este evento se obtenga un plan de acción con
responsables y fechas compromiso de cierre para cada una de ellas.
Conclusión
Aunque el uso de Kanban ha ido siempre en crecimiento, sigue siendo un método al que
otros le llevan mucha ventaja en cuanto a popularidad.
Nosotros intentamos poner con este pequeño aporte, nuestro granito de arena para
impulsar más su uso, debido a que los resultados que con él se obtienen son
extremadamente beneficiosos y a muy corto tiempo. Creemos que hay que hacer más y
mejores esfuerzos para que su entendimiento sea total y supere la creencia de que se trata
solo de un tablero con tarjetas.
Gracias por leer y animarse a entrar al fantástico mundo de Kanban, ¡disfruta sus
resultados!
LEO MRAK 35
Sobre el Autor
Leo Mrak, es un profesional con más de 22 años de experiencia en Proyectos de ingeniería
de Software, Mejora de Procesos y Agilidad Empresarial.
Ha pasado por diferentes roles, desde programador, DBA, responsable de áreas de testing,
project manager, gerente de oficina de proyectos, hasta consultor en mejora de procesos y
coach e instructor en agilidad empresarial.
Ha desempeñado proyectos para empresas como Frauen aus Allen Ländern, Ingenico Iberia,
Endesa Iberia, Edenred, Contpaqi, Everis, Indra, Truper, Cassidian, IDS, Honda, entre otras.
En los últimos años se ha especializado en el mentoring utilizando marcos y filosofías de
referencia como Lean/Agile, Domains Of Business Agility, Kanban, Scrum, Management 3.0,
Gestión del Cambio 3.0, PMBOK, CMMI for Services, CMMI for Development, ItiL, entre
muchos otros.
Ha desarrollado y dictado seminarios de Dirección de Proyectos tradicional (PMBok, CMMI)
y Ágil (Lean/Agile, Scrum, Kanban, XP, Gestión del Cambio 3.0). También participó en la
definición y construcción de plataformas de Dirección de Proyectos como Kanav y GudPlan.
Participó como docente y colaborador en la Fundación Arturo Rosenblueth.
Es co-fundador de la comunidad ágil Agile Collective (http://agile-collective.blogspot.mx/).
Se ha presentado en eventos y ha dictado webinars a nivel nacional e internacional. Cuenta
en su haber con varios artículos y técnicas utilizadas por empresas y universidades.
Cuenta con certificaciones como Project Management Professional (PMP), Scrum Master,
Kanban Professional, Lean-Agile Project Management e ITIL. También posee la certificación
como Scrum Master Instructor, Scrum Coach Accredited y Management 3.0 Foundation.
Es Analista de Sistemas de Información por la Universidad Tecnológica Nacional de Córdoba,
Argentina y posee un Master en Dirección y Administración de Empresas (MBA) por la
Universidad Complutense de Madrid.
LEO MRAK 36

Kanban Implementation Guide SP 1.1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Kanban Implementation Guide SP 1.1

Cargado por

Copyright:

Formatos disponibles

Español

Guía de referencia rápida

Actividad 9 – Establecer Niveles de Servicio ............................................................................. 32

importante que las empresas que implementen el pensamiento Lean se redefinan

Muda (desperdicio): el utilizar recursos mayores a los necesarios (tiempo,

Lean en el Desarrollo de Software

cada vez que cambiamos (switch) de tarea mínimamente necesitaremos de tiempo

Los 7 Principios del Desarrollo de Software Lean

2. Embeber calidad: como comentamos anteriormente, mientras más tardío sea el

5. Entregar rápido: en el desarrollo de software es todo un reto el poder liberar en el

Teoría de las Restricciones

Manifiesto por el Desarrollo Ágil de Software

Colaboración con el cliente sobre negociación contractual

Principios del Manifiesto Ágil

¿Por dónde empezar?

Actividad 1 – Analizar nuestro proceso de desarrollo de software

• Visualizar todo el trabajo

• Id: permite identificar y dar trazabilidad al ítem.

Establecer Políticas de Uso del Tablero

• El que soluciona un defecto es el mismo desarrollador que atendió el ítem (otra

Actividad 2 - Establecer Clases de Servicio

Clase Estándar Clase Prioritaria

• Tipos de trabajo: Bugs • Tipos de trabajo: bugs

Clase de Fecha Fija Clase Expedito

• Tipos de trabajo: historias de • Tipos de trabajo: error

Un ejemplo de la vida real:

Clase Apoyo para la Clasificación Tratamiento

Prioritaria • Ítems que provienen de un cliente VIP Se agrega en lo más alto

Estándar • Nuevo requerimiento evolutivo a Se van atendiendo según

Actividad 3 - Establecer Políticas de Calidad

Fagan Inspection, etc. Además, el análisis colaborativo, el uso de plataformas modernas de

Actividad 4 - Limitar el Trabajo en Progreso (WIP)

Lead Time = WIP / Throughput

estas columnas suavizan el flujo y aumentan el throughput, entregando más cantidad de

• Establezca un valor inicial, no deje columnas sin WIP

Actividad 5 - Preparar y priorizar el trabajo

Actividad 6 – Planificar la Entrega

tiempo sus actividades en base a lo planeado. Lo anterior disminuye considerablemente los

Actividad 7 – Establecer métricas

Cycle Average Time

2:24:00 Very Low

0% 20% 40% 60% 80% 100%

Cumulative Flow Diagrams (CFD)

Usted debería orientar su interpretación de la siguiente manera:

• La pendiente del área de Deployed representa la cantidad de ítems logrados en el

Otros Indicadores de utilidad

Items by Service Class (weekly)

Items by Category (weekly) Items by Service Class (weekly)

Actividad 8 – Administrar el Flujo

A continuación, algunos puntos que deberán ser considerados:

• Revisar la calidad del tablero: el siguiente ejemplo muestra algunas situaciones

1. Existen 2 ítems en Expedite, lo que viola su propio WIP.

Actividad 9 – Establecer Niveles de Servicio

Clase Estándar Clase Prioritaria

• Promedio: 4 horas • Promedio: 3 horas

Clase de Fecha Fija Clase Expedito

• El 95% dentro de la fecha • Promedio: 2 horas

Actividad 10 – Realizar Mejora Continua

Eventos facilitadores de mejora continua son:

Reuniones No Reuniones Eventos Kaizen

o ¿Qué estamos haciendo bien?

También podría gustarte