¿Está planeando implementar Kanban en sus procesos comerciales? Aquí es por dónde empezar. Sistema Kanban: qué es, por dónde empezar, cómo implementarlo, principios fundamentales

Lo más brevemente posible sobre el método Kanban, sus términos básicos y áreas de aplicabilidad.

Describimos el método Kanban, sus términos básicos y áreas de aplicabilidad lo más brevemente posible.

1. ¿Qué es el método Kanban?

El método Kanban es un método para mejorar tu trabajo. Hagas lo que hagas, la hipótesis es que practicar el método Kanban te permitirá hacer tu trabajo aún mejor. Desde una perspectiva Kanban, esto significa que cumplirá mejor con las expectativas de los clientes.

Kanban como herramienta en la gestión de TI fue presentado por David J. Anderson en Microsoft (2005) y Corbis. Y el método se generalizó y recibió su nombre en 2007.

2. ¿Son el Método Kanban y Toyota Kanban lo mismo?

(Tarjeta más grande). Ciertamente no de esa manera. Kanban en las plantas de Toyota es la fabricación ajustada, cuyo principio definitorio es el concepto de "justo a tiempo". Kanban, como término de gestión, realmente vino de Toyota. Traducido del japonés, esta palabra significa "señal" o "tarjeta". En las fábricas de automóviles, estas tarjetas se utilizaban para transmitir información de una etapa a la siguiente sobre cuántas y qué piezas se necesitarían.

Veamos un breve ejemplo. Necesitamos fabricar tres coches "justo a tiempo". Esto significa que podemos determinar con precisión de antemano cuántas piezas necesitaremos en determinadas etapas, y comenzamos desde el final a sacar la cantidad necesaria de piezas para crear este automóvil, respondiendo a las preguntas: "¿Cuántos litros de pintura necesitaremos?" ¿Necesitas?”, “¿Cuántas ruedas?”, “¿Cuántos motores?” etcétera. De este modo, no creamos excedentes de repuestos en forma de sobras y ahorramos en almacenes, logística y otros costes.

El método Kanban también se adhiere al concepto de “justo a tiempo”, pero a diferencia de las fábricas de Toyota, aquí estamos hablando de trabajo intelectual. En otras palabras, el código de un programador o la idea de un comercializador no pueden ser tocados ni vistos por una persona promedio hasta que se convierta en un producto o servicio final. Así, el método Kanban se utiliza para visualizar el flujo de trabajo intelectual y reducir la cantidad de este trabajo inacabado. Gracias a esto, se logra una velocidad uniforme y predecible de prestación del servicio al consumidor final.

3. ¿Se puede utilizar el método Kanban fuera de TI?

Sí. El método Kanban es adecuado para visualizar el flujo de cualquier trabajo creativo e intelectual. Pero es mucho más eficaz utilizarlo a través del prisma del paradigma de servicio. Mira lo que haces como servicio. ¿Qué etapas pasa por la obra para poder prestar el servicio? ¿Con qué criterios entenderá que el servicio se presta de acuerdo con las expectativas del Cliente? Este es el punto de partida para utilizar el método Kanban. Los practicantes de Kanban llaman a este punto "comienza con lo que tienes ahora".

4. ¿Kanban es como Scrum?

No. Scrum es un marco con reglas y límites estrictos. Puedes utilizar diferentes herramientas y metodologías dentro de Scrum, pero si abandonas algo requerido en Scrum, ya no podrá considerarse Scrum. Kanban es un método, una herramienta con un conjunto de prácticas y principios. Puedes utilizar todas las prácticas, algunas de ellas o no utilizarlas en absoluto. En Kanban no existe un concepto estricto de qué es Kanban y qué no es Kanban. Sin embargo, el uso sensato de las prácticas puede ayudarle significativamente a brindar un servicio de la más alta calidad y satisfacer las expectativas del cliente.

5. ¿Kanban tiene valores?

Sí. Hay nueve: transparencia, equilibrio, colaboración, orientación al cliente, fluidez, liderazgo, comprensión, acuerdo, respeto.

6. Escribiste sobre los principios de Kanban. ¿Qué son?

Kanban tiene principios básicos, que también se denominan principios de gestión del cambio:

1. Comienza con lo que tienes ahora.
2. Acordar el desarrollo evolutivo.
3. Fomentar el desarrollo del liderazgo en todos los niveles.

Dado que el método Kanban vive en un paradigma de servicio, se adhiere a sus principios:

1. Conocer las necesidades y expectativas del cliente.
2. Gestiona el trabajo, deja que la gente se organice en torno a él.
3. Desarrollar reglas para mejorar el desempeño.

7. ¿Cuáles son las prácticas en Kanban?

También hay seis de ellos:

1. Visualizar.
2. Limite el trabajo sin terminar.
3. Gestionar el flujo de trabajo.
4. Utilice reglas explícitas.
5. Introducir bucles de retroalimentación (cadencias).
6. Mejorar y evolucionar.

Se trata de técnicas directamente prácticas que utilizamos para mejorar nuestro trabajo y mejorar la calidad del servicio.

8. ¡Oh, cadencias! ¿Qué son las cadencias en Kanban?

Cadencia es un término de la música. En el contexto del método Kanban, denota ritmo. Las cadencias son reuniones periódicas que también son circuitos de retroalimentación. La regularidad marca el ritmo con el que fluye el flujo de trabajo. Siete cadencias:

1. Reunión Kanban (diariamente). Aquí discutimos el estado de las tareas bloqueadas.
2. Reunión de llenado de colas (generalmente cada dos semanas). Asumimos la responsabilidad de lo que haremos como servicio.
3. Reunión de planificación de entrega (normalmente cada dos semanas). Devolvemos las obligaciones cumplidas.
4. Reunión de revisión del servicio (generalmente cada dos semanas). Utilizando métricas, discutimos la calidad del servicio y cómo mejorarlo, si es necesario.
5. Reunión de operaciones (normalmente una vez al mes). Discutimos la calidad de la interacción de los servicios relacionados con las métricas.
6. Reunión de revisión de riesgos (normalmente una vez al mes). Discutimos con las métricas el impacto de las tareas bloqueadas en el funcionamiento del servicio.
7. Reunión de revisión de la estrategia (normalmente trimestral). Discutimos cambios de estrategia con métricas.

9. Escuché algo sobre clases de servicio. ¿Qué es esto?

Kanban utiliza clases de servicio para priorizar ciertos tipos de trabajo, clientes o mitigar los impactos comerciales, como el costo de la demora. El costo del retraso es el lucro cesante o los costos incurridos debido a la entrega tardía de los servicios. Veamos el impacto de los costos de demora y la clase de servicio correspondiente usando ejemplos:

1. Clase acelerada – primeros auxilios de emergencia-reanimación. Conducir en un carril exclusivo. No hay tiempo para posponer la solución del problema. Lo necesito lo antes posible.
2. Clase de fecha fija: los costos de demora aumentan dramáticamente después de un cierto período. Ejemplo: un proyecto en forma de ley federal con una fecha de inicio fija. Si no llegamos a tiempo, corremos el riesgo de perder nuestra licencia.
3. Clase estándar: el coste del retraso aumenta en proporción al tiempo. Si lo hacemos de inmediato, obtenemos ganancias inmediatamente. Si lo hacemos durante mucho tiempo, obtendremos beneficios durante mucho tiempo.
4. Clase intangible: lo hacemos, pero este trabajo no genera ningún beneficio obvio, el costo del retraso crece lentamente. Por ejemplo, limpiar la casa. No es necesario que limpies con regularidad, pero al cabo de medio año sí que tendrás que hacer una limpieza a fondo.

10. ¿Qué pasa con las métricas? ¿Cómo medir la efectividad de un servicio?

El método Kanban cuenta con métricas que permiten responder las preguntas: cuáles son los problemas en el flujo de trabajo, cuál es el rendimiento del servicio, cuál es el tiempo de ejecución, cuál es el tiempo de resolución del bloqueo, cuál es el tiempo de ciclo y cuál ¿Se distribuyen los tipos de trabajo? Todo ello permite al gestor del servicio tomar decisiones sobre el desarrollo y mejora de la calidad del servicio en base a los datos acumulados.

11. ¿Qué desafíos enfrenta Kanban durante la implementación?

El principal desafío es explicar a las personas de todos los niveles el valor de las prácticas Kanban: visualización y limitación del trabajo en progreso. Debido a que las personas no ven el volumen de trabajo intelectual, les resulta difícil comprender la carga a la que están expuestos. Pero el cerebro, por ejemplo, es el mismo músculo que el bíceps. Imagínate un gimnasio: entras y ves el peso en la barra: “Está bien, es muy poco. Y ahora es demasiado. ¡Pero esto es perfecto! Es necesario trabajar con el cerebro de la misma manera: “Ésta es una tarea grande y ésta es pequeña y, en general, de alguna manera he asumido mucho. Limitaré la carga”. Cuando visualizamos el flujo de trabajo de un extremo a otro en todos los niveles y limitamos la cantidad de trabajo en progreso, creamos un principio de atracción para el trabajo del conocimiento y hacemos que sus resultados fluyan uniformemente hacia nuestros clientes.

12. ¿Qué programas existen para el método Kanban?

Hay muchos de ellos también. Enumeramos solo los profesionales, desarrollados específicamente para el método. Nuestro corazón está entregado al desarrollo ruso Kaiten. Además de esto, también existen TargetProcess, SwiftKanban, LeanKit y otros.

13. ¿Y qué empresas utilizan ya el método Kanban?

Entre los rusos se encuentran Alfa-Bank, Home Credit Bank, Pochta-Bank, Dodo Pizza, HeadHunter, Clever y otros. Del extranjero: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb's, Siemens, Tupalo. Esta lista puede continuar durante mucho tiempo.

14. ¿Hay algo más importante?

Sí. Finalmente, me gustaría señalar la importancia de dos roles en el método Kanban. Estos son el administrador de prestación de servicios y el administrador de solicitudes de servicios. El primero se encarga de eliminar los obstáculos en el flujo de suministro. El segundo es para gestionar el flujo de solicitudes al servicio de muchos clientes. Es muy importante que estos dos roles sean socios y trabajen juntos.

15. Está bien, lo entiendo. ¿Por dónde empezar a implementar Kanban en una organización?

Para empezar a implementar Kanban en las organizaciones utilizamos la herramienta S.T.A.T.I.K. – un enfoque sistemático para el uso de Kanban. Puedes leer más sobre esto en Internet. Pero recomendamos asistir a una formación donde se enseñe esta herramienta en formato de juego de negocios. Usando su servicio (organización) como ejemplo, puede diseñar un sistema Kanban para su uso posterior en condiciones de combate.

Formador y consultor en metodologías ágiles, Scrumtrack.

Buenas tardes

Uno de mis intereses profesionales, como coordinador de equipos de pruebas, son las metodologías de desarrollo de software. Actualmente, las metodologías denominadas Agile, especialmente Scrum y Kanban, son cada vez más populares. Los “entrenadores” sin escrúpulos juegan con términos “publicitados”; los seminarios y las certificaciones (“Scrum master certificado”, “Product Owner certificado”, etc.) están creciendo a pasos agigantados.

En la mayoría de los artículos y capacitaciones sin escrúpulos, cualquier metodología se presenta como una solución mágica que resolverá instantáneamente los problemas de comunicación y salvará inmediatamente a los miembros individuales del equipo de la incompetencia. En general, le ayudará a resolver exactamente sus problemas. Este año entro al programa de maestría en la Universidad Estatal de Bielorrusia con un título en tecnologías de gestión de recursos humanos y planeo considerar en detalle los pros y los contras, así como las limitaciones de la aplicabilidad de las metodologías de desarrollo de software más comunes.

En el proceso de trabajo, a menudo encontré malentendidos e interpretaciones incorrectas de herramientas metodológicas, el uso de metodologías de moda sin tener en cuenta el contexto. Después de leer el artículo, me di cuenta de que el problema es más global que local. Hoy propongo echar un vistazo a Kanban, su historia, principios básicos y posibles límites de aplicación.

Historia del término

Kanban es un término japonés que comenzó a utilizarse en relación con la producción en los años 60 del siglo XX en Toyota. Este principio se basa en el método de producción del transportador, así como en diferentes velocidades para realizar operaciones tecnológicas individuales en la producción. Intentaré explicarlo con mis dedos. En cualquier producción existe una producción principal (“transportador principal”) y una producción adicional (“transportadores adicionales”). La tasa de producción de productos finales la establece el transportador principal, mientras que los transportadores adicionales no pueden acelerar la tasa de liberación del producto, pero pueden disminuirla si las piezas requeridas no se liberan a tiempo.

Además, durante la producción puede haber un cambio de prioridades. Por ejemplo, resultó que la estación que producía los espejos izquierdos producía 20 piezas y la estación que producía los espejos derechos producía 10 piezas, mientras que hay 15 automóviles en la línea de montaje y se necesitan 15 piezas de espejos de ambos tipos. Hay un conflicto de métricas: la producción no ha disminuido cuantitativamente (los transportadores adicionales produjeron 30 productos a tiempo), pero aún existe el riesgo de que la producción se detenga. Kanban está diseñado para ayudar con este problema.

En su forma más simple, Kanban incluye dos reglas simples:

• La estación de producción tiene un plan de producción de piezas (“backlog”). El plan está ordenado por prioridad y puede cambiar en cualquier momento (por ejemplo, una estación que produce demasiados espejos izquierdos debería poder cambiar a espejos derechos lo antes posible);
• el número de tareas realizadas en la estación simultáneamente es limitado (es decir, no producir más de un número determinado de espejos al mismo tiempo). Esta limitación es necesaria para controlar la velocidad de producción en la estación, así como la velocidad de respuesta a los cambios de plan.

Tiempo presente

Últimamente, Kanban ha ido ganando mucha popularidad en la producción de software. Algunos equipos encuentran esta metodología extremadamente útil, otros la utilizan como un "culto a la carga". Según mi experiencia empírica, Kanban puro funciona mal para equipos de productos (léase "canal principal"), pero funciona muy bien para equipos de soporte como:

• grupos de soporte de software, donde el "plan" no es importante, pero sí la velocidad de respuesta a los cambios;
• equipos de prueba que trabajan por separado de los equipos de desarrollo;
• Servicios de apoyo;
• otros ejemplos de “industrias no esenciales”.

Por otra parte, cabe señalar que Kanban funciona bien en startups que no tienen un plan claro, pero que están trabajando activamente en el desarrollo. Propongo considerar un ejemplo del uso de Kanban en el desarrollo de software. Pido disculpas de antemano por las feas ilustraciones. Imaginemos un equipo de un desarrollador trabajando en un proyecto pequeño. El plan de desarrollo (atraso) se ordena por orden de prioridad de las piezas de trabajo, el límite del equipo para las tareas en el proceso es 1 pieza.

Para gestionar el proceso, el director del proyecto puede:

1. cambiar el límite en el número de tareas en trabajo;
2. agregue una tarea con una prioridad más alta (por ejemplo p0) para que se realice lo antes posible;

Durante el proceso de trabajo, puede suceder que el trabajo se bloquee (el hosting se ha estropeado, no se ha descargado el framework necesario, etc.). En general, el trabajo bloqueado se devuelve al trabajo pendiente y se selecciona una nueva tarea con la mayor prioridad. Dependiendo de la naturaleza de las tareas y del tipo de equipo, el límite podrá aumentar o disminuir. Por ejemplo, nuestro desarrollador puede crear simultáneamente un formulario de registro y observar el proceso de implementación de un nuevo servidor. Sin embargo, si el tiempo de finalización de la tarea es menor que el requerido, el director del proyecto puede reducir el límite o aumentar el equipo. Así, con una gestión adecuada, Kanban proporciona la mayor velocidad de trabajo posible para un determinado equipo, máxima velocidad de respuesta a los cambios y al mismo tiempo reduce los “costos” de soporte de la metodología. ¡Bueno eso es todo! Kanban no es fácil, simple. ¡Es muy sencillo!

Las limitaciones de Kanban cuando se utiliza en equipos de productos incluyen:

• esta metodología no funciona bien con equipos grandes (más de 5 personas);
• En su forma pura, Kanban no funciona bien con equipos multifuncionales. Aquellos. A diferencia de Scrum, es difícil combinar pruebas y desarrollo en un solo equipo. Una mejor idea es dividir el proceso en una “estación” de desarrollo y una “estación” de pruebas con administradores y trabajos pendientes separados;
• Debido a su historia y especificidades, Kanban no está destinado a una planificación a largo plazo.

Conclusión

En conclusión, me gustaría agregar que comparar cualquier metodología según el principio de "quién es más genial" no es productivo ni contraconstructivo (Capitán Obvio). Cada metodología más o menos común tiene sus pros, sus contras y sus límites de aplicación. Además, las metodologías ágiles imponen inherentemente mayores exigencias al trabajo en equipo y la experiencia de los miembros del equipo.

Si hay interés en el tema, continuaré considerando Kanban con más detalle y luego propongo clasificar Scrum y RUP en partes e imágenes.

Puedes verlo con más detalle y claridad.

Kanban: ¿qué es? ¿Cuánta información interesante contiene una tarjeta Kanban y qué función cumple el método en la producción? En el artículo explicaremos en detalle las reglas para el uso efectivo de Kanban y también daremos una descripción clara del esquema para usar las tarjetas correspondientes usando un ejemplo específico. Además, tras familiarizarte con el material, aprenderás por qué es necesario un tablero Kanban, en qué áreas, además de la producción, es recomendable utilizar este método, y cuál puede ser una buena alternativa al mismo.

La esencia del concepto y las principales características del método.

Hoy en día se puede observar una clara tendencia hacia el aumento de los costos de almacenamiento de inventarios, que es la razón principal de la formación de complejos de gestión de inventarios "instantáneos", que incluyen el sistema kanban. Traducido del japonés, "kanban" significa "etiqueta", "insignia". Este término sirve como un método de información a través del cual se da permiso o indicación para la producción o exclusión (transferencia) de un producto en un sistema pull.

La opción presentada para transmitir información le permite gestionar completamente líneas de producción ajustadas mediante el uso de tarjetas de información para transferir una orden de producción específica de la siguiente etapa a la anterior.

El desarrollador de este sistema productivo es Toyota Motors, lo que explica la idea presentada como uno de los primeros intentos de implementar en la práctica el método justo a tiempo. Según el sistema kanban, la producción se lleva a cabo de acuerdo con la siguiente regla: las divisiones de la empresa reciben recursos en una cantidad específica y dentro de un plazo claramente definido necesario para completar el pedido.

Detalles del proceso

El esquema del método presentado es extremadamente simple, sin embargo, tiene un efecto muy efectivo en la organización del proceso de producción. Después de abastecer las divisiones de la empresa en términos de recursos, se realiza un cálculo detallado del volumen requerido de trabajo en curso, que debe provenir directamente de la penúltima etapa (el pedido del producto terminado, en consecuencia, es la etapa final de el proceso). Del mismo modo, desde la penúltima etapa se solicita a la etapa anterior un volumen específico de productos semiacabados.

Por lo tanto, la escala de producción en un sitio determinado se forma de acuerdo con las necesidades de la siguiente etapa de producción. Es lógico que entre cada dos etapas del proceso productivo situadas en las proximidades se establezca un doble tipo de conexión:

1. Desde la enésima etapa hasta la n-1, se solicita (“tira”) la cantidad requerida de trabajo en progreso.
2. Desde la etapa n-1 hasta la etapa n, los recursos materiales se envían en el volumen requerido.

Herramientas de transferencia de información

Para comprender mejor qué es Kanban, debe comprender que la herramienta para transmitir información en este sistema son tarjetas especiales, que se clasifican en dos grupos:

1. Herramientas directamente relacionadas con la orden de producción. En este tipo de fichas se indica en primer lugar el número de piezas que se deben producir en la etapa anterior del proceso productivo. Se envían desde la enésima etapa de producción a la n-1 y sirven como motivo principal para desarrollar el programa de producción para estos sitios.
2. Las herramientas de selección contienen información sobre la cantidad de recursos materiales necesarios (esto puede incluir productos semiacabados, materiales, piezas, etc.) que se deben tomar en la etapa de montaje previa. Las tarjetas de este tipo muestran el volumen de recursos realmente recibido por la enésima etapa del proceso de producción desde la n-1.

Es importante señalar que las tarjetas pueden circular no solo en relación con la infraestructura interna de la empresa, sino también entre sus sucursales o corporaciones que apoyan la cooperación.

Métodos eficaces de uso de Kanban: ¿qué es?

Taiichi Ohno, presidente de Toyota Motor Corporation, ha desarrollado una serie de principios para utilizar tarjetas kanban con la máxima eficiencia:

• La operación posterior de la actividad productiva elimina el volumen de piezas indicado por la ficha de la operación anterior.
• La operación de producción ubicada al frente se realiza de acuerdo con la creación de piezas en la cantidad y secuencia indicadas en una tarjeta específica.
• No hay piezas que se puedan crear sin una tarjeta. Esta disposición permite reducir la sobreproducción, así como el movimiento excesivo de productos. Por tanto, el volumen de tarjetas en circulación es igual a la cantidad máxima de inventario.
• Una tarjeta es un pedido para la fabricación de un producto (el producto en cualquier caso va adjunto a la tarjeta correspondiente).
• Las piezas que tengan algún defecto no pueden pasar al proceso posterior. Esta disposición permite que la producción de productos esté lo más libre de defectos posible.
• Reducir el número de tarjetas aumenta su nivel de sensibilidad. De esta forma, salen a la luz los problemas existentes y se lleva a cabo un control efectivo de los inventarios.

Características del uso de tarjetas.

Al final resultó que, la gestión kanban se lleva a cabo de acuerdo con un esquema determinado, que implica el uso de tarjetas especiales. Así, durante su uso, se deben cumplir plenamente los requisitos para garantizar una visibilidad absoluta y la máxima seguridad del sistema en cuestión: se elimina por completo la pérdida de tarjetas, así como su mezcla.

Los expertos han desarrollado una herramienta eficaz que permite proporcionar la máxima productividad al sistema Kanban. El tablero de este método sirve como punto de recogida de tarjetas activas, ya que los empleados suelen utilizar varias herramientas diferentes en el lugar de trabajo. Así, las tarjetas que van al fabricante se colocan en el tablero de control. Y cuando las herramientas de tarjetas recién recibidas llegan al campo "inicio", se transfiere todo el juego de tarjetas del número de pieza correspondiente para llevar a cabo el proceso de producción posterior.

Beneficios de utilizar el método Kanban: ¿qué es?

Las empresas que lo utilizan reciben suministros diarios de recursos materiales (y a menudo varias veces a lo largo del día). Esto permite actualizar completamente los inventarios de producción aproximadamente entre 100 y 300 veces al año. Si comparamos Kanban con sistemas como MRP o MAP, en este caso las actualizaciones ocurren aproximadamente 10 veces más a menudo.

Es recomendable evaluar el método kanban con ejemplos que revelen su ventaja absoluta sobre otros menos productivos. Así, Toyota Motors Corporation suministró recursos a uno de los numerosos centros de producción tres veces al día en 1976, y en 1983, cada diez minutos.

Los Kanbans se utilizan a menudo cuando se trabaja con supermercados (stock especialmente formado para este propósito). Así, el consumidor envía un kanban de selección al supermercado, que indica, como se señaló anteriormente, el volumen del producto, y el supermercado le transfiere la cantidad especificada de productos. Al mismo tiempo, el supermercado envía un kanban de reabastecimiento al proveedor, tras lo cual el proveedor transfiere los productos al supermercado.

Elementos fundamentales del método.

Los componentes más importantes de un sistema kanban son los siguientes:

1. Un complejo de información que contiene en su estructura no sólo tarjetas, sino también cronogramas de producción, transporte o suministro, así como mapas tecnológicos.
2. Un complejo que está directamente relacionado con el control de las necesidades y a nivel profesional.
3. Un complejo que permite el control de calidad total (TQM) y selectivo (Jidoka) del producto.
4. Un complejo que asegura una nivelación absoluta de la producción.

Los elementos presentados, utilizados en conjunto, permiten lograr el ciclo de producción más corto, un alto nivel de rotación de activos (incluidos los inventarios), así como eliminar o minimizar los costos de almacenamiento tanto para la producción como para, por supuesto, lograr la más alta calidad del producto. producto en cada etapa del proceso productivo.

Desventajas del sistema y los resultados de su uso.

Como cualquier desarrollo, el sistema justo a tiempo tiene algunas desventajas. En primer lugar, la dificultad de organizar un alto nivel de coherencia entre las etapas de producción de un producto en particular.

En segundo lugar, existe un riesgo importante de perturbación del proceso de producción y, en consecuencia, de la venta de productos. Sin embargo, un análisis detallado de la práctica mundial en relación con la aplicación del método en cuestión mostró que el sistema presentado permite reducir los inventarios de producción a la mitad y el inventario en un 8%, con una aceleración significativa de la rotación del capital de trabajo y , por supuesto, un aumento en la calidad del producto terminado.

Es importante señalar que el uso de kanbans no termina con los procesos de producción. Por lo tanto, el sistema se utiliza activamente en actividades de oficina y proyectos, en programación (existe todo un complejo de desarrollo kanban), así como en la consecución de resultados personales (tipo de kanban personal).

El sistema kanban comenzó su andadura en la década de 1950 en las líneas de producción de Toyota Corporation, tras lo cual migró a las oficinas y se convirtió en una importante herramienta para los directores de proyectos.

La infinita flexibilidad de la práctica y sus oportunidades para la autoorganización del personal hicieron posible lograr eficiencia donde otros enfoques no funcionaban. Este es el caso cuando la propia tarjeta se convirtió en la tarjeta de visita del sistema: se estableció como moneda interna en las organizaciones que implementaron Kanban.

Origen

Al igual que el concepto de manufactura esbelta, el sistema kanban fue desarrollado por los gerentes de Toyota. El autor del sistema, el ingeniero japonés Taiichi Ono, se inspiró en el principio de funcionamiento de los supermercados estadounidenses, donde el propio comprador elige los productos que necesita. El papel de “supermercado” en la corporación Toyota lo desempeñaba un almacén.

Allí, las tarjetas de señales, y así se traduce literalmente "kanban" del japonés, los trabajadores intercambiaban tarjetas de señales, regulando el proceso de producción con sus propias manos.

Las tarjetas estaban adheridas a contenedores con piezas. Estas etiquetas contenían información sobre el número y la cantidad de piezas, qué departamento las enviaba y dónde debían llegar.

El trabajador que participó directamente en la instalación y el montaje de las máquinas, el downstream, tomó las piezas del contenedor, al que se adjuntó un "kanban" con una solicitud para el almacén. La tarjeta fue retirada y, junto con la caja vacía, fue trasladada por el transportista al almacén. Allí, otro empleado ya había preparado un nuevo contenedor de repuestos, en el que estaba adherido un "kanban" de producción, una etiqueta con información sobre los repuestos producidos.

El kanban de producción se reemplazó por un kanban de solicitud para el almacén y se envió a la línea de producción de piezas, aguas arriba. Por lo tanto, se produjo exactamente la cantidad de piezas que se indicaba en la tarjeta. Los contenedores con repuestos nuevos fueron llevados a los transportadores de la línea de montaje.

Principios Kanban

Los gerentes de Toyota formularon 6 reglas que forman el sistema:

1. Los trabajadores intermedios retiran exactamente tantas piezas del almacén como se indica en el kanban.
2. Los representantes del upstream también suministran repuestos estrictamente de acuerdo con las tarjetas.
3. Nada se produce ni se mueve sin un Kanban.
4. Kanban siempre debe estar adjunto a las partes
5. Las piezas defectuosas no se utilizan en el sistema.
6. Reducir la cantidad de tarjetas kanban hace que la administración responda mejor al cambio. Pero a menos que sea absolutamente necesario, no debes cambiar el número de tarjetas establecido.

Kanban es un sistema "pull". Crea un equilibrio entre un flujo constante, que elimina los costos de espera, y un trabajo en proceso mínimo (WIP), que reduce el riesgo de sobreproducción. El RVP se regula mediante tarjetas: su número es fijo y las instrucciones que contienen guían a los ejecutores posteriores.

La regla de una etiqueta obligatoria funciona como la ley de conservación de la energía.

El límite de RVP se establece en proporción al número de tarjetas kanban, el cual se calcula en función del nivel de ventas y de la variación estadística de los procesos actuales. El número máximo de etiquetas (la misma “energía” en el sistema) fija el nivel superior del RVP en un momento dado. RVP también está limitado por el principio de tracción: la velocidad de producción del flujo superior depende de la velocidad del flujo inferior.

El gráfico muestra que uno de los elementos básicos del sistema es la cultura Kaizen. El proceso autónomo y la variación estándar liberan a la gerencia de una gestión constante para que puedan concentrarse en mejorar el desempeño de los empleados.

Aplicación de Kanban en TI

Si bien Kanban continúa aportando valor en las líneas de producción, se ha abierto camino en el mundo del software.

Solo las tarjetas que contienen información sobre los plazos, una descripción o número de proceso y el nombre del ejecutante ahora no se adjuntan al contenedor con repuestos, sino a un tablero con columnas alineadas:

• Trabajo pendiente: tareas que deben completarse
• Tareas que se están desarrollando actualmente
• Tareas que se completaron pero que aún no se transfirieron a los evaluadores
• Tareas listas para ser transferidas al departamento de pruebas.
• Tareas que son revisadas por el director del proyecto (PM)
• Tareas completadas

Por lo general, se escribe un número encima de las columnas: límite, indicando el número máximo de procesos en el mismo. El límite de atraso se calcula en función del tiempo de entrega. Si el sistema tiene 5 trabajos en progreso y cada uno de ellos tarda un promedio de 1 día en completarse, entonces el trabajo pendiente se puede limitar a un límite de 5.

La estructura anterior no es estricta. Dependiendo de las características específicas del proyecto, se pueden agregar parlantes improvisados. A menudo existe un sistema kanban en el que es necesario determinar los criterios de preparación de una tarea antes de su ejecución. Luego aparecen dos columnas, que en inglés se llaman especificar(especificar parámetros) y ejecutar(empezar a trabajar).

• Más Se puede agregar una columna con una cola de prioridad.Cuando el ejecutante está libre, debe vaciar esta columna particular de tareas y luego asumir otras.
• Las tareas que no se completaron se devuelven al trabajo pendiente o se eliminan del esquema.

• Kanban no fomenta la multitarea, por lo que Se establece un límite de proceso para un ejecutor.

• Es preferible el trabajo terminado a varios iniciados.

• Puedes aceptar un segundo trabajo si el primero fue bloqueado.
• El tiempo para completar una tarea debe estar equilibrado.Un período demasiado corto afectará la calidad. Un límite demasiado extendido desperdicia recursos del equipo y aumenta el costo del proceso.

¿Por qué se utiliza un tablero Kanban en todas partes y no, por ejemplo, en tabletas o en un monitor enorme? Como responden a esta pregunta los fanáticos del sistema, una placa normal tiene dos ventajas: es simple y proporciona control visual. Es fácil realizar cambios y proporciona interacción táctil y social entre los miembros del equipo.

Ventajas y desventajas de Kanban

Kanban tiene las siguientes ventajas:

1. Flexibilidad de planificación. El equipo se concentra solo en el trabajo actual, la prioridad de la tarea la establece el gerente.
2. Alta implicación del equipo en el proceso de desarrollo. A través de reuniones periódicas, procesos transparentes y oportunidades de autoorganización, los empleados se unen y muestran un interés genuino.
3. Duración del ciclo más corta. Si varias personas tienen habilidades similares la duración se reduce, pero si solo hay una aparece un cuello de botella. Por tanto, los empleados deben compartir conocimientos y así optimizar los tiempos de los ciclos. Luego, todo el equipo puede retomar el trabajo que se ha estancado y restablecer el flujo fluido.
4. Menos cuellos de botella. Los límites de RVP le permiten encontrar rápidamente cuellos de botella y áreas problemáticas que han surgido debido a la falta de atención, personas o habilidades.
5. Visibilidad. Cuando todos los trabajadores tienen acceso a los datos, los cuellos de botella son más fáciles de detectar. Los equipos Kanban, además de las propias tarjetas, suelen utilizar dos informes generales: gráficos de control y de flujo acumulativo.

En la práctica, el sistema funciona bien en áreas de producción complementarias:

• equipos de soporte de software o mesa de ayuda.
• Kanban funciona bien cuando se gestionan nuevas empresas sin un plan claro, pero cuyo desarrollo avanza activamente.

Kanban también tiene desventajas:

1. el sistema no funciona bien con equipos de más de 5 personas
2. no está destinado a la planificación a largo plazo.

Diferencias con Scrum

Scrum, al igual que el kanban ágil, es una metodología flexible y también se utiliza a menudo en el campo de TI. Las diferencias entre ellos no son evidentes a primera vista. Hay muchas similitudes, por ejemplo, la presencia de retrasos en ambos enfoques.

	Melé	Kanban
Paso	Sprints repetibles de duración fija.	Proceso continuo
lanzamiento de lanzamiento	Al final de cada sprint después de la aprobación del director del proyecto (propietario del producto)	El flujo continúa sin interrupción o a criterio del equipo.
Roles	Propietario de producto, Scrum Master, equipo de desarrollo	Un equipo dirigido por un PM, en algunos casos participan entrenadores de kanban ágiles.
Principales indicadores	Velocidad del equipo	Plazo de EJECUCION
Aceptabilidad de los cambios	Los cambios durante un sprint no son deseables ya que pueden conducir a estimaciones incorrectas de las tareas.	El cambio puede ocurrir en cualquier momento

Ejemplos de aplicación en TI

Directamente de Microsoft: Kanban debuta en el desarrollo de software

El uso de los principios Kanban en la industria de la tecnología de la información comenzó hace poco más de 10 años. David Anderson, uno de los principales divulgadores de Kanban para desarrolladores de software, fue consultor de Microsoft en 2005. No estaban satisfechos con el trabajo de su departamento, XIT Sustained Engineering, que eliminó errores en las aplicaciones internas. A principios del año del informe, este departamento era el peor de su departamento. El trabajo pendiente excedió el tamaño permitido en 5 veces y el tiempo para procesar una solicitud fue plazo de EJECUCION- normalmente tardaba 5 meses.

El nuevo primer ministro, con la ayuda de las consultas de Anderson, aumentó la productividad del departamento de problemas en un 155% en 9 meses. Plazo de EJECUCION Ahora eran 5 semanas, el trabajo pendiente volvió a su tamaño normal y la finalización de las tareas a tiempo se estableció en un 90%. Todos estos resultados se lograron con una participación mínima de los nuevos empleados; el personal continuó corrigiendo errores de software utilizando los mismos métodos. Sólo han cambiado los enfoques para organizar el trabajo.

Dato interesante: el director del programa Dragos Dumitriu, que se comprometió a cambiar el rumbo del XIT, quedó fascinado con el libro de Anderson. Para su sorpresa, conoció al ideólogo del software Kanban en la propia Microsoft, donde había conseguido trabajo el día anterior. Dumitriu pidió ayuda a Anderson en su tarea y este accedió a poner en práctica los principios de su libro.

Dumitriu encontró un departamento formado por tres desarrolladores y tres testers que tenían 80 solicitudes acumuladas en su cartera de pedidos. El propio primer ministro fue nombrado temporalmente, ya que los requisitos para el puesto incluían capacidad para trabajar con tecnología ASP, administración mediante SQL Server y conocimiento de MS Project Server. Los jefes vieron este puesto como el de un “técnico” que sabe programar, debe compilar informes y predecir la carga atrasada. Entonces se creía que el problema del departamento se identificaría si se recogiera una impresionante variedad de datos. Dumitriu no era tan “técnico”.

Sin embargo, cuando él y Anderson comenzaron a analizar el desempeño de XIT, rápidamente identificó factores clave que estaban impactando negativamente la velocidad del departamento:

• Tomó demasiado tiempo predecir las consecuencias (ROM) de ejecutar una solicitud. Tanto el desarrollador como el tester tuvieron que dedicar un día completo a realizar los cálculos necesarios, revisiones de código y documentación completa. En promedio, se recibió una solicitud diaria. Según estimaciones de PM, el 40% de la productividad del departamento se gastó en ROM;
• Se dio prioridad a las solicitudes de mayor valor. XIT recibió financiación del coste del pedido. La prioridad de las solicitudes se discutía todos los meses en una reunión de jefes de departamento con clientes, jefes de otros departamentos. Con un atraso enorme al ritmo actual, cuando solo se procesaban entre 6 y 7 solicitudes por mes, las prioridades de otras solicitudes cambiaban constantemente debido al paso del tiempo. Muchos de ellos fueron pospuestos para un impresionante “más tarde”, ni siquiera igual al mes siguiente.
• En la etapa ROM se eliminaron la mitad de las solicitudes. Algunos de ellos eran demasiado grandes y fueron recalificados como proyectos para transferirlos a otros departamentos, otros eran demasiado caros y simplemente se cancelaron. Algunas solicitudes no se llevaron a cabo porque su implementación habría sido demasiado larga. Así, el 40% de la productividad del departamento se dedicó al análisis de solicitudes, de las cuales el 50% fueron rechazadas. Se desperdiciaron entre el 15 y el 20% de los recursos laborales.
• El trabajo preparatorio de la solicitud podría durar meses antes de que comience la implementación. Los cálculos en la etapa ROM podrían perderse u olvidarse durante este tiempo. Especialmente si la implementación no la realizó el mismo desarrollador que inició el análisis.

Soluciones Kanban para un departamento de Microsoft con problemas

1. Dumitriu y Anderson insistieron en conversaciones con la dirección y los responsables de clientes en abandonar la etapa ROM. Los cálculos se realizaron inmediatamente antes de la implementación y por el mismo ejecutante, es decir, permanecieron "frescos".
2. La priorización de las solicitudes no se realizó durante reuniones mensuales, sino según la situación, a través de llamadas telefónicas o correos electrónicos. Se clasificaron 80 tareas pendientes en función de los clientes. A estos últimos se les pidió que resaltaran las consultas principales que deben completarse primero.
3. La financiación del XIT se ha vuelto fija.
4. El coste de las solicitudes ya no se tiene en cuenta.
5. El primer ministro ingresó buffers en el tablero Kanban. Los desarrolladores trabajaron en dos zonas: tareas aprobadas y completadas. Había 6 solicitudes en el búfer, 5 se pusieron a trabajar. Probadores seleccionados del búfer "en espera de prueba". Algunas tareas que no requerían cambios en el código terminaron allí, evitando a los desarrolladores. Al dividir las solicitudes en procesos de tarea única, el PM podría tener un mayor control sobre la situación, además de brindar transparencia a los clientes. La introducción de amortiguadores redujo el tiempo de entrega. Los clientes, bajo un sistema predecible, están en mejores condiciones de determinar qué solicitud debe almacenarse a continuación.
6. Si las solicitudes eran demasiado grandes o costosas, se tomaba una decisión de inmediato. Si el desarrollador confirmaba que estaba listo para completar la tarea dentro de los 15 días o que los cambios valían la pena, entonces se aceptaba la solicitud, independientemente del tamaño o el costo.
7. Después de observar el flujo en el departamento, el primer ministro llegó a la conclusión de que era necesario cambiar la estructura del personal a favor de los desarrolladores que estaban más cargados de trabajo. Los cambios se realizaron en una proporción de 2:1: 4 desarrolladores y 2 testers comenzaron a trabajar en XIT.

A finales de 2005, la productividad del departamento aumentó un 155%. Para mejorar aún más el trabajo de XIT, se contrataron allí dos empleados: un desarrollador y un evaluador. La cantidad de solicitudes pendientes se redujo a 10 y un desarrollador comenzó a procesar de manera constante 11 solicitudes por trimestre. En promedio, se completaron 56 solicitudes por trimestre, en comparación con las 11 anteriores. El coste de las solicitudes bajó de 7.500 dólares a 2.900 dólares.

Aplicación en Corbis

Después de haber logrado el éxito en Microsoft, Anderson comenzó a resolver un nuevo desafío en 2006. Ahora trabajaba en Corbis, otra empresa de Bill Gates, que aún no había abandonado MS. Una de las actividades de Corbis fue la concesión de licencias fotográficas. En aquel momento era el segundo banco de fotografías más grande del mundo, con una base de datos de aproximadamente 3,5 mil imágenes.

El trabajo de Anderson era acelerar los principales lanzamientos de la empresa. El intervalo entre sus salidas fue de tres meses y podría alargarse aún más. Sólo discutir el plan de lanzamiento llevó a la gerencia dos semanas. Era necesario organizar lanzamientos menores o actualizaciones cada dos semanas. Al mismo tiempo, hubo que destinar recursos clave al trabajo en el proyecto principal.

Apareció un tablero Kanban en la oficina de Corbis, donde Anderson se comunicaba diariamente con el equipo. El objetivo del PM era mejorar el control visual de los procesos, promover la autoorganización y una mayor responsabilidad personal de los ejecutantes. El sistema Kanban también tenía como objetivo reducir la supervisión de la gestión y aumentar la productividad.

Además de las tarjetas y gráficos multicolores, en el tablero apareció un "contenedor de basura", al que se enviaron tareas demasiado grandes.

Foto del funcionario.

Un sistema Kanban para mantener la ingeniería en sistemas de software por David J Anderson

El sistema kanban dejó claro dónde el flujo deja de ser fluido y dónde se producen retrasos, el llamado cuello de botella. Las discusiones rápidas con el equipo ayudaron a identificar los problemas actuales. Por ejemplo, las pruebas duraron 3 días, lo que afectó negativamente la fecha de lanzamiento. Tres empleados se unieron y encontraron una manera de reducir el tiempo a un día.

Un cuello de botella es una sección del esquema o algoritmo operativo de una empresa donde las limitaciones de recursos o la productividad de las personas reducen drásticamente el flujo de tareas. La escasez de trabajadores, una mala conexión a Internet o un director de vacaciones bloquea o ralentiza la realización de tareas.

Los límites de las tarjetas Kanban se establecieron empíricamente dos veces. En la columna "listo para el desarrollo", se han aumentado los límites. También hay una nueva columna: "listo para probar". Muchas solicitudes para el downstream se formularon incorrectamente, lo que provocó una pérdida de tiempo innecesaria. Por lo tanto, el PM examinó el funcionamiento del flujo superior y encontró errores.

El procesamiento de solicitudes podía tardar 100 días, pero aun así los lanzamientos comenzaron a publicarse cada dos semanas, como estaba previsto. La decisión sobre el contenido del número se tomó 5 días antes de su publicación. Las prácticas de conteo, como en el caso del departamento XIT de Microsoft, se abandonaron en favor de la productividad. Las tareas se priorizaron según el “coste del retraso” o la disponibilidad de recursos.

El sistema Kanban no sólo ayudó a Anderson a lograr su objetivo, sino que también mejoró el estado de ánimo del equipo. Gracias a las discusiones conjuntas y la visibilidad de los procesos, los empleados desarrollaron confianza entre sí. El personal también se adhirió al Kaizen, es decir, la práctica de mejora continua.

¿Qué es la metodología kanban y cómo te ayuda a completar las tareas a tiempo?

En condiciones de multitarea constante y una gran cantidad de clientes, tarde o temprano cualquier sistema se sobrecarga. Los plazos comienzan a incumplirse, las expectativas no se cumplen y el sistema se convierte en un caos. Hoy propongo familiarizarme con una metodología como kanban. Este enfoque promete asignar recursos de manera efectiva y resolver todos nuestros problemas. Vamos a revisar.

Un momento de la historia kanban

La base de la idea Kaban fue inventada por Toyoyta Motors. Un fabricante de automóviles estaba sufriendo grandes pérdidas debido a una asignación inadecuada de inventario y capacidad en la línea de producción. Algunas etapas de producción podrían estar inactivas y otras sobrecargadas.

En 1959 se propuso un sistema de control de producción que permitía equilibrar todos los tramos de la línea. El principio básico era que en cada etapa los trabajadores colocaban tarjetas con el número requerido de piezas, que se pasaban a lo largo de la línea. Cada trabajador que seguía la línea de producción tomó exactamente tantas piezas del anterior como le había sido asignada en la tarjeta.

De esta manera, cada pieza tenía una tarjeta y simplemente no podía haber excedente. Como resultado, los inventarios no crecieron en las áreas y cada trabajador posterior recibió exactamente la cantidad de piezas que necesitaba.

Formulemos qué es kanban y apliquémoslo al desarrollo de productos de Internet.

Kanban es un sistema de gestión de fabricación ajustada (en japonés: "señal"/"tarjeta") que utiliza tarjetas de información para comunicar pedidos en todas las etapas de producción. En palabras simples, rastreamos todo el recorrido de un producto, desde la idea hasta su lanzamiento en el lineal de la tienda.

Arriba hay un tablero kanban. Esta es la herramienta principal para mostrar el estado de la tarea. El principio fundamental: vemos en qué etapa del proceso de producción se encuentra una tarea en particular. Además, se realiza un seguimiento del tiempo en todas las áreas, es decir, siempre puedes encontrar " " en el sistema y trabajar con ellos.

Usted mismo determina el número de columnas en función de las características de su proyecto. Es importante que estas sean las principales etapas por las que pasa tu producto. El ejemplo anterior muestra más o menos las etapas principales por las que pasa un producto en línea.

La aplicación de la metodología es muy amplia. Kanban se utiliza para la implementación de proyectos, gestión de ventas, líneas de producción, desarrollo de TI e incluso para organizar su propia vida.

Perdón por interrumpir la lectura. Únete a mi canal de Telegram. Nuevos anuncios de artículos, desarrollo de productos digitales y growth hack, todo está ahí. ¡Esperando por ti! Continuemos...

Principios Kanban

• Visualización visual de tareas. Todas las tareas deben presentarse en forma de tarjetas y reflejarse en la pizarra. Es muy importante actualizar el estado de las tareas. Por ejemplo, si los desarrolladores prepararon el código y lo enviaron para probarlo, entonces la tarjeta de tarea debe ir a la columna correspondiente. De esta forma, cualquier miembro del equipo puede ver en cualquier momento en qué etapa se encuentra la tarea.
• Limitación de las columnas WIP (trabajo en curso o trabajo realizado simultáneamente) en cada etapa de producción. Para que el sistema tarde o temprano no se "ahogue" con el flujo de tareas, es necesario establecer restricciones. Por ejemplo, en el tablero kanban de arriba en la columna Análisis, tenemos 2 personas trabajando y no pueden manejar más de 2 tareas, no tiene sentido cargarlas más, ya que las etapas posteriores del sistema estarán inactivas. Las restricciones de columna se seleccionan empíricamente.
• Concéntrese en las tareas no cumplidas. Al mirar el tablero con tareas, en primer lugar preste atención a aquellas tareas que "cuelga" en una u otra columna. Si una de las etapas le lleva más tiempo, intente redistribuir recursos o agregar personas, si es posible.
• Mejora continua. Una vez que equilibre la carga en el sistema, le resultará más fácil monitorear todo el proceso. Mida el tiempo del ciclo (cuánto tiempo permanece la tarea en una columna separada y cuánto tiempo transcurre desde el momento en que ingresa a Por hacer hasta que se lanza Listo). Cambie las cargas en el sistema y reduzca el tiempo que lleva completar todas las etapas.
• Presta atención a los detalles. Por ejemplo, si el código que los desarrolladores escriben periódicamente no pasa las pruebas y se devuelve para revisión, entonces ¿quizás haya opciones para mejorar la calidad del desarrollo para que se pruebe un producto de mayor calidad?

El enfoque kanban puede parecer idealista, pero les aseguro que sus principios producen resultados. En primer lugar, es necesario adaptar la metodología a su situación y luego pulir el sistema.

herramientas kanban

O dónde mantener un tablero kanban.

• tablas de excel
• tablero con pegatinas
• Otra fantasía...

De hecho, hay muchas opciones, puedes buscarlas en Google e inspirarte. Lo principal es que tienes este tablero y todos los participantes en el proceso pueden ver lo que está sucediendo con las tareas en este momento.

Ejemplos de tableros kanban

Aquí tenéis un tablero que cuelga de la pared, donde cada tarea está reflejada en notas adhesivas.

O podría ser un servicio en la nube como Trello.

Hay varias opiniones sobre qué herramientas y opciones utilizar en su trabajo, pero esto es principalmente una cuestión de gustos. Simplemente pruebe diferentes soluciones y decídase por la que más le guste. La cuestión es empezar a utilizar kanban y no quedarse estancado en utilizar el tablero más bonito posible.

Mi opinión es la siguiente: para realizar una lluvia de ideas o trabajar en casos sin conexión, un tablero normal con pegatinas funciona bien. Pero para el trabajo diario, por supuesto, es necesario utilizar una solución en la nube como Jira, Kanbantool, Trello, etc. En ellos, todo el equipo puede agregar comentarios a las tareas, moverlas por columnas y mucho más.

Matices/pensamientos

Si hablamos de productos de Internet, entonces el kanban funciona, ayuda y mejora, pero hay una serie de inquietudes o matices que hay que tener en cuenta.

• Lo más probable es que la introducción de límites de WIP en una columna asuste un poco al equipo de gestión del proyecto. Al fin y al cabo, ¿cómo se puede determinar cuántas tareas puede resolver un desarrollador o, por ejemplo, un tester en paralelo? ¿Qué pasa si introducimos restricciones y ellos simplemente se relajan?

Verá, si una persona no está completamente cargada, esto no está mal. Puede estudiar y analizar el trabajo realizado, encontrar deficiencias y corregirlas, e incluso descansar. Además, puedes ayudar a tus compañeros de otras partes del proceso (columnas), más detalles a continuación.

• Según los gurús de kanaban, el sistema funciona idealmente en equipos multifuncionales. Pues algo así, si no tienes nada que hacer, vete a ayudar a algún compañero de trabajo. Es cierto que para formar un equipo en el que los desarrolladores puedan ser probadores y viceversa, y el arquitecto del sistema ayude al diseñador, será necesario desembolsar mucho dinero. ¿Vale la pena?

Por supuesto, es fantástico cuando los miembros del equipo aprenden unos de otros y pueden ayudar de alguna manera si sucede algo. Pero para que se cumpla esta condición, es necesario contar con equipos pequeños que, preferiblemente, se encuentren en algún lugar cercano y se comuniquen constantemente. En proyectos grandes es difícil reproducir tal intercambio de experiencias.

Por lo tanto, me siento más inclinado a perfeccionar mis habilidades si tengo un momento de tranquilidad. Mira lo que hiciste, piensa en cómo puedes mejorarlo, lee artículos útiles. Una persona es un organismo vivo, no un engranaje de una cinta transportadora.

Total

Hemos analizado la metodología kanban y ahora espero que entiendas cómo aplicarla en tu proyecto. Intente dividir sus procesos en etapas principales y optimice el sistema en función del conocimiento adquirido.