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
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 2005-2012 ScrumManager - http://www.scrummanager.net
Prólogo
Prólogo 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 formacion@scrummanager.net 2008 2005-2012 ScrumManager - http://www.scrummanager.net 7
Kanban herramienta lean para control visual
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 economí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 organizació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 racional 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 principios de planificación y ejecución del trabajo. Proporcionar instrucciones y supervisión detallada a cada trabajador. Producción en cadena La producción en cadena, también denominada fordismo, es el sistema de producción desarrollado 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 industrial 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 producció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 resultado depende de la calidad del proceso empleado 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. 11 2005-2012 ScrumManager - http://www.scrummanager.net
Gestión Visual Kanban Estas circunstancias evolucionaron la producción fordista hacia un sistema que elimina las existencias del proceso de producción y el sobreefectivo 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 continuamente 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. 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. 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 proporcionar 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 planeamiento 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 diferentes 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 12 2005-2012 ScrumManager - http://www.scrummanager.net
Gestión Visual Kanban 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. 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 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 profesional 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 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 detallada 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. 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 concurrente y agilidad. 2005-2012 ScrumManager Project http://www.scrummanager.net 13
Gestión Visual Kanban 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. 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. Para mantener un ritmo de entrega continuo y sostenido, la gestión de proyectos evolutiva emplea 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 semana 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. 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. 14 2005-2012 ScrumManager - http://www.scrummanager.net
Gestión Visual Kanban 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. 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 desaparecen al desaprender estos aspectos y considerar marcos de trabajo personalizados para las características de nuestra organización 1 construidos 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. 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 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 autogestionado, a diferencia de la consideración de Scrum como método definidio por roles prácticas y artefactos concretos. 2005-2012 ScrumManager Project http://www.scrummanager.net 15
16 2005-2012 ScrumManager - http://www.scrummanager.net
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 acostumbrados 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. 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. 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. 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, reduciendo 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. 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 reemplazar 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. 2005-2012 ScrumManager Project http://www.scrummanager.net 19
Gestión Visual Kanban 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 posibilidades 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. Fortalezas de Kanban Un sistema visual kanban se puede emplear para ofrecer información, trazar la gestión de un procedimiento, controlar su ejecución, o una combinación de ellas. INFORMACIÓN CONTROL GESTIÓN VISUAL No hay por tanto un modelo de gestión kanban, ni formatos o prescripciones. 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. 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. 20 2005-2012 ScrumManager - http://www.scrummanager.net
Favorece una cultura de colaboración y resolución. Es un medio de comunicación abierto y transparente 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 correspondiente historia de usuario. Los estados básicos que se suelen representar en un tablero kanban son pendiente, en curso y terminada. 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 manifiesto 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. El trabajo se expande hasta llenar el tiempo disponible para que se termine. Ley de Parkinson 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 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 Produce incremento continuo Y por supuesto responde al principio ágil imprescindible: 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. 2005-2012 ScrumManager Project http://www.scrummanager.net 21
Gestión Visual Kanban 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 habituales 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. 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 determinado orden, mientras que las de un equipo de programación sí. Supongamos que un equipo de mantenimiento tiene las siguientes tareas: Instalación de impresora 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. 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ísticas en cuanto a: Secuenciabilidad de las tareas. Multifuncionalidad de los miembros del equipo. El segundo factor clave es el grado de multifuncionalidad 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 22 2005-2012 ScrumManager - http://www.scrummanager.net
realizar análisis, programación, pruebas, integració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. En este sentido una recomendación generalmente ú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. 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 considerando 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. 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. 2005-2012 ScrumManager Project http://www.scrummanager.net 23
Gestión Visual Kanban 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 distribució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. 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. Cada columna representa un epic o gran historia del producto, que está descrita en la tarjeta de la parte superior (1) 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. 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. 24 2005-2012 ScrumManager - http://www.scrummanager.net
La organización mantiene una pila de producció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. En este ejemplo, las tarjetas que representan las tareas, incluyen una barra de estado que representa cuánto falta para terminar. 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. 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. 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 : 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: (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 2005-2012 ScrumManager Project http://www.scrummanager.net 25
Gestión Visual Kanban (6) Una descripción de la historia de usuario. 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. De esta forma se van encajando las historias de usuario, o preparando para pasar a producción. La columna Pendiente contiene cuatro slots en los que van entrando las cajas kanban, a medida que se van terminando las anteriores. 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. 26 2005-2012 ScrumManager - http://www.scrummanager.net
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 escenario 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. 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. 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 programació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: 2005-2012 ScrumManager Project http://www.scrummanager.net 27
NOTAS