gestión visual kanban · 1. crear constancia en la mejora de productos y servicios, con el...

Gestión visual kanban Rev. 1.2

http://www.scrummanager.net/oks

Scrum Manager Proyectos

Apuntes de formación

Tema: Gestión visual kanban

V. 1.2.1 Julio - 2012

Juan Palacio Claudia Ruata

Información de derechos y licencia de uso: http://www.safecreative.org/work/1207101946476 Más información: http://www.scrummanager.net/oks

http://www.safecreative.org/work/1207101946476

http://www.scrummanager.net/oks

http://www.safecreative.org/work/1207101946476

2005-2012 – ScrumManager - http://www.scrummanager.net

Contenido

Contenido 4

Prólogo 5

Apuntes de formación Scrum Manager 7 Plataforma abierta para consulta y formación profesional Scrum Manager 7

Kanban herramienta lean para control visual 9

I: Producción Lean 11 División del trabajo 11 Organización científica del trabajo 11 Producción en cadena 11 Sistema de producción Toyota 11

Calidad total 12

Preferimos conceptos a metodologías 13 Concepto 1: Gestión de proyectos predictiva e incremental 13 Concepto 2: Ingeniería concurrente y agilidad. 13 Concepto 3: Incremento iterativo o continuo. 14

Preferimos una herramienta kanban a un método kanban. 14

Kanban herramienta ágil de control visual 17

¿Gestión visual? 19 Kanban también es herramienta útil para la gestión ágil. 19

Fortalezas de Kanban 20 Información 20

Favorece la comunicación directa 20

Detección temprana de problemas 20

Favorece una cultura de colaboración y resolución. 21

Gestión / Control 21

Monitorización y regulación del flujo, y la carga de trabajo 21

Genera un flujo de trabajo que lleva los problemas a la superficie 21

Facilita un ritmo sostenido y evita la ley de Parkinson 21

Produce incremento continuo 21

Monitorización y regulación de “Mura” y “Muri” 22

Ejemplos de uso 24 Información: 24 Información + autogestión 25

Kanban Box 25

Resumen 27

NOTAS 29

Prólogo

Prólogo

2008 – 2005-2012 – ScrumManager - http://www.scrummanager.net 7

Apuntes de formación Scrum Manager Este es un recurso educativo abierto (OER) y forma parte de la plataforma Scrum Manager Open Knowledge. Son los apuntes del curso abierto: Gestión Visual Kanban, disponible en http://scrummanager.net/oks/ Se puede emplear de forma gratuita para consulta y auto-formación a título personal.

Plataforma abierta para consulta y formación profesional Scrum Manager Scrum Manager Open Knowledge es una plataforma de acceso libre para consulta y formación, está disponible en http://scrummanager.net/oks/ donde encontrarás la última versión de este curso, además de otros materiales, foros, talleres, etc. Un punto abierto en la Red para consultar y compartir conocimiento, y mantenerte profesionalmente actualizado. Más información: http://www.scrummanager.net http://www.scrummanager.net/oks [email protected]

http://scrummanager.net/oks/

http://scrummanager.net/oks/

Kanban herramienta lean para control visual

11 2005-2012 – ScrumManager - http://www.scrummanager.net

I: Producción Lean

División del trabajo “La riqueza de las naciones” es la obra más célebre de Adam Smith. Fue publicada en 1776 y se considera el primer libro moderno de eco-nomía. En él desarrolla la teoría económica sobre la división del trabajo. Para Smith el principal factor para mejorar la productividad del trabajo es su división, que ilustró en su célebre ejemplo de la manufactura de alfileres, en el que comparaba la producción que puede alcanzar un herrero realizando todas las tareas necesarias, con la obtenida en un sistema con división del trabajo entre obreros especializados en cada tipo de tarea (estirado del alambre, cortado, afilado, etc.). Como demostró, la división del trabajo hace posible producir 5.000 alfileres diarios por obrero, frente a los 50 que produciría un artesano.

Organización científica del trabajo Frederick W. Taylor fue el primero en analizar y estudió el trabajo de forma sistemática. Taylorismo es el nombre dado al método de producción que incorpora su conocimiento, para aumentar la productividad. Al taylorismo se le denomina también “organi-zación científica del trabajo” o “gestión científica del trabajo” por aplicar principios básicos del método científico en el diseño de los procesos de trabajo. Taylor expuso su sistema de organización racio-nal del trabajo en su obra “Principles of Scientific Management” (1912) que de forma somera se puede condensar en cuatro principios:

Reemplazar los métodos artesanales por métodos basados en el análisis científico del trabajo.

Seleccionar y formar a los empleados con criterios científicos, en lugar de dejar que aprendan de forma autónoma.

Dividir el trabajo en gestión y trabajo, de forma que los gestores puedan gestionar los princi-pios de planificación y ejecución del trabajo.

Proporcionar instrucciones y supervisión deta-llada a cada trabajador.

Producción en cadena La producción en cadena, también denominada fordismo, es el sistema de producción desarro-llado por el fabricante de automóviles Henry Ford para la fabricación de los primeros automóviles de su factoría en la primera década del siglo XX. Pone en práctica los principios de la división y la organización científica del trabajo, y ha sido ampliamente utilizado para la producción indus-trial hasta que en la década de los 70 comenzó a ser reemplazada por el toyotismo. El fordismo hizo posible: Reducción significativa del coste de produc-

ción (El Ford T que valía $850 en 1908 cuando se empezó a producir, se vendía a $250 en 1927)

Flujo constante de la producción. Ingeniería de procesos: la calidad del resulta-

do depende de la calidad del proceso emple-ado en su fabricación.

Sistema de producción Toyota El fundador de Toyota, Sakichi Toyoda, su hijo Kiichiro Yotoda y el ingeniero Taiichi Ohno, comenzaron a evolucionar los sistemas de producción de sus factorías transformando el fordismo hasta llegar a principios de los 70 en lo que acabaría siendo y denominándose “Sistema de Producción Toyota” o toyotismo. Cuando intentaron importar los sistemas de producción masiva americanos, para rehacer su industria tras la segunda guerra mundial, se dieron cuenta de que el fordismo no les valía, porque creaba empresas para producir grandes cantidades del mismo producto, pero no servía para producir pequeñas cantidades de productos diferentes. El sistema fordista generaba muchas existencias del producto que acababa con sobreproducción y almacenes llenos por falta de clientes. Necesitaban un sistema que produjera con costes reducidos, pero no a costa de incrementar la producción, puesto que no tenían gran demanda.

Gestión Visual Kanban


Estas circunstancias evolucionaron la producción fordista hacia un sistema que elimina las exis-tencias del proceso de producción y el “sobre-efectivo” tanto de personal como de equipo para lograr la fábrica mínima, capaz de producir lo necesario: lo que un cliente está esperando. El sistema fordista es un sistema de empuje, (“push”) mientras que el toyotismo es un sistema de arrastre (“pull”). En el fordismo cada puesto empuja continua-mente al siguiente, enviándole trabajo de forma sistemática. Sobre la estimación de consumo, se pone en marcha la cadena y se produce al ritmo previsto. El toyotismo es un sistema de arrastre: un puesto no empuja al siguiente sino que tira del anterior, pidiéndole trabajo por la demanda de un cliente. Para lograr simplicidad organizativa y flexibilidad que permitan al sistema adaptarse a variaciones del flujo de demanda y diferencias en el producto, el toyotismo emplea diversas técnicas de apoyo: Información y control visual KANBAN. Información y control visual ANDON. Sistemas de prevención de errores Poka-yoke. Herramientas polivalentes y de cambio rápido.

Calidad total El concepto de “calidad total” está asociado a William Edwards Deming, profesor universitario y consultor que en los años 50 logró imbuir en la industria japonesa el concepto de calidad como arma estratégica. Mostró la magnitud de los costes que se generan en empresas que no tienen definidos procesos para gestionar la calidad. Costes originados por retrabajo, desperdicio de materiales o productos defectuosos y compensación a clientes.

Las ideas de Deming se reflejan muy bien en los denominados “Catorce puntos de Deming” y las “Siete enfermedades de la gerencia de Deming”.

Los 14 puntos de Deming. Son catorce principios definidos por Deming para gestionar la mejora de la competitividad. Se publicaron en su libro “Out of the Crisis”. 1. Crear constancia en la mejora de productos y

servicios, con el objetivo de ser competitivo y mantenerse en el negocio, además propor-cionar puestos de trabajo.

2. Adoptar una nueva filosofía de cooperación en la cual todos se benefician, y ponerla en práctica enseñándola a los empleados, clientes y proveedores.

3. Desistir de la dependencia en la inspección en masa para lograr calidad. En lugar de esto, mejorar el proceso e incluir calidad en el producto desde el comienzo.

4. Terminar con la práctica de comprar a los más bajos precios. En lugar de esto, minimizar el costo total en el largo plazo. Buscar tener un solo proveedor para cada ítem, basándose en una relación de largo plazo de lealtad y confianza.

5. Mejorar constantemente y por siempre los sistemas de producción, servicio y planea-miento de cualquier actividad. Esto va a mejorar la calidad y la productividad, bajando los costos constantemente.

6. Establecer entrenamiento dentro del trabajo (capacitación).

7. Establecer líderes, reconociendo sus diferen-tes habilidades, capacidades y aspiraciones. El objetivo de la supervisión debería ser ayudar a la gente, máquinas y dispositivos a realizar su trabajo.

8. Eliminar el miedo y construir confianza, de esta manera todos podrán trabajar más eficientemente.

9. Borrar las barreras entre los departamentos. Abolir la competición y construir un sistema de cooperación basado en el mutuo beneficio que abarque toda la organización.

10. Eliminar eslóganes, exhortaciones y metas pidiendo cero defectos o nuevos niveles de productividad. Estas exhortaciones solo crean relaciones de rivalidad, la principal causa de la baja calidad y la baja productividad reside en el sistema y este va más allá del poder de la fuerza de trabajo.

11. Eliminar cuotas numéricas y la gestión por objetivos.

12. Remover barreras para apreciar la mano de obra y los elementos que privan a la gente de la alegría en su trabajo. Esto incluye eliminar las evaluaciones anuales o el

Deming difundió el círculo de calidad propuesto por Shewart: “Planificar – Hacer – Verificar – Actuar”, y de hecho actualmente se le conoce como el círculo de Deming.


2005 - 2012 – ScrumManager Project – http://www.scrummanager.net 13

sistema de méritos que da rangos a la gente y crean competición y conflictos.

13. Instituir un programa vigoroso de educación y auto mejora.

14. Poner a todos en la compañía a trabajar para llevar a cabo la transformación. La transformación es trabajo de todos.

Las 7 enfermedades mortales de la gerencia. 1. Falta de constancia en los propósitos 2. Énfasis en las ganancias a corto plazo y los

dividendos inmediatos 3. Evaluación por rendimiento, clasificación de

méritos o revisión anual de resultados 4. Movilidad de los ejecutivos 5. Gerencia de la compañía basándose

solamente en las cifras visibles 6. Costos médicos excesivos. 7. Costo excesivo de garantías

Preferimos conceptos a metodologías Hoy no resulta fácil componer un criterio profe-sional solvente en gestión ágil de proyectos. La sobrecarga informativa sobre nuevos modelos, marcos, procesos, métodos… en artículos, blogs, foros, cursos, charlas, webinars, libros, etc. puede terminar confundiendo más que aclarando. Este apartado expone los conceptos subyacentes para comprender mejor los diferentes modelos o metodologías.

Concepto 1: Gestión de proyectos predictiva e incremental

Modelo de gestión de proyectos predictivo: Planifica el proyecto de inicio a fin. Estima el esfuerzo y tiempo necesario para su ejecución completa.

La meta es entregar el producto completo en el plazo y con el coste previsto Tiene por objetivo la previsibilidad: conocer cuánto va a costar el proyecto (en tiempo y recursos) y gestionar su desarrollo para entregar en la fecha prevista con los costes previstos el trabajo encargado por el cliente.

Modelo de gestión de proyectos evolutivo o incremental: Comienza el desarrollo del sistema con una visión general del objetivo, e información inicial detalla-da suficiente para la primera entrega, pero no para todo el proyecto. A partir de ahí el producto se construye y entrega de forma incremental, desarrollando las diferentes partes que el cliente va describiendo con detalle, y según el orden de prioridad que él establece en cada momento.

Concepto 2: Ingeniería concu-rrente y agilidad.

El producto se construye y entrega de forma incremental, desarrollando las diferentes partes que el cliente va describiendo con detalle, y según el orden de prioridad que él establece en

cada momento.

La meta es entregar el producto completo en el plazo y con el coste previsto



Ingeniería concurrente: Ciclo de vida: evolutivo e incremental con

solapamiento de fases. Desarrollo basado en procesos: la calidad del

resultado depende de la calidad del proceso. Trabajo gestionado.

Agilidad: Ciclo de vida: evolutivo e incremental con

solapamiento de fases. Desarrollo basado en personas: la calidad del

resultado depende del conocimiento tácito de las personas implicadas.

Trabajo autogestionado.

Concepto 3: Incremento iterativo o continuo.

Para mantener un ritmo de entrega continuo y sostenido, la gestión de proyectos evolutiva em-plea uno de estos dos patrones:

Incremento iterativo: Avance incremental del proyecto basado en “pulsos de tiempo” o “timeboxing”. Las entregas parciales (incrementos) se realizan en ciclos de tiempo breves (Sprints o iteraciones) de duración prefijada, normalmente entre una se-mana y un mes y medio. Al inicio de cada ciclo se estima cuánto trabajo se puede realizar y qué parte del proyecto se realizará

Incremento continuo: Entrega continua de funcionalidades al ritmo que se van produciendo, manteniendo un flujo constante, sin tiempos muertos ni cuellos de botella.

Preferimos una herramienta kanban a un método kanban. El término kanban se emplea en la actualidad para referirse a dos enfoques diferentes: Herramienta de control visual Método definido para aplicar principios lean en

proyectos TIC.

1.- Kanban como herramienta de información y gestión visual. Scrum Manager considera a kanban como una herramienta especialmente útil para gestionar proyectos incrementales con entregas continuas. El uso de tableros kanban facilita el ajuste del flujo constante de avance y entrega evitando los dos problemas más importantes: cuellos de botella y tiempos muertos.

El uso como herramienta de control visual, permite un uso flexible de kanban sin considerar prescripciones ni excepciones en el método de trabajo, siendo el gestor quien aplica los principios ágiles o de ingeniería concurrente (o el punto de síntesis de su organización) con una implementación personalizadas.

2.- Kanban como método para gestión evolutiva de proyectos (ágil o ingeniería concurrente) La consideración de kanban como método puede resultar apropiada para gestores que prefieren la aplicación de métodos estándar al diseño de los propios.



¿Scrum vs. Kanban, o incremento iterativo vs. continuo? Scrum y Kanban considerados como marcos o métodos, que prescriben prácticas, artefactos y roles concretos. dibujan las siguientes diferencias entre ellos (Kniberg & Skarin, 2009) Scrum prescribe roles, kanban no. Scrum trabaja con iteraciones de tiempo fijo,

kanban con cadencias (simples, múltiples o dirigidas por eventos).

Scrum limita el wip por iteración, kanban limita el wip por estado del flujo de trabajo.

Los equipos de scrum son multidisciplinares, en kanban pueden ser de especialistas.

Scrum no permite cambiar tareas del sprint, en kanban la tarea puede alterarse hasta entrar en el flujo.

En scrum la pila de producto debe tener la longitud de al menos un sprint.En kanban se debe atender al ritmo de arrastre de tareas.

En scrum se deben estimar las historias y las tareas y calcular la velocidad, kanban no mide tareas ni velocidad.

Scrum necesita una pila de producto priorizada, en kanban es la siguiente historia o tarea arrastrada desde el cliente.

Scrum prescribe reuniones diarias, kanban no. Scrum emplea diagramas burndown, kanban

no. Los tableros scrum se resetean al final de

cada sprint. Etc.

Al guiarnos por las metodologías y no por los conceptos, se pueden plantear más dudas que soluciones: “Si quiero usar kanban pero tengo (o quiero) estimar las tareas para registrar la velocidad por razones organizativas de mi empresa o porque se me ha ocurrido que…”

“Si mi empresa gestiona proyectos simultáneos con una organización de oficina de proyectos y encaja mejor el establecimiento de roles; pero sin embargo quiero trabajar con kanban en lugar de con scrum… ¿Debería hacer scrumban? ¿qué es eso?. ¿O lo que voy a hacer es Scrumbut y soy un mal gestor? etc.” Las dudas y preferencias entre metodologías de-saparecen al desaprender estos aspectos y considerar marcos de trabajo personalizados para las características de nuestra organización

1 cons-

truidos desde los conceptos y con el conocimiento y experiencia de sus gestores.

Conceptos

Empleando las técnicas y pautas que en cada caso resulten más apropiadas: tableros kanban, graficos burn-down, estimación de poker, gráficos burn-up, etc. De esta forma kanban toma su significado original: una técnica de gestión visual desarrollada y empleada por la manufactura Lean.

La manufactura Lean emplea técnicas De información visual sobre el estado de la

producción, que se muestra directamente en la propia sala de montaje o manufactura.

De control visual, que muestra también información de forma directa sobre las piezas o elementos de los que están informando en las líneas de montaje cuyas características de producción están mostrando en tiempo real.

De prevención de errores. Herramientas adaptables y polivalentes para el

desarrollo de productos diferenciados con recursos. Comunes.

1 Concepto de campo de Scrum como entorno ágil auto-

gestionado, a diferencia de la consideración de Scrum como método definidio por roles prácticas y artefactos concretos.

Kanban herramienta ágil de control visual


¿Gestión visual? En una calle la organización es compleja: circulación de coches, peatones, zonas de aparcamiento, carriles para autobuses, etc. pero la señalética nos indica todo. Estamos acos-tumbrados a la "gestión visual." La industria de la automoción es posiblemente la primera que incorporó la "gestión visual" en el propio escenario de producción: todo está a la vista, la identificación de los sectores, los productos son reconocibles y están etiquetados indicando su fase dentro del proceso de la cadena. En todo momento se sabe qué se está produciendo. La información está en el mismo entorno de trabajo, visible, expresada con simplicidad, y no en ordenadores o libros de registro de procesos.

Kanban es una técnica de control visual. Es un sistema de señalización para desencadenar acciones. El término japonés Kanban se puede traducir por tablero, o tarjeta de señalización, haciendo referencia a un sistema de señalización empleado en los procesos de producción para coordinar que cada parte se entrega al departamento o sección correspondiente sólo cuando se necesita, redu-ciendo al mismo tiempo la sobreproducción o almacenamientos innecesarios. El origen de este sistema de control visual se remonta a finales de los cuarenta o principios de los cincuenta, cuando su autor, Taiichi Onho desarrollaba señales para implementar con gestión visual métodos de producción "Just In Time" (JIT) en los centros de producción de Toyota de Japón.

Estas prácticas no tuvieron demasiada difusión, más allá de los centros en los que se aplicaban, hasta las fechas de recesión en los 70, cuando se empezó a popularizar el uso de “kanban’s”, para minimizar el trabajo en el proceso (WIP)

2 y reducir

los costes asociados al almacenamiento de inventarios.

Originalmente Toyota empezó a usar kanban para reducir costos y gestionar el uso de las máquinas, pero hoy Toyota continúa usando el sistema no sólo para gestionar costes y flujos, sino también para identificar impedimentos en el flujo de producción y analizar los puntos de mejora de forma continua.

Kanban también es herramienta útil para la gestión ágil. El desarrollo ágil de software emplea prácticas de gestión visual, por ser las que mejor sirven a los principios de comunicación directa y simplicidad en la documentación y gestión. Desde 2005 es cada vez más frecuente re-emplazar los formatos de lista para las pilas de producto y de sprint, por notas adhesivas, porque que resultan muy versátiles al poder cambiar su posición: para re-ordenar las prioridades de las historias de una pila de producto, e indicar sólo con su posición qué tareas o historias se están programando, o probando, o ya se han terminado, etc.

2 “Work in process” (trabajo en el proceso) también “in-process

inventory” (inventario en el proceso) o elementos del producto, que aún no están terminados y se encuentran en el proceso de producción. No confundir con Work in progress (trabajo en progreso) término que designa un trabajo que ha comenzado pero aún no está terminado.

Kanban es un sistema de señalización para comunicar información relativa y necesaria en la ejecución o monitoriza-

ción de un trabajo.



La generalización del uso de kanban como herramienta en equipos de programación ha hecho que en la actualidad se emplee el término kanban también para definir, como ya se ha visto, un método concreto de aplicación de esta herramienta. Antes de ver algunos ejemplos de las posibi-lidades de kanban, conviene resaltar que desde el principio de flexibilidad de Scrum Manager, consideramos a kanban no como un método ágil o lean, sino como una herramienta, o técnica para difundir información relativa y necesaria en la ejecución o control de un trabajo.

No hay por tanto un modelo de gestión kanban, ni formatos o prescripciones.

Fortalezas de Kanban Un sistema visual kanban se puede emplear para ofrecer información, trazar la gestión de un proce-dimiento, controlar su ejecución, o una combi-nación de ellas.

Información Los principios ágiles a los que se puede dar un soporte adecuado usando kanban en su dimensión de “radiador de información” son:

Favorece la comunicación directa

Facilita la comunicación directa del equipo al actualizar la información en reuniones enfrente de un tablero kanban. Comparte la visibilidad de la evolución del proyecto entre todos los implicados.

Detección temprana de problemas

Kanban visualiza información de seguimiento continio del proyecto. La actualización de la información just-in-time, ayuda a identificar en un primer momento los posibles impedimentos problemas y riesgos, que de otra forma suelen pasar desapercibidos hasta que empiezan a producir retrasos o repercusiones ya inevitables.

INFORMACIÓN – CONTROL – GESTIÓN

VISUAL

Kanban no es un modelo o marco de gestión, sino una herramienta de

señalización. No hay por tanto un formato cerrado de

tarjetas o tableros kanban.


Favorece una cultura de colaboración y resolución.

Es un medio de comunicación abierto y transpa-rente para el equipo y todos los participantes.

Gestión / Control Kanban como herramienta para la gestión del proyecto ofrece además de información, pautas de flujo y control aporta:

Monitorización y regulación del flujo, y la carga de trabajo

La posición de cada tarjeta sobre el tablero refleja el estado en el que se encuentra la corres-pondiente historia de usuario. Los estados básicos que se suelen representar en un tablero kanban son “pendiente”, “en curso” y “terminada”.

En algunos casos puede resultar conveniente marcar sub-estados (testing, validada…). La ordenación de las tareas desde el área “pendiente”, indica ya en el inicio la secuencia de las tareas según sus prioridades. Al usar kanban como herramienta de gestión se recomienda asignar un parámetro WIP (Work in Process) en aquellos estados que pueden producir cuellos de botella. El “WIP” limita el número máximo de tareas que pueden estar de forma simultánea en esa área.

Genera un flujo de trabajo que lleva los problemas a la superficie

Los conflictos en la priorización de las historias de usuario o tareas, los derivados de problemas de flujo por impedimentos o volumen de trabajo, las incidencias en el desarrollo se ponen de mani-

fiesto de forma inmediata en el seguimiento diario del flujo en el tablero .

Facilita un ritmo sostenido y evita la ley de Parkinson

Genera un incremento continuo de trabajo cuyo ritmo no está marcado por una planificación temporal: Gantt o Sprint (incremento iterativo) La ausencia hitos temporales evita la tendencia habitual de alargar el tiempo de trabajo hasta completar el tiempo estimado (ley de parkinson). Por otra parte, la ausencia de hitos temporales, sin técnicas de monitorización y gestión del avance generaría alargamiento de tiempos y retrasos por procrastinación y perfeccionismo.

Produce incremento continuo

Y por supuesto responde al principio ágil impres-cindible: entrega frecuente de valor. Tareas que se completan con un ritmo sostenido y de forma continua, y con ellas historias de usuario que se van sumando al producto, proporcionándole un incremento continuo de valor según las prioridades de negocio marcadas por el propietario del producto.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante

de forma indefinida

Manifiesto Ágil

El trabajo se expande hasta llenar el tiempo disponible para que se termine.

Ley de Parkinson



Monitorización y regulación de “Mura” y “Muri” Muda, Mura y Muri son tres conceptos claves de la mejora continua Kaizen, que la producción lean incorpora como variables protagonistas para incrementar la eficiencia. Muda: Desperdicio Muri: Tensión. Sobrecarga de trabajo que

produce cuellos de botella. Mura: Discrepancia. Variabilidad del flujo de

trabajo. Las mudas, o razones de desperdicio más habi-tuales en los proyectos TIC son: Burocracia: Procedimientos, documentación y

papeleo innecesario que no aporta valor al resultado.

Sobreproducción: Desarrollar más características de las necesarias.

Multiproyecto: Alternar el tiempo de trabajo entre varios proyectos e interrupciones del flujo de trabajo.

Esperas: Tiempos de espera por falta de cadencia en el flujo de trabajo.

“Ir haciendo” o falta de solución de las esperas: Encargar trabajo para ir avanzando algo no definido y así no tener paradas a las personas.

Desajustes de capacidad: Personas de gran talento asignadas a tareas rutinarias, y viceversa.

Errores: Retrabajo por bugs. Los tableros kanban resultan especialmente útiles para detectar y gestionar las otras dos variables kaizen: mura y muri.

Factores determinantes de cuellos de botella y los tiempos muertos (muri y mura) Cada organización tiene sus propias característi-cas en cuanto a: Secuenciabilidad de las tareas. Multifuncionalidad de los miembros del equipo.

Y estos son los factores que en cada caso determinan la dificultad y la solución para lograr un flujo continuo de desarrollo. La secuenciabilidad se refiere a la necesidad de seguir un determinado orden en la ejecución de las tareas. Por ejemplo las tareas de un equipo de mantenimiento no deben ejecutarse en un deter-minado orden, mientras que las de un equipo de programación sí. Supongamos que un equipo de mantenimiento tiene las siguientes tareas: Instalación de impre-sora en el departamento de personal, instalación y enracado del nuevo servidor de fihceros, actualización de la versión de… Los miembros del equipo pueden realizar estas tareas en cualquier orden. No es necesario hacer una en concreto para comenzar la siguiente. Sin embargo, las tareas por las que pasa una historia de usuario en un equipo de programación, suelen requerir un orden determinado (análisis, codificación, pruebas, integración) y no se puede realizar una tarea hasta que no se ha completado la anterior. Los dos equipos del ejemplo (mantenimiento y programación) pueden emplear un tablero kanban para gestionar el trabajo, pero sin duda el diseño y los criterios para mejorar el flujo son diferentes en cada caso.

El segundo factor clave es el grado de multi-funcionalidad o polivalencia de los miembros del equipo. Siguiendo con los ejemplos anteriores este factor determinaría si todos los miembros del equipo de mantenimiento son capaces de realizar cualquier tarea (instalación de impresora, servidor de ficheros, etc. ) o cada una tiene su especialista. Y lo mismo si nos referimos al ejemplo del equipo de programación: ¿todos los miembros pueden


realizar análisis, programación, pruebas, integra-ción, etc.? Lógicamente los equipos que trabajan con tareas no secuenciales y que están formados por personas polivalentes son los que más fácil tienen conseguir un flujo de entrega constante. Cuando surgen las dificultades las variables que se deben combinar según las posibilidades en cada caso son: Volumen de demanda. Orden del backlog o pila de historias de

usuario: Si se va a producir un cuello de botella en una fase, procurar que la próxima historia que va a entrar al tablero requiera poco esfuerzo de esa fase.

WIP o límite de tareas en una determinada fase.

Staffing: Tamaño del equipo y especialización o polivalencia.

WIP -Work In Process (Trabajo en el proceso) como método para ajustar los cuellos de botella o muri Al emplear kanban como técnica con la que regular un incremento continuo desaparece el concepto de sprint. El incremento no es en este caso el resultado de un sprint, sino cada historia de usuario que se termina y entrega. Par lograr un flujo continuo de funcionalidades que, una a una van aportando incrementos de forma sostenida, es necesario evitar la aparición de cuellos de botella: la acumulación de tareas en una determinada fase del proceso. Una técnica muy útil es limitar la cantidad de trabajo que puede acumularse en las fases que pueden generar cuellos de botella. Al parámetro que indica el número máximo de tareas en un área del tablero kanban se le denomina WIP: Work In Process. Un valor “WIP” demasiado bajo puede producir cuellos de botella en otras fases, en especial si el sistema es demasiado rígido (tareas secuenciales y equipo de especialistas) La experiencia ayuda al equipo a ir ajustándolo para lograr un flujo continuo, o lo más continuo posible. Si no se cuenta con experiencia previa, y consi-derando que las tareas no deberían tener tamaños mayores de 4 horas ideales, el equipo debe establecer un criterio de inicio, y a partir de él ir ajustando.

En este sentido una recomendación general-mente útil (en equipos de personas polivalentes) es empezar con un WIP igual al nº de miembros del equipo x 1.5, redondeando el resultado por exceso, o x2. No es aconsejable trabajar con tareas de tamaño que se prevea superior a un día de trabajo, y si esto ocurre lo aconsejable es dividirlas en otras de menor tamaño.

Formato básico con control del trabajo en el poceso (WIP) La figura siguiente presenta una implementación kanban con límite de trabajo en los estados “Producto analizado” y “En curso”.

En este ejemplo, el propietario de producto tiene una zona para registrar y ordenar de forma priorizada el backlog. (A). Es el área en la que el responsable de producto añade, modifica, y reordena la prioridad de cada historia de forma continua. Pero sólo son 3 las historias que pueden estar en estado “decididas” para pasar a producción. 3 con la que ya está previsto analizar y revisar la estimación con el equipo.

De igual forma, el área “en curso” tiene un límite de 3 historias. Hasta que una no pasa a “HECHO”, no puede entrar ninguna a producción, y de igual forma mientras haya 3 en la zona “ANALIZADO” no se decide cuál será la próxima historia del backlog. De esta forma se crea un flujo de trabajo sin cuellos de botella, continuo y enfocado.



Ejemplos de uso

Información: Dos ejemplos que muestran posible usos de tableros kanban para monitorizar el progreso del trabajo, pero sólo mostrando la información de forma simple, visual y abierta, sin aportar pautas o criterios de gestión. No emplean el formato más habitual de distribu-ción horizontal en orden: “Pendiente” -> “En curso” -> “Terminado”; sino que agrupan en vertical la información del desarrollo de cada epic o historia de usuario. Pueden ser útiles como tableros de información para gestores de producto.

A nivel de epics / historias Este ejemplo representa un posible tablero kanban en el puesto de trabajo del o de los responsables del producto, que podría ser el product manager, o el departamento de marketing, la oficina de proyectos, etc. según la organización de la empresa y de productos que desarrolle. El tablero informa del estado de desarrollo del producto a nivel de epics

3 y las correspondientes

historias de usuario.

Cada columna representa un “epic” o gran historia del producto, que está descrita en la tarjeta de la parte superior (1) Este tablero puede ser útil para un gestor de producto, que podría indicar en la tarjeta del epic información adicional como la versión o release de producto en la que se integrará, o fecha en la en la que se espera incluir, o esfuerzo estimado para su desarrollo, etc.

3 Grandes historias o funcionalidades generales.

Debajo de la tarjeta con el epic, de cada columna se despliegan las historias de usuario (2) que lo componen.

En este ejemplo la tarjeta de cada historia de usuario refleja el avance que la misma está teniendo en la pizarra del equipo, a través de una barra de una barra de progreso que actualiza a diario el propietario de producto, pintando sobre la tarjeta de la historia.

A nivel de historias / tareas Con un esquema similar al anterior, el tablero de este ejemplo muestra información visual de las historias de usuario que se están desarrollando, las tareas que componen cada una, y el grado de avance.

Las historias de usuario y su descomposición en tareas, están presentados en columnas. En la cabecera (1) está situada la tarjeta con la descripción e información de estimación o fechas previstas según la velocidad del equipo, y a lo largo de la columna, las diferentes historias.


En este ejemplo, las tarjetas que representan las tareas, incluyen una “barra de estado” que representa cuánto falta para terminar.

Información + autogestión Formato básico Este es el formato más habitual para ayudar a los equipos a auto-gestionar un flujo de trabajo continuo a través del avance de las tareas por tres estados básicos: pendiente, en curso y terminado.

Según las necesidades o preferencias de cada equipo, se suelen ampliar o detallar estos estados básicos, con indicaciones relativas a si se ha preparado ya la prueba unitaria, si se ha realizado, o si la tarea pendiente está en la pila o ya está preparada y estimada, etc.

Kanban Box Una práctica diseñada para responder a las dificultades frecuentes al gestionar tareas de varios proyectos en el mismo departamento de producción es una implementación Kanban diseñada en Scrum Manager que hemos denominado Kanban Box. La configuración es la siguiente:

La organización mantiene una “pila de produ-cción” o lista de historias de usuario, pendientes, estimadas y priorizadas. Si la organización trabaja en un único producto, la “pila de producción” es en definitiva la pila del producto o product backlog. Si lleva a cabo el desarrollo o mantenimiento simultáneo de varios sistemas, la pila de producción es gestionada por los propietarios de producto, o la oficina de proyectos... en definitiva quienes sean responsables según la estructura de la organización.

En la pila de producción las tareas están estimadas y ordenadas según los criterios de prioridad compartidos entre los intereses de los diferentes proyectos y de la organización en conjunto. El equipo que va a hacerse cargo de una historia, la descompone en tareas que representa en una “caja kanban”:

(1) Estimación temprana de la historia, realizada por “juicio de experto” por el propietario del producto.

(2) Estimación de la tarea realizada por el equipo al descomponer la historia en tareas.

En cada caja se representa:

(1) Puntos totales de esfuerzo estimados (2) Tarjetas con las tareas (3) Un fondo de escala graduado con los

puntos totales de esfuerzo estimados (4) Barra dibujada con rotulador “borrable”

que representa la velocidad prevista (5) Barra de velocidad real



(6) Una descripción de la historia de usuario.

De esta forma se van “encajando” las historias de usuario, o preparando para pasar a producción.

Las cajas preparadas van entrando en los “slots” disponibles en la columna “pendiente” del tablero general de la organización.

A diario, cada equipo realiza la reunión de seguimiento o reunión de pie frente al tablero, actualizando el estado de cada tarea (pendiente -> en curso -> hecho), y la actualización de las barras de velocidad: La barra de velocidad prevista (1) se actualiza todos los días con el ritmo de velocidad previsto según la velocidad media de la organización, y el nº de miembros del equipo. Si por ejemplo se trata de un equipo de 3 personas, y la velocidad media es de 3 puntos por persona/día, cada día la barra de velocidad prevista disminuye e 9 puntos. La barra de velocidad real (2) representa la suma del esfuerzo de las tareas que aún se encuentran en estado “pendiente” y “en curso”.

La diferencia de altura entre las barras de velocidad muestra desviaciones del esfuerzo previsto, en uno u otro sentido, de forma visual y rápida., de forma similar a un gráfico burn-down. El tablero general de una organización o departamento de producción con cuatro equipos presentaría un aspecto similar a la figura siguiente. La columna “Pendiente” contiene cuatro “slots” en los que van entrando las cajas kanban, a medida que se van terminando las anteriores.


Resumen La aplicación a la producción lean de los principios de calidad total definidos por Edwards Deming marca el momento en el que se encuentra la evolución del conocimiento de la manufactura industrial. La gestión de proyectos TIC ha incorporado la herramienta la kanban empleada por la manufactura lean, en formato de tableros con información visual en notas adhesivas. El uso de tableros kanban en proyectos TIC facilita: Información directa. Gestión de un flujo continuo de trabajo. Los conceptos subyacentes a las diferentes metodologías prácticas para la gestión ágil de proyectos son: Modelo de gestión del proyecto:

Predictivo.

Evolutivo. Marco de desarrollo:

Ingeniería concurrente.

Agilidad. Incremento:

Iterativo

Continuo La gestión visual introduce en el propio escena-rio de trabajo información con instrucciones para su ejecución o información sobre su estado. Kanban es un sistema de señalización para comunicar información relativa y necesaria en la ejecución o monitorización de un trabajo. El origen del sistema de señalización Kanban se remonta a finales de los cuarenta, en los centros de producción de Toyota de Japón. A partir de 2005 surgen prácticas de programa-ción ágil que muestran la información de control o monitorización de los proyectos con técnica Kanban, empleando tarjetas adhesivas sobre tableros. Kanban no es un modelo o marco de gestión, sino una herramienta de señalización. No hay por tanto un formato cerrado de tarjetas o tableros kanban. La señalización kanban se puede emplear para:

La gestión de un proyecto puede utilizar señalización kanban para: Ofrecer información de seguimiento del

proyecto. Herramienta de gestión y control del ritmo del

proyecto. Información Como herramienta de información, la señalización kanban da soporte a los siguientes principios ágiles: Comunicación directa. Detección temprana de problemas. Cultura de colaboración y resolución. Gestión / control Como herramienta de gestión aporta: Monitorización y regulación del flujo y carga

de trabajo. Genera un flujo de trabajo que lleva los

problemas a la superficie Produce un ritmo de trabajo sostenido y evita

la ley de Parkinson. Factores determinantes de cuellos de botella y tiempos muertos. Secuenciabilidad de las tareas. Polivalencia de los miembros del equipo. WIP – Work In Process (Trabajo en el proceso) WIP es el parámetro que determina el número máximo de tareas que se pueden encontrar en el estado “en curso” de forma simultánea. Un valor WIP demasiado bajo produce tiempos muertos, y demasiado alto, cuellos de botella.

gestión visual kanban · 1. crear constancia en la mejora de productos y servicios, con el...

Documents