En bref - les diagrammes de Gantt sont utiles lorsque les dépendances sont le principal facteur dans la formation de la nomenclature, tandis que les tableaux Kanban peuvent être utilisés pour des travaux qui n'ont pas de dépendances entre eux.
De plus, les diagrammes de Gantt conviennent lorsqu'il existe un plan préliminaire pour l'ensemble du contenu du projet (au moins de haut niveau), tandis que les tableaux Kanban conviennent mieux aux cas où l'ensemble du plan apparaît et est finalisé au fur et à mesure que le projet se développe.
Les tableaux Kanban sont mieux adaptés aux travaux répétitifs (travail avec des étapes similaires), et les diagrammes de Gantt sont les meilleurs pour combiner différents types de travaux.
Enfin, ces outils impliquent différentes perspectives sur le travail, qui doivent correspondre à votre approche du travail et à votre approche du développement (Agile ou prédictif).
Prenons maintenant quelques minutes de plus pour comprendre les détails.
Ce sont plus que des façons différentes de visualiser les données.
Les diagrammes de Gantt et les tableaux Kanban sont très différents, non?
Le diagramme de Gantt et le tableau Kanban proposent par défaut leurs propres méthodes de visualisation des données. Bien que la méthode de visualisation puisse être importante et avoir des implications pratiques, les concepts et méthodes qui la sous-tendent sont plus importants, alors examinons-les rapidement.
Les concepts derrière les tableaux Kanban
Tout d'abord, il est important de noter que Kanban Board est différent de Kanban, qui est une méthode, et également différent de Kanban Development, qui est une alternative à Scrum (et est largement inspiré de Scrum).
La méthode Kanban est utilisée en production depuis un certain temps. La méthode a plusieurs règles, dont l'une consiste à visualiser le travail. Cette visualisation se fait sur des tableaux kanban.
Dans la méthode Kanban, nous déterminons les étapes du travail et créons des colonnes pour elles sur le tableau.
A chaque étape, plusieurs personnes travaillent. Ajoutons-les également au tableau.
Une autre règle fondamentale dans Kanban (en plus de la visualisation) est que chaque étape du travail doit avoir une limite sur le travail incomplet afin que vous puissiez vous concentrer sur l'achèvement des tâches.
Il n'y a pas de formule pour calculer la limite idéale de travail en cours pour chaque étape. En règle générale, les gens définissent la valeur initiale sur la base de leur propre expérience, puis recherchent l'optimum par essais et erreurs.
Ajoutons donc des limites de travaux en cours au tableau.
Imaginons qu'ils travaillent déjà sur plusieurs éléments.
Habituellement, dans de tels cas, nous envoyons l'élément à l'étape suivante, c'est-à-dire «le poussons». Kanban propose une autre solution: c'est un système de «traction», c'est-à-dire que nous ne pouvons pas envoyer de travail à l'étape suivante; il reste là jusqu'à ce que l'étape suivante nécessite un autre élément de travail et il ne le "tirera" pas dans sa colonne.
Ça a l'air bizarre? Avez-vous pensé aux différences pratiques entre les approches? Je vais en parler dans une minute, mais d'abord, mettons à jour notre tableau pour mieux le visualiser en divisant chaque colonne en deux sections: une pour les éléments de cette colonne qui ont encore besoin de travail, et un pour ceux qui sont terminés.
Maintenant, au lieu de déplacer (F) vers la colonne suivante, nous le plaçons sur le côté droit de la même colonne.
Donc, vous avez posé des questions sur la différence pratique, et la voici: imaginez que (G), (H), (I) et (C) sont finis.
Que ferez-vous si vous êtes à l'étape 2?
Habituellement, la réponse est la suivante: vous prenez l'élément (I) de la colonne précédente et commencez à travailler dessus. Mais attendez - votre limite de travail en cours est de trois, et vous avez déjà trois éléments! Oui - (F), (G) et (H), qui sont sur le côté droit de la colonne, sont toujours comptés. C'est également un système de traction, et vous devez attendre que les personnes à l'étape 3 s'étirent (F), plutôt que de les pousser dans leur colonne.
Le problème est que vous n'êtes pas autorisé à prendre un nouvel élément de travail, mais vous n'avez plus rien à faire; alors qu'est-ce qui se passe maintenant?
Cette restriction est critique dans Kanban. À ce stade, les personnes de l'étape 2 ne peuvent pas commencer à travailler sur un nouvel élément et elles doivent aller aider les personnes confrontées à un goulot d'étranglement - étape 3 dans notre exemple:
Cela peut s'étendre à d'autres colonnes: lorsque (J) est exécuté à l'étape 1 et (A) et (B) sont exécutés à l'étape 4, ils doivent également rejoindre l'étape 3 et essayer de résoudre le problème ensemble.
C'est l'idée de la méthode Kanban: tout le monde est concentré sur l'ensemble du processus, et non sur l'une de ses étapes, et la plus haute priorité est donnée à l'achèvement précoce des tâches, au lieu de terminer un grand nombre de tâches et de créer un travail inachevé.
Donc, le tableau Kanban est la façon dont nous visualisons cette option de travail. J'insiste généralement sur ce point car la plupart des gens utilisent des tableaux blancs, tels que Trello, comme méthode de visualisation gratuite simple pour leurs tâches, quelle que soit la méthode Kanban. (Je dois admettre, parfois je le fais aussi!)
Examinons maintenant les concepts sous-jacents aux diagrammes de Gantt, puis nous pouvons les comparer.
Concepts de diagramme de Gantt
Voici un diagramme de Gantt typique:
Comme vous pouvez le voir, les dates de début et de fin des opérations sont affichées ici, il y a la date d'achèvement du projet dans son ensemble. D'où viennent les dates?
Un diagramme de Gantt normal est entièrement basé sur les dépendances entre les opérations. Par exemple, l'opération A 'du résultat B ne peut pas commencer avant la fin de l'opération A du résultat A.
Ainsi, pour créer un diagramme de Gantt, nous créons d'abord un SRI, ce qui signifie «structure hiérarchique du travail», bien qu'en fait il ne s'agit pas de travail, mais de la hiérarchie des résultats / produits. (Au moins, ça devrait l'être.)
Ensuite, nous vérifions quelles opérations doivent être effectuées pour obtenir chaque résultat et les ajoutons à la liste. Ces actions sont quelque peu similaires aux colonnes du tableau Kanban, sauf que nous ne sommes pas limités à un ensemble fixe d'étapes, et chaque résultat peut être différent.
Ensuite, nous évaluons la durée des opérations.
Ensuite, nous déterminons les dépendances entre les opérations, qui à leur tour affecteront les dates de début et de fin des opérations. Les dates sont généralement calculées à l'aide de la méthode du chemin critique (CPM).
Et voila, nous avons un horaire!
Eh bien, c'est la forme la plus simple d'horaire, vous pouvez également prendre en compte les ressources, les restrictions, les différentes heures de travail pour diverses opérations et ressources, etc.
Ainsi, le premier résultat de l'utilisation de cette combinaison CPM / Gantt est que nous aurons un calcul ascendant qui nous donnera la date d'achèvement du projet. Mais ce n'est pas tout ... nous pouvons en apprendre beaucoup plus.
Voici quelques exemples:
Nous pouvons vérifier différents scénarios
Supposons que nous craignions que l'un des fournisseurs puisse terminer les travaux 30 jours plus tard. Comment cela affectera-t-il le projet? Ce n'est pas facile à déterminer dans un système non linéaire, mais lorsque nous avons le bon modèle de planification, nous pouvons simplement changer la durée de cet élément et voir comment il affecte tout le reste.
Nous pouvons analyser les retards
Supposons que nous ayons terminé notre projet trois mois plus tard que prévu. Cependant, certaines parties du projet ont été retardées en raison du client, et maintenant nous devons analyser les retards et voir quelle partie du retard est notre responsabilité. Dans ce cas, nous pouvons ajouter des retards client aux éléments du graphique, voir quel retard ils créent pour l'ensemble du projet, puis la différence entre cela et le retard réel sera de notre responsabilité.
Nous pouvons trouver les opérations les plus importantes
Toutes les opérations ne sont pas équivalentes. Certains peuvent être retardés pendant une durée raisonnable sans retarder l'ensemble du projet, tandis que d'autres ont un impact plus important, ce qui signifie que chaque jour de retard dans ces opérations ajoutera un jour de retard à l'ensemble du projet. Ne vaut-il pas la peine de savoir quelles opérations sont critiques, et donc d'être plus prudent avec elles? La méthode du chemin critique nous aide à trouver ces actions.
Nous avons donc examiné les concepts et les méthodes qui sous-tendent les diagrammes de Gantt et Kanban des planches. Maintenant, nous pouvons vraiment les comparer.
Différences de contexte
Les diagrammes de Gantt sont destinés à des projets, et non à la production et à d'autres types d'activités quotidiennes (c'est-à-dire une entreprise ordinaire ou des systèmes d'exploitation). J'ai vu beaucoup de gens voir leurs affaires quotidiennes comme des projets et essayer d'utiliser des outils et des méthodes tels que le diagramme de Gantt et le CPM, mais cela ne fonctionne pas très bien. J'ai aussi vu des gens qui prétendent que tout est un projet (ce qui m'encourage généralement à entamer une très longue discussion avec eux;)
Le kanban, d'autre part, était à l'origine (et peut-être principalement) destiné à la production, mais les gens l'ont longtemps utilisé dans des projets.
Différences dans les types d'éléments de travail
Les colonnes sont fixées sur le tableau Kanban, ce qui le rend utile lorsque les éléments ont des étapes très similaires de travail sur eux. Ce n'est pas toujours le cas, ce qui limite l'utilisation de Kanban. Nous pouvons toujours nous forcer à rendre les colonnes aussi générales que possible, applicables à chaque élément, mais cela rend le système Kanban inefficace.
Ainsi, si les éléments de votre projet sont très différents les uns des autres (par exemple, dans un projet de construction), le tableau Kanban peut ne pas fonctionner.
Différences de dépendance
Un diagramme de Gantt est presque vide de sens sans dépendances. Je me souviens encore de l'une des versions de Microsoft Project il y a de nombreuses années, lorsqu'elles ont introduit la «planification manuelle» et qu'il était possible de créer des diagrammes sans dépendances. Beaucoup considéraient ce blasphème!
Malgré cela, vous pouvez considérer CPM / Gantt comme un outil de gestion des dépendances, mais ce n'est pas le cas avec le tableau Kanban, qui est utilisé lorsque les éléments eux-mêmes n'ont aucune interdépendance, et la seule dépendance est les étapes de travail, qui sont visualisées sous forme de colonnes sur tableau noir.
Pour les projets, le concept de dépendances est un peu controversé. L'explication générale est qu'il existe des dépendances dans les projets prédictifs (certaines personnes appellent cela une «cascade», ce que je n'aime pas), et donc le diagramme de Gantt est une bonne option; alors que dans les projets Agile il n'y a pas de dépendances, d'où la proposition d'utiliser des tableaux Kanban.
J'ai même entendu des gens qui ne sont pas de grands fans d'Agile interroger Agile car "cela ne prend pas en compte les addictions". Le fait est qu'Agile n'ignore pas les dépendances, mais l'idée est d'aborder le projet et de former des éléments de telle manière que les dépendances ne soient pas créées. Si cela est fait correctement, il n'y aura pas (ou du moins pas beaucoup) de dépendances.
Différences dans les méthodes de planification
Le diagramme de Gantt fonctionne lorsqu'il existe un plan préliminaire qui couvre toute la portée du projet et fonctionne mieux lorsque le plan est relativement détaillé. Cela est dû au fait que si seuls des éléments d'un niveau très élevé sont présents dans le plan, les dépendances entre eux seront très imprécises et plutôt arbitraires, car les vraies dépendances sont formées sur la base d'opérations relativement petites, puis se reflètent aux niveaux supérieurs du plan.
Ainsi, s'il n'y a pas de plan complet au début du projet, le diagramme de Gantt ne fonctionnera pas. En revanche, il n'y a pas de telles restrictions dans la méthode Kanban. Vous pouvez toujours ajouter de nouveaux éléments à la première colonne et réorganiser la colonne; puis vous continuez et ajoutez d'autres éléments à mesure qu'ils apparaissent. Pour mieux comprendre cela, imaginez une équipe qui prend en charge une application logicielle en direct, corrigeant des bogues et ajoutant des fonctionnalités mineures (qui est une routine quotidienne, pas un projet).
Pour cette raison, le diagramme de Gantt n'est pas adapté aux projets Agile typiques dans lesquels il n'y a pas de plans préliminaires. Cependant, certains projets Agile (tels que DSDM) ont un plan préliminaire de haut niveau.
Quand utiliser les tableaux Kanban
Étant donné que les projets Agile peuvent avoir des éléments sans dépendances, vous pouvez utiliser des tableaux Kanban. Il peut s'agir soit d'un tableau Kanban uniquement pour la visualisation, comme c'est généralement le cas dans la plupart des projets Scrum, soit d'une technique Kanban avec son propre tableau, que l'on trouve souvent dans la méthode de développement Kanban.
D'un autre côté, un projet Agile typique au début peut ne pas avoir un contenu clair, mais lui permet d'apparaître et de se développer tout au long du projet. Il est très bien entretenu par Kanban.
En effet, il n'est ni possible de supprimer les dépendances dans les projets prédictifs, ni de lancer un projet sans contenu spécifique. Bien que vous puissiez toujours démarrer un projet sans plan, il ne deviendra pas un projet prédictif ou adaptatif; ce ne sera que du chaos. Ainsi, déjà pour ces deux raisons, Kanban ne sera pas une bonne solution pour les projets prédictifs.
Quand utiliser les diagrammes de Gantt
Un projet prédictif a de nombreuses dépendances et certains contenus, qui sont déterminés à l'avance. Le diagramme de Gantt est conçu spécifiquement pour soutenir ce type de projet - c'est simple!
Étant donné que les projets Agile n'ont pas de dépendances (ou du moins ne devraient pas en avoir), le diagramme de Gantt ne leur sera pas utile. Bien que certains projets Agile (tels que DSDM) aient un plan préliminaire de haut niveau qui peut être géré à l'aide d'un diagramme de Gantt, la plupart des projets Agile utilisant Scrum ou ses autres variantes n'ont pas nécessairement de plan préliminaire, ce qui rend l'utilisation d'un diagramme de Gantt pratiquement impossible.
Combinaison
Alors que diriez-vous de combiner deux outils?
Chacun d'eux est plus utile pour l'une des approches; donc cela n'aidera pas si nous essayons de mélanger les deux outils au niveau du projet. Cependant, un scénario utile est peut-être d'avoir un diagramme de Gantt pour le projet dans son ensemble (projet prédictif) et d'utiliser les tableaux Kanban pour les étapes du projet, le cas échéant. Par exemple, dans un projet de construction, nous pouvons utiliser des tableaux Kanban pour des étapes de travail qui ont moins de dépendances et des résultats similaires. Certaines étapes de conception conviennent à cela.
Fait intéressant, certains outils de planification prennent en charge les deux vues pour le même ensemble de données, ce qui signifie que vous pouvez planifier votre projet avec eux et le visualiser sous forme de diagramme de Gantt et de tableau Kanban. Ils sont très utiles pour un tel mix.