No tienes acceso a esta clase

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

Aprende Inglés, Programación, AI, Ciberseguridad y más a precio especial.

Antes: $249

Currency
$209
Suscríbete

Termina en:

2 Días
3 Hrs
37 Min
29 Seg

Agile en ingeniería de datos

6/25
Recursos

Aportes 33

Preguntas 1

Ordenar por:

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

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.

Yo he trabajado en una empresa con la metodología Kanban. Lo bueno es que, para tareas sencillas, Kanban es perfecto. Pero con tareas que requieren mas de 1 dia, se complica. Ya que Kanban esta diseñado para hacer tareas en cortos periodos. En esos casos, creo que queda a criterio de la empresa, ser mas flexible con la utilizacion de una u otra metodología.

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 ~

6. Agile en ingeniería de datos

  • Entregar resultados diferenciales de manera continua
  • Una advertencia: Muchos temas de Agile tienen muchísima opinión.
  • Scrum, se separa en sprints.
  • Kanban. Hacer contribuciones en corto tiempo por tarjetas.

La elección entre Scrum y Kanban depende de varios factores, incluyendo el tipo de proyecto, las necesidades del equipo y la cultura organizacional. Ambos marcos de trabajo ágiles tienen sus propias fortalezas y se adaptan mejor a diferentes situaciones. Veamos algunas características y consideraciones clave de cada uno:

Scrum:

  • Estructura: Scrum se basa en iteraciones llamadas “sprints” con una duración fija, generalmente de 1 a 4 semanas. Cada sprint tiene un objetivo claro y se planifica con un conjunto de historias de usuario.
  • Roles y responsabilidades: Scrum tiene roles específicos, como el Scrum Master (responsable de facilitar el proceso), el Product Owner (responsable de gestionar el backlog del producto) y el equipo de desarrollo.
  • Visibilidad y transparencia: Scrum promueve la transparencia y la visibilidad del progreso a través de reuniones diarias de seguimiento (Daily Scrum), reuniones de planificación de sprint, revisiones y retrospectivas.
  • Flexibilidad limitada: Scrum ofrece menos flexibilidad en términos de cambios durante un sprint, ya que se busca mantener la estabilidad durante ese período.

Kanban:

  • Flujo continuo: Kanban se basa en el flujo continuo de trabajo, visualizado a través de un tablero Kanban con columnas que representan diferentes etapas del proceso.
  • Limitación del trabajo en progreso (WIP): Kanban enfatiza la importancia de limitar el número de tareas en progreso a la vez para evitar cuellos de botella y maximizar la eficiencia.
  • Adaptabilidad: Kanban es más flexible y permite cambios en cualquier momento. No hay iteraciones fijas, lo que brinda más libertad para responder a las demandas cambiantes del proyecto.
  • Enfoque en la mejora continua: Kanban promueve la mejora continua del proceso, buscando identificar y eliminar los obstáculos y mejorar la eficiencia.

En resumen, Scrum es adecuado para proyectos donde se requiere una planificación más estructurada, con un enfoque en entregables específicos en cada sprint. Kanban, por otro lado, se adapta mejor a proyectos con requisitos cambiantes y un flujo de trabajo más continuo y flexible.

La elección entre Scrum y Kanban dependerá de las necesidades específicas del proyecto y del equipo, así como de la cultura y la capacidad de adaptación de la organización. Algunas organizaciones pueden incluso combinar elementos de ambos marcos de trabajo para crear un enfoque híbrido que se ajuste mejor a sus circunstancias.

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 >-<

** Scrum**

Agile Scrum es un marco de trabajo dentro de la filosofía Ágil que se basa en la colaboración y la planificación iterativa. El equipo de trabajo se organiza en roles como el Product Owner (dueño del producto), el Scrum Master (facilitador) y los desarrolladores. El trabajo se divide en iteraciones llamadas “sprints”, que suelen durar de 1 a 4 semanas. Durante cada sprint, el equipo elige una serie de tareas a realizar y trabaja en ellas. Al final del sprint, se presenta un incremento funcional del producto.

Ejemplo de Agile Scrum: Imagina que un equipo está desarrollando una aplicación móvil. En un sprint de dos semanas, se comprometen a diseñar la pantalla de inicio y permitir a los usuarios iniciar sesión. Al final del sprint, presentan la pantalla de inicio con la funcionalidad de inicio de sesión completa.

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.

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.

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.

la verdad y esto quizas es una opinion basada es en experiencia previa lo mejor es ambas, scrum gestiona mejor el tiempo, kanban gestiona mejor las tareas, unir ambos mundos es lo mejor, lo estandar de scrum son los sprint de dos semanas con las ceremonias diarias de 15 minutos, tambien a eso le agregas la weekly y la retro, si a esa gestion de tiempos le agregas lo mejor de kanban con el seguimiento de tareas es para mi un mundo ideal, o al menos el mejor que trabaje

Gracias

Kanban se centra en el flujo continuo de trabajo, permitiendo cambios en el trabajo en progreso cuando sea necesario. No tiene sprints fijos. y Scrum se basa en sprints, que son ciclos de desarrollo cortos y consistentes (usualmente de 1 a 4 semanas), al final de los cuales se entrega un incremento de producto potencialmente entregable.
scrum tiene mas pasos y roles, kanban no tiene roles, scrum se presta para el desarrollo de software, mientras que kamban esta mas orientado a la producción, kamban no tiene fin, scrum tiene un limite de tiempo.
![](https://static.platzi.com/media/user_upload/image-2aa0571d-41f8-46f2-b8db-faaf44633b19.jpg)
Kanban y Scrum son un marco diferente. Si bien Kanban se centra en la mejora de procesos, Scrum generalmente se implementa para ayudar a los equipos a finalizar más trabajos y más rápido. Para hacerlo, Scrum organiza “sprints”, sesiones de trabajo de dos semanas con reuniones diarias y una cantidad determinada de trabajo a finalizar durante el ciclo de Scrum. **Scrum es más estricto que Kanban.** Este marco incluye un conjunto específico de reglas que los equipos deben seguir, mientras que Kanban se usa más para visualizar el trabajo. Muchos equipos implementan Scrum en un tablero Kanban, pero en esos casos, la metodología sigue siendo Scrum, no Kanban. Esta última, más que una metodología estricta, es una forma de visualizar el trabajo.

Scrum y Kanban son dos metodologías ágiles de gestión de proyectos que comparten algunos principios, pero tienen diferencias fundamentales.

Scrum es un marco de trabajo más estructurado que se centra en la entrega incremental de productos o servicios. Se basa en un ciclo de desarrollo de dos semanas llamado sprint, durante el cual el equipo se centra en completar una lista de tareas o historias de usuario.

Kanban es un marco más flexible que se centra en la mejora continua del flujo de trabajo. Se basa en un tablero visual que representa las tareas en diferentes estados de progreso. El equipo puede agregar tareas al tablero según sea necesario y ajustar el flujo de trabajo según sea necesario.

En resumen, las principales diferencias entre Scrum y Kanban son:

Enfoque: Scrum es más estructurado y se centra en la entrega incremental, mientras que Kanban es más flexible y se centra en la mejora continua.

Ciclos: Scrum utiliza un ciclo de desarrollo de dos semanas, mientras que Kanban no tiene ciclos definidos.

Tareas: Scrum se centra en historias de usuario, mientras que Kanban se centra en tareas individuales.

Scrum → Cuando tenemos un proyecto que podemos visualizar e ir entregando por partes. Kanban → Cuando no podemos planear ni una semana y necesitamos disminuir el tiempo de entrega a nuestros usuarios. Scrum → Lo que busca es visualizar que es lo que van a entregar y como pueden ir cambiandolo hasta perfeccionalizarlo. Kanban → Conocer e identificar los estados por los que cambia tu equipo para hacerlo mas visible. Scrum → Equipos multifuncionales, es decir que se complementan para no detener dependencias de diferentes areas. Kanban → No necesitas siquiera tener un equipo de trabajo, puede ser de una sola persona. Scrum → Trabajan con entregas de plazos fijos (Spring) Kanban → No se pueden definir plazos de entregas, no hay una planeación. Scrum → Se preescriben roles, necesitamos un product owner que se encarga de que se haga cada vez lo mas importante, mientras que el scrum master se encarga de que todo funcione bien y este con una mejora constante. Kanban → No se tienen roles definidos. Scrum → Los cambios se toman en consideración en el Baclock para el siguiente spring. Kanban → Los cambios van ingresando con forme a la priorización que se le va dando. Scrum → Es mas prescriptivo, te dice mas cosas por hacer, mas reglas. Kanban → Es mas adaptativo, parte de pocas reglas para que nosotros las moldearemos. Kanban → No solo es tener un tablero en el cual podamos ver el avance, ya que kanban se enfoca en reducir el Lead Time, que es el tiempo en el que dura una tarea es ser terminada. La implementación de Scrumban se recomienda que se haga empezando con Kanban en la cual podemos implementar ciertas partes de Scrum.
Algo interesante que puedo mencionar acá es que, en Scrum, se pueden usar herramientas cuya disposición visual recuerda mucho a Kanban. Por ej., en mi antiguo empleo usábamos JIRA para revisar la asignación y estado de las actividades (to be done, in process, done, under review, etc). La definición de estados es flexible, pero la mecánica de Scrum prevalece.
![](https://static.platzi.com/media/user_upload/image-a8c253a5-f069-4a1f-9a0b-aa90d5a35647.jpg)

AGILE

La filosofía de trabajo Ágil es una manera de abordar proyectos en la que se valora la flexibilidad, la colaboración y la adaptabilidad. En lugar de planificar todo el proyecto de antemano, se divide en partes más pequeñas llamadas “iteraciones” o “sprints”. Cada iteración produce un resultado parcial y funcional, lo que permite realizar ajustes y mejoras constantes en el proyecto a medida que avanza. El enfoque Ágil promueve la comunicación entre los miembros del equipo y la respuesta rápida a los cambios.

La agilidad viene implementada en dos grandes metodologias que buscan hacer esa contribución diferencial, estas son SCRUM y KANBAN.

Kanban

Agile Kanban es otro método dentro de la filosofía Ágil que se centra en la visualización y el flujo de trabajo. Se utiliza un tablero Kanban con columnas que representan diferentes etapas del proceso, como “Por hacer”, “En proceso” y “Hecho”. Las tareas se mueven de una columna a otra a medida que avanzan en el proceso. Kanban permite una planificación y ajuste más flexibles, ya que no está limitado por iteraciones fijas.

Ejemplo de Agile Kanban: Supongamos que un equipo de diseño trabaja en la creación de elementos gráficos para un sitio web. Utilizan un tablero Kanban y tienen tareas en las columnas “Por hacer”, “En diseño” y “Listo para revisar”. A medida que completan los diseños, los mueven a la columna “Listo para revisar” para que el equipo pueda aprobarlos.

Bueno, mi aporte es solo relativo a mi escaso o nulo conocimiento del funcionamiento mas allà de lo visto hasta aquí. (Ya llegaré al curso para tener mas panorama) Hasta ahora me parece mejor Scrum, siempre y cuando se itere luego del tiempo que determine la organización. Pero reitero, solo toco de oido.

todo depende el proyecto al cual vamos a intervenir, depende de lo que se adapte al momento, de momento he trabajado con el metodo kambas pro ser tareas cortas

A Kanban lo veo útil para ordenar el trabajo pendiente en equipos pequeños, cumpliendo lo que promete: dar visibilidad. En contrapartida, tiene como debilidad no ser la herramienta más efectiva al momento de generar reportes, tener una visión macro del proyecto o retroalimentar a partir de lo aprendido.

Scrum Vs Kanban

  1. En scrum existen dos figuras; la de scrum master y product owner, mientras que en kanban no existe estos roles.

  2. En scrum se manejan unos tiempos fijos que se llaman sprints, sin embargo, en kanban se tiene un trabajo continuo.

  3. la metodologia scrum limita el numero de tareas que se pueden tener en paralelo en el tablero, pero en kanba se limita el Trabajo en proceso por el estado del flujo del trabajo.

  4. con scrum se exigen equipos multidisciplinarios, para que los miembros del equpo tengan la capacidad de realizar varias tareas, en kanban se permiten equipos conforados solo por especialistas.

  5. En Scrum no es posible cambiar las tareas del Sprint, lo que significa que una vez se haya asignado la tarea al mismo, este no podrá ser movida, en cualquier caso, lo que se permite es modificar la fecha de entrega más no la tarea. Por el contrario, en Kanban, se puede modificar la tarea hasta que entra en flujo, una vez entre en ese proceso, no se podrá modificar.

  6. En Scrum el conjunto de tareas que se realizan durante el Sprint, debe tener, por lo menos, el tamaño de un Sprint, ya que no se puede tener menos de uno. Todo lo contrario sucede con 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.

  7. En Scrum se mide todo lo que sea necesario, se mide lo que se va a llevar realizar cada historia de un usuario, también se mide cuánto tiempo se lleva culminar cada tarea, y se mide la velocidad del equipo. En Kanban, como ya se tiene una cierta destreza de la metodología, no se miden las tareas ni la velocidad.

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ó.

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 😆

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.