No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripción 🔥

Aprende todo un fin de semana sin pagar una suscripción 🔥

Regístrate

Comienza en:

4D
1H
27M
1S

Agile en ingeniería de datos

6/24
Recursos

Aportes 14

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

o inicia sesión.

Scrum vs Kanban
En muchos casos se intenta diferenciar Kanban de lo que es la metodología Scrum en sí, por lo que vamos a ver algunas de las diferencias que existen entre ambas:

En Scrum existen los roles de Scrum Master, de Product Owner y del equipo, mientras que Kanban no existen roles.
En Scrum se trabaja con iteraciones de tiempo fijo, con unos ciclos fijos que se denominan Sprints, mientras que en Kanban tenemos un trabajo continuo y no tenemos esas interacciones o esos ciclos durante el desarrollo.
Scrum limita el WIP (work in process o número de tareas que se pueden tener en paralelo en una de las posiciones del tablero) por iteración, mientras que Kanban limitar ese WIP por el estado del flujo de trabajo.
Mientras que Scrum exige equipos multidisciplinares, para que todos los miembros del equipo puedan realizar varias tareas y sea todo más más ágil, en Kanban se permiten los equipos formados por especialistas. En este caso podemos tener algún problema a la hora de gestionar esos equipos, pero existen una serie de normas o de prácticas para llevar a cabo para solucionarlo.
En Scrum no se permiten cambiar las tareas del Sprint, es decir, una vez que la tarea asignada al mismo no puede ser movida, en todo caso lo que se permite es modificar la fecha de entrega del Sprint, pero no esa tarea. En Kanban, por el contrario, se puede modificar la tarea hasta que entra en flujo, hasta ese momento podemos modificar la tarea.
En Scrum la pila del producto, es decir, el conjunto de tareas que tenemos que realizar durante el Sprint, tiene que tener al menos el tamaño de un Sprint, ya que, lógicamente, no podemos tener menos de un Sprint. En Kanban, al tener un ritmo de trabajo continuo, lo que se hace es ir arrastrando las nuevas tareas por el panel hasta que lleguen a su estado final y finalicen. Cualquier nuevo requisito del cliente será una nueva tarjeta o post-it que se añadirá al flujo de entrada y que seguirá su flujo normal hasta la salida.
En Scrum se mide todo lo que sea necesario, se miden historias, es decir, cuánto nos va a llevar realizar cada historia de usuario, se mide cuánto tiempo o esfuerzo nos va a llevar realizar cada una de las tareas y se mide también la velocidad del equipo, que es la cantidad de trabajo que hemos realizado dividido por la cantidad de tiempo. En Kanban, como ya tenemos una cierta habilidad de la metodología, no se miden ni tareas ni velocidad.
En Scrum se necesita una pila del producto priorizada, porque como el desarrollo completo lo vamos a dividir en distintos Sprints, la necesitamos para que los primeros Sprints se encarguen de realizar las tareas de mayor prioridad. Con lo que vamos a conseguir llevar valor al cliente de una manera mucho más rápida y las tareas con menor prioridad serán realizando en los Sprints posteriores. Esta priorización la hará el Product Owner. En Kanban la historia o tarea es arrastrada directamente desde el cliente, por lo cual no necesita esa priorización.
En Scrum se tienen una serie de reuniones y se utilizan una serie de gráficos, como el burn down, en el que podemos ver el avance del proyecto, y el burn up, que sirve para medir la velocidad del equipo. En Kaban no se considera ni ese tipo de reuniones ni de gráficos.
En Scrum los tableros se van a resetear al final de cada Sprint, es decir, conforme vamos finalizando el mismo, el tablero queda vacío y comenzamos de nuevo añadir nueva nuevas historias de usuario, las siguientes en prioridad. En Kanban, como vamos a tener un flujo de entrada-salida, conforme las tarjetas van pasando por cada uno de los estados hasta llegar al estado final, cuando llegan a ese estado salen del tablero y se archivan, vamos a tener un flujo continuo.

Me parece interesante de kanban el flujo continuo y lo fácil de ver el progreso con el tablero kanban, aunque en scrum creo que el poder tener reuniones rapidas diariamente y una grande al final permite una gran retroalimentación y aprendizaje.
Al final de cuentas lo que importa es el criterio de escoger la mejor herramienta para resolver nuestro problema y no escoger la que es más popular.

despúes de esta clase me queda más claro el sistema de planeación que llevamos dentro de nuestro proceso, tenemos una combinación de los dos ya que por ejemplo manejamos sprints y distribución de tareas para cierto rango de tiempo , pero la manera en que las visualizamos es mediante tableros en dodne se refleja el por hacer, haciendo y hecho.

Mi resumen de la clase:

Agile se basa en hacer entregables que entreguen valor en cada etapa.

Scrum: Hay spring de 1 a 4 semanas. Las tareas se van refinando para hacer una buena planeación, hay daylis para saber en qué están todos que hicieron y que les impiden avanzar. Al terminar la semana se hacen entregables y se reflexiona sobre que deben de mejorar.
Kanban: Se van entregando tarjetas, hay un panel que se ponen lo que hay que hacer, lo que se esta haciendo y lo que se entregó.

Como recomendacion, la metodologia Agile o agil, tiene la ventaja de ir adaptandose al proyecto en cuestion, al contrario de una metodologia tradicional que se debe seguir el pie de la letra sin modificaciones para nuestro proyecto.

En resumen, tanto Scrum como Kanban son metodologías ágiles que buscan mejorar la eficiencia y la productividad de los equipos de trabajo. Si bien tienen enfoques diferentes, ambos pueden ser útiles dependiendo del proyecto y el equipo de trabajo.

En el caso de Scrum, es una buena opción cuando se tiene un equipo multidisciplinario que trabaja con plazos fijos y requiere una estructura más rígida para la toma de decisiones. Además, es útil para proyectos en los que es necesario priorizar tareas y trabajos con entregas concretas, y para equipos que requieren un mayor control en la planificación y ejecución de las tareas.

Por otro lado, Kanban es ideal para equipos que trabajan en proyectos de flujo continuo, en los que se necesita una mayor flexibilidad y adaptabilidad a los cambios en el proyecto y en las necesidades de los clientes. Es especialmente útil para proyectos en los que no hay un plazo fijo de entrega, ya que permite trabajar de manera más fluida y sin ciclos de tiempo predefinidos.

En cualquier caso, lo más importante es evaluar las necesidades del proyecto y del equipo de trabajo para determinar qué metodología se adapta mejor a ellas. Es posible que se necesite una combinación de ambas metodologías o incluso la adopción de otra metodología ágil distinta para obtener los mejores resultados.

Pienso que se puede usar Scrum como planeacion y Kanban diariamente para mantenernos enterados sin necesidad de tener una reu

Buena explicacion.

Kanban para mí es más enfocada en tareas no tan complejas, que llevan menos tiempo de desarrollo.
Scrum justamente lo contrario, para tareas más complejas que llevan más tiempo para resolver las soluciones a desarrollar, y para ir entregando valor al cliente en cortos periodo de tiempo.
Como desventaja de Kanban veo que se enfoca en continuidad del flujo de tareas, pero no hay reuniones seguidas para en equipo ver cómo está cada uno con sus tareas y en qué se puede colaborar con el otro.
Y como desventaja de Scrum, el error de equipos que lo implementan cuando no son proyectos ambiguos y complejos, entonces se tornan muchos de los pasos de Scrum innecesarios y no se termina cumpliendo la metodología.

Al parecer Kanban sirve para procesos de trabajo incipientes e intermedios y scrum para equipos de alta tecnología y de mayor volumen de trabajo

Scrumban FTW. Or anything really as long as it’s not waterfall 😆

Personalmente me gusta más SCRUM en terminos de planeacion, pero me ajusto a todo, creo que en lo que hago usamos ambas, yo no se jajaja, esas cosas me estresan pensarlo porque es complicar mucho el trabajo de developer; pero mientras más claras tengas las tareas y mejor puedas comunicarlo con tu equipo, más productivo es el desarrollo (es lo que me gusta de SCRUM), pero again, esa vaina es muy rara >-<

Considero que Kanban es para tareas mas rutinarias o procesos repetitivos. El proceso es cíclico e ilimitado. El período del sprint es mucho mas corto (1 semana por ejemplo) Scrum es mejor para proyectos en donde, al final del sprint, se puede tener un producto terminado (MVP). En cada sprint hay una mejora continua del producto. Los sprint tienden a ser mas largos.

Creo que Scrum es para desarrollos que implican un equipo de 4+ personas como puede ser un proyecto universitario final.
Por el contrario, Kanban es útil para desarrollos pequeños, de 2 a 3 personas como lo son proyectos en GitHub, donde en tu repositorio puedes tener una tabla de Kanban para que c/u de los colaboradores sepa en que se esta trabando sin necesidad de reuniones o comunicación directa ~