En resumen: los diagramas de Gantt son útiles cuando las dependencias son el factor principal en la formación del programa, mientras que los tableros Kanban se pueden usar para trabajos que no tienen dependencias entre ellos.
Además, los gráficos de Gantt son adecuados cuando hay un plan preliminar para todo el contenido del proyecto (al menos de alto nivel), mientras que los tableros Kanban son más adecuados para los casos en que todo el plan surge y se finaliza a medida que se desarrolla el proyecto.
Los tableros Kanban son más adecuados para el trabajo repetitivo (trabajo con pasos similares), y los diagramas de Gantt son los mejores para combinar diferentes tipos de trabajo.
Finalmente, estas herramientas implican diferentes perspectivas de trabajo, que deberían corresponder a su enfoque de trabajo y su enfoque de desarrollo (ágil o predictivo).
Ahora tomemos unos minutos más para descubrir los detalles.
Estas son más que solo diferentes formas de visualizar datos.
Los diagramas de Gantt y los tableros Kanban se ven muy diferentes, ¿verdad?
Tanto el diagrama de Gantt como el tablero Kanban ofrecen de manera predeterminada sus propias formas de visualizar datos. Aunque el método de visualización puede ser importante y tener implicaciones prácticas, los conceptos y métodos subyacentes son más importantes, así que echemos un vistazo rápido a ellos.
Los conceptos detrás de los tableros Kanban
Primero, es importante tener en cuenta que Kanban Board es diferente de Kanban, que es un método, y también diferente de Kanban Development, que es una alternativa a Scrum (y está inspirado en gran medida por Scrum).
El método Kanban se ha utilizado en producción durante algún tiempo. El método tiene varias reglas, y una de ellas es visualizar el trabajo. Esta visualización se realiza en tableros kanban.
En el método Kanban, determinamos las etapas en el trabajo y creamos columnas para ellos en el tablero.
En cada etapa, varias personas trabajan. Añádalos también a la pizarra.
Otra regla fundamental en Kanban (además de la visualización) es que cada etapa del trabajo debe tener un límite de trabajo incompleto para que pueda concentrarse en completar las tareas.
No existe una fórmula para calcular el límite ideal de trabajo en progreso para cada etapa. Como regla general, las personas establecen el valor inicial sobre la base de su propia experiencia, y luego buscan lo óptimo por ensayo y error.
Entonces, agreguemos límites de trabajo en progreso al tablero.
Imaginemos que ya están trabajando en varios elementos.
Por lo general, en tales casos, enviamos el elemento a la siguiente etapa, es decir, "lo empujamos". Kanban ofrece otra solución: es un sistema de "atracción", es decir, no podemos enviar el trabajo a la siguiente etapa; permanece allí hasta que el siguiente paso requiera otro elemento de trabajo y no lo "arrastrará" a su columna.
¿Suena raro? ¿Has pensado en las diferencias prácticas entre los enfoques? Hablaré de ellos en un minuto, pero primero, vamos a actualizar nuestro tablero para visualizarlo mejor dividiendo cada columna en dos secciones: una para los elementos de esta columna que aún necesitan trabajo y otra para los que están terminados.
Ahora, en lugar de mover (F) a la siguiente columna, lo colocamos en el lado derecho de la misma columna.
Entonces, preguntaste sobre la diferencia práctica, y aquí está: imagina que (G), (H), (I) y (C) están terminados.
¿Qué harás si estás en la Etapa 2?
Por lo general, la respuesta es esta: toma el elemento (I) de la columna anterior y comienza a trabajar en él. Pero espere, ¡su límite de trabajo en progreso es tres y ya tiene tres elementos! Sí, (F), (G) y (H), que están en el lado derecho de la columna, todavía se cuentan. También es un sistema de extracción, y debe esperar a que las personas en el paso 3 se estiren (F), en lugar de empujarlo hacia su columna.
El problema es que no se le permite tomar un nuevo elemento de trabajo, pero no tiene nada más que hacer; Entonces, ¿qué está pasando ahora?
Esta restricción es crítica en Kanban. En este punto, las personas en la Etapa 2 no pueden comenzar a trabajar en un nuevo elemento y deben ir y ayudar a las personas que están lidiando con un cuello de botella: la Etapa 3 en nuestro ejemplo:
Esto puede extenderse a otras columnas: cuando (J) se ejecuta en la Etapa 1 y (A) y (B) se realizan en la Etapa 4, también deben unirse a la Etapa 3 e intentar resolver el problema juntos.
Esta es la idea del método Kanban: todos se centran en todo el proceso, y no en una de sus etapas, y se da la máxima prioridad a la finalización temprana de los elementos de trabajo, en lugar de completar una gran cantidad de tareas y crear trabajos inacabados.
Entonces, entonces, el tablero Kanban es la forma en que visualizamos esta opción de trabajo. Generalmente enfatizo esto porque la mayoría de las personas usan pizarras blancas, como Trello, como un método simple de visualización gratuita para sus tareas, independientemente del método Kanban. (Debo admitir, ¡a veces también lo hago!)
Entonces, echemos un vistazo a los conceptos subyacentes a los gráficos de Gantt, y luego podemos compararlos.
Conceptos del diagrama de Gantt
Aquí hay un gráfico típico de Gantt:
Como puede ver, las fechas de inicio y finalización de las operaciones se muestran aquí, existe la fecha de finalización del proyecto en su conjunto. ¿De dónde vienen las fechas?
Un diagrama de Gantt normal se basa completamente en dependencias entre operaciones. Por ejemplo, la operación A 'del resultado B no puede comenzar hasta que se complete la operación A del resultado A.
Entonces, para crear un diagrama de Gantt, primero creamos un SRI, que significa "estructura jerárquica de trabajo", aunque en realidad no se trata de trabajo, sino de la jerarquía de resultados / productos. (Al menos debería serlo).
Luego verificamos qué operaciones deben realizarse para obtener cada resultado y las agregamos a la lista. Estas acciones son algo similares a las columnas en el tablero Kanban, excepto que no estamos limitados a un conjunto fijo de pasos, y cada resultado puede ser diferente.
Luego evaluamos la duración de las operaciones.
Luego determinamos las dependencias entre operaciones, que a su vez afectarán las fechas de inicio y finalización de las operaciones. Las fechas generalmente se calculan utilizando el método de ruta crítica (CPM).
Y voila, tenemos un horario!
Bueno, esta es la forma más simple de programación, también puede tener en cuenta los recursos, las restricciones, las diferentes horas de trabajo para diversas operaciones y recursos, etc.
Entonces, el primer resultado de usar esta combinación de CPM / Gantt es que tendremos un cálculo ascendente que nos dará la fecha de finalización del proyecto. Pero eso no es todo ... podemos aprender mucho más.
Aquí hay algunos ejemplos:
Podemos verificar diferentes escenarios
Supongamos que nos preocupa que uno de los proveedores pueda completar el trabajo 30 días después. ¿Cómo afectará esto al proyecto? Esto no es fácil de determinar en un sistema no lineal, pero cuando tenemos el modelo de programación correcto, simplemente podemos cambiar la duración de este elemento y ver cómo afecta a todo lo demás.
Podemos analizar los retrasos
Supongamos que completamos nuestro proyecto tres meses después de lo que deberíamos. Sin embargo, algunas partes del proyecto se retrasaron debido al cliente, y ahora necesitamos analizar las demoras y ver qué parte de la demora es nuestra responsabilidad. En este caso, podemos agregar retrasos del cliente a los elementos del gráfico, ver qué retraso crean para todo el proyecto, y luego la diferencia entre este y el retraso real será nuestra responsabilidad.
Podemos encontrar las operaciones más importantes.
No todas las operaciones son equivalentes. Algunos pueden retrasarse por un tiempo razonable sin retrasar todo el proyecto, mientras que otros tienen un mayor impacto, lo que significa que cada día de retraso en estas operaciones agregará un día de retraso a todo el proyecto. ¿No vale la pena saber qué operaciones son críticas y, por lo tanto, tener más cuidado con ellas? El método de la ruta crítica nos ayuda a encontrar estas acciones.
Entonces, examinamos los conceptos y métodos que subyacen a los diagramas de tableros de Gantt y Kanban. Ahora realmente podemos compararlos.
Diferencias en el contexto
Los diagramas de Gantt están destinados a proyectos y no a producción y otros tipos de actividades diarias (es decir, negocios ordinarios u OS). He visto a muchas personas ver sus asuntos diarios como proyectos e intentar usar herramientas y métodos como el diagrama de Gantt y el CPM, pero esto no funciona muy bien. También vi personas que afirman que todo es un proyecto (lo que generalmente me anima a comenzar una discusión muy larga con ellos;)
Kanban, por otro lado, estaba originalmente (y quizás principalmente) destinado a la producción, pero la gente lo ha usado durante mucho tiempo en proyectos.
Diferencias en los tipos de elementos de trabajo
Las columnas se fijan en el tablero Kanban, lo que lo hace útil cuando los elementos tienen etapas muy similares de trabajo en ellas. Este no es siempre el caso, lo que limita el uso de Kanban. Siempre podemos obligarnos a hacer que las columnas sean lo más generales posible, aplicables a cada elemento, pero esto hace que el sistema Kanban sea ineficaz.
Por lo tanto, si los elementos en su proyecto son muy diferentes entre sí (por ejemplo, en un proyecto de construcción), el tablero Kanban puede no funcionar.
Diferencias de dependencia
Un diagrama de Gantt es casi sin sentido sin dependencias. Todavía recuerdo uno de los lanzamientos de Microsoft Project hace muchos años cuando introdujeron por primera vez la "planificación manual" y fue posible crear diagramas sin dependencias. ¡Muchos consideraron esta blasfemia!
A pesar de esto, puede considerar CPM / Gantt como una herramienta para administrar dependencias, pero este no es el caso con el tablero Kanban, que se utiliza cuando los elementos en sí no tienen interdependencias, y la única dependencia son las etapas de trabajo, que se visualizan en forma de columnas en pizarra
Para los proyectos, el concepto de dependencias es un poco controvertido. La explicación general es que hay dependencias en los proyectos predictivos (algunas personas llaman a esto una "cascada", que no me gusta) y, por lo tanto, el diagrama de Gantt es una buena opción; mientras que en los proyectos Agile no hay dependencias, de ahí la propuesta de usar tableros Kanban.
Incluso escuché a algunas personas que no son grandes admiradores de Agile cuestionar a Agile porque "no tiene en cuenta las adicciones". El hecho es que Agile no ignora las dependencias, pero la idea es abordar el proyecto y formar elementos de tal manera que no se creen dependencias. Si se hace correctamente, no habrá dependencias (o al menos no muchas).
Diferencias en los métodos de planificación
El diagrama de Gantt funciona cuando hay un plan preliminar que cubre todo el alcance del proyecto, y funciona mejor cuando el plan es relativamente detallado. Esto se debe al hecho de que si solo los elementos de un nivel muy alto están presentes en el plan, las dependencias entre ellos serán muy inexactas y bastante arbitrarias, ya que las relaciones reales se forman sobre la base de operaciones relativamente pequeñas, y luego se reflejan en los niveles más altos del plan.
Por lo tanto, si no hay un plan completo al comienzo del proyecto, el diagrama de Gantt no funcionará. Por otro lado, no existen tales restricciones en el método Kanban. Siempre puede agregar nuevos elementos a la primera columna y organizar la columna nuevamente; luego continúas y agregas más elementos a medida que aparecen. Para comprender mejor esto, imagine un equipo que admita una aplicación de software en vivo, corrija errores y agregue características menores (que es una rutina diaria, no un proyecto).
Debido a esto, el diagrama de Gantt no es adecuado para proyectos Agile típicos en los que no hay planes preliminares. Sin embargo, algunos proyectos ágiles (como DSDM) tienen un plan preliminar de alto nivel.
Cuando usar tableros Kanban
Dado que los proyectos ágiles pueden tener elementos sin dependencias, puede usar tableros Kanban en ellos. Puede ser un tablero Kanban solo para visualización, como suele ser el caso en la mayoría de los proyectos Scrum, o una técnica Kanban con su propio tablero, que a menudo se encuentra en el método de desarrollo Kanban.
Por otro lado, un proyecto ágil típico al principio puede no tener un contenido claro, pero permite que aparezca y se desarrolle a lo largo de todo el proyecto. Está muy bien mantenido por Kanban.
De hecho, no es posible eliminar dependencias en proyectos predictivos, ni lanzar un proyecto sin contenido específico. Aunque siempre puede comenzar un proyecto sin un plan, no se convertirá en un proyecto predictivo o adaptativo; Será solo un caos. Por lo tanto, ya por estas dos razones, Kanban no será una buena solución para proyectos predictivos.
Cuándo usar gráficos de Gantt
Un proyecto predictivo tiene muchas dependencias y cierto contenido, que se determina de antemano. El diagrama de Gantt está diseñado específicamente para admitir este tipo de proyecto: ¡es simple!
Dado que los proyectos ágiles no tienen dependencias (o al menos no deberían tenerlas), el diagrama de Gantt no les será útil. Aunque algunos proyectos Ágiles (como DSDM) tienen un plan preliminar de alto nivel que se puede administrar usando un diagrama de Gantt, la mayoría de los proyectos Ágiles que usan Scrum o sus otras variaciones no necesariamente tienen ningún plan preliminar, lo que hace que el uso de un diagrama de Gantt sea prácticamente imposible
Combinación
Entonces, ¿qué tal combinar dos herramientas?
Cada uno de ellos es más útil para uno de los enfoques; así que esto no ayudará si intentamos mezclar las dos herramientas a nivel de proyecto. Sin embargo, quizás un escenario útil es tener un diagrama de Gantt para el proyecto en su conjunto (proyecto predictivo) y usar los tableros Kanban para las etapas del proyecto, según corresponda. Por ejemplo, en un proyecto de construcción, podemos usar tableros Kanban para etapas de trabajo que tienen menos dependencias y resultados similares. Algunos pasos de diseño son adecuados para esto.
Curiosamente, algunas herramientas de planificación admiten ambas vistas para el mismo conjunto de datos, lo que significa que puede planificar su proyecto con ellas y visualizarlo como un diagrama de Gantt y un tablero Kanban. Son muy útiles para tal mezcla.