¿Qué es el Método Kanban?, Conceptos y Funciones.
Incluso si nunca has trabajado o estudiado Kanban, si trabajas con agilidad, es probable que hayas escuchado alguna de estas frases:
Independientemente de tu nivel de conocimiento sobre agilidad, al final de este artículo podrás comprender cada una de estas frases y podrás identificar las correctas, las incorrectas y las que forman parte del universo Kanban.
Primero, debemos definir que este artículo trata específicamente sobre el Método Kanban y esto es importante porque kanban tiene varios significados diferentes:
Palabra japonesa: La palabra japonesa kanban significa "señalización" o "tarjeta" y podría usarse para referirse a un sistema de señalización que utiliza tarjetas.
Tablero Kanban: Varias metodologías y frameworks utilizados en agilidad, como Scrum(https://www.aluracursos.com/blog/que-es-scrum) , por ejemplo, utilizan un tablero que podemos llamar “Tablero Kanban”, en el cual tenemos unas tarjetas que se mueven por el tablero, es decir, unos “kanbans”.
Lean Manufacturing (el sistema de producción Toyota): En el sistema de producción de Toyota, ideado por el ingeniero Taiichi Ohno, en la década de 1950, se utilizaba la palabra kanban para referirse a la señalización creada para permitir el uso del sistema de tracción (esto lo detallaremos adelante).
Método Kanban: en 2010, David J. Anderson creó el modelo Kanban para el desarrollo de software, que combina elementos del pensamiento Lean con el pensamiento ágil en el proceso de desarrollo de software. Este nuevo modelo se denominó Método Kanban. Posteriormente, el Método Kanban evolucionaría para ser utilizado con otro tipo de productos, además del software.
David J. Anderson sugirió que el nombre Método Kanban siempre tenga la palabra Kanban escrita con una "K" mayúscula. Esto en un intento de diferenciar el Método Kanban de los otros significados de la palabra kanban (con una "k" minúscula). Anderson describió este método de trabajo en el libro “Kanban: Cambio evolutivo exitoso para su negocio de tecnología”, publicado en 2010. Ese mismo año, fue uno de los creadores de la Universidad Kaban(https://kanban.university).
En los materiales de Kanban University, como la Guía Oficial del Método Kanban (que se puede descargar desde el propio sitio web en 17 idiomas, incluidos inglés, portugués y español) siempre encontramos claramente la distinción entre el concepto de Método y Framework. Esto es para que los practicantes del Método Kanban tengan claro que la función y la forma de implementarlo es un poco diferente a la implementación de un marco, como Scrum, por ejemplo.
Una metodología, por otro lado, es mucho más prescriptiva y completa que un método o marco. Por lo tanto, el Método Kanban claramente no es una metodología.
El Método Kanban es un conjunto de principios y prácticas que tienen como objetivo proporcionar una evolución en la forma en que su equipo (o empresa) entrega valor en los servicios prestados. En Kanban, eliminamos el desperdicio y mejoramos la entrega continua de valor a través de un sistema pull.
Aunque la oración anterior parece solo un truco de marketing, hay una serie de conceptos técnicos incluidos en esta explicación, que veremos en detalle en este artículo.
Lo más interesante de estudiar el Método Kanban es que uno de sus principios es: “Empieza con lo que haces ahora” o “Empieza con lo que ya tienes”. Siguiendo este principio, es importante comprender bien la metodología, el método o el marco que ya está utilizando.
De esta forma, comenzaremos nuestro estudio precisamente conociendo los conceptos de agilidad que se relacionan con el Método Kanban y que también se utilizan en otras metodologías o frameworks.
En el primer tipo de sistema, un determinado servicio o determinada etapa de trabajo sólo se realizará cuando su valor (su resultado) sea necesario para la línea de producción o para la entrega del valor final del producto.
El tipo de trabajo del sistema pull dio lugar al concepto de Just in Time ("solo en el momento adecuado"), que luego se popularizó en la industria y los servicios.
Imagino que ahora es mucho más fácil entender la frase que usamos para definir el Método Kanban en el ítem “En resumen, qué es el Método Kanban”. Tal vez sea hora de releer la oración, tratando de entenderla un poco mejor. ¡Vuelve allí y vuelve a leer!
Luego de entender esta definición, la pregunta que suele surgir es: ¿Kanban reemplaza a Scrum o lo complementa?
La respuesta a esta pregunta es un poco más compleja de lo que parece. De hecho, Kanban y Scrum son “cosas” diferentes. Scrum es un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas a problemas complejos (definición presente en la Guía Scrum 2020). Kanban es un método basado en Lean Thinking y Agile Thinking, destinado a mejorar la ejecución de servicios, entregar valor de forma continua y hacer evolucionar continuamente el sistema de producción a través de la resolución sistemática de problemas.
En la práctica, la mayoría de los equipos eligen entre Scrum y Kanban según su entorno y necesidades. Sin embargo, muchas veces esta decisión acaba siendo tomada bajo la influencia de lo que el creador de la técnica de casos de uso, Ivar Jacobson, denominó la “Guerra de los Métodos”, la “propaganda” hecha por cada uno de los “métodos” (en este caso, “Métodos”). método” abarca el marco y la metodología también) como la “solución a todos los problemas”.
La fuerza de marketing de Scrum Framework es mucho mayor que la de otros métodos utilizados en la agilidad. Esto se debe en parte a la facilidad de comprensión del framework, incluso si su aplicación correcta es extremadamente compleja, y también a los esfuerzos de los creadores de Scrum para brindar cursos y certificaciones.
Sin embargo, se debe tener más en cuenta la facilidad de implementación del Método Kanban y los resultados más rápidos, incluso en equipos que saben poco sobre agilidad. La elección se puede realizar de una forma mucho más técnica, conociendo con un poco más de profundidad tanto el Framework Scrum como el Método Kanban.
Ahora es el momento de profundizar un poco más en el Método Kanban y aprender más sobre sus detalles. Lo haremos de forma evolutiva, tal y como recomienda el propio método.
La primera parte de estudiar el Método Kanban es comprender sus Principios y Prácticas, que guiarán todo el proceso de aprendizaje e implementación de este método.
Los principios son lineamientos que nos ayudan a tomar decisiones frente a los desafíos que se presentan en el proceso de implementación y uso del método. Estas son pautas generales que nos ayudan a saber qué camino tomar cuando surgen preguntas.
Podemos dividir los principios en Principios enfocados en la gestión del cambio y Principios enfocados en la prestación de servicios. La diferencia es que la gestión del cambio se ocupa de la evolución del uso del método a lo largo del tiempo, mientras que el enfoque en la prestación de servicios se refiere al progreso del trabajo día a día.
Imagina que trabajas en un equipo de mantenimiento de sistemas. La evolución del método es la mejora continua en la forma en que el equipo utiliza el método para trabajar, mientras que la prestación del servicio es la ejecución real de las actividades de corrección de errores y mejora.
Kanban es un método "evolutivo" y "evolutivo": el método en sí debe evolucionar continuamente para mejorar la entrega de valor mientras promueve una evolución del servicio proporcionado por el equipo que lo usa. Este concepto hace que el Método Kanban sea fácil de implementar, pero con un enfoque de mejora continua.
Para mantener esta continua evolución del método, es necesario observar los principios enfocados a la gestión del cambio, que son:
La observación de estos principios pretende facilitar el inicio de la utilización del método, mantenerlo en continua evolución y, al mismo tiempo, obligar a sus practicantes a estudiar y comprender mejor cómo interactúa el método con su entorno y los problemas del día a día.
Los principios relacionados con la entrega de servicios nos ayudan a monitorear el progreso del trabajo del equipo y buscan aumentar el valor entregado.
Para mantener al equipo enfocado en este aumento de valor, seguimos los principios:
Es normal que el trabajo del día a día del equipo genere algunos conflictos debido a las diferentes formas de pensar y resolver los problemas. Al observar estos principios, es más fácil tomar decisiones que pueden ayudar al equipoa trabajar de forma más cohesionada.
Una dificultad común en el uso de los principios de cualquier método o marco es que no responden a las preguntas cotidianas. La forma correcta de utilizar los principios es pensar en ellos cada vez que se deba tomar una decisión y verificar si esa decisión viola este principio de alguna manera. Siempre que una decisión viola un principio, debemos rechazarlo y buscar una forma más adecuada de resolver la situación.
Después de conocer los principios, es necesario comprender las Prácticas Generales. Podemos decir que estas prácticas son acciones concretas que debemos tomar a diario, a veces como pautas efectivas para nuestras acciones, a veces como un ejemplo para desarrollar nuestras propias prácticas.
En este punto de nuestro estudio, vale la pena recordar que el Método Kanban no es prescriptivo, por lo que muchas veces es necesario desarrollar nuestras propias prácticas o incluso nuestros propios principios, siempre y cuando respetemos lo definido en las bases del método.
A continuación, veremos cada una de las prácticas, una explicación de por qué existen y algunos ejemplos de cómo podemos aplicarlas.
Crear un modelo visual que refleje cómo trabaja el equipo y nos permita visualizar el trabajo en progreso es una de las prácticas generales del Método Kanban. La idea es materializar el trabajo intelectual.
Vale recordar que el Método Kanban fue desarrollado específicamente para el desarrollo de software y posteriormente adaptado a otro tipo de servicios, siempre enfocados al trabajo intelectual.
Incluso se puede decir que esta práctica es fundamental hasta el punto de que el propio nombre del método refleja la creación de una señal de trabajo para que pueda ser visualizada (recordemos el significado de la palabra kanban en japonés).
La forma más común de visualizar el trabajo es creando un “tablero Kanban” y agregando tarjetas en las que podemos colocar las demandas que se están trabajando, como en la siguiente figura:
La frase “Deja de empezar, empieza a terminar”, que vimos al principio del artículo, se refiere a la prioridad de terminar el trabajo que ya está en progreso, en lugar de comenzar un nuevo trabajo. El trabajo en progreso o Work in Progress (WIP) es una de las métricas más importantes del Método Kanban (hablaremos de las métricas en detalle más adelante).
El estudio de las métricas del equipo que rastrean su propia productividad muestra que cuando el trabajo en progreso es muy alto (por encima del umbral ideal del equipo), la productividad comienza a disminuir. Esto a menudo se debe a la alta complejidad en las relaciones entre el equipo y la falta de enfoque en los servicios más importantes en ese momento.
Es común que los equipos que comienzan a utilizar el método se cuestionen si esta práctica es realmente efectiva, pero con el tiempo y el análisis de las métricas, suele quedar muy claro que aumentar el WIP puede perjudicar la productividad, si supera el límite ideal.
El flujo es el movimiento de trabajo que se puede observar fácilmente a través del Tablero Kanban y el uso de métricas. Cuanto más fluido y predecible sea el flujo de trabajo, mejor gestionado estará.
Las métricas son grandes aliadas para medir la “salud” del flujo de trabajo, pero el propio tablero puede mostrar algo de este flujo visualmente. Aquí es donde la práctica de gestionar el flujo se basa en la práctica de visualizar el trabajo. Es importante resaltar que las prácticas se interrelacionan y generan la base del método.
Todo lo relacionado con el funcionamiento del sistema Kanban puede considerarse una política:
Hacer explícitas las políticas facilita la comunicación y la interacción del equipo, de modo que todas las reglas a seguir en el día a día serán claras y accesibles para todos.
Establecer ciclos de feedback significa crear una cadencia de trabajo para facilitar la evolución, no solo de la forma de trabajar, sino también de la prestación de servicios en sí. Las cadencias suelen estar marcadas por reuniones que definen el progreso de ese ítem. Podemos usar como ejemplo la cadencia del trabajo diario, que se realiza a través de la Reunión de Equipo Kanban.
Esta reunión facilita que el equipo visualice el trabajo, destacando el trabajo que está más cerca de completarse y donde el equipo debe concentrar sus esfuerzos ese día.
Es importante señalar que, como todos los aspectos del Método Kanban, establecer cadencias también depende del entorno y las necesidades de cada equipo. Solo las dificultades y oportunidades del trabajo diario mostrarán, por ejemplo, si el equipo debe o no usar la cadencia del equipo Kanban diariamente.
Comprender los ciclos de mejora continua es un trabajo colaborativo que involucra a todas las personas del equipo. Sin embargo, el equipo debe establecer un entorno propicio para la experimentación y el control de errores. Los entornos hostiles a la experimentación obstaculizan los ciclos naturales de evolución.
Cuando entendemos correctamente la filosofía del Método Kanban, se vuelve un poco más fácil implementar este método. Un error muy común al implementar Kanban es compararlo con Scrum Framework.
Como ya hemos visto, Scrum es más prescriptivo y necesita todos sus elementos desde el primer día de implementación para que el equipo funcione correctamente. En el caso del Método Kanban, “comenzamos con lo que ya tenemos” y “evolucionamos continuamente”.
En otras palabras, comenzamos el día cero prácticamente trabajando de la misma manera que habíamos trabajado antes, solo comenzando a aplicar los principios y prácticas del método para evolucionar nuestro formato de trabajo hasta llegar a un “Sistema Kanban Completo”.
Estudiemos ahora los principales puntos necesarios para implementar Kanban en su empresa o equipo.
Las prácticas “Empieza con lo que ya tienes” y “Mejora colaborativamente, evoluciona experimentalmente” son fundamentales para entender el primer paso en la implementación del Método Kanban.
Cuando entendemos que Kanban nos brinda un conjunto de prácticas y principios que se pueden acoplar al trabajo que ya hacemos, sin tener que hacer cambios bruscos al comienzo del despliegue, todo parece más fácil. Además, dichos cambios se implementarán gradualmente.
Desafortunadamente, la mayoría de las implementaciones siguen el ritmo de un marco o metodología, donde los principales cambios se realizan el primer día. ¡No cometas ese error! Seguir las prácticas del propio método.
Utilice las prácticas de visualizar el trabajo y administrar el flujo para comenzar a identificar los puntos donde se deben realizar los primeros cambios. Simplemente creando su tablero Kanban y poniendo el flujo de trabajo a la vista, los puntos clave para mejorar surgirán frente a usted.
Detallaremos un poco más sobre las principales métricas utilizadas en el Método Kanban, pero es importante que desde el primer momento de la implementación, el equipo tenga claro que “lo que no se puede medir, no se puede mejorar”. Esta frase es de la autoría de William Thomson, físico irlandés más conocido como Lord Kelvin, y es prácticamente un mantra Kanban.
Al principio, el equipo está un poco perdido con las noticias y es difícil formalizar las políticas de trabajo. Sin embargo, con el tiempo, el funcionamiento cotidiano comienza a ser más claro y las políticas pueden detallarse y formalizarse. Mantenga este detalle durante todo el ciclo de implementación.
Cuando el equipo comienza a cobrar un poco más de impulso, es posible establecer algunos límites de trabajo en curso y establecer límites formales. Estos límites WIP, combinados con la medición continua, favorecen la mejora del tiempo de entrega y el rendimiento, que estudiaremos un poco más adelante cuando detallamos las métricas.
Solo después de los primeros desafíos y los primeros ajustes puedes comenzar a visualizar los ciclos de feedback. Probablemente tu equipo ya tenga ciclos de feedback y reuniones periódicas sobre determinados temas, pero ahora el reto es adaptarlos a la filosofía del Método Kanban.
Seguir revisando los pasos y evolucionando continuamente, buscando permanecer fiel a las bases de principios y prácticas recomendadas por el método.
Si llegaste hasta aquí, ¡felicidades! Ya conoce todos los elementos básicos del Método Kanban y comprende fácilmente una secuencia de implementación básica.
Sin embargo, la implementación y uso del método en el día a día traerá varios desafíos para los cuales necesitamos un conocimiento un poco más profundo. A partir de este punto de nuestro artículo, estudiaremos con más detalle algunos puntos importantes.
Pero primero, veamos lo que hemos aprendido.
Una de las formas más reconocidas de aprender es compartiendo tus conocimientos. Por eso, te invito a compartir con nosotros en las redes sociales, especialmente en LinkedIn, lo que te pareció más interesante hasta el momento.
Puedes crear una explicación rápida de una de las prácticas del Método Kanban, por ejemplo, y poner el hashtag #AprendinoBlogdaAlura. Ah, no olvides etiquetarme Roberto Sabino, y a yo que te traduzco Ingrid Silva y etiquetar a Alura Latam, también ;).
Para profundizar en el Método Kanban, recomiendo el curso de Kanban, Análisis para la Implementación que está disponible en la plataforma.
Como ya hemos visto, las métricas son fundamentales para el uso y evolución del Método Kanban. Podemos utilizar distintos tipos de métricas, dependiendo de nuestro producto y del entorno en el que nos encontremos. Sin embargo, algunos son muy utilizados porque, además de tener una gran base matemática, también aportan cierta estandarización a los diferentes practicantes del método.
Uno de los mayores apoyos para el uso de métricas en Kanban es la teoría de colas, una rama de las matemáticas y la estadística que permite estudiar el comportamiento de las colas de servicio en sistemas simples y complejos.
Imagina, por ejemplo, una cola para comprar pan en la panadería. Si la panadería tiene dos colas, pero dos personas sirviendo (una para cada cola), el comportamiento de estas colas será diferente al de otra panadería donde hay una sola cola y dos personas sirviendo.
Por supuesto, para una panadería, es casi obvio que es mejor tener una sola línea con uno o más asistentes. Esto es tan natural que casi todas las panaderías funcionan de esta manera.
En cambio, cuando queremos pedir fiambres, solemos entrar en otra cola, ya que el comportamiento de la cola del pan es diferente al comportamiento de la cola de fiambres.
¿Y cuándo tenemos que atender a las personas con prioridad, como los ancianos o las personas con alguna discapacidad? En este caso, normalmente tenemos una “cola de prioridad”.
Ahora, imagina algunas situaciones específicas:
Con estos sencillos ejemplos ya podemos ver que hay una complejidad en el escalado (para sistemas de colas más complejos):
¿Qué “capacidad” debemos poner a disposición para servir a las personas?
¿Nuestro servicio está dando “flujo” a los pedidos?
¿Es necesario “crear” nuevas colas?
¿Es “trabajo en progreso” demasiado alto?
Para entender cómo la Teoría de Colas puede ayudarnos en la implementación y operación del Método Kanban, es importante dejar claro que el Sistema Kanban es un Sistema de Colas. A menudo veremos referencias a Kanban como el Sistema Kanban.
La diferencia entre Método y Sistema es que el método es el conjunto de principios y prácticas que debemos respetar para recibir sus beneficios, mientras que el sistema se refiere a la operación realizada con el método.
Si estamos utilizando Kanban para crear una nueva funcionalidad de una aplicación web, por ejemplo, nuestro Sistema Kanban en funcionamiento corresponde a:
Desarrollada por John Little a principios de la década de 1960, la Ley de Little es una de las leyes que conforman la teoría de las colas y relaciona la cantidad de clientes con el tiempo promedio que pasan en el sistema. Traduciendo a las métricas que vamos a utilizar como base para Kanban, podríamos decir que:
Para que cada uno de los componentes de esta ecuación quede muy claro y tenga sentido, vamos a estudiar cada una de las métricas más utilizadas en Kanban.
Tiempo de Servicio o Lead Time es el tiempo que tarda un pedido (servicio) que ha llegado al llamado “punto de compromiso” en llegar al final del Sistema Kanban, la última columna del tablero, que suele ser la de “Finalizado” o "Entregado".
Es importante entender que el punto de compromiso es el momento en el flujo de trabajo cuando el cliente entiende que el servicio se está realizando y esto se puede "arreglado".
Usando la siguiente tabla como ejemplo:
Podemos estar de acuerdo con nuestros clientes en que el punto de compromiso es la columna "Análisis".
Con esto, los servicios que están en “Backlog” aún no están en proceso. Desde el momento en que la tarjeta (solicitud de servicio) está en Análisis, comenzamos a contar el Lead Time o Tiempo de servicio.
Una vez que se entrega el servicio y se mueve la tarjeta a la columna “Terminado”, cerramos el conteo de tiempo.
Normalmente, el conteo de tiempo debe definirse en una política explícita que establezca las reglas sobre cómo se contará este tiempo. Dejo como ejemplo la política de medición lead time:
Siguiendo esta política, cuando la tarjeta llegue a la columna “Análisis” comenzaremos a contar el tiempo en días hábiles. Cuando llegamos a “Terminado”, finalizamos la cuenta.
Recuerde: las métricas deben medirse varias veces y generar promedios de conteo, ya que de un conteo aislado a otro puede haber mucha diferencia.
Algunas de las medidas pueden generar puntos fuera de la curva por varias razones.
La política también definió 2 Tiempos de Ciclo, que explico en el ítem a continuación.
Cycle Time o Cycle Time es una medida comúnmente utilizada para contar el tiempo que se tarda en realizar uno de los pasos del proceso, como el tiempo de ciclo de análisis. Podríamos definir este tiempo como los días hábiles que el servicio estuvo en la etapa de análisis.
Sin embargo, también podemos definir tiempos de ciclo de pasos significativos en el proceso, como en el ejemplo, la política presentada anteriormente.
En él se debe medir una carta desde que se inicia el análisis hasta llegar al punto de éstos. En este caso, el ciclo es importante porque refleja el trabajo del equipo de desarrollo hasta que el elemento está disponible para el equipo de pruebas.
Utilice tiempos de ciclo para proporcionar métricas importantes y mejorar el flujo.
Como hemos visto que una de las prácticas del Método Kanban es limitar el trabajo en progreso, esta medida será una métrica importante para la evolución de todo el sistema.
El trabajo en progreso o Work-in-Progress (WIP) suele ser la clave para la evolución de la productividad inicial de un equipo que comienza a usar Kanban. Por definición, cada tarjeta que ha alcanzado el punto de compromiso y aún no está terminada es un Trabajo en progreso. Además, puede contar WIP por columna. Por ciclo, considere el WIP promedio y otras variaciones de este indicador.
El Flujo o Throughput, que también puede llamarse Tasa Promedio de Transferencia, es la cantidad de servicios (tarjetas) completados en un período. Esta es una métrica importante de la velocidad a la que el equipo entrega valor.
Ahora podemos entender la Ley de Little: ¡El tiempo promedio de manejo es igual al trabajo promedio en progreso dividido por el rendimiento del sistema!
Para profundizar en el tema de las métricas, recomiendo el Curso Kanban: evoluciona tus entregas con métricas que está disponible en la plataforma.
A menudo, empezar a utilizar el método se hace con una pizarra física (una pizarra en la pared) o alguna otra forma de visualizar el trabajo.
Me gusta especialmente esta práctica, porque comenzar un nuevo método y seguir usando una nueva herramienta es muy desafiante y puede desviar la atención de la mejora del proceso.
Con el tiempo, se vuelve difícil usar métricas, emitir informes de productividad, hacer comparaciones de métricas desde un tablero físico. Estos y otros puntos pueden ser un indicativo de que es hora de utilizar un cuadro electrónico, que también puede llamarse e-Kanban o Kanban electrónico.
Lo cierto es que las principales herramientas de gestión de proyectos y productos del mercado soportan el Método Kanban. Destaco 3 de ellos a continuación:
Otro aspecto que suele surgir cuando el Sistema Kanban ya está evolucionando es la necesidad de Ciclos de Feedback. Como vimos al principio del artículo, establecer ciclos fedback es una de las prácticas del Método y se pueden insertar desde el principio de la implementación. Sin embargo, estos ciclos se vuelven cada vez más necesarios a medida que el sistema evoluciona.
A diferencia de Scrum, donde las ceremonias o eventos se implementan desde el principio y el enfoque está en el evento en sí, Kanban aboga por el cuidado con todo el ciclo de retroalimentación.
Un ciclo de retroalimentación es un marcador de ritmo de trabajo, que generalmente toma la forma de una reunión. Por ejemplo, el ciclo de feedback diario del equipo generalmente se realiza en la reunión diaria del equipo Kanban. Esta reunión marca el ritmo diario de trabajo, analizando el avance del Trabajo en Progreso y visualizando la ayuda que el equipo puede brindar entre sus integrantes para posibilitar la culminación más rápida de cada una de las demandas.
En Kanban, las reuniones del ciclo de retroalimentación también se denominan cadencias.
Kanban University, en su Official Guide to the Kanban Method, ofrece una descripción básica de las cadencias, pero en el e-book Kanban Esencial Condensado hay una explicación más completa. A continuación, la imagen con las cadencias recomendadas:
Siguiendo la práctica de “Empieza con lo que haces hoy”, no hay nuevos roles cuando comenzamos a trabajar con Kanban. Sin embargo, surgieron dos roles con el tiempo y son recomendados por los mantenedores del método.
Recordando que Kanban está hecho para ser "poco prescriptivo", por lo que los roles que se enumeran a continuación no necesitan ser roles o roles rígidos, sino que deben ser desempeñados por quien esté más cerca de ese rol.
También llamado Service Request Manager, este rol corresponde a lo que conocemos en Scrum como Product Owner y, en ocasiones, puede corresponder a lo que las empresas llaman Product Manager.
Recordando que este rol no se encuentra en la Guía Scrum 2020. Su rol es entender las necesidades y expectativas del cliente, facilitando la selección de los servicios a realizar (priorización).
También llamado Service Delivery Manager, este rol corresponde a lo que conocemos en Scrum como Scrum Master. Su función es facilitar el flujo de trabajo hasta la entrega, ayudando al equipo a ejecutar correctamente las cadencias y creando el entorno necesario para que el equipo evolucione con el método y se autoorganice.
Si llegaste hasta aquí, ¡felicidades! Ya tienes conocimientos avanzados dentro de Kanban y puedes buscar nuevos conocimientos para complementarlos.
En la plataforma Alura encontrarás:
Una de las formas más reconocidas de aprender es compartir tus conocimientos. Por eso, te invito a compartir con nosotros en las redes sociales, especialmente en LinkedIn, lo que te pareció más interesante de este artículo.
Puedes elegir uno de los artículos presentados y comentar los aspectos que más te llamaron la atención, por ejemplo, y poner el hashtag #AprendinoBlogdaAlura.
Ah, no olcides etiquetarme Roberto Sabino,y a yo que te traduzco Ingrid Silva y etiquetar a Alura Latam también ;).
Con las Apostilas de tecnologia de Alura sobre front-end, programación, UX y diseño y ciencia de datos, avance en sus estudios y desarrollo de su carrera en T.
Puedes profundizar en los siguientes temas:
Roberto Sabino
Sabino es autor de los libros: Excel Básico para el Mundo del Trabajo, PowerPoint 2019, Windows 10, Excel 2019 y Excel 2019 Avanzado de la Editora Senac. Postgraduado en Mercados Financieros por Mackenzie-SP y Graduado en Tecnología de Procesamiento de Datos por FATEC-SP, Certificado en Ingeniería de Requisitos por IREB. Emprendedor en el sitio web de Office Resolve, está entusiasmado con el uso de las herramientas de Office como aceleradores de productividad. Su hobby es crear nuevas herramientas automatizadas con el lenguaje VBA.
Traducido por Ingrid Silva.
Cursos de Programación, Front End, Data Science, Innovación y Gestión.
Luri es nuestra inteligencia artificial que resuelve dudas, da ejemplos prácticos y ayuda a profundizar aún más durante las clases. Puedes conversar con Luri hasta 100 mensajes por semana
Paga en moneda local en los siguientes países
Cursos de Programación, Front End, Data Science, Innovación y Gestión.
Luri es nuestra inteligencia artificial que resuelve dudas, da ejemplos prácticos y ayuda a profundizar aún más durante las clases. Puedes conversar con Luri hasta 100 mensajes por semana
Paga en moneda local en los siguientes países
Puedes realizar el pago de tus planes en moneda local en los siguientes países:
| País | | | | | | | |
|---|---|---|---|---|---|---|---|
| Plan Semestral |
487.37
BOB |
66665.20
CLP |
271231.76
COP |
65.90
USD |
262.00
PEN |
1205.94
MXN |
2700.55
UYU |
| Plan Anual |
738.82
BOB |
101059.99
CLP |
411169.23
COP |
99.90
USD |
397.18
PEN |
1828.13
MXN |
4093.86
UYU |
Acceso a todos
los cursos
Estudia las 24 horas,
dónde y cuándo quieras
Nuevos cursos
cada semana