Transcription

• Speaker

  Focus Projet

• Tanguy El Mouahidine

  Bienvenue sur Focus Projet, le podcast du management de projet. Le management de projet, qu'est-ce que c'est ? Ça va être les différentes techniques et outils qui vont nous permettre de mener à bien nos projets. Planning, coût, risque, gestion d'équipe, changement, communication, définition du besoin. Au fil des épisodes, on va voir tout cela ensemble. Alors que tu sois le directeur de projet de la prochaine Gilea Factory, ou que tu te retrouves à t'occuper des projets de ton entreprise en plus de ton travail, abonne-toi. Ce podcast va simplifier la réussite de tes projets. Depuis des années, deux écoles s'affrontent sur la gestion de projets. Les défenseurs des méthodologies agiles, qui les opposent aux méthodologies plus traditionnelles et prédictives, qu'ils appellent Waterfall. La hype de l'agilité est un peu passée et la mode est maintenant à l'hybridation. Mais on retrouve toujours de grossières caricatures de certaines pratiques pour en promouvoir d'autres. Pour ma part, je considère que ces méthodes agiles ou prédictives correspondent à la manière dont on développe le projet et de ce fait, la gestion de projet en elle-même peut s'appliquer aux deux, même s'il y a des nuances. Pour discuter de cela, je reçois une nouvelle fois Renaud Chaunet. Bonjour Renaud.

• Renaud Choné

  Bonjour Tanguy.

• Tanguy El Mouahidine

  Tu peux commencer par te présenter peut-être pour commencer ?

• Renaud Choné

  Alors oui, très bien. Moi, écoute, je vais me présenter en étant un peu différent de toi, parce que moi, à la base, je suis un développeur logiciel, nouvelle technique. Bon, alors ça fait pas mal de temps que je suis dans le métier et c'est ce qui fait que je suis un ardent défenseur des méthodes agiles, de l'approche agile, parce que je sais quels problèmes ça résout et ça me parle vraiment. Mais je ne suis pas simplement développeur, c'est-à-dire que j'ai été aussi DSI dans une PME, directeur technique chez un éditeur. Et je comprends aussi tout à fait les besoins de management, que ce soit des besoins de gestion de projet, de portefeuille de projet, de gestion de ressources, toutes ces choses auxquelles finalement l'agilité ne répond pas du tout. Et actuellement, je suis le fondateur de Time Performance, c'est un éditeur de logiciels SaaS qui propose un outil simple pour faire de l'excellente gestion de projet tout en restant agile. Voilà, d'où l'intérêt de cette discussion qu'on a tous les deux.

• Tanguy El Mouahidine

  Du coup, on s'est déjà vu il y a à peu près un an, dans l'épisode 23, on a discuté de comment mettre en place progressivement la gestion de projet. Et la question de l'agilité est arrivée dans la discussion sans réellement être traitée. Donc, c'est ce qu'on va essayer de faire maintenant. Pour commencer, comment tu définirais l'agilité en rapport peut-être avec la gestion de projet de manière générale ?

• Renaud Choné

  Alors, pour l'agilité, de toute façon, la seule définition, elle vient du manifeste agile. C'est vraiment le point de référence où tout le monde se met d'accord. Et puis après, il y a plusieurs développements. Et chacun prend son chemin. Donc, qu'est-ce que c'est que finalement l'agilité dans Manifest Agile ? Qu'est-ce qu'on te dit ? On te dit, c'est la recherche de nouvelles méthodes ou de pratiques de développement logiciel. On ne parle pas de gestion de projet, là, au passage. Et puis, il faut insister sur le point nouvelles méthodes. On cherche quelque chose de différent. C'est ça qui est le plus important dans le Manifest Agile. c'est que grosso modo ce que l'on dit c'est qu'on veut pas faire comme les méthodes précédentes parce qu'on a trouvé que ça marchait pas. Et c'est pour ça que dans le manifeste, après dans la suite du manifeste, on parle des quatre valeurs qui sont en fait quatre préceptes. Et ces quatre préceptes ils sont formulés sous la forme de nous on préfère faire ça plutôt que cela. Et plutôt que cela, à chaque fois qu'il n'y a que cela, c'est ce qu'on faisait classiquement. Donc classiquement c'est quoi ? C'est des processus, des documents, des contrats. de la documentation. Voilà, ça, c'est ce qu'on demande, justement, dans des approches assez traditionnelles qui sont issues, fondées sur le principe du taylorisme. C'est-à-dire que si tu veux qu'un projet se déroule bien, tu es obligé, tu vas essayer de standardiser tout. Et donc, tu vas définir des process, des tâches. Pour chaque tâche, tu vas devenir qui est responsable, quels sont les inputs, quels sont les outputs. Et tout ça, l'agilité rejette cette partie-là en disant, justement, on veut tout le contraire. C'est là que l'agilité est différente. Parce que le fait de rechercher des méthodes pour développer mieux des logiciels, c'est le principe d'une méthode. C'est qu'on cherche à faire mieux, on essaie de trouver des solutions pour faire mieux. Mais là, vraiment l'apport de l'agilité, c'est de dire tout ce que vous nous aviez vendu avant, avec ces processus super formalisés, super rigides, avec des responsabilités, des inputs et des outputs, on n'en veut pas. Ça ne marche pas, on sait que dans le monde du logiciel, c'est improductif et on a beaucoup d'échecs. Et je vais te donner... un exemple justement de la différence des deux approches. C'est un cas classique, c'est la compréhension du besoin par les équipes techniques. Je pense que tu connais cette image humoristique, cette BD, où ça commence par un client qui veut une balançoire. Donc, tu as le client qui décrit ce qu'il voudrait, tu as le commercial, ce qu'il a vendu, tu as le designer, ce qu'il a conçu, tu as après la photo avec le développeur, ce qu'ils ont construit, et en fait, tu as la dernière photo où c'était le besoin réel du client. Et à chaque fois, tu as une image différente. Et cette problématique-là, où tu as ce problème de communication entre d'une part... des gens du métier et d'autre part des gens qui sont techniques, c'est quelque chose d'assez classique. Et donc, il y a deux façons de le résoudre. Qu'est-ce qu'on va te dire dans l'approche traditionnelle ? Dans l'approche traditionnelle, on va te dire, bon, alors on va écrire plein de documents, on va te faire une belle expression de besoin, puis après, on va détailler ça, on va traduire ça sous la forme de spécifications générales, puis de spécifications détaillées, et on va mettre le plus de détails possible pour qu'il y ait le moins de malentendus possible. Et puis, pour être sûr que tout le monde est d'accord, on va leur demander de signer le document. Voilà. Et donc, une fois qu'on a fait ça, il y a un an et demi qui s'est passé, mais ce n'est pas grave. On a déjà pris du repère là-dessus. Maintenant qu'on a fait ça, on se revoit dans deux ans et puis on regarde si vous avez fait ce que vous avez marqué dans le cahier d'échec, dans le document de spécification. Donc ça, c'est l'approche classique, où la solution au problème, c'est de dire, on va écrire plus de choses, on va être plus soigneux, plus dans le détail. Après, si tu prends l'approche, donc l'approche AG, il y a un problème de communication entre les métiers et la technique. Et bien, ce problème de communication, plutôt que de se voir tout au début puis à la fin, et bien en fait, on va travailler ensemble tout au long du projet. Et tout au long du projet, on va discuter et petit à petit, la communication va s'améliorer. C'est-à-dire qu'au début, on ne va pas se comprendre, mais petit à petit, à force de faire des réunions toutes les semaines, toutes les deux semaines ensemble, de voir la différence entre ce qu'on a produit et ce que vous nous aviez demandé, petit à petit, finalement... Les gens du métier comprennent un peu mieux peut-être les contraintes techniques et les techniques apprennent le métier. Et donc, tu vois, c'est une approche qui est assez différente et on essaie de résoudre les mêmes problèmes.

• Tanguy El Mouahidine

  Oui, oui. Après, j'allais dire, les deux ne sont pas forcément totalement incompatibles. D'ailleurs, peut-être, on peut écrire un peu et avoir cette approche de ne pas se revoir dans deux ans et continuer à discuter tout le long.

• Renaud Choné

  Oui, non, mais bien sûr, là, c'est caricatural. Voilà, le principe est celui-là. Et en même temps, ce n'est pas incompatible. Et surtout, chaque mode de fonctionnement peut s'appliquer dans un certain contexte ou pas. Par exemple, si tu es dans des métiers comme dans le bâtiment, il est hors de question de se dire « Attendez, je vais développer les parpetits bouts, je vais vous dire le nombre de pièces, mais j'ai changé toutes les deux semaines, je vais vous rajouter des pièces dans la maison. » Ce n'est pas ça. Ce n'est pas possible. Et donc, il faut voir que le monde du logiciel... a cette particularité que n'a pas d'autres domaines. On n'est pas dans le monde industriel. Dans le monde industriel, on est obligé de prévoir les choses en avance parce que changer, c'est très compliqué. Dans le monde du logiciel, on veut supprimer une pièce, on appuie sur une touche, la pièce est supprimée. Dans le bâtiment, on construisait une pièce, mais à côté, pas comme il faut. Ça coûte très cher de tout en déconstruire.

• Tanguy El Mouahidine

  Ça coûte plus cher de la casser que de la construire.

• Renaud Choné

  Donc, il n'y a pas les mêmes problématiques. Et donc, voilà. Donc, après, il faut adapter la méthode à la problématique et même dans l'informatique. Ce n'est pas du tout pareil de développer un logiciel ou par exemple d'installer le même logiciel chez un autre client. Quand on installe un logiciel chez un autre client, le mieux c'est au contraire l'approche prédictive parce qu'on l'a déjà fait dix fois, on connaît les problématiques, etc. Et ça va aller beaucoup plus vite si on a un processus à gérer. Par contre, si on crée un nouveau logiciel, on ne l'a jamais fait avant et il n'y a pas de recette miracle. Voilà. Et donc, quelqu'un qui est le chef de projet qui va arriver, attendez, moi j'ai le planning pour tout le projet, je vais vous dire comment ça va se dérouler. Ce n'est pas crédible, c'est tout simplement pas crédible. Et là, voilà, il n'y a pas de possible de le faire. Encore une fois, il n'y a pas de mauvaise méthode. Il n'y a que des mauvaises méthodes dans un mauvais contexte. Oui,

• Tanguy El Mouahidine

  tout à fait. Tu as peut-être déjà répondu, de manière générale, on parle de l'agilité et de gestion de projet pour cet épisode, de ton... point de vue des méthodes Agile, est-ce que Scrum, mais il y en a d'autres, ça peut être Safe ou autre, sont-elles des méthodes de gestion de projet en elles-mêmes ?

• Renaud Choné

  Je pense que j'ai déjà répondu, et en fait, j'ai oublié de répondre à la deuxième question, c'était qu'est-ce que la gestion de projet ? La gestion de projet, il y a souvent des malentendus, parce que les gens ont vu des façons de gérer des projets, et ont dit que c'est de la gestion de projet. Moi, la gestion de projet, je donne le terme le plus général, c'est... toute la partie qui concerne l'organisation du projet. C'est tout ce qui n'est pas tâche de réalisation. C'est comment on s'organise. Et donc, ce n'est pas un ensemble de techniques particulières. Après, on aura un suivant tel ou tel projet. Pour s'organiser, on va utiliser telle technique, mais ce n'est pas obligatoire d'utiliser telle technique. C'est juste quelque chose d'assez global. Maintenant, est-ce que les méthodes agiles sont de la gestion de projet ? Je pense qu'on sera tous d'accord si on connaît un peu la gestion de projet pour dire que les méthodes agiles portent sur le processus de développement seul, exclusivement. Il manque plein de choses pour faire de la gestion de projet. De toute façon, les méthodes agiles, c'est une petite ligne manifeste. A aucun moment, on parle de gestion de projet, pas de gestion. On cherche à développer des logiciels. Donc on n'est pas du tout dans la gestion de projet. D'ailleurs, la gestion de projet, ça ne s'applique pas qu'au développement logiciel. Ça s'applique à tous les projets. Et surtout, ça ne s'intéresse pas à la partie technique, qui intéresse le plus justement les développeurs qui cherchent à s'améliorer dans leur pratique. Faire du TDD, du test drive and development, ce n'est pas un sujet pour la partie gestion de projet. Néanmoins, il y a aussi une explication pourquoi il y a une confusion. souvent qui viennent de la part de développeurs qui ne connaissent pas la gestion de projet et qui voient la gestion de projet par le petit bout de la lormiette. Donc la confusion est entretenue parce que dans un projet de développement d'un logiciel, en fait le développement, le processus de développement du logiciel, ça va être 90%. 90% du temps on va faire du développement de logiciel. Et donc là c'est quelque chose qui va être très important. Et donc forcément la gestion de projet doit s'adapter. à la façon dont on construit le logiciel parce que ça représente 90% du travail. Donc c'est pour ça. Donc première chose, dans ce type de projet-là, c'est facile de confondre les deux parce qu'en fait, le processus de développement est très important, représente une grande part de l'activité. Et puis, il y a certaines méthodes agiles et notamment Scrum qui va aussi définir des rôles et des cérémonies ou des types de réunions, des points de validation, des choses comme ça. Et là, on touche un peu à l'organisation. Comme j'ai dit tout à l'heure, l'organisation, c'est de la gestion. Donc, la frontière entre la gestion de projet et les méthodes agiles devient alors encore un petit peu plus floue. Mais voilà, on se rapproche, mais pas complètement.

• Tanguy El Mouahidine

  Oui, oui. Tu as un peu dit les différences. Qu'est-ce qu'il faudrait rajouter d'une certaine manière à ces méthodes agiles pour gérer sereinement un projet dans son ensemble ?

• Renaud Choné

  C'est très simple. Dans les méthodes agiles, c'est pop, il y a un projet, il y a une équipe qui est là. Ah bon ? Il n'y a pas de phase d'avant-projet, de qualification de projet, de création d'un business case, d'un vacat d'affaires, quelles sont les justifications, la sélection des parties prenantes, comment les équipes sont recrutées, etc. Non, tout le monde est là, on commence des zéros, on commence, on travaille. Évidemment, pour être chef de projet, c'est justement qu'il y a la valeur d'un chef de projet, c'est de l'anticipation. Et donc, au début d'un projet, en fait, le succès d'un projet, ça se fait beaucoup au début.

• Tanguy El Mouahidine

  On est tout à fait d'accord là-dessus.

• Renaud Choné

  Il faut recruter les bonnes personnes, avoir les bons interlocuteurs, s'assurer qu'on ait le mandat, qu'on ait les moyens suffisants, etc. Donc tout ce travail-là de chefferie de projet n'est pas du tout vu dans la partie agile parce que c'est avant le processus de développement. Le processus de développement commencera une fois qu'on aura fait tout ça. Donc il y a beaucoup de travail à faire à ce niveau-là. Pareil pour la clôture d'un projet. Ça n'existe pas, il n'y a pas de phase de clôture de projet dans Scrum. Le projet continue ad vitam aeternam. Donc il n'y a pas de passage en TMA, de passage en run. Le run est censé se faire au fur et à mesure, mais même une passage en TMA, une fois qu'il y a un moment, le développement du logiciel va plus ou moins s'arrêter parce qu'on a développé assez de fonctionnalités. Donc ça aussi, c'est des choses qui ne sont pas du tout envisagées. Mais même tout au long du projet, les méthodes agiles s'intéressent à l'équipe et éventuellement à l'interface avec la personne qui gère la définition du besoin. mais il n'y a pas d'autre partie prenante. C'est-à-dire qu'on ne discute pas avec l'infra, par exemple, pour discuter, il va falloir provisionner tel serveur, machin, chose. Ce ne sont pas des choses qui sont dans l'approche agile, ce n'est pas la problématique principale. Ça, c'est des problématiques autres. Il y a toute la partie communication vers l'extérieur. Est-ce qu'on pense réellement amener le DSI, les managers, devant le tableau de post-it de l'équipe agile ? Sérieux, ou de les mettre en disant, regardez dans mon gira, regardez la liste des tickets qu'on a fait. Si vous avez des chefs de projet comme ça, qui gèrent des projets agiles et qui arrivent en réunion de copil, comité de pilotage et qui présentent des listes de tickets, vous savez que vous n'avez pas un chef de projet. Il y a un vrai problème de communication et donc il y a tout ce travail-là. Il va y avoir tous les travaux, toute la négociation qu'il peut y avoir et puis il y a aussi du politique. Parce qu'on se voit très bien dans un projet, il y a un contexte politique de l'entreprise. Il y a des tracteurs, il y a des promoteurs. Tout ce que sait faire un chef de projet. Et justement, dans l'apathie, dans l'agilité, le rôle du chef de projet, c'est un peu de protéger l'équipe de tout ce monde extérieur qui est un peu chaotique, pour qu'ils puissent se concentrer finalement sur ce qu'ils ont à faire sur leur métier et ne pas être impactés par ça.

• Tanguy El Mouahidine

  Tu l'as un peu dit en donnant cet exemple du chef de projet qui doit protéger l'équipe, mais comment faire cohabiter du coup cette agilité avec ces différentes méthodes ? la gestion de projet d'une manière générale comme on a pu le voir précédemment, notamment dans les épisodes qu'on a pu faire ensemble ?

• Renaud Choné

  Il n'y a vraiment aucun problème, sauf qu'on tombe dans un des trois écueils. Alors les trois écueils, c'est le chef de projet qui est trop dans la théorie et dans les techniques traditionnelles. C'est-à-dire qu'il a été formé, on lui a appris qu'un projet, ça se faisait comme ça. Il fallait faire son diagramme de gants, son père, son chemin critique, et ainsi de suite. Et il dit, voilà, moi, je vais gérer mon projet, je vais continuer à gérer mon projet avec les mêmes techniques. Comme je te l'ai dit au début, il y a vraiment des approches différentes. Et il ne faut pas que le chef de projet, il faut que le chef de projet soit assez malin pour s'adapter, en disant, quels sont les objectifs de la gestion de projet ? Les objectifs de la gestion de projet, c'est que le client soit content de ce qu'il obtient pour un prix raisonnable, dans un délai raisonnable. Il n'y a aucune contrainte sur la façon d'y arriver. La façon d'y arriver, après, ça vaut d'inventer la bonne façon d'y arriver. C'est juste ça. Donc, il ne faut pas que le chef de projet arrive avec une idée préconçue, impose des outils, impose des méthodes, et veut imposer un cycle de vie, la façon de développer le logiciel. Ce n'est pas au chef de projet d'expliquer comment développer un logiciel à une équipe agie. Ça, c'est le premier écœur. Donc, ne pas être trop dans la théorie. Le chef de projet va devoir s'adapter, prendre en compte. accepter, voir les intérêts, comprendre bien l'agilité en profondeur, ce que ça change, parce que les rôles changent aussi. Par exemple, quand on est agile, l'agilité, ce qu'elle promeut, c'est d'avoir des équipes qui sont plus autonomes, responsables. Par exemple, le chef de projet, ce n'est pas lui qui fait les estimations dans une approche agile.

• Tanguy El Mouahidine

  J'allais dire, si on veut que les estimations soient bonnes, en général, il vaut mieux que ce ne soit pas que le chef de projet qui fasse l'estimation tout seul dans son coin, quelle que soit la méthode pour le faire.

• Renaud Choné

  Voilà, mais tu vois, c'est un peu à l'opposé des approches traditionnelles. Traditionnellement, c'était le chef de projet qui faisait les estimations. Le deuxième piège, c'est plus la personnalité du chef de projet, c'est le côté micro-manager, c'est-à-dire le chef de projet qui pense que son équipe va pouvoir lui donner des tâches. je te gère à la tâche, je te donne des tâches, toi lundi tu vas te faire ça, etc., je vais te donner deux heures. C'est un peu le côté, c'est vraiment le côté petit chef de projet. C'est le côté petit chef du chef de projet. C'est le mec qui est hyper, qu'on appelle en anglais, « control freak » , c'est-à-dire le mec qui va mettre tout le monde sous contrôle. Ça aussi, ça va très mal se passer avec une équipe qui est habituée à l'agilité, parce que justement, elle est habituée à avoir une certaine autonomie, une certaine responsabilité. Donc ça, c'est vraiment les deux premiers écueils qui sont plus portés sur le chef de projet. projet en lui-même. Le troisième écueil, c'est le dogmatisme de certains agilistes. C'est un avis que tu connais bien. Avec un projet par principe de tout type de management. Et ça, tu vois ça dans les tags « no estimates » , « no project » . Donc le management, c'est mal. Donc le management, c'est mal. Donc il est hors de question de faire de la gestion de projet dans ces conditions-là. Donc des fois, il faut un peu… En fait, le problème, c'est l'humain. Le problème,

• Tanguy El Mouahidine

  c'est toujours lui-même.

• Renaud Choné

  Voilà. Mais grosso modo, si les gens ont de bonnes volontés, de bonne intelligence, que la culture de l'entreprise n'est pas toxique, il n'y a aucun problème pour faire de la qualité, agilité et gestion.

• Tanguy El Mouahidine

  Et du coup, quel conseil donnerais-tu aux équipes projet qui veulent intégrer l'agilité dans leur pratique ?

• Renaud Choné

  Alors, le premier conseil. D'abord, on s'assure... que c'est la bonne approche. C'est-à-dire en fonction du type de projet et du contexte du projet. Parce que l'agilité, ce n'est pas pour tous les projets.

• Tanguy El Mouahidine

  C'est un peu ce que tu disais au début, selon ce qu'on va avoir à faire, ça ne va pas forcément correspondre et être adapté.

• Renaud Choné

  Eh bien voilà, l'exemple classique, c'est qu'on travaille dans le public, il faut faire, il y a des marchés, il y a des marchés publics. C'est difficile de passer, s'il y a un côté contractuel comme ça qui impose le passage d'un marché, d'une contractualisation. sur la production de logiciels, là ça va être compliqué de mettre en place de l'agilité. Ça va être beaucoup plus compliqué. Donc est-ce que l'agilité c'est vraiment le meilleur moyen ? Est-ce qu'il ne faut pas plutôt repartir sur les solutions traditionnelles ? Donc ça c'est la première chose. D'abord l'agilité c'est pas la solution à tout. Assurez-vous que c'est la bonne solution. Après, il faut aussi s'assurer que le management a bien compris les tenants, les aboutissants de l'agilité. Il faut comprendre que c'est d'abord un changement organisationnel, l'agilité. On ne fonctionne plus de la même façon. Il n'y a plus des donneurs d'ordre et puis ceux qui exécutent. C'est on travaille ensemble. Et donc, voilà, si on travaille ensemble, c'est un peu différent. Et donc, il faut prendre bien ça en compte. Ce n'est pas du tout pareil. Et c'est important qu'il n'y ait pas de malentendus. L'équipe, elle se sent agile, mais finalement, le management…

• Tanguy El Mouahidine

  Pas du tout.

• Renaud Choné

  Si on a, par exemple, des donneurs d'ordre… un sponsor de projet qui est complètement absent pendant l'ensemble du projet, on n'arrive pas à discuter avec lui, ce n'est pas possible d'être agile. Il faut qu'il s'implique dans le projet. Dans l'agilité, le sponsor, le métier, s'implique dans le projet et est disponible pour l'équipe. S'il n'y a pas ça, ça ne marchera pas. C'est pour ça qu'après, on invente des systèmes de proxy,

• Tanguy El Mouahidine

  PO,

• Renaud Choné

  etc. C'est un mauvais signe. Peut-être qu'il ne fallait pas aller dans ce domaine-là. Et puis après, une fois, ben… C'est quoi l'agilité ? C'est simplement remettre en question les processus existants. Vous pouvez vous former, lire vos documentés, c'est une siluce du bon sens et du pragmatisme l'agilité. C'est simplement qu'on recherche des nouvelles façons de travailler, parce que les anciennes ne nous conviennent pas. Si elles vous conviennent, je ne change rien, c'est bon. Mais si elles ne vous conviennent pas, recherchez comment faire ça. C'est assez documenté, il y a pas mal de gens qui proposent différentes choses. je dirais un seul piège, méfiez-vous de certains coachs. Disons que tout le monde peut se proclamer coach, expert, agile, et finalement,

• Tanguy El Mouahidine

  ils vont dire des choses justes,

• Renaud Choné

  mais aussi ils auront beaucoup de biais personnels sur leur expérience, etc. Donc faites-vous confiance, forgez-vous votre propre expérience. L'agilité, il n'y a rien qui est gravé dans le marbre. On vous dit simplement... Recherchez, essayez de vous améliorer dans votre façon de travailler et on va prendre une approche qui est différente de la précédente. C'est tout ce que ça dit. Mais ça ne dit pas quelle approche il faut prendre. C'est pour ça qu'il y a 36 000 agilités. Tout le monde peut dire qu'on est agile.

• Tanguy El Mouahidine

  Du coup, d'une certaine manière, il faut arriver à adapter la méthode qu'on met en place à ses réels besoins et à son contexte.

• Renaud Choné

  Oui, ça peut être des choses très simples. Par exemple, il y a ce document, on nous demande de le faire, mais on se rend compte que ça ne sert à rien. Moi, j'ai déjà travaillé dans une équipe. où on demandait à tracer toutes les exigences dans le code. C'est-à-dire qu'à chaque fois que les gens écrivaient des lignes de code, ils étaient obligés de tracer des exigences, mais personnalisées, concrètement. Et ce n'est pas comme ça qu'on travaille aujourd'hui. À la limite, c'est intéressant de mettre de la traçabilité entre les tests et les exigences, en disant tel test vérifie telle exigence. Mais mettre ça dans le code, le code était alourdi par tous ces commentaires qui ne servaient à rien et qui n'étaient pas lus, en plus, qui ne sont pas utilisés, en concret. C'est ça aussi, c'est ça que dit l'agilité, c'est écrire des documents, pour écrire des documents ça n'a pas de sens. Si c'est utilisé c'est bien, un autre exemple c'est tout ce qui est document de conception. Moi j'ai été dans les années 2000 formateur UML, langage de modélisation de logiciels. Très bien, c'était bien parce que c'était important d'avoir des plans, mais aujourd'hui quand on veut naviguer dans le code, on appuie sur une touche, on navigue dans le code, on n'avait pas ces outils-là à l'époque. Donc il fallait mieux avoir un plan quelque part. plutôt que de faire des recherches textuelles dans le code pour espérer récupérer les choses. Donc on a beaucoup plus besoin d'un plan quand on se déplace difficilement. Quand on se déplace facilement, il vaut mieux aller voir dans le code, parce qu'en plus, tu es sûr que c'est à jour. Alors que le document, c'est beaucoup moins sûr. Encore une fois, il faut s'intéresser sur la finalité, pas sur la technique, l'outil. C'est comme ça qu'on peut s'améliorer.

• Tanguy El Mouahidine

  Et du coup, que conseilles-tu aux équipes agiles qui sentent qu'il leur manque quelque chose pour bien réussir leur projet d'une manière plus globale et pas juste leur développement ?

• Renaud Choné

  Tout à fait. Je pense que les symptômes sont assez clairs. C'est le projet qui part dans toutes les directions, ça change tout le temps. Le projet qui n'avance pas, les retards systématiques, les réunions qui semblent stériles, le client qui n'est pas content, il ne va pas payer pour rien à payer. on travaille au mode pompier, et puis là c'est clair, on a un problème de gestion de projet, c'est évident. Alors je dirais que pour les équipes, c'est compliqué pour elles d'agir tout de suite, donc la solution c'est soit d'aller sur un autre projet avec un meilleur chef de projet, soit de devenir soi-même chef de projet, et c'est pas compliqué, on peut se former, les projets informatiques et surtout les projets agiles sont très faciles à gérer, donc voilà, devenir chef de projet. de projet, renseignez-vous et ne dépendez plus de quelqu'un qui ne fait pas son travail. Quelque part, il y a quelqu'un qui n'a pas fait son travail.

• Tanguy El Mouahidine

  ou s'il n'y a personne qui fait ce travail-là, c'est peut-être qu'il manque...

• Renaud Choné

  Non, mais alors là, c'est le manager du dessus.

• Tanguy El Mouahidine

  Voilà, c'est peut-être le manager. Dans ce cas-là, c'est peut-être pas l'équipe en elle-même, c'est peut-être le manager qui...

• Renaud Choné

  Voilà, c'est l'organisation et donc le manager qui est responsable de cette organisation.

• Tanguy El Mouahidine

  Il y a peut-être des choses au niveau de l'organisation à changer pour justement prendre en compte ces problématiques-là.

• Renaud Choné

  C'est régulier. Quand moi, je travaille avec des entreprises, on me dit, on a un projet, mais on n'a pas de chef de projet. Là, c'est un problème d'organisation. Ce n'est pas l'équipe qui va changer ça. Je ne sais pas, c'est assez compliqué.

• Tanguy El Mouahidine

  Pour finir, j'en parlais un peu au début, l'hybridation dans tout ça, est-ce que tu vois ça d'une certaine manière comme une implémentation de plus de gestion de projet dans l'agilité ou comme une autre hype pour remplacer l'agilité ?

• Renaud Choné

  Alors, moi, je ne suis vraiment pas un fan de l'hybridation. C'est un peu comme être assis sur deux chaises. Donc, en théorie, c'est possible, il n'y a pas de problème. mais les motivations me semblent assez suspectes. C'est-à-dire, d'une part, c'est soit le management qui essaye de mettre une petite couche de vernis sur les processus actuels pour être à la mode, soit c'est une équipe de développement qui voudrait être agile, mais le contexte de l'entreprise ne s'y prête pas. Alors, on essaye de faire un mauvais comprendre. Il y a pas mal de méthodes, il n'y a pas de mauvaises méthodes. Prenez la bonne méthode et appliquez-la, et ça marchera très bien. Les méthodes agiles, il n'y a pas besoin de les hybrider, de toute façon, c'est tellement libre. que voilà, en fait vous créez votre propre méthode agile, il n'y a aucun problème. Et sur les méthodes classiques, si tu es dans un mode où, dans l'hybridisation que j'ai vue, on va quand même écrire des cahiers des charges bien fichés au début, on va bien tout vérifier au départ, etc.

• Tanguy El Mouahidine

  C'est peut-être plus valable dans d'autres domaines que l'informatique du coup, pour certaines phases.

• Renaud Choné

  Oui, mais pourquoi faire de l'agile ? Encore une fois, l'aglie n'est pas la solution. C'est la solution à un problème. Si vous n'avez pas le problème, prenez une autre solution. Je ne vois pas d'intérêt. Après, tu peux faire du développement itératif et incrémental. Il y a plein de gens qui ont inventé divers variantes. Mais bon, ce n'est pas le miracle. J'y crois pas.

• Tanguy El Mouahidine

  Très bien. Pour conclure, une question que j'aurais oublié de te poser sur ce sujet.

• Renaud Choné

  Par exemple, comment le logiciel Time Performance peut aider à faire de la bonne gestion de projet en restant agile ?

• Tanguy El Mouahidine

  C'est une bonne question.

• Renaud Choné

  Vous pouvez me contacter, on peut faire des débours, il n'y a pas de souci.

• Tanguy El Mouahidine

  Parce que du coup, on arrive à bien mettre les deux en place dans le logiciel.

• Renaud Choné

  Non seulement on arrive à mettre ça en place, mais ce n'est pas fait que pour l'agilité. Ça marche partout, la gestion de projet, tu en as partout. En fait, grosso modo, c'est un outil qui marche. quand tu as besoin de faire une gestion de projet que tu pourrais faire sous Excel. Donc, relativement, pas de planification compliquée. Si tu as besoin de faire du Gantt, du PER, du chemin critique, la performance n'est pas la bonne solution, on ne fait pas ça. Parce qu'il y a d'autres outils qui le font très bien. Par contre, pour tous les autres, et notamment tous ceux qui font de la gestion de projet sous Excel, là, je vous dis, vous êtes fous. Il y a tellement de solutions sur le marché, vous en trouverez, et ça sera plus efficace. Donc, c'est un outil un peu tout terrain, mais qui met les bonnes pratiques, par exemple. Et surtout, l'objectif, c'était justement pour les équipes agiles, déjà d'avoir cette agilité. Donc, de pouvoir modifier très facilement un planning de projet. Et la meilleure façon de pouvoir le modifier facilement, c'est de ne pas chercher à trop planifier. C'est-à-dire de ne pas aller dans le détail. Parce que ça n'a pas de sens quand tu es agile. Ça bouge beaucoup, tu as des incertitudes, donc tu ne vas pas aller dans le détail. Donc, ça, c'est un premier point. Mais après, avoir des systèmes de gestion, ça ne te prend que 5 minutes par semaine de saisie. C'est-à-dire qu'en 5 minutes de semaine par saisie, l'outil te dessine des courbes de la valeur acquise, il te calcule en temps réel l'écart de budget. Donc, ça te dit si tu dépenses trop par rapport à ce que tu avais prévu, par rapport à ce que tu avais estimé, etc. Mais en temps réel, l'objectif, c'est un outil comme ça, c'est de faire tout le côté bureaucratique gestion de la partie gestion de projet. pour que les personnes, les chefs de projet puissent se concentrer sur l'humain, notamment sur l'humain, sur la négociation, les choses comme ça. Et ça, ce n'est pas un outil qui va résoudre la problématique. Et aussi, c'est pour impliquer l'équipe dans la gestion de projet. Quand j'ai fait cet outil-là, je veux que l'équipe soit impliquée. Dans l'agilité, on dit qu'il faut les rendre autonomes, il faut les rendre responsables. Très bien, à ce moment-là, je vous donne les indicateurs. Et ça aussi, c'est quelque chose qui change, c'est en termes de communication. Ce qui est important, c'est de partager la vision. Tout le monde doit avoir la vision sur le projet doit être partagé. Donc, ce n'est pas le chef de projet qui a le planning. C'est tout le monde qui a le planning. Tous ceux qui participent au projet ont le planning. Et puis, tout le monde a accès aux indicateurs, même aux alertes sur le budget, sur les dépassements, etc. On est transparent aussi. C'est aussi une des valeurs de l'outil qui va être très différent. C'est dans Tain Performance, le chef de projet ne gère pas les tâches. Il n'est pas là pour gérer son équipe. Lui, il gère les résultats, les livrables, donc les engagements. Donc, il est là pour bien clarifier quelles sont les attendues du projet, le périmètre du projet. Mais ce n'est pas lui qui gère les tâches. Ça, c'est l'équipe qui le fait, comme on approche Agile. Tout simplement, parce que moi, ce que j'explique, c'est que c'est plutôt pour faire des études et de la recherche, des choses comme ça. C'est pour des gens qui sont BAC plus quelque chose. Et moi, ce que je dis, c'est qu'un ingénieur, on ne lui donne pas des tâches à faire. Un ingénieur, on lui pose un problème et il se débrouille. Donc voilà, avec Performance, c'est un peu l'idée. Pour que le chef de projet pose bien le problème, que ses équipes sachent ce qu'on attend d'eux, avec des objectifs en termes de délais qui sont négociés avec l'équipe, on se met d'accord sur les objectifs et après on laisse les gens travailler. Et on suit le fait que ça se passe bien. Et ça, ça permet de faire gagner beaucoup de temps au chef de projet.

• Tanguy El Mouahidine

  Très bien. Merci beaucoup, en tout cas, Renaud, pour cette vision sur l'agilité et la gestion de projet. J'espère que ça aura pu donner des idées ou clarifier ce que certaines peuvent entendre sur l'agilité et avoir un point de vue un peu pragmatique.

• Renaud Choné

  Voilà, je conclure en disant que la gestion de projet, c'est un mal nécessaire. Pour les développeurs, la façon dont ils peuvent le voir, c'est un mal, mais c'est vraiment nécessaire. si vous voulez éviter de souffrir dans votre projet.

• Tanguy El Mouahidine

  Très bien, merci beaucoup.

• Renaud Choné

  Bonne journée, au revoir Tanguy.

• Tanguy El Mouahidine

  Encore merci Renaud pour ton éclairage sur les interactions entre l'agilité et la gestion de projet. J'espère que cela vous permettra de mieux comprendre ce qu'est l'agilité et comment cela s'accorde avec la gestion de projet. Des questions, un point de vue différent sur l'articulation entre méthodes agiles et gestion de projet ? On se retrouve sur LinkedIn pour en discuter. Vous pensez que cet épisode peut être utile à quelqu'un que vous connaissez ? Partagez-le lui. Et si ce n'est pas déjà fait, abonnez-vous à Focus Projet sur votre plateforme préférée. Bonne semaine et à lundi prochain !