Je viens de poster un commentaire sur cette vidéo
!! Boite à outil VS cadre VS mindset
- PRINCE2 600 pages
- PMBok 300 pages
- Scrum 25 pages
- Manifeste Agile 1 page
PRINCE2 => machine à vendre formations et certifications
PMBok => machine à vendre formations et certifications
Scrum => possibilité de formations et certificationsManifeste Agile => état d’esprit et expérience de terrain
Avec l’avènement des frameworks Agile de type Scrum ou SAFe, j’ai cette impression assez désagréable que les concepts même de Gestion de Projet et de Chef de Projet sont devenus des gros mots. Avec cette connotation péjorative dans la communauté dite Agile de la gestion de projet est une notion révolue, d’un autre âge. J’ai parfois même l’impression que c’est la notion de projet qui est devenue tabou dans la communauté, alors que dans mon esprit, toute démarche de changement est un projet.
Avec la mouvance Agile, j’ai ce sentiment que du passé nous voulons faire table rase.
Les méthodologies PRINCE2 ou PMBok n’est pas la Gestion de Projet. Ce sont des méthodologies, ou plutôt des guidelines dans les dernières versions, aidant à appréhender l’ensemble des facettes d’un projet. Et elles sont nombreuses, d’où les pavé de plusieurs centaines de pages si on se veut un minimum sérieux sur le sujet.
Ces méthodologies de gestion de projet sont loin d’être parfaites, mais elles ont le mérite d’essayer de poser un cadre systémique sur ces monstres infiniment polymorphes que sont les projets.
Ces méthodes sont certes critiquables, mais ont je trouve une vision plus réaliste des projets que Scrum (blasphème ?) qui se limite à des situations très spécifiques, d’une équipe dédiée, un peu à part dans l’entreprise, pouvant totalement se consacrer à un sujet, le plus souvent du développement logiciel. De mon constat, sorti de ce contexte, j’ai rarement vu Scrum briller.
Selon moi, il ne devrait pas il y avoir d’opposition entre gestion de projet et Agilité. L’Agilité peut prendre diverses formes. Et la gestion de projet, selon le projet et le contexte d’entreprise, peut embrasser l’Agilité à divers degré.
Néanmoins, je pense que la gestion de projet est peut être trop restrictif en 2024, et que nous devrions désormais davantage parler le Delivery Management (gestion de livrables ?) qui met en exergue la raison d’être des projets.
Au final, ce dont les entreprises ont vraiment besoin, ce n’est pas tant des coachs en agilité ou des chefs de projet, mais des Delivery Managers.
Bonjour
Etant Coach ET PMP, je suis tout à fait d’accord avec toi…
Le cadre méthodologique projet classique est parti dans la poubelle, remplacé par la mode Agile.
J’adore faire de l’Agile, faire vite… Mais c’est parfois bien de réfléchir un peu.
J’ai vu tellement de projets qui se sont planté car le binôme PO & SM ne voulait pas rédiger la vision… J’ai même eu une ancienne chef de projet, reconvertie Scrum Master, refuser de faire le planning, le CdC … car elle était maintenant SM ! Et refuser également de regarder le Backlog, les critères d’acceptations, DOD, DOR, … car elle était Chef de Projet…
Ce n’est pas une impression.
L’agilité, ou vision « produit » s’est toujours opposée à la vision « projet » en informatique.
D’abord, il faut rappeler ce qu’est un projet : une organisation temporaire des moyens de production, avec une date de début et une date de fin. Ce mode d’organisation, issue de l’ingénierie traditionnelle, est bien adaptée à la conception de biens capitalistiques (c’est-à-dire des biens dont la valeur s’accumule dans le temps). Si on investit 1M€/an pendant 4 ans, alors à la fin on a un bien de 4M€. On peut ensuite espérer gagner plus de 4M€ en l’exploitant pendant plusieurs années sans y toucher outre mesure de l’entretien, dont le coût est marginal par rapport au budget de développement. C’est la raison pour laquelle les DSI se sont traditionnellement développées en 3 silos : bureau d’étude, projets, exploitation, en mimétisme des organisation d’ingénierie traditionnelles, et que le vocabulaire de l’IT est honteusement pompé du BTP.
Pendant très longtemps, la vision qu’on avait du logiciel était très stable, mais la nature incorporelle du logiciel (ça ne coûte rien à supprimer ou dupliquer), l’évolution rapide et continue des technologie (obsolescence), couplée à l’arrivée d’internet (cybersécurité) ont changé la donne. Aujourd’hui, l’espérance de vie d’un logiciel en condition de maintenabilité et de sécurité est de l’ordre d’un mois. Et lorsqu’on fait une modification dans le logiciel, on doit s’assurer de la non-régression de l’ensemble, voire du super-ensemble dans lequel le logiciel s’intègre. Si on prend l’exemple d’un pont, si les glissières de sécurité ne sont pas conformes, on peut les remplacer. Ce remplacement ne peut structurellement pas remettre en question la solidité de l’ouvrage quant à la circulation de véhicules de 3,5 t à 90 km/h. Quand on change les glissières, on n’a donc pas besoin de vérifier la solidité du parapet. Dans un logiciel, il y a des interdépendances beaucoup plus complexes, sans compter que l’ingénierie logicielle est encore jeune et que les techniques d’isolation (monolithes modulaires, micro services, …) sont encore en phase de consolidation et d’appropriation par une grande part de la profession. Ca revient à imaginer qu’on ne soit pas capables de modifier un pont, simplement d’en remplacer une instance par une nouvelle instance. On peut donc modifier des propriétés involontairement, d’où l’importance des fameux « tests de non-régression » en génie logiciel.
Une autre problème récurrent en génie logiciel c’est l’innovation. En effet, l’incorporalité du logiciel fait qu’il est très facile de dupliquer ou de réutiliser un morceau de code. En conséquence, la plupart des coûts de développement sont consommés pour la fabrication de code qui cherche à résoudre des problèmes originaux. Dans ce contexte, l’activité de développement est peu prédictible, et il est extrêmement difficile de faire des estimations fiables de cette activité. Cela explique le taux catastrophiquement faible de projets on-time on-budget, et qui n’a pas bougé depuis plus de 15 ans (stable à 30%).
La vision projet n’est donc pas adaptée, car le besoin ou les contraintes évoluent plus vite que la capacité de production de l’équipe. C’est le problème classique de beaucoup d’applications, qui arrivent en étant déjà obsolètes en production. Ca veut dire que, contrairement à un ouvrage capitalistique, un logiciel qui à coûté 1M€/an pendant 4 ans peut très bien avoir une valeur nulle, voire négative (du fait des risques encourus en raison son obsolescence).
Dans ce contexte, les agilistes ont suggéré d’abandonner cette approche projet en cascade (conception, développement, exploitation), au profit d’une approche incrémentale. Cette approche implique une approche perpétuelle, dite « produit ». Le logiciel devient donc une commodité, mais aussi une source de valeur. Contrairement à l’approche projet, où l’on réfléchit au logiciel comme un bien, l’approche produit considère le logiciel comme un service qu’on fait évoluer. C’est donc toute l’équipe qui travaille ensemble pour résoudre des enjeux métiers successif au fur et à mesure de leur identification (dysfonctionnement, nouveau besoin, …). Par ailleurs, on pilote ces évolutions par le budget et non par les coûts. C’est à dire qu’au lieu de se dire « combien ça coûte de résoudre ce problème ? », on se demande « combien je veux investir dans la résolution de ce problème ? ».
On n’est donc pas en mesure de dire quand est-ce qu’on aura terminé le développement, puisque l’idée c’est de travailler dans le même mode de fonctionnement de manière perpétuelle, jusqu’à l’abandon du logiciel et l’arrêt de son exploitation (qui n’est pas planifié d’avance). Par ailleurs, on ne sait même pas dire c’est quoi le produit « fini » puisqu’il s’agit de travailler en permanence sur le sujet le plus susceptible d’apporter de la valeur, et non pas de fabriquer un bien donné dont on aurait une vision préalable.
Quelques sources pour aller plus loin :
Redefining Success: Beyond CHAOS Reports in IT Project Management | by Oliver Mende | Medium
Statistiques gestion de projet : Quel est le taux de succès des projets ? (reussirsesprojets.com)
Contexte, contexte, contexte.
Quel excellent article
Merci pour ton travail @punkstarman
Merci, c’est gentil.
Est-ce que la méthode doit s’adapter au produit, à son contexte… ou à ceux qui vont l’appliquer ?
En tout ça c’est bien ceux qui vont l’appliquer qui vont l’adapter.
Et ils le feront en tenant compte
et ce dans un ordre variant selon leurs caractères, cohésion, pression, envie, affinité, adhésion à leur entreprise, …
Oui, les gens font partie du contexte auquel il faut s’adapter en choisissant une méthode et sa mise en application.
Le framework Cynefin que tu promeus, et qui rejoint aussi la mouvance #noframework (la récente vidéo de ScrumLife à ce sujet avec une intervenante était très intéressante par ailleurs) va dans le même sens que l’idée de « conception projet » que j’essaie de développer où la « méthodologie » doit être adaptée au contexte.
Dave Snowden, le créateur de Cynefin, prend des positions compatibles avec la mouvance #noframework, sans nier l’utilité de Scrum, XP, DSDM, etc. Il argue que ce que les agilistes appellent des frameworks sont plutôt des agencements (cf. Deleuze). Il préconise de transcender les guerres entre méthodes et les systèmes de certification pyramidaux pour apprendre à composer des agencements inédits en fonction du contexte. On veut des chefs cuistot plutôt que des livres de recette.
Je viens de regarder la première partie de la vidéo au sujet de l’outil Hexi.
L’approche est intéressante et rejoins bien ma vision de la Conception Projet (Project Design), où un projet est une entité en tant que telle qu’il faut construire selon la nature du sujet (développement logiciel, réorganisation, intégration, gestion de crise, etc), les ressources à disposition, le contexte d’entreprise et tout un tas d’autres facteurs avec lesquels il faut composer.
Dans un futur outil de gestion de projet que j’aimerai bien réaliser, il est certain qu’il faut aller au delà du Gantt ou du Kanban.
Bonjour Adrien,
Je note tout d’abord que tes réponses sont souvent très développées (voire intimidantes) et que je ne prends que rarement le temps d’y répondre (rien de personnel).
Bien que j’y relève une haute érudition signe aussi d’un solide background, je ne peux m’empêcher de penser que je ne partage pas vraiment ta vision d’un projet que je trouve trop restrictive et qui quelque part montre l’état d’esprit d’une bonne partie de la communauté Agile qui reste campée sur l’ingénierie logicielle.
J’ai toujours trouvé la vision produit très utile et bienvenue dans l’industrie logicielle, ce qui lui a permis d’adopter une approche bien plus holistique. Cependant, cette vision produit ne doit pas d’une part elle non plus devenir l’alpha et l’omega (le monde de l’entreprise ne se limite pas à du développement logiciel et tout ne peut être assimilé à un produit) et ne doit pas d’autre part exclure le fait que pour des raisons pratiques, il y a des phases, des « releases », qui peuvent sans mal être assimilées à des projets.
Mon propos est : si on arrêtait d’opposer les méthodes ? Pourquoi ne peut-on pas imaginer une part de vérité dans chacune d’entre elles ? Une part de complémentarité ?
Je reproche par exemple aux méthodes Agile de laisser croire que la phase de conception est inutile voire néfaste (en tout cas, pas mal de personnes interprètent les méthodes Agile sous cet angle). Dans ma carrière, il y a plus d’un cas de figure où il aurait été de bon ton à l’équipe de développeurs de se poser avant de se lancer dans le code puis de se rendre compte à posteriori que leur feature rentrait en conflit avec d’autres pans du logiciel.
Ensuite, même si tu ne t’intéresse peut-être qu’à l’industrie du logiciel, ma réflexion est davantage et immodestement universaliste. Pour un projet donné, que ce soit du génie logiciel, de l’infrastructure réseau, de la gestion de crise, de la transformation d’entreprise et autres, quels sont les meilleurs outils à notre disposition. Et mon sentiment intime c’est qu’il n’y a pas de réponse unique et que pour être optimale, cette réponse doit être adaptée à chaque situation en tenant compte du contexte dans un sens holistique (nature du sujet, collaborateurs, entreprise, concurrence, réglementation, etc).
Hey, merci pour le retour. Mon boulot consiste (entre autres) à rédiger des rapports d’analyses techniques complexes, surtout en ce moment, alors ce n’est pas surprenant. Je tâcherai de faire plus d’efforts 
Pour la définition d’un projet, comme beaucoup de gens je me base sur la définition du PMMI.
C’est pas parfait, mais c’est compliqué de se mettre d’accord sur une autre définition.
Je pense qu’on est moins en désaccord que tu semble le penser.
Pour résumer, mon propos c’est :
Je parle beaucoup de logiciel parce que même si j’ai un peu d’expérience en ingénierie dans d’autres domaine, j’ai quand même 30 ans d’expérience dans le logiciel, alors forcément je parle des sujets que je connais bien, et moins des autres.
L’agilité ne remet pas en question la conception, elle remet en question le phasage.
Malheureusement, beaucoup d’organisations confondent « supprimer le phasage » et « supprimer la phase ». Si les développeurs sont partis bille en tête pour faire un truc qui ne fonctionne pas sans se poser dans une phase de conception, n’est-ce pas justement parce qu’ils ont été endoctrinés à coder à partir de spécifications issues d’une phase de conception, qui est censée résoudre, en amont de leur travail, les conflits qu’ils ont rencontré ?
Se poser dans une « phase de conception » aurait permis d’éviter les problèmes, mais pas tous. Bien sûr, c’est mieux de faire une phase de conception plutôt que pas du tout. Bien sûr, c’est mieux de faire une phase de conception par un ingénieur logiciel plutôt que par un autre métier. Bien sûr, c’est mieux de faire une phase de conception par l’ingénieur logiciel qui va coder plutôt que par un autre. Mais ce qui est encore mieux, c’est de faire de la conception collectivement et en continu plutôt qu’en amont. En considérant le produit dans son ensemble. Et c’est cette approche, où le travail est fait en continu, de manière perpétuelle et de bout-en-bout qu’on appelle une approche « produit ».
Attention, je parle bien, en mode projet, de séquencer les responsabilités. Le phasage des fonctionnalités successives (qu’on appelle généralement « lotissement ») n’est pas le sujet. On peut parfaitement faire des lots en mode produit (les sprints scrum). Tout comme on peut faire un bon gros tunnel en mode projet. C’est pour ça que « faire des sprints » ne suffit pas à faire de l’agile. Et comme ça touche à la responsabilité, c’est politique, et donc difficile à faire évoluer dans une organisation.
On ne peut pas arrêter d’opposer les deux car elles reposent sur deux conceptions antagonistes et incompatibles de l’organisation du travail : soit on séquence les responsabilités, soit on ne les séquence pas. On ne peut pas faire les deux en même temps. Mais opposer les deux ne veut pas dire qu’une est meilleure que l’autre.
Et d’ailleurs, on sait dire quelle approche est la plus cohérente selon le contexte :