Transcripciones
1. ¡Hola!: Hola y bienvenidos al curso sobre kanban ágil. En este curso, comprenderás una de las más populares, una Escuela gigante de partes llamada Kanban. Este curso te enseñará sobre los principios Kanban y cómo Kanban puede ayudarte a ti y a tu equipo a crear una cultura de mejora continua. Empezaremos con aprender qué es Kanban y cómo puedes usarlo en tus proyectos y equipos. Empezaremos a visualizar un flujo de proceso a través una sencilla tabla Kanban y luego exploraremos diversas formas de tableros Kanban. Identificaremos diversos temas relacionados con el flujo de procesos, incluyendo demasiado trabajo en curso y la utilización de recursos, tarea de tamaño
desigual, etc. Usando demostraciones simples y fáciles de entender en tablero Kanban. No sólo identificaremos estas ineficiencias, sino también suelo para las mismas mejorando continuamente el flujo del proceso usando tablero Kanban. También hablaremos de las mejores prácticas a
seguir mediante el uso de Kanban para sacarlo al máximo provecho. lo que únete a este curso hoy mismo e incorpora el método Kanban de gestión
ágil de proyectos a tu estilo de trabajo y entrega un gran software. Ahora llegando a quién es este curso. Este curso es para cualquier persona que tenga una familiaridad pasajera con la gestión de proyectos. En cualquier persona que tenga un gerente de proyecto, un miembro de un equipo de proyecto, honestidad más fría en un equipo de proyecto que esté tratando de ser más levantado o alguien que no tenga experiencia con enfoques formales de gestión de proyectos. Pero como buscar un sustantivo, debería cualquiera que acabe de escuchar a ese tonto Kanban y quiera saber más al respecto. Y ya sabes cuál es la mejor parte. No es necesaria la conveniencia de brian para tomar este curso. Entonces aunque no sepas lo que es Kanban y los diversos principios y conceptos bajo Kanban y gestión ágil de proyectos. No se preocupe. Cubriremos cada uno de los conceptos desde cero. Entonces, ¿por qué me debes tomar este curso? A modo de introducción, soy Mónica Robert. Soy ingeniero de software, estrategia de marketing MBA. Pero lo más importante, tengo experiencia laboral en el mundo real desde American Express, donde trabajé de cerca con equipos de software para gestionar múltiples proyectos como gerente de producto. Ahora me apasiona compartir mis conocimientos y experiencia. Eso es lo que me ha llevado justo aquí a ti. Quiero que entiendas a fondo y disfrutes este curso para que puedas inspirarte a lograr todos tus objetivos de carrera. Tengo las herramientas necesarias para hacer el trabajo. Entonces hagámoslo. Te veré en la clase. Gracias.
2. Introducción a la Kanban: Ahora empecemos nuestra discusión sobre Kanban. Kanban es un método muy flexible y fácil de implementar para hacer mejora de procesos. De hecho, creo que es tan fácil que debería ser el punto de partida para todos los equipos que están pensando en adoptar el enfoque ágil. Y a diferencia de Scrum, que tiene reglas estrictas a seguir en Programación Extrema, que tiene prácticas estrictas. Kanban es muy flexible y los equipos tienen mucho alcance de ser creativos. Al implementar kanban. Dicho en pocas palabras, Kanban es increíble y muy fácil de implementar. Ahora entendamos qué es Kanban. Por lo que kanban es una palabra japonesa, que literalmente significa asignar tablero o señalización usando tarjetas. Viene de la industria manufacturera. Cuando Toyota, que es un fabricante japonés de automóviles, implementó Kanban para monitorear el
proceso de fabricación de automóviles e identificó los pasos que son los enlaces fronterizos. A partir de ahí, se ha adaptado para el desarrollo de
software y ha tenido un éxito similar. Entonces la idea de Kanban es esta, visualizando el flujo de trabajo para lograr la mejora del proceso. Entendamos esta línea en detalle. La primera parte es visualizar el flujo de trabajo. Esto significa que debe haber una imagen clara de qué pasos y acciones está tomando el equipo. Al visualizar esto, tratamos de identificar en qué paso tenemos ineficiencias o desperdicios, y ¿cuáles son los pasos a los que se está interrumpiendo el flujo? Después viene la segunda parte, que está logrando la mejora del proceso. Se dan varios pasos en prácticas que pueden los hombres sugiere para mejorar el proceso y lograr un mayor flujo de recorrerlo. Algunas prácticas son como limitar el trabajo en curso, en la gestión del flujo, en la implementación de bucles de retroalimentación, etcétera, que discutiremos en las conferencias posteriores. Pero tenga en cuenta que estas son solo sugerencias y no reglas. El equipo puede llegar a cualquier tipo de solución creativa a los problemas que identificaron vil visualizando el flujo de trabajo. Ahora antes de que les cuente más sobre Kanban y sus prácticas, creo que primero debería mostrarles cómo visualizamos el proceso usando una pizarra Kanban. Una vez que entiendas esto, todas las demás cosas te tendrán mucho más sentido. Por lo que en la próxima conferencia, veremos la junta Kanban. Nos vemos en el siguiente. Gracias.
3. Introducción al tablero de Kanban: Hola y bienvenidos de nuevo. En esta conferencia, vamos a discutir sobre la junta kanban. Entonces, básicamente, el tablero Kanban es una herramienta que los equipos utilizan para visualizar el flujo evocar. Ahora esto puede ser un tablero físico en la pared con notas adhesivas que se utilizan para representar el soneto tau. Auditoría puede ser aburrimiento basado en software también. Al igual que estos días, muchos equipos crean un tablero de este tipo en el software SIG. En este tablero, creamos diferentes columnas para diferentes pasos involucrados en el proceso de desarrollo. Por lo que como se puede ver en la pantalla, en el lado izquierdo, tenemos un tablero físico con notas pegajosas en él. Y en el lado derecho, tenemos un tablero Kanban creado en software GIS con diversos pasos del proceso definido en cada una de las columnas. Y así en la primera columna tenemos la lista de tareas pendientes. Entonces tenemos en progreso, seguido de vista trimestral y hecho. Y dentro de cada paso tenemos conjunto de tareas a realizar. Ahora tomemos un ejemplo para entender más esto. De ahí que esta forma implícita de tablero Kanban. Aquí hemos segregado el flujo de trabajo de tareas en tres partes. se inicia ni se inicia la primera columna, seguida de en curso. Y entonces cada tarea comienza a la izquierda en esta columna. Cuando el equipo comienza a trabajar en él, la nota pegajosa se retira de la primera columna y la coloca en la segunda columna. Y cuando la tarea está completa, se mueve a la última columna, que se hace. Por lo que se trataba de un sencillo tablero kanban que puede funcionar no sólo para proyectos, sino para visualizar también las tareas personales. De todos modos, esto es bastante básico. Y si realmente quieres beneficiarte de la junta Kanban, necesitas mirar tu proceso y conocer columnas que muestran exactamente el proceso para tu equipo. Por ejemplo, aquí hay un tablero de muestras con pocas columnas adicionales, que te relacionarás si alguna vez has trabajado en un equipo de desarrollo. Esta pizarra es del libro de David Anderson llamado Kanban. En este tablero también, los artículos
a granel fluyen de izquierda a derecha. Se tiene una cola de entrada que solo llama
a todas las cosas en las que tienen que trabajar los equipos. Una vez que se recoge un elemento, cada elemento se somete a este proceso de análisis, seguido de desarrollo, luego construir listo, luego probar, luego liberar su DIE. Dentro del análisis y desarrollo, tenemos padres agregación de en curso y hecho. Por lo que puede haber algunas tareas para las que el análisis se hace por parte del desarrollo aún no ha comenzado. Por lo que dicha tarea residirá en la sección Dunn de la columna de análisis. Lo mismo va para el TAB de desarrollo. Por favor sí recuerda que esto también es un ejemplo Junta. Como se mencionó anteriormente, cada equipo es diferente y el proceso siguió como amigo. Y por lo tanto los pasos en tablero Kanban para cada equipo serán diferentes. Por ejemplo, aquí, supongamos que tienes un paso extra después de las pruebas y antes de liberar a los adolescentes a la producción, donde tu equipo presenta la tarea desarrollada para el equipo empresarial o los gerentes de negocio. Y en función de sus comentarios, algunos caminos se envían de vuelta a la cola de entrada, y algunos avanzan con el lanzamiento en etapa temprana. Si este es el escenario, entonces necesitamos agregar otra columna aquí para la revisión de negocios. Y tal vez bifurcar la cola de entrada en nueva y enviar desde revisión. De esta manera, es importante crear las columnas correctas en la tabla Kanban representan exactamente el proceso que se sigue en su caso. Una vez que hagas esto, tu tablero Kanban empezará a mostrarte las ineficiencias en tu proceso. Entonces eso es todo en esta conferencia. En las próximas conferencias, les mostraré algunas de las ineficiencias que destaca la junta kanban y algunas prácticas correctivas empleadas en Kanban. Nos vemos en el siguiente. Gracias.
4. Encontrar las ineficiencias en el proceso: Hola y bienvenidos de nuevo. En esta conferencia, comenzaremos a mirar algunos de los temas que podemos encontrar en un proceso cuando implementemos la junta Kanban. Para efectos de estos casos, voy a utilizar esta pizarra Kanban, que es bastante similar a la junta que vimos en la última conferencia. Por lo que el camino normal para una tarea en esta pizarra Kanban, entra
una nueva solicitud de negocio. Debe ceder como prioridad de cuerpo. Y se recoge y se lleva a cabo el desarrollo. Ahí, se prueba el producto desarrollado. Ese producto probado se presenta entonces a los gerentes de negocio. Y si pasan, se pone listo para los estudios. Entonces también tenemos una retroalimentación. Pero si en la revisión de negocios, algunos cambios son sugeridos por el gerente de negocios. La tarea vuelve al primer paso y vuelve a someterse a todo el proceso. Espero que entienda aquí el flujo de tareas. Ahora veamos el primer número. Supongamos que ves una tabla como esta por muchos de los días en un mes. Por lo que les solicito pausar el video aquí por unos segundos y que me hagan saber ¿qué sugiere este tablero? Ok, bueno, este tablero sugiere que por alguna razón, el flujo o el paso de prueba no es tanto como debería ser. El flujo de entrada es mayor y el flujo de salida es bajo. Ahora, cuando estás trabajando en ese equipo, probablemente ya
tendrías esta sensación de que muchos de
los artículos están pendientes de prueba o la prueba es lenta, etcétera. Pero la Junta señala claramente que el flujo podría mejorarse mucho. Hacemos más pruebas. Por lo que a esta situación se le llama tener demasiado trabajo WIP en curso. En esta situación, no tiene sentido hacer más desarrollo o construcción ya que se va a quedar atascado en la etapa de pruebas. Por lo que una clara sugerencia es que más miembros del equipo necesitan
trabajar en la etapa de pruebas en lugar de cualquiera de las etapas anteriores. Y cuando el equipo se ajuste para acomodar esta tarea comenzará a despejar de la columna. Por lo que de alguna manera, la directiva está ayudando al equipo a identificar qué tareas se deben recoger. También puedes pensarlo y comparar la situación para un equipo no adulto. Un miembro del equipo que trabaje como desarrollador seguirá escogiendo las tareas de desarrollo. Pero muchas de estas tareas pueden tardar mucho tiempo en llegar a la etapa de lanzamiento final. No obstante, en un equipo Agile que utiliza Kanban, El equipo sabe dónde emplear más recursos para lograr un mejor flujo. Ahora existe una práctica kanban que asegura que se
están tomando medidas antes de que cualquier paso se desorden. Se conoce como limitando el WIP. Entendamos esto a detalle. Por lo que en esta práctica limitante de WIP, dijimos un límite en el número máximo de tareas que pueden estar presentes en esa columna. O ese paso a la vez. Si se alcanza ese límite, ese demonio se asegura de que no haya más entrada en el escalón hasta que se despeje la tarea pendiente en el escalón. Por ejemplo, si pongo un límite de seis tareas en el paso de las pruebas. Ahora supongan 6 mil terminando aquí. Vamos a detener todo el desarrollo, construir un tiempo. Algunas de las tareas están despejadas del paso. Esto asegura que la pendiente no esté abarrotada y que el equipo de pruebas no esté sobrecargado. De esta manera, los límites de WIP se pueden establecer en todos los pasos. Si bien no es necesario fijarlo en todos los pasos. Pero en mi opinión, se consideran rodaje dijo estos límites en todos los escalones. Ahora surge la pregunta, ¿cómo decidimos qué límite establecer? Bueno, no hay fórmula mágica que nos dé este número. Los equipos tienen que ponerse juntos, discutir, y llegar a un número. Entonces lentamente podrás evolucionar y mejorarlo en
base a la experiencia y medición del flujo de trabajo. Entonces eso es todo sobre WIP. Tan sólo para resumir, para evitar demasiado WIP, dijimos límites. Y cuando se alcanza ese límite, equipo se ajusta para despejar y por lo tanto mejorar el flujo. Entonces ese sólido es la conferencia. Nos vemos en el siguiente. Gracias.
5. Underutilization de recursos: Hola y bienvenidos de nuevo. En la última conferencia, vimos el problema de un solo paso ser demasiado lento y obstaculizar el flujo. En esta conferencia, vamos a ver otro tipo de ineficiencia, que está por debajo de la utilización de recursos. Entendamos esto a través de un tablero Kanban. Supongamos que ves un tablero como éste. Mucho del tass paso de construcción de I+D. Y como puedes ver, ese paso de pruebas está vacío. Ahora como este paso de pruebas está vacío, es muy para conseguir Mohawk. Las tareas siguen pendientes en el paso anterior, y por lo tanto no están pasando al siguiente paso, que es un paso de prueba. En tal situación, la fuerza de trabajo para las pruebas estará subutilizada. Entonces básicamente los recursos que están gestionando las tareas y el paso de prueba y no obtener el flujo de entrada tanto como puedan manejar. Generalmente, este tipo de problemas no se encuentra intuitivamente. Y ahí es donde la junta Kanban ayuda. Entonces si ves que una columna en particular está vacía la mayor parte del tiempo, es una señal de que tienes algunos recursos infrautilizados los cuales puedes enfocarte en los minerales. Entonces, tanto en los temas, uno que discutimos en la conferencia anterior como en el otro que acabamos de discutir, hay un tema de flujo. En algunos pasos el trabajo fluye más rápido y algunos pasos es más lento. Y la forma en que manejamos este tipo de situaciones se llama en realidad administrar el flujo. Y solo para aclarar, administrar el flujo no es algo que algún directivo tendrá que hacer. Entonces esto es algo que es reconocido por el equipo. Cuando el equipo ve el tema del flujo en la pizarra, los propios integrantes saben en qué trabajar a continuación. Y es por ello que Kanban también es conocido como un sistema basado en pull-based. Debes estar preguntándote qué es un sistema basado en pull-based. Entonces, permítanme tomar un ejemplo para explicar las diferencias entre el sistema push y pull y cómo Kanban es un sistema basado en pull-pull. Entonces supongamos que hay varias tareas por hacer, como desarrollar una función, algunas correcciones de errores, alguna documentación, etcétera. Entonces en un sistema de empuje, habrá alguien. Puede ser un gerente, líder del equipo de
auditoría que asignará estos impuestos a los integrantes del equipo. Todo lo que puedes ver que la tarea será empujada a los integrantes del equipo. Pero cuando visualices el flujo usando Kanban o miembro del equipo mirará el tablero Kanban, sabrá inmediatamente dónde es más necesario y podrá recoger el libro más relevante de inmediato. El persona estará sacando la tarea más relevante de la lista de tareas a realizar. Ahora como estamos hablando de sistema basado en pull-based, vamos a discutir también los beneficios relacionados con él. agrega el beneficio de un sistema basado en pull-based, optimiza un flujo de trabajo. Reduce el tiempo de entrega y lo más importante, reduce la sobrecarga en los trabajadores. Y también siento que las personas están más contentas cuando eligen el trabajo que realizan. Y especie de gerente localizando la obra a ellos. Tan sólo para resumir esta conferencia, la directiva Kanban destaca los temas relacionados con el flujo para el equipo. Y un equipo ágil, por lo tanto, puede ajustar o hacer gestión de
flujo para optimizar un flujo en todo el sistema. Eso es todo en esta conferencia. Nos vemos en el siguiente. Gracias.
6. Tareas de tamaño excesivo: Hola y bienvenidos de nuevo. En esta conferencia, discutiremos otro tipo de tema. Supongamos que algún día ves un tazón como éste. Aparte de la otra tarea, está esta tarea número tres, que está ahí en la columna del edificio. Pocos días después, se ve que sólo se han movido otras tareas. Pero la tarea número tres sigue sentada en la columna del edificio. Y después de unos días después también. Otra vez te das cuenta de lo mismo. Ahora puedes adivinar lo que esto está sugiriendo? Bueno, esto está sugiriendo que una tarea está tomando más tiempo entonces debería un tiempo más largo del agua que la tarea habitual toma. Puede haber muchas razones para esto. Discutamos algunos de ellos junto con sus remedios correspondientes. En primer lugar, como cada tarea es el amigo, existe la posibilidad de que esta tarea en particular requiera más cantidad de trabajo. Pero para su comprensión, para que Kanban funcione correctamente, es decir, si queremos obtener información útil de nuestra junta directiva, necesitamos asegurarnos de que todas las tareas tomen
cerca de la misma cantidad de tiempo y fluyan a un tasa. Esto significa que si hay una tarea grande que se tiene que desglosar en tareas de menor tamaño. Para ello, una práctica común adoptada es agregar una nueva columna al principio con el paso 10m como alcance o análisis o especificación donde la agenda principal es crear tarea de igual tamaño para el resto del flujo. Entonces el punto que quiero resaltar aquí es que siempre debes recordar que en Kanban, necesitamos asegurarnos de que sus tareas sean de igual tamaño. Entonces éste es uno. Aparte de esto, hay otras posibilidades también. Existe la posibilidad de que la persona asignada a esta tarea sea blogueada o necesite ayuda. A lo mejor hay algunos bichos o problemas debido a la base de las acciones vulcanas. A lo mejor la persona asignada se dejó llevar y está expandiendo inapropiadamente el alcance de la tarea. Por lo que las razones podrían ser cualquiera, y no existe una práctica establecida para abordar este tipo de temas. No obstante, una mirada regular a la junta kanban destacan este tipo de temas. Y entonces un equipo gigante puede entonces actuar en consecuencia para resolverlo. Entonces sólo para resumir lo que discutimos, si una tarea está tomando más tiempo, entonces debería serlo. Después mantener la pista regular. En la pizarra Kanban siempre ayuda. Y si es necesario, desglose la tarea en tareas de menor tamaño. Eso es todo en esta conferencia. Nos vemos en el siguiente. Gracias.
7. Marcar la tarea: Hola y bienvenidos de nuevo. En esta conferencia, veamos otro tipo de tema que puede surgir en el proceso de desarrollo. Entonces esta es la junta kanban de
nuestro proceso de ejemplo donde tenemos este paso de revisión de negocios, donde los gerentes revisan la característica desarrollada. Si está bien. Se va al siguiente paso. Y si necesita algunos cambios, se remonta al primer paso. Por lo que esto de ida y vuelta crea un bucle de retroalimentación. Por lo que puede haber más bucles de retroalimentación en el proceso que sigues en el de tu organización. Los bucles de retroalimentación son importantes. Aseguran que la información comercial relevante se alimente en el proceso y los pasos correctos para que el feto
que se está desarrollando esté actualizado y acomode los cambios en el mercado y la estrategia competitiva. No obstante, también debemos darnos cuenta de que si una gran cantidad de artículos son enviados de vuelta para revocarlos después de revisión, el flujo general del proceso se reducirá. Siempre que un artículo sea enviado de vuelta para revocar. El trabajo realizado al respecto anteriormente va a desperdiciar. Además 13 miembros necesitan trabajar de nuevo en ello. Por lo que se trata claramente de ineficiencia que debe abordarse. Tenemos que asegurarnos de que los artículos no sean enviados de vuelta para su revisión varias veces. Pero, ¿cómo sabemos que algún artículo ha sido revisado varias veces? Cuando visualizamos esto en el tablero Kanban es hacer una marca en esa nota pegajosa para el número de ronda. Esa nota pegajosa va de ida y vuelta a través del proceso. Entendamos esto a través de un ejemplo. Entonces, por ejemplo, cuando el nodo retrocede por primera vez desde el paso de revisión, somos el único punto sobre marca en él para denotar que esta tarea ya ha sido revisada. Ahora esta tarea avanzará por el proceso y nuevamente llegó a nuestro paso de revisión de negocios. Aquí. Si el anochecer nuevamente necesita más cambios, tarea se volverá a enviar de nuevo desde este paso de revisión. Esta vez, vamos a sumar otro simulacro para denotar que esto ha sido revisado dos veces. Si los datos se envían de vuelta al tercer panel, agregarás un tercer punto y así sucesivamente. De esta manera, cuando veas tu tablero Kanban, sabrás cuántos artículos son nuevos artículos y cuántos artículos hay, que fue enviado de vuelta para su revisión. Por lo que tener estos pequeños MAC nos puede ayudar a resaltar este tema. Si bien estamos en el tema de retroalimentación y revisión, quiero discutir una cosa más. Como habrías experimentado. A menudo el proceso de revisión en las oficinas no es algo cotidiano. Los directivos no se sientan a revisar las tareas todos los días. Entonces lo que pasa es que pide seguir recibiendo piloto para su revisión. Y cuando hay alrededor de 78 tareas a ver,
una reunión como se planeó. A ese momento, estas tareas se sostienen en la cola. Por lo que esto también crea ineficiencia y desperdicio. El punto que quiero destacar aquí es que el apilamiento de tareas para revisión también crea ineficiencia y desperdicio. Tenemos que asegurarnos de que este tipo de reuniones se realicen con frecuencia y regularidad para minimizar este desperdicio. Y el violín por otro lado, tener que frecuentar reuniones también conduce a la ineficiencia. Por lo que las personas a menudo sienten que obtienen menos tiempo para trabajar cuando tienen que asistir a muchas reuniones. Entonces el punto que estoy tratando de hacer aquí es que necesitas encontrar el límite óptimo de WIP para tu paso de revisión, lo que maximiza tu rendimiento, aumentando así tu eficiencia. Entonces eso es todo en esta conferencia. Espero que esto te resulte útil. Nos vemos en el siguiente. Gracias.
8. Otros problemas: Hola y bienvenidos de nuevo. En este video, veremos algunos otros temas comunes que enfrentamos durante el proceso de desarrollo. ¿ Y cómo puede kanban ayudarnos a identificarlos? Los temas de los que voy a estar hablando en esta conferencia son temas muy específicos de casos. Y puede que no los estés enfrentando. Es por ello que no voy a pasar demasiado tiempo en cada uno de ellos. El orden del día de la conferencia es mostrar que la junta Kanban se puede personalizar para diferentes tipos de procesos y monitorear diferentes tipos de tema probable. El primer escenario que vamos a discutir en este video es de tener muchas dependencias externas. Como te habrías dado cuenta mientras trabajabas en un proyecto. Todos los proyectos tienen algún nivel de dependencias externas. Por ejemplo, si tienes un cliente mirando hacia arriba todo el texto que verá
el cliente probablemente necesitará la aprobación del equipo de marketing. Y si hay n términos y condición mencionados, definitivamente
necesitarás la aprobación del equipo legal. Y se requieren muchas de esas aprobaciones y revisiones. Por lo que estas son dependencias externas. Ya que lo productivo tiene muy poco control sobre estos equipos. No obstante, el problema no es que se trate de dependencias externas. El problema es que el equipo se reúne para hacer seguimientos regulares con los equipos correspondientes. Y si eso se olvida, la aprobación se retrasa, y eventualmente el proyecto se retrasa. Una solución simple a este problema es agregar una columna separada para arrastrar las dependencias, pero esta columna en una posición apropiada en el proceso. Tenga en cuenta que no es necesario un límite de WIP en esta columna. El equipo sólo necesita desarrollar una práctica de seguimiento
regular de la tarea enumerada en esta columna. Y si alguna tarea está ahí sentada demasiado tiempo, el miembro del equipo puede escalarla a los niveles apropiados. Ahora llegando al siguiente escenario, que también es común, donde nuestro equipo no solo está trabajando en las características del producto, sino que a veces el equipo tiene que hacer alguna presentación importante. Todo demo para clientes o algunas conferencias
surge para las cuales el equipo necesita pasar tiempo para la preparación. Si bien esto no es un trabajo directamente relacionado con el producto, pero es un trabajo importante y mucho tiempo tal vez gastado en ello. Entonces, ¿cómo contabilizamos esta vez en el tablón de letreros? Para eso simplemente creó una tarea para ello, igual que cualquier otra tarea. Y también fluirá por el tablón de letreros. El punto es que la junta directiva Kanban debe reflejar dónde está pasando el equipo el tiempo para que podamos aumentar la eficiencia siempre que sea posible. Por lo que en pocas palabras, la tabla Kanban se considera deporte y por lo tanto debe reflejar todas las cosas que hace el equipo. De igual manera, existen algunas otras tareas que no están directamente relacionadas con el producto, sino que se deben hacer para mejorar la eficiencia del equipo. Por ejemplo, es posible que deseemos automatizar alguna tarea operativa, o quizá queramos actualizar algunas herramientas que utilizamos. Dado que el foco está en el producto, estas cosas nunca se recogen. Entonces lo que podemos hacer es agregar tarea de mejora también en la pizarra. De esta manera, también obtendrán suficiente visibilidad y se harán igual que otra tarea. Otro uso de la junta Kanban puede ser en el proceso de reclutamiento donde
contratamos a una nueva persona y estamos asignando trabajo a esta nueva incorporación. Simplemente podemos asignar a esta persona al paso más lento del proceso. Ahí es donde la persona estará más fuera de uso. Y la persona estará ayudando a incrementar la salida del proceso. Por lo que estos fueron algunos de los casos que quería discutir en este video para mostrar que Kanban es flexible para incorporar no sólo el trabajo relacionado con el producto, sino también otras tareas relevantes. Eso es todo en esta conferencia. Nos vemos en el siguiente. Gracias.
9. Definir la hoja HE: Hola y bienvenidos de nuevo. En este video, discutiremos sobre definir hecho. Es entonces cuando decir que se completa una tarea en particular. Y aquí simplemente no vamos a definir hecho para la función. Tenemos que definir la finalización de cada paso. Entendamos esto a través de un ejemplo. A ver que tenemos una tarea a, que está en el paso de construcción. Para ver que ese paso está completo, el desarrollador primero debe saber exactamente qué se espera de la función desarrollada y qué se va a entregar exactamente. De igual manera, si hablamos del largometraje final,
la característica final que va a entrar en producción que debe coincidir con los clientes son la expectativa de los gerentes. Entonces según Kanban, se sugiere que cada columna, o digamos que la mayoría de las columnas deben tener esta bifurcación de en curso y hecho. Y debe definirse claramente que después de hacer ¿Qué podemos pasar nuestra tarea de estar en progreso en ese paso a ser completado o hecho en ese paso. Cuando define claramente lo que se hace, la calidad se mantiene en cada paso. Y por lo tanto, el resultado final es de alta calidad. 1 que hay que señalar aquí es que cuando decimos que un paso está completo en una tarea, no
significa necesariamente que el baile pase al siguiente paso. El sencillez de contraseña en la columna bancaria del paso anterior. Recuerda que hablamos de Kanban siendo un sistema basado en pull. Esto es lo que es. Incluso si el desarrollador ha escrito el cable, no
significa que la tarea esté ahora pendiente con el equipo de pruebas. Tarea llega al equipo de pruebas cuando el equipo de pruebas lo tira del paso de desarrollo. Entonces básicamente nadie se la empuja a ellos. Es su discreción y se fue a recoger la tarea. Otra cosa que quiero destacar aquí, que tal vez te estés preguntando también, que hacen estas dos sub columnas en progreso y hechas tienen límites de WIP separados. Bueno, como Kanban es flexible, es tu dos veces. Pero la práctica general, que también tiene más sentido, es tener un solo límite para todo el paso. tanto la tarea esté en ese paso, debe
ser contrarrestada contra que los pasos trabajen en progreso. Entonces, en mi opinión, no tienen límites de WIP separados para la sub columna. Por último, hay dos prácticas que aquí quiero
destacar para que las reglas hechas se implementen adecuadamente. En primer lugar, es una buena práctica escribir realmente estas reglas en algunas notas y tener estos nodos en la pizarra Kanban. En segundo lugar, siempre que alguien esté moviendo un nodo de una columna a otra, otro miembro del equipo debe comprobar si las reglas para hecho mientras se cumplió en el paso anterior o no. En un equipo Agile, todo
el equipo es responsable de la calidad de la entrega. Por lo tanto, el equipo debe revisar el trabajo del otro para evitar errores de juicio o descuido por parte de una persona para evitar cualquier impacto negativo en la tarea de comedores. Entonces eso es todo en esta conferencia. Espero que estén apreciando la importancia de precisar claramente las reglas hechas. Te veré en la próxima conferencia. Gracias.
10. Standup diario: Hola y bienvenidos de nuevo. Ahora que tenemos un tablero para visualizar el proceso. Esa es reunión maravillosamente regular prescrita por Kanban para aprovechar
al máximo esta reunión diaria, Se llama el standup diario. El Islam también tiene una práctica similar que se conoce como scrum diario. No obstante, existen muchas diferencias entre estos dos. Y el motivo de las diferencias es lo mismo que hemos estado viendo desde la flexión de Kanban, que es Kanban es flexible, mientras que Scrum tiene reglas estrictas. Entonces cuando decimos reglas estrictas, significa que Scrum tiene reglas sobre cuánto tiempo será esta reunión, quién estará manejando la reunión, y qué se discutirá en esta reunión. Lo que Kanban no tiene tales reglas. Entonces si la pregunta en tu mente es, quién se pondría de pie inestable, entonces cualquier miembro puede hacer eso. A lo mejor todo el mundo, un nuevo miembro del equipo tiene la oportunidad de comer al azar y traer un nuevo sabor a la reunión. O tal vez este trabajo se le asigne a la persona mayor del equipo. No obstante, por lo general se ve a los jefes de proyecto haciendo esto porque esto los mantiene actualizados sobre el estado de toda la tarea. Y si hay alguna tarea que está bloqueada o algunos miembros del equipo que necesitan ayuda, pueden hacerlo. Pero como dije, es la elección del equipo. ¿Quién dirige la reunión? La siguiente pregunta es, ¿cuánto dura esta actividad? Pues bien, no hay una duración fija de esta reunión. Si el equipo tiene experiencia, lo
pueden terminar en cinco minutos. Pero muchas veces los miembros de p empiezan a discutir trabajo del
otro o incluso a celebrar los éxitos del otro. No hay daño. Aunque la reunión tome 30 minutos. Sólo termina en mayor colaboración entre los integrantes del equipo. Ahora, por último, ¿qué se va a discutir durante el stand-up? Bueno, el equipo debe mover las notas pegajosas hacia adelante si no lo han hecho antes. Es decir, aunque estos stickies se deben mover cada vez que se hace la tarea, pero si se pierde algo, standup
diario es un momento para que el tablero esté actualizado. Aparte de esto, el equipo debe tratar de identificar temas. El tipo de temas se discutieron antes. Los miembros pueden destacar si están enfrentando algún problema en la Tarea. Dos, estas son las cosas que hay que hacer. Aparte de eso, es un equipo de producto sobre lo que quieren discutir. Basta con mantener el foco en la pizarra y tratar de agregar o sacar el mayor valor posible de ella. Ahora justo antes de cerrar esta conferencia, permítanme señalar qué no es el standup diario. Por lo que el standup diario no es una reunión de revisión o demostración de características construidas o discusión sobre el producto, etcétera. Podrás tener estas reuniones por separado. Reunión de stand-up como solo un
encuentro para ver cómo fluye el trabajo a través del proceso. Por lo que ese otoño en esta conferencia. Espero que esto te resulte útil. Gracias.
11. Especificar las reglas: Hola y bienvenidos de nuevo. En este video, vamos a hablar
de algo muy importante que debemos hacer cuando estamos usando Kanban. Esto es algo que no tenemos que ver con Scrum. Esto se debe al gran beneficio de la flexibilidad que viene con Kanban. El único inconveniente que tiene es que no tiene reglas estándar. Entonces si entiendes a Scrum, sabrías que tiene reglas muy estrictas que
seguir y todo el equipo sabe de las reglas. De hecho, hay un rol especial call scrum master que asegura que todo el mundo sepa de las reglas. Pero con Kanban, no tenemos estas reglas. No hay una regla fija para cuándo deberíamos tener un stand up diario. Quién mueve la nota pegajosa o cuando no hay maestro kanban. Puede o no haber férulas, planeación de
sprint, o reuniones de revisión de sprint. Entonces el punto es que las reglas no están fijas y cada equipo tiene que idear sus propias reglas para implementar kanban. Y cuando creas reglas, debes asegurarte de que estas reglas se
mencionen explícitamente y todos las entiendan claramente. Ahora esto no quiere decir que el equipo kanban tenga que escribir documentos largos especificando todo el proceso. Hacer explícita la política puede ser tan simple como escribir límites de WIP en la parte superior de la columna. Y como se discutió anteriormente, el equipo debe definir hecho. Cuando un equipo dietas esa definición de hecho Ag honesto y la pone en la pizarra Kanban. Ese equipo hace explícita esta definición. Por lo que cualquier regla o práctica que adopte como parte de la implementación del kanban debe mencionarse explícitamente para que todos estén a bordo. Ahora, ya que todo el equipo crea de forma colaborativa estas reglas, es posible que pienses que esto puede no ser realmente útil. Pero déjame decirte una cosa. Sí lo ayuda. Supongamos que un gerente o el jefe está tratando de empujar algo de trabajo. Si se
mencionan explícitamente los límites de WIP y el directivo ha estado de acuerdo con la política de límites WIP. El equipo tiene terreno sólido que sólo si se quita de la lista un trabajo existente, entonces sólo el nuevo trabajo encontrará su lugar. Por lo que las políticas explícitas no solo ayudan dentro de ese equipo Kanban, sino que también ayudan en
la interacción del equipo Kanban con otros interesados de la organización. Entonces eso es todo en esta conferencia. Gracias.
Monika Rawat, Product Manager. Entrepreneur
