Quel est l'intérêt d'un diagramme de Gantt, et cela m'aidera-t-il? [fermé]

Mon collègue (non technique) m'a menacé d'un diagramme de Gantt pour un nouveau projet que nous planifions actuellement. Qu'est-ce que cela est susceptible de nous apporter et sera-ce un outil utile?

Comme le dit Wikipedia, le diagramme de Gannt est un type de graphique à barres (le plus souvent un "type de ligne") qui aide à la planification du projet. Il est souvent dessiné manuellement sur le mur sur une grande (très grande) feuille de papier, car il est facilement modifiable dans ce format.

Il s'agit d'un type très simple d'outil de planification; vous pouvez le produire dans Excel ou un équivalent; et plutôt efficace, tant que le temps requis pour certaines phases du projet peut être approximativement estimé. S'il y a un retard - pas de problème - une ligne est rallongée, les autres restent les mêmes et vous avez une nouvelle date de fin de projet.
Les phases qui se chevauchent (dans le temps) sont facilement visibles sur elle, aussi facilement que les dépendances du démarrage d'une phase en s'appuyant sur la fin d'une autre.

c'est tout ce qu'il y a vraiment.

Bien sûr, le problème avec le Gannt (ou le "chronogramme" comme on l'appelle généralement dans ma partie du monde) est que, au début d'un projet, vous avez tout bien rédigé sur le mur, en vous sentant enthousiaste et heureux, ... puis un retard se produit, et vous le changez sur le graphique, et vous vous sentez toujours heureux ... puis un autre retard se produit, vous le redessinez, et vous vous sentez toujours assez bien .. Des retards de 100x se produisent ... vous vous sentez comme _______ (censuré).

Cela signifie que ce n'est un bon outil de planification de projet que si vous respectez réellement ces petits délais. Alors arrêtez de perdre du temps ici et mettez-vous au travail!

Un diagramme de Gantt bien produit et maintenu peut être un excellent outil. Les principaux avantages sont de montrer quelles tâches dépendent d'autres tâches, de prédire comment le projet peut être affecté par des retards et de mettre en évidence les heures perdues parce que vous attendiez autre chose.

J'ai utilisé avec succès des diagrammes de Gantt dans le passé pour la gestion de projets logiciels. J'ai également vu des gens les abandonner, frustrés.

Tout outil de gestion de projet n'est utile que s'il répond à des questions que quelqu'un pose réellement. Dans mon cas, on me posait continuellement deux questions, et mon diagramme de Gantt pouvait y répondre:

• Mon responsable: quand le logiciel sera-t-il livrable?
• Un développeur: j'ai terminé la tâche que vous m'aviez confiée. Quelle tâche me confiez-vous maintenant?

Quels sont donc les facteurs nécessaires pour qu'un diagramme de Gantt soit utile?

Plusieurs membres de l'équipe

Cela devrait être évident. S'il n'y a qu'un seul membre de l'équipe, alors tout ce dont vous avez besoin est une liste de tâches dans une colonne. Vous allez seulement les faire l'un après l'autre.

Connaissance des tâches

Cela semble être une autre déclaration évidente, mais vous seriez surpris de voir combien de projets logiciels ne sont pas suffisamment bien définis pour pouvoir être divisés en tâches. Vous aurez en fait besoin d'une spécification initiale et d'un certain degré de conception initiale. Dans certaines des méthodologies agiles / extrêmes, vous ne pouviez pas utiliser un diagramme de Gantt, car vous ne savez pas quelles seront les tâches dans l'itération de 3 semaines suivante.

Temps et motivation pour maintenir le graphique

Quelqu'un DOIT mettre du temps pour entretenir la chose. Trop souvent, quelqu'un passe des jours à créer un diagramme de Gantt détaillé, puis le néglige. Peut-être qu'il le sortira un mois plus tard, rira nerveusement et le jettera, pour ne plus jamais en parler.

Une fois que vous avez les tâches et les meilleures estimations, vous les mettez sur le graphique. Et lorsque la première tâche est terminée, vous devez la marquer sur le graphique, puis faire bouger toutes les autres tâches pour compenser le fait que votre estimation était erronée. Et deux jours plus tard, vous recommencez. Et puis encore deux jours plus tard. Et bien sûr, quand il s'avère que vous avez oublié quelque chose ou qu'un défaut apparaît, vous devez mettre les nouvelles tâches sur le graphique.

Cela peut sembler un important engagement de temps continu, et vous avez raison. D'où vient cette motivation?

Quelqu'un se soucie réellement des résultats

Les fois où j'ai utilisé avec succès un diagramme de Gantt, il y avait des réunions hebdomadaires de gestion de projet. Le directeur faisait le tour de la salle en demandant à chaque chef d'équipe d'indiquer quand son projet serait livré. Si un projet était en retard, les ressources seraient réaffectées. Pour les deux premières réunions, je balbutierais que je ne savais pas vraiment quand il serait livré, et je proposerais un vague "dans trois mois". L'embarras de cela m'a fait changer de stratégie, et je suis bien sûr d'avoir un diagramme de Gantt à jour et précis avant chaque réunion.

Comme effet secondaire, cela a rendu mon projet mieux organisé et plus efficace, et les membres de mon équipe plus motivés.

Aucune invention ne mérite plus de crédit pour avoir rendu la planification de projets aussi impopulaire qu’aujourd’hui que Tracking Gantts. Le suivi des Gantts ne doit pas seulement être considéré comme nuisible - il doit être considéré comme mauvais. Voici pourquoi.

Raison n ° 1: Leur motivation

Tracking Gantts vous permet de voir, pour chaque étape de votre plan, combien de temps vous pensez que cela va prendre et combien de temps cela prend réellement. Vous apprenez, chaque jour et lors d'une réunion de mise en état, que la phase X devait commencer en mars, mais elle ne commencera clairement qu'en mai. Impressionnant. Vous saviez déjà, lors de la planification initiale, que le plan devra changer au fur et à mesure de l'avancement du projet. De nouvelles informations apparaissent. Les gens et les ressources sont imprévisibles, etc. Alors pourquoi est-il important de se rappeler constamment, à chaque réunion de mise en état, à quel point vos premières prédictions se portent mal dans la vie réelle?

Raison n ° 2: ils vous obligent à vous en tenir au plan d'origine

L'idée même de suivre le diagramme de Gantt d'un projet signifie qu'au lieu de se concentrer sur l'adaptation constante de votre plan de travail en fonction de nouvelles informations, vous choisissez de vous en tenir à un plan obsolète, simplement parce qu'il vous permet de pointer du doigt et de mettre en évidence les erreurs de prédiction qui étaient les résultat inévitable de l'énorme incertitude qu'impliquait la première phase de planification du projet. Après tout, vous ne pouvez pas suivre le Gantt si vous autorisez le plan à changer radicalement, non? Il doit avoir la même forme générale et être composé des mêmes étapes, sinon il n'y a rien à suivre ... Boneheaded s'en tenir aux plans est la principale raison pour laquelle "Waterfall" est en fait considéré comme un terme péjoratif de nos jours. La planification à l'avance est confondue avec le respect du plan d'origine.

Raison n ° 3: ils ne vous apprennent rien

Ce n'est pas comme si le retard dans ce projet allait réellement changer la façon dont vous planifiez le prochain projet, à moins que les projets que vous planifiez soient prévisibles et répétitifs. Après tout, c'est pour cela que Gantts était initialement utilisé - la planification du travail dans les lignes de production en usine, où les tâches sont très bien définies et leur durée est extrêmement prévisible.

La valeur ajoutée par le suivi à un diagramme de Gantt de développement logiciel est nulle. Sans doute encore moins de zéro. Non seulement les estimations passées ne sont pas pertinentes pour les nouveaux projets, mais l'illusion que vous pouvez réellement améliorer votre capacité d'estimation au fil du temps par rétrospection est dangereuse. Bien sûr, un étudiant CS pourrait ne pas vraiment savoir que l'intégration prend beaucoup de temps dans la vie réelle. Mais quiconque a été impliqué dans plus de deux projets au cours de sa vie est déjà bien au courant des suspects habituels pour les projets retardés. La vraie raison pour laquelle les projets sont retardés n'est pas un facteur d'erreur mathématique qui doit être appliqué aux estimations en général - c'est l'incertitude inhérente qui vient avec faire quelque chose pour la première fois et ne pas savoir exactement comment cela va se dérouler.

Il existe en fait des systèmes de gestion de projet qui tentent d'attaquer le problème sous cet angle erroné. Ils mesurent vos prévisions par rapport aux performances réelles et tentent de corriger votre estimation globale à l'aide d'une analyse statistique. Comme si «Danny sous-estimait toujours tout de 14,3%» est toujours le cas. Danny n'est pas stupide, et supposer que l'erreur de ses prédictions est prévisible est en effet idiot. Il confond le "remède" primitif - ajoutant des facteurs à votre estimation - avec la cause du problème. Votre estimation n'est pas inexacte car elle n'a pas été multipliée par le facteur «correct». Votre plan est tout simplement incomplet; et chaque plan est incomplet à sa manière.

Raison n ° 4: Ils concentrent votre attention sur les mauvaises choses

Au lieu de vous concentrer sur ce qui doit être fait pour livrer à temps, vous vous concentrez maintenant sur la justification de vos prévisions inexactes. Au lieu de vous concentrer sur la planification plus en détail et d'adapter votre plan à de nouvelles informations, vous ressuscitez un plan obsolète. Les projets sont rarement retardés car les parties du plan de travail ont été incorrectement estimées. Ils sont retardés car une merde de choses a simplement été laissée en dehors du plan d'origine. Le suivi de Gantts aggrave encore la situation, car quelle sorte de motivation avez-vous pour insérer plus de détails dans votre plan si tout cela finit par être mis en évidence comme une mauvaise estimation à chaque réunion de statut? Ils vous font vous en tenir à de gros morceaux de travail traçables dans votre diagramme de Gantt. Au lieu de vous laisser vous concentrer sur l'adaptation et sur la bonne voie,

Il y a aussi le problème de ne pas avoir suffisamment d'outils pour gérer des plans suffisamment élaborés. Vous avez une bien meilleure chance de construire un bon plan initial (et une estimation) si vos outils vous permettent d'exposer toutes les étapes fréquemment négligées en cours de route. Les Gantts traditionnels sont des bêtes à basse résolution qui sont vues à juste titre par les développeurs comme des caricatures de la réalité de la gestion de projet. Ce dont nous avons besoin, c'est d'un outil qui facilite l'ajout d'autant d'informations que possible au plan de travail le plus tôt possible, puis facilite l'adaptation de votre plan, car le brouillard d'incertitude s'estompe lentement au-dessus de votre projet. La dernière chose dont vous avez besoin est des rappels incessants à basse résolution de vos prévisions passées inexactes. Les Gantts de suivi sont bons pour pointer du doigt et couvrir les culs, pas pour faire avancer les choses.

Le logiciel de diagramme de Gantt permet d'analyser des interdépendances complexes et de prévoir les effets des dépassements et des retards.

Cependant, pour la plupart des projets logiciels, il y a peu d'interdépendances et d'entrées externes, donc la clé de la prédiction est de savoir quel est le bon multiplicateur à utiliser lorsque l'équipe du logiciel dit que cela prendra 3 semaines.

Comme d'autres l'ont dit, un diagramme de Gantt (communément appelé officieusement un plan de projet) est un moyen de cartographier les tâches et les interdépendances entre ces tâches, l'objectif étant d'établir le temps total minimum écoulé pour un projet.

Du point de vue de la gestion, le résultat clé est l'identification du chemin critique, c'est-à-dire la liste des tâches qui, si elles sont retardées, le projet est retardé.

Un exemple très simple - disons que deux programmeurs travaillent sur un projet avec trois tâches (module de code A prenant un programmeur 10 jours, module de code B prenant un programmeur 5 jours, puis intégrant a et b prenant les deux programmeurs 2 jours). Les deux premières tâches (modules de codage A et B) seront travaillées en parallèle et l'objectif est de compléter les trois tâches et donc de tout projeter en 12 jours.

Dans ce cas, le chemin critique est le codage du module A puis les tests d'intégration. Le codage du module B peut en fait commencer 5 jours en retard (ou être dépassé de cinq jours) sans impact car même s'il s'est terminé à temps, le module de codage A va prendre beaucoup plus de temps. En revanche, si le module de codage A ou les tests d'intégration glissent à tout moment, le projet entier glissera.

Connaître ce genre de choses vous aide à comprendre comment déployer des ressources et si un retard dans une tâche particulière est susceptible d'avoir un impact sur l'ensemble du projet.

Sont-ils utiles? Évidemment oui, mais avec une mise en garde importante: tant que les informations qui y sont contenues sont bonnes - c'est-à-dire:

• la liste des tâches est complète
• les estimations sont exactes
• les dépendances entre les tâches sont complètes et
• les ressources représentatives de l'équipe et correctement mappées à la tâche.

Et à partir de là, l'équipe doit travailler sur le graphique et exécuter les tâches dans le bon ordre (ne pas faire quelque chose de plus intéressant que la tâche assignée, car cela retardera potentiellement quelque chose / quelqu'un d'autre sur la ligne).

Si vous faites tout cela, alors oui, alors cela peut vraiment vous aider, mais le travail doit être mis en avant pour garantir qu'il est précis et réaliste.

J'ADORE les diagrammes de Gantt et s'il y avait de meilleurs choix de logiciels pour le Mac pour les créer, je les utiliserais tout le temps.

Voir les dépendances est énorme. "Si nous n'obtenons pas la partie de remplissage des données du projet, la construction des améliorations de Whatsit ne peut pas commencer."

Si votre projet est un projet de développement logiciel, un diagramme de Gantt ne sera pas très utile et sera surtout une perte de temps. Ils ne sont pas conçus pour la nature fluide du développement logiciel, c'est-à-dire.

• Les tâches ne dépendent généralement pas de l'ordre. Ils peuvent être effectués dans n'importe quel ordre.
• L'ordre des tâches peut modifier le temps requis pour terminer la tâche.
• Les tâches peuvent engendrer d'autres tâches, par exemple des bogues

Le résultat est que vous passerez plus de temps à mettre à jour le plan qu'à faire le travail.

Gérez simplement vos besoins et tout le reste se prendra en charge.

YMMV