Question

J'ai travaillé sur quelques projets gérés à l'aide d'un diagramme de Gantt. Certaines de ces tâches comportent un grand nombre de tâches et le chef de projet passe tout son temps à lutter avec MS Project au lieu de faire les bons choix.

Je peux comprendre l’intérêt d’un certain nombre d’équipes distinctes qui s’efforcent de gérer un projet (juridique, informatique, marketing, par exemple).

Quelqu'un at-il déjà participé à un projet de développement logiciel utilisant un diagramme de Gantt avec succès?

Était-ce utile?

La solution

La microgestion de projets de développement de logiciels utilisant MS Project est l’une des choses les plus stupides que l’on puisse faire, en particulier dans un environnement agile. Trop de choses qui prennent 1 / 10e ou 10 fois le temps que vous avez prédit, trop de choses qui dépassent les attentes et trop de réunions de planification de projets qui prennent du temps de travail utile.

De plus, être un esclave du diagramme de Gantt est une chose très courante, en particulier pour les gestionnaires de projets issus de différentes disciplines.

Cependant, ils sont utiles pour garantir que les actions (obtenir un compte avec la configuration XYZ, obtenir la conformité pour vérifier le libellé du site Web, etc.) sont terminées dans les délais impartis. Les délais finaux pour les tâches de programmation sont également corrects.

À mon avis, je suis certain que certaines personnes ont obtenu de bons résultats grâce à la microgestion des programmes.

Autres conseils

Nous utilisons toujours des diagrammes de Gannt dans la planification du projet. Ils sont toujours utiles. Après tout, tout est fait. Gannt chart est l’un des meilleurs outils pour visualiser votre projet.

C’est cependant un outil. Si l'outil est utilisé correctement, il est efficace. Si ce n’est pas le cas, cela pourrait être contre-efficace.

Vous devez savoir planifier votre projet correctement. Vous devez comprendre ce qui doit être inclus dans la liste des tâches et comment. Par exemple, pour un projet informatique, il est presque toujours inutile de descendre au niveau des assignations individuelles (créer une table pour le stockage en utilisant des données ). Conservez-le au niveau de l'histoire ( autorisez les utilisateurs à se connecter ), affectez-le à toute l'équipe et la planification deviendra beaucoup plus simple.

Plus tard, vous pourrez toujours descendre au niveau des tâches individuelles et créer un plan de projet distinct pour gérer les affectations d'une tâche distincte.

Oui, je l’ai vu réussir. Dans les cas où cela a réussi, ils ont utilisé une approche hiérarchique.

Plutôt que d’avoir un seul et même grand diagramme de Gannt comportant des centaines de tâches, il existait un diagramme principal pour l’ensemble du projet, avec des objectifs de niveau supérieur. Ensuite, il y avait des tableaux séparés pour la réalisation des sous-objectifs. Bien que cela limite la flexibilité d'une manière (vous ne pouvez pas équilibrer automatiquement les ressources entre les équipes de sous-objectifs), cela semble mieux correspondre à la façon dont les humains fonctionnent bien: dans les petites ou moyennes équipes.

Je ne suis pas un chef de projet professionnel, mais j'exécute des projets de développement pour des projets complexes. outils d'analyse de programme.

J'ai dessiné des diagrammes de Gantt de la taille des pages à la fin des années 70. Ils n'ont jamais eu assez de détails, alors je l'ai abandonné. Les diagrammes de Gantt avec 5 tâches sont inutiles.

À partir des années 90, j'ai utilisé MS. projet sur quelque 10 projets réels de 6 à 12 mois avec tâches d'environ 1 semaine, et entre 50 et 250 tâches organisées dans les hiérarchies liées aux éléments d'architecture logicielle, avec des équipes de 5-10 personnes. Ces plans sont imprimés sous forme de grille de 3 pages sur 5. et nous avions tendance à coller cela à un mur où il pourrait être vu.

Ce sont merveilleux pour la planification, parce que ils vous obligent à détailler les principales activités d'un projet, écrivez les descriptions, la séquence et la hiérarchisation. L’équipe peut voir les tâches, et voir quels sont les leurs, et vous pouvez le revoir avec l'équipe membres afin que chacun puisse donner un retour utile sur les durées et la commande de tâches.

Ils n’étaient PAS utiles pour le suivi des progrès du projet. Sun Tzu nous dit qu'aucun plan ne survit intact sur le champ de bataille, et Gantt les graphiques ne font pas exception. C'est vrai qu'avec du soin, on pourrait révisez soigneusement le plan toutes les quelques semaines et notez les progrès réalisés. Un "vrai chef de projet" aurait pu le faire. Nous avons fait assez attention de sorte que les tâches du plan original ont tenu assez bien à travers environ la moitié du projet, et à ce moment-là les gens assez bien compris le problème et la re-planification supplémentaire s'est produite mais de manière informelle plutôt que avec le projet MS.

J’ai également utilisé MS Project pour planifier de nombreuses tâches similaires temps et objectifs d'estimation. Cela a l'effet malheureux de produire des estimations réalistes avec la plupart des coûts visibles. C'est incroyable de voir à quel point les estimations réalistes détruisent les propositions de projets. L’industrie semble vouloir de mauvaises sous-estimations pour démarrer des projets; ce n'est pas étonnant que tant de temps et de budget soient dépassés.

J'ai une relation d'amour-haine avec le projet MS lui-même. Il faut des descriptions de tâches, la priorité des tâches et les affectations de ressources. Mais je ne peux pas dire: "Je préfère cette tâche se terminer en premier sur cette tâche". ce qui demanderait comme une préséance de tâche facultative, et je ne peux pas affecter une ressource en partie à une tâche et en partie à une autre et obtenir un calendrier raisonnable.

Mais pour une estimation de projet complexe, je ne vois pas comment vous pouvez vivre sans cela. Les personnes agiles vous diront que vous ne pouvez pas planifier; Je ne sais pas qui ils ont comme clients. Je n'ai jamais trouvé de client qui soit disposé à me laisser travailler sans plan ni budget en dollars / temps qu'il me retiendrait.

Un graphique GANNT est-il plus petit qu’une seule page? Cette petite information pourrait facilement s'asseoir sur un tableau blanc ou postit ou tout ce que vous avez toujours en vue. Il n'y a pas vraiment de raison pour que vous commenciez à vous battre avec un outil GANNT quand vous pouvez spécifier les informations nécessaires en une minute avec un crayon sur le papier que vous avez.

J'ai travaillé sur un projet dans lequel un fichier Diagramme de Gantt / MS Project a été utilisé pour gérer le projet avec succès. Les informations sur le projet ont été gérées par un responsable non-développeur qui a rencontré l'équipe individuellement pour obtenir des mises à jour de statut. Ce système semblait fonctionner assez bien et le diagramme de Gantt donnait un aperçu rapide du statut de toute l'équipe. Et en discutant avec un de mes amis qui travaille dans une entreprise qui utilise cette approche, cela semble très bien fonctionner pour leurs équipes.

Les autres projets sur lesquels le responsable du développement est censé maintenir le graphique, sur lesquels j'ai travaillé, n'ont pas abouti. Le responsable passe généralement plus de temps à essayer de lutter avec MS Project. Et si la culture est axée sur la pénalisation des retards de planification et non sur la résolution des problèmes, le diagramme de Gantt peut facilement être manipulé pour afficher un projet dans les délais impartis jusqu'à la date de livraison. Dans ces cas, le diagramme de Gantt devient un travail supplémentaire qui n’apporte aucune valeur au projet.

Je pense que l’essentiel est d’avoir une personne extérieure à l’équipe de développement qui mette à jour le fichier MS Project. Et le diagramme de Gantt doit être considéré comme un outil à utiliser pour la communication sur l’état du projet, les éventuels problèmes de retards de planification et la planification des besoins en ressources. Une fois ces éléments en place, le diagramme de Gantt peut être utile.

J'ai trouvé les diagrammes de Gantt utiles pour planifier le calendrier d'un projet et permettre X jours de vacances, de glissements, etc. Ils permettent également de s'assurer que toutes les ressources sont allouées à 100% tout au long du projet.

Lorsque je travaillais réellement sur le projet, en tant que développeur et chef d'équipe, je trouvais préférable de travailler dans de courtes itérations avec des tâches claires définies pour toute l'équipe. Au fur et à mesure que les choses glissent, changent ou que des personnes sont ajoutées / supprimées du projet, il est agréable de pouvoir ajuster le diagramme de Gantt et de voir le résultat des modifications apportées au projet.

J'ai travaillé sur quelques projets pour lesquels nous avons utilisé des diagrammes de GANTT. Oui, ils étaient utiles, et oui, ils étaient plus grands qu'une page. Ce que nous avons fait était de couper et coller (littéralement, avec des ciseaux et de la colle) la carte dans une seule grande carte et de la coller au mur.

McConnell, dans son excellent Guide de survie du projet logiciel , recommande de proposer à tous les membres d’une équipe l’objet d’une information approximative pour savoir s’ils sont sur la bonne voie, et c’est ce que nous recherchions. / p>

Je suis tout à fait d'accord avec les commentaires sur les diagrammes de GANTT qui ne conviennent pas au développement agile - pour lesquels nous ne comprenons pas clairement les détails de la mise en œuvre dès le départ.

D'autre part, je ne peux m'empêcher de me rappeler avec tendresse d'un week-end pénible que j'ai passé à élaborer un tableau de GANTT pour un projet que je gérais, où la technologie et les exigences étaient très bien comprises et où le calendrier était critique.

Nous avons eu le mur d’entrée de notre section de compartiment couvert en partie par ce diagramme de GANTT (5 pages A4 de large), et il était extrêmement utile de s’assurer que nous travaillions sur le chemin critique: faire ce qui devait être fait. fait maintenant - et m'a également permis de faire rapport au comité de projet avec des rapports détaillés sur la progression du projet par rapport au calendrier.

L’utilité des diagrammes de GANTT dépend certainement du contexte, mais je dirais que si vous connaissez vos besoins, et en particulier si vous attachez une grande importance à votre emploi du temps, ils peuvent être incroyablement utiles.

Je ne suis pas un grand fan des diagrammes de Gantt, en particulier ceux créés dans MS Project - il faut donc beaucoup de place pour les pages pour si peu d'informations et au plus (comme la plupart des graphiques), les informations sont déformées ou masquées. Si un diagramme de Gantt aide l’équipe à déterminer ce qui est requis, à qui est assignée quelle tâche, quelles tâches glissent, quels sont les risques - alors c’est utile - cependant - la plupart des diagrammes de Gantt sont développés au début du projet et ensuite jamais vus ou utilisé à nouveau. Donc, revenons à la question initiale - la taille est-elle importante ???? citer un livre récent - si c'est stupide et fonctionne, alors ce n'est pas stupide

Un diagramme de Gantt n’est utile que s’il contient suffisamment de détails pour qu'un chef de projet puisse voir le statut du projet et que les dépendances et les ressources soient correctement comptabilisées.

Vous pouvez toujours coller plusieurs feuilles avec du ruban adhésif.

La discipline consistant à analyser le projet - le décomposer en phases, étapes, produits livrables, déterminer les besoins en ressources est probablement encore plus importante que l’impression d’un joli graphique.

Beaucoup de mes projets de développement non négligeables ont tiré parti de l'utilisation judicieuse des outils de planification de projet.

  

Oui, je l’ai vu réussir. Dans les cas où cela a réussi, ils ont utilisé une approche hiérarchique.

     

...

Absolument. Je suggérerais également que cela fonctionne mieux lorsque la hiérarchie correspond également à la hiérarchie de l'équipe, par exemple, le gestionnaire de projet crée le graphique de niveau supérieur, les chefs d'équipe gèrent les graphiques de niveau intermédiaire, les développeurs gérant peut-être leurs propres diagrammes de Gantt, mais plus probablement avec quelque chose comme JIRA. , comme cela fournit un point de focalisation unique du point de vue du développeur, et qu’il est généralement plus facile à manipuler (c’est-à-dire qu’il ne ressemble pas à un plan, il ne les effraie donc pas;))

La meilleure utilisation des diagrammes de Gantt dans MSProject est la planification de la capacité aux stades embryonnaires d’un projet. Vous pouvez effectuer une planification large et des hypothèses, déplacer des éléments, déplacer des personnes, ajouter plusieurs étapes, etc. Cela peut vous donner l'assurance que vous développez un plan raisonnable.

Mais l’utiliser ensuite pour suivre au jour le jour la myriade de petites tâches que les gens doivent réellement faire est, comme il a été mentionné, de poser des problèmes. Ce que j’avais l'habitude d'utiliser avec grand succès pour gérer les échelles de temps à ce niveau micro, c'est le document EBS de Fogbugz . Vous devez y travailler, mais cela aide vraiment à garder le contrôle des choses.

En résumé, Gantt est idéal pour développer un plan logiciel, mais pas pour sa mise à jour détaillée au jour le jour.

En ce qui concerne la question de la page, la plupart des plans que j’ai conçus et qui ont fonctionné le mieux (c’est-à-dire qui ont communiqué le plan aux personnes avec un niveau de détail compréhensible) peuvent être adaptés à une impression au format A3. Parfois, quelques pages A3. Mais, selon mon expérience, A4 est tout simplement trop petit dans la plupart des cas.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top