Hello, petite question dans la même idée que le sujet du plan de charge qui a donné lieu a une vidéo, est ce que le diagramme de Gantt est adapté et surtout utile en agile ?
Vidéo sur le plan de charge en agile : https://youtu.be/bc5YMNA77jw?si=LIu454I1F_AyoClC
À partir du moment où un outil rentre en opposition avec « L’adaptation au changement plus que le suivi d’un plan », on est par définition opposition avec la base de l’agilité…
À voir si certaines personnes ont éventuellement réussi à l’adapter dans un contexte hybride de sorte à le mettre à jour régulièrement… Pas convaincu du tout personnellement, mais je laisse les autres membres de la communauté intervenir, peut-être que certains ont une expérience à nous partager à ce sujet.
Par contre, un cas à grande échelle que j’ai en tête qui a été réalisé avec un outils de suivi beaucoup plus light (une feuille A4 mise à jour mensuellement), c’est ce qu’à réaliser Gary Gruver pour le firmware laserjet de HP de 2008 à 2011. Il a écrit un livre à ce sujet d’ailleurs.
Un example de ce que ça donne:
On a juste une liste d’objectifs de « haut niveau », puis on délègue la manière de les résoudre aux équipes.
Tout ça pour démontrer qu’on a pas besoin d’un diagramme Gantt, même sur un projet de grande ampleur (400 développeurs sur plusieurs continents, avec un code source de plusieurs millions de lignes dans le cas que j’ai mentionné).
Un diagramme de Gantt, c’est un outil. Comme tous les outils, on peut s’en servir de plein de manières différentes, pour des bonnes et des mauvaises raisons. Celui-là n’échappe pas à la règle. Donc fondamentalement « ça dépend ».
Une équipe Scrum peut par exemple faire un Gantt des tâches du sprint s’il y a beaucoup de corps de métier complémentaires à synchroniser dans l’équipes et qu’on veut bien visualiser pour se mettre d’accord en planning(*). Un PO peut aussi faire un Gantt prévisionnel de sa roadmap produit, surtout s’il a des précédences par rapport à des produits tierces en dépendance. On peut aussi s’en servir comme une alterative aux formats de workflow complexes (type BPMN) pour visualiser un processus métier ou utilisateur.
Mais si l’idée c’est de faire un « Gantt du projet », avec une granularité au niveau tâche et 18 mois de planning, c’est que la personne est complétement passé à côté de l’agilité.
(*) Et bien sûr on ne se gênera pas pour chercher à simplifier ça à la prochaine rétrospective 
Si les méthodes agiles et le diagramme de Gantt ne conviennent pas aux mêmes contextes. Mais le contexte d’une équipe est souvent à plusieurs facettes. Par exemple, même si une équipe donnée requiert majoritairement l’agilité, certains aspects de leur activité peuvent s’apprêter mieux à un diagramme de Gantt.
Le cadre Cynefin peut aider à mieux discerner quand utiliser telle ou telle méthode. Au lieu de dire seulement « ça dépend », Cynefin aide à répondre à la question « de quoi ça dépend ? » Les méthodes agiles conviennent aux situations peu complexes, où on sait à peu près la direction dans laquelle on veut aller mais il y a de l’incertitude sur certains détails. Le diagramme de Gantt, comme le cycle en V, convient aux situations claires, où on sait ce qu’il faut faire.
Je suis plutôt en phase avec l’assertion « Les méthodes agiles conviennent aux situations peu complexes ».
Dans les projets avec beaucoup de dépendances, le cycle en V reste un choix raisonnable. Et un diagramme de Gantt est bon outil pour modéliser ces dépendances.
Je suis curieux de savoir pourquoi le nombre de dépendances est un facteur favorisant le cycle en V. Tu saurais étayer sur le sujet ?
Tout d’abord, je n’ai pas dit que le nombre de dépendances favorisait le cycle en V.
Simplement que le cycle en V tant décrié n’est pas selon moi une abomination, que cela restait un choix raisonnable.
Je suis plutôt agnostique sur les méthodologies telles qu’on nous les vend. En vrai, je pense qu’on surestime leur importance dans le succès d’un projet. J’ai l’habitude de dire, un brin provocateur je le reconnais, que l’Humanité n’a pas attendu Scrum pour construire des Pyramides ou envoyer des hommes sur la Lune.
Cela étant posé, pour développer un peu plus ma pensée, j’ai l’impression que la méthode Scrum fonctionne de façon optimale lorsqu’il est aisé de découper le projet en sprints. Cela suppose que les dépendances entre les acteurs, les composants et les tâches ne soient pas trop fortes.
De ce que j’observe, la méthode Scrum est particulièrement puissante sur les sujets de développement des features ou en phase de mise au point d’un MVP, par exemple, là où justement une équipe, souvent réduite, peut agir sans trop se soucier des autres.
Par contre, sur les sujets d’intégration d’ampleur, mise en place de progiciels de type ERP par exemple, qui mobilise toute l’entreprise, j’ai rarement observé l’utilisation heureuse de méthodes Agile, et quand bien même il y a une volonté de mettre en place de telles méthodes Agile en début de projet, il y a très souvent une tendance naturelle à revenir à une méthode plus classique de type waterfall. Est-ce parce que les équipes projet ne maîtrisaient pas suffisamment l’Agile ? Vous pourriez arguer que oui, mais j’ai quand même le sentiment qu’il y a quelque chose de plus profond.
Une des pistes pour expliquer ce phénomène est de se dire qu’un projet est bien plus qu’une liste de tâches et une méthode pour les réaliser. C’est aussi une multitude de décisions à prendre. Et que selon la nature de ces décisions, les méthodes Agile ne sont pas les plus adaptées.
Il y a des décisions réversibles, où revenir en arrière a un coût faible ou acceptable. Il s’agit de la majorité des décisions. Mais dans un projet d’intégration d’ampleur, il y a aussi des décisions irréversibles, qui peuvent fortement engager la société sur le plan commercial ou stratégique, et qui souvent coûtent très cher à implémenter, et encore plus cher à défaire, quand cela est possible ce qui n’est pas toujours le cas.
Dans de tels projets où on observe ce genre de décisions, souvent à cause des fortes interdépendances (intrications même) qui rendent ces décisions irréversibles, je pense que les méthodes Agile perdent beaucoup de leur pertinence et qu’une phase de cadrage, d’étude amont, de spécifications (peu importe la terminologie) avec des jalons et une grande coordination entre les acteurs est incontournable, à mes yeux.
C’est d’ailleurs un peu le sens de ma question dans un autre topic que j’avais ouvert il n’y pas très longtemps. J’espère en tout cas avoir été plus clair.
Au contraire, c’est quand c’est pas facile que c’est utile de faire du Scrum.
Parce que ça oblige à expérimenter sur des volumes dispensables plutôt que dispendieux.
Mais pour cela, il faut une forme d’humilité : partir du principe qu’on ne sait pas vraiment quel produit on va fabriquer et affiner son design au fur et à mesure, à partir de l’usage réel et non de l’expérience du concepteur. Et accepter de se tromper régulièrement, de quand même valoriser le travail exploratoire, et de renoncer aux fonctions décevantes. Dans mon expérience, tous les pires projets agiles qui se sont soldés par un échec cuisant ont tous eu pour point commun un décideur qui avait trop de certitudes.
J’ai l’exemple d’un client qui voulait développer un outil de gestion de plans de charge dans une suite logicielle de gestion de projet. Malgré des inquiétudes sur plusieurs aspects du projet, les parties en présence étaient trop contentes de se lancer dans un travail d’envergure qui apportait beaucoup de choses intéressantes dans une vision managériale traditionnelle : visibilité à long terme de l’activité, marge substantielle, … Sans trop de surprise, ça n’a « pas marché ». Depuis 7 ans que les devs sont finis, le produit est toujours installé sur l’environement de production mais personne ne s’en sert, les chefs de projet font toujours leurs plan de charge sur Excel. Pas assez bien pour fonctionner, trop cher pour une refonte, le projet est « mort-né ». Au lieu de cela, on aurait pu faire un premier jet en quelques semaines, se rendre compte des défauts et réfléchir à réorienter le produit dans une direction viable. Ou l’abandonner après x k€ et non x M€.
Cette démarche de cadrage en amont, c’est exactement ce que propose Scrum et la démarche agile. C’est juste qu’au lieu de faire le cadrage puis ensuite de repartir de zéro faire le vrai projet, on fait le cadrage et ensuite on capitalise sur le prototype pour le sujet suivant ad libitum.
Et non avec une date de fin à l’issue de laquelle le produit n’a plus qu’à se laisser mourir. Là encore, j’ai des exemples à la pelle, et des clients qui ont des piles d’applis (parfois des centaines) développées avec des technos à la pointe de l’époque que plus personne ne veut maintenir aujourd’hui. A force de projets waterfall, ils ont vécu à crédit et fabriqué des applis plus ou moins utiles en espérant les rentabiliser en n’y touchant plus pendant 10 ans. Aujourd’hui elles sont tellement obsoletes que les rapports d’autits font froid dans le dos et annoncent un terrible 0% de compliance du parc applicatif.
Et là, c’est la banqueroute technologique.
Gantt, permet de faire un plan de ce qu’on sait qu’on veut livrer et de combien de temps ça prendra à faire, tenu compte des imprévus prévisibles ou plutôt maitrisables
Un backlog, permet de faire un plan de ce qui est le probablement le mieux à livrer pour ajouter de la valeur à court terme.
En fait, il y a moyen de naviguer entre deux eaux.
Pourquoi mettre en place de l’agilité si on peut garantir le plan ?
Pourquoi mettre en place un plan si de toute façon, il ne peut être respecté ?
Fixons ce qui peut l’être, explorons le reste.
Ceux qui font de la recherche ( universitaire) ou ceux qui cherchent de l’or, ou du pétrole font-ils un gantt ?
Ceux qui construisent un bâtiment n’ont-ils qu’un backlog (boh aujourd’hui on va construire le toit, c’est plus important qu’une cave, on verra bien demain ?
Je pense que le pire en fait c’est plus de faire un choix entre les deux, pour y trouver son confort, tant pis si ca ne correspond pas au contexte.
==> Attention de ne pas faire du choix une religion
==> Et encore plus attention à ceux qui disent « Attention de ne pas faire du choix une religion », parce que souvent ils disent ca pour ceux qui ne choisissent pas la leur
Depuis le temps que je les tanne sur le sujet… x)
J’ai quelques bribes de script à proposer pour une telle vidéo
merci pour vos réponses, je suis de l’avis de ceux qui trouvent que ça n’a pas sa place dans un contexte agile.
jusque là, je ne suis jamais tombé sur un cas de contexte projet où l’agile ne fonctionne pas.
que ce soit un projet facile, complexe, tendu, avec grosse ou petite équipe, etc. à chaque fois, ça a marché.
j’espère même ne plus jamais avoir à vivre un projet en cycle en V dans une boite qui ne veut pas changer cela avec une transformation DevOps
L’agilité est elle un Contexte où une réponse, une posture envisageable face à un contexte (vuca)
@TheLimande C’est très honnête intellectuellement de ta part de ne pas avoir mentionné ça dès le départ pour éviter d’influencer les réponses, et laisser tout le monde participer à la discussion et s’exprimer librement. Bien joué.
Bonjour à tous,
Je suis tombe la dessus tout à l’heure et je vous le mets la.
Dontt hate the payer, hate the game.
Gantt ne vous veux aucun mal. Le modèle mental qu’il induit oui, mais c’est une histoire de dynamique et de contexte.
Je propose un truc : faites un Gantt, discutez en, et cramez le immédiatement après. Vous aurez eu le bénéfice de créer une vision à un instant T et une conversation, mais aucune attache avec les mensonges que vous avez pu vous dire.
c’est une réponse pour moi
vu qu’il y a plus de transparence, ça ne peut que marcher
oui j’aurais pu planter le décors du pourquoi je pose cette question mais ça aurait orienté mon avis, alors que là, je suis resté naif tout en ayant mon avis très argumenté
c’est aussi que ça a chauffé avec la PO qui me soutenait avoir besoin d’un Gantt pour prédire la date de fin plutôt que les rapports que je lui propose, automatiques, sans action humaine de chef de projet
j’ai fait ce choix car dans le sujet de la place de l’UX / Designer dans un projet Agile, je vous ai trop présenté le contexte ce qui peut orienter la discussion
