Metodologías de trabajo: Scrum vs Kanban


Pasemos a definir primero ambas metodologías de trabajo y luego veremos las diferencias entre ellas:

Scrum

Scrum es un marco ágil que define roles (Product Owner, ScrumMaster…), artefactos (Product Backlog, Release Backlog, Sprint Backlog…) y prácticas (Reuniones cortas diarias -Daily Standups-, planificación de Sprints, reuniones para las revisiones de Sprints…).

Los equipos que trabajan con Scrum toman el cuerpo de un trabajo (como una serie de requisitos para construir un producto de software) y lo dividen en pequeñas unidades de trabajo (User Stories) cuya prioridad puede ser cambiante según las necesidades.

Al tomar una pequeña parte de las unidades de trabajo y comprometerse a acabar con ellos antes de un plazo corto de tiempo (conocido como Sprint, que suelen ser unos 10 días hábiles), el equipo puede centrarse en la construcción del siguiente pequeño incremento del producto antes de detenerse, replanificar y acometer de nuevo.

Es un buen método, pero a su vez bastante perjudicial, puesto que no se obtendrá el 50% de los beneficios, poniendo en el 50 % del esfuerzo. Para tener éxito en Scrum tienes que darle roles a las personas del equipo, enseñarles y organizar el trabajo de acuerdo a la metodología. Tener sesiones de limpieza del backlog, mediciones en los llamados Story Points, etc. Es un método bastante prescriptivo que requiere que el equipo se adapte a las normas para seguirlas correctamente.

La realidad es que en la informática se depende de muchos factores externos (problemas de hardware en los servidores, se pierde la conectividad, etc.), y aunque Scrum es bueno para planear toda la estabilidad que promete (con un sprint backlog fijo de trabajo), la realidad es que los equipos tienen que lidiar con estas interrupciones, y la absorción de estas no es una característica fuerte de Scrum.

Hay otra características de Scrum, y es que se suele tener un “Scrum board” para visualizar el estado del trabajo en esta pizarra e ir moviendo y pegando post-it distribuidos en líneas según el estado y tareas. Como podemos ver en la siguiente imagen:

Hay otra característica de Scrum que aparece al hacer esta actividad muy similar a Kanban, que es decir si usted no entiende la diferencia entre los cocodrilos y caimanes.

Kanban

Una característica de Kanban, es que se suele tener un “Kanban board” para visualizar el estado del trabajo en esta pizarra e ir moviendo y pegando post-it distribuidos en líneas según el estado y tareas. Como podemos ver en la siguiente imagen:

En esto radica la dificultad de entender la diferencia entre Scrum y Kanban, cuando los artefactos más visibles de ambos métodos son exactamente los mismos. Se dice, que intentar buscar la diferencia entre ambos es como entender la diferencia entre un cocodrilo y un alligator.

No obstante, hay diferencias significativas en Kanban. Lo primero es que es un método evolutivo que introduce cambios en la organización. Lo que significa que no hay roles o prácticas adicionales a introducir en las organizaciones que adopten este método.

Los roles y funciones existentes se mantienen en Kanban. Los flujos de trabajo se investigan y se visualizan para proporcionar control de todo el trabajo, pero que no cambian la forma en que la gente hace su trabajo o cómo interactúan con él.

Scrum se ocupa de los problemas asociados con el desarrollo de producto y presenta métodos para aumentar la agilidad.
Kanban examina la cadena desde arriba (quizás desde los departamentos de ventas y de marketing donde se generan las ideas) a través de los departamentos de fabricación / desarrollo / técnicos, hacia abajo hasta el punto donde el valor o producto se libera al cliente (cómo se embalan o se envían).

Es similar a la cadena de producción definida para la creación de un coche, desde que el acero bruto llega por un extremo de la fábrica hasta que a través de la factoría y los procesos de refinamiento, hasta que sale un coche por el otro extremo de la fábrica. Kanban revisa y controla toda la cadena de creación del producto.

Imagina que estás en un departamento de IT donde se va a construir un nuevo ordenador portátil. Seguramente tendrás una cadena de valores que comienza por una solicitud a RRHH notificando un nuevo empleado. Se toman las acciones (los portátiles están ordenados, con una imagen, configurados, se añaden varios sistemas de manejo). En algún punto más tarde, el ordenador será entregado al cliente. Acabas de describir una cadena de valor que se puede visualizar, gestionar y gradualmente mejorar con Kanban.

Veamos la diferencia entre ambas metodologías:

Diferencias: Scrum vs Kanban

Scrum Kanban
Se introducen nuevos roles y prácticas. Hay que adaptarse a la nueva rutina de la metodología. Se introducen cambios evolutivos en la forma existente de trabajo. Los roles y prácticas no cambian.
Es más adecuado a los proyectos de desarrollo de aplicaciones donde un producto es construido usando un proceso repetitivo./td>

Puede ser usado en este contexto también, pero también se adecua para trabajos de tipo operacional, día a día, de negocio o actividad normal.
Bloquea un compromiso durante el periodo que dura el Sprint (2 semanas), donde los equipos de trabajo no deberían cambiar. Permite diferentes clases de trabajo para acomodar las tareas más prioritario basado en la clase de servicio.

Fuente:

Scrum vs Kanban


http://www.infoq.com/news/2009/05/kniberg-kanban-v-scrum
https://www.scrumalliance.org/community/articles/2014/july/scrum-vs-kanban

Dejar un Comentario