Quelle est la vraie valeur de PRINCE2©?

PRINCE2© (PRojects IN a Controlled Environment) est une excellente meilleure pratique pour gérer les projets complexes. C’est une méthode intégrée, principalement utilisée au Royaume Uni et qui a été créée en 1989. C’est la deuxième version d’une méthode initialement créée en 1975 et nommé PROMPT©.

On sait que 70% des échecs des projets pilotés en mode classique viennent d’une non-utilisation d’une méthode structurée de gestion de projets (étude KPMG 2014). Les professionnels de la gestion de projet le savent et utilise aujourd’hui de plus en plus largement les méthodes éprouvées telles que PRINCE2©© ou PMP®. Ces meilleures pratiques, internationalement reconnues, contiennent les processus nécessaires à un pilotage de projet le plus mature possible.

Même si cette méthode est moins connue que PMP®, PRINCE2© est une excellente méthode de gestion de projets, pour les raisons principales suivantes:

  • la plupart des entreprises font du PRINCE2© sans le savoir. En effet, la plupart des projets donnent lieu à deux phases largement partagées: l’étude de faisabilité et l’étude de cadrage. Ces deux études font respectivement référence à l' »Elaboration du Projet » (faisabilité) et l' »Initialisation du projet » (cadrage). Ces deux processus PRINCE2© sont largement explicités, à travers toutes les activités réalisées, les rôles qui les réalisent, les documents générés par la méthodes, et qui est responsable de chacune des activités. Ainsi, adopter PRINCE2© n’est pas très difficile car les chefs de projet en place sont déjà habitués à cette mécanique.
  • PRINCE2© vient avec une organisation très claire des rôles et responsabilités, ce qui n’est pas le cas de PMP par exemple. En effet, dans PRINCE2© on trouve la définition précise de ce qu’est un chef de projet, ses relations avec le comité de pilotage, avec l’Assurance Projet, la Direction de l’entreprise, les programmes du catalogue de programmes de l’entreprise, et d’autres structures temporaires. Les liens hiérarchiques sont clairement identifiés et explicités. Les rôles des programmes sont cohérents avec PRINCE2©; si bien qu’en suivant les méthodes PRINCE2© et MSP (Managing Succesful Programs), les rôles et responsabilités des différents acteurs dans les projets et les programmes sont très clairs.
  • La structure en 7 principes, 7 thèmes et 7 processus est très claire elle aussi; la structure de la méthodologie faisant en sorte que rien ne peut être oublié en la suivant. Par exemple, le principe de « Justification Permanente de l’Affaire » est sous-tendu par le thème Business Case, le thème Risques et l’ensemble des processus. Autre exemple, le principe de « Leçons apprises de l’expérience » ne peut pas être oublié, car PRINCE2© explique en détails quand et comment noter cette expérience et la consolider
  • PRINCE2© peut être mise en œuvre progressivement, grâce à l’utilisation du modèle de maturité P3M3. Mais même sans ce modèle, il suffit de reprendre les processus pour identifier les thèmes manquants et les documents management qui gagneraient à être mis en place (le Business Case par exemple, le Journal de Projet, le Rapport des Retours d’Expérience, etc). Selon l’organisation, il est facile d’identifier les éléments manquants de la méthode et de prioriser leur mise en œuvre.

Les avantages à mettre en œuvre PRINCE2© dans une entreprise sont nombreux. Son implantation peut être progressive et livrer rapidement de la valeur. Par exemple:

  • mettre en œuvre le Journal de Projet: ce journal permet de retrouver très vite un évènement qui s’est déroulé dans le projet, sans avoir à parcourir l’ensemble des mails de sa boite
  • mettre en œuvre un processus d’Elaboration de Projet basé sur un Business Case; ce processus ayant pour vocation à identifier et chiffrer « à grosses mailles » les options du projet (Ne rien faire, faire le minimum, faire quelque chose). Toutes les parties prenantes ne sont pas toujours au courant de ce que doit livrer une étude de faisabilité
  • mettre en œuvre une Documentation d’Initialisation de Projet en se basant sur les livrables standard de PRINCE2©; en suivant la structure de rapports de PRINCE2©, on évite la présence d’informations du même type dans plusieurs documents, et on est sûrs de ne rien oublier
  • mettre en œuvre une gestion de risques structurée avec une estimation partagée des probabilités et des impacts des risques; ceci permet à l’ensemble des chefs de projet de l’entreprise de comparer les risques et les traiter de façon homogène.

Il reste à mobiliser les parties prenantes pour faire adopter PRINCE2© dans l’entreprise. Pour y parvenir, la formation des parties prenantes est indispensable, avec comme formateur un opérationnel de la gestion de projets avec PRINCE2©: il faut impérativement que le formateur connaisse les difficultés des chefs de projets et PRINCE2©, pour les mettre en regard l’un de l’autre.

Implanter PRINCE2© dans l’entreprise n’est donc pas très difficile même si un accompagnement et une formation des acteurs est fondamentale. La valeur de PRINCE2© est immédiate.

Retrouvez plus de détails sur: https://www.skills4all.com/course/index.php?categoryid=18

Certification PMP®: Quelle vraie valeur?

Est-ce que ces référentiels apportent une vraie valeur? Est-ce une vraie différentiation? Quel est réellement l’intérêt d’être certifié PMP®?

Autant de questions qu’on peut se poser sur PMP® comme sur la plupart des autres certifications du marché. Cependant, PMP® tient une place un peu à part.

Le métier de chef de projet est un métier qui demande de multiples compétences: des savoirs, des savoir-faire, et d’avantage encore de savoir-être. Les meilleurs chefs de projet ne sont pas que des techniciens du Gantt et de l’earn value management; ils ont du doigté, de la diplomatie et savent faire avancer les sujets malgré les difficultés. « Une main de fer dans un gant de velours »: voilà un adage qui leur correspondrait bien selon moi.

Bien sûr, tous les projets n’ont pas le même niveau de complexité ou les mêmes enjeux. Il est naturel de croire que les gros projets à forts enjeux doivent mobiliser plus de compétences que les plus petits. Néanmoins, les domaines de compétences sont communs et gagnent à être tous utilisés. Ce n’est pas parce qu’un projet est « petit » qu’il faut zapper la gestion des risques, l’implication des parties prenantes, la communication et la contractualisation par exemple. Ce sont des aspects importants de tous les projets.

Dans ce sens, PMP® est un vrai livre de chevet: En effet, il contient toutes les connaissances que devrait maîtriser un chef de projet worldclass. Bien sûr, PMP® n’est pas la bible; d’autres référentiels existent. Mais la classification des connaissances en domaines (« knowledge areas ») en donne une vision claire et en correpondance avec le cycle de vie du projet (Initiating, Planning, Executing, Monitoring & Controlling et Closing).

Les chefs de projet qui se plongent dans le référentiel trouvent tous que le contenu du PMBOK© Guide aurait pu leur servir dans de nombreux cas. Dans les situations difficiles, techniquement ou « politiquement », dans des contextes culturels forts, avec des parties prenantes aux enjeux divers souvent antagonistes. Le livre contient de nombreux outils, techniques et méthodes qui apportent immédiatement. Rien de révolutionnaire évidemment car le PMBOK© Guide recense les outils existants, mais les mets dans l’ordre et là où ils sont les plus efficaces.

Le processus de certification est lui aussi à forte valeur car il s’appuie sur 3 piliers:

  • Connaitre en détails le PMBOK© Guide,
  • Avoir une expérience opérationnelle reconnue: 3 ou 5 années en fonction de son niveau d’études
  • Réussir un examen exigeant de 200 questions, portant sur tout le référentiel, et extrêmement sécurisé

Un certifié PMP® ne l’est pas par hasard: réussir l’examen PMP® c’est l’aboutissement d’une vraie préparation et d’une compréhension profonde du référentiel. Impossible de se présenter à la certification parce qu’il y avait de la lumière: la personne mal préparée n’a quasiment aucune chance de la réussir.

C’est pour toutes ces raisons que la certification PMP® est parmi les plus reconnues et les plus recherchées sur le marché. Un certifié PMP®, c’est forcément un chef de projet expérimenté, qui connait bien les outils, méthodes et processus de gestion de projet, quelqu’un d’impliqué dans sa profession, et souhaitant évoluer. N’est-ce pas potentiellement une excellente recrue pour l’entreprise?

Vous vous souvenez des 4 principes agiles?

Même si on va prendre SCRUM en example, les autres méthodes agiles partagent les mêmes principes fondateurs. Ces principes changent les façons classiques de travailler et l’organisation de ce travail. Ils sont très forts si on cherche à les suivre, même s’ils peuvent paraitre triviaux. Passons-les en revue et identifions les impacts qu’ils génèrent.

Principe n°1: Individus et échanges plus que processus et outils

Avant d’entrer dans les détails, juste un retour sur les 3 rôles principaux formant la Scrum Team:

  • le Product Owner, responsable d’orienter le développement en fonction des besoins des utilisateurs ou clients
  • la Development Team, responsable de tout le cycle de production pour aboutir à un produit fonctionnel (livré par itérations) y compris l’architecture, les développeurs, les testeurs, etc
  • le Scrum Master, chargé de l’adoption de la méthodologie dans l’équipe et dans l’entreprise

Ce principe a de nombreuses conséquences. Tout le monde s’accorde à dire que les personnes travaillent mieux ensemble quand elles sont en immersion et en présence les unes avec autres. De fait, Agile déconseille le travail à distance et les équipes délocalisées. Bien sur, il y a la vraie vie; mais c’est une raison majeure de dysfonctionnement dans les équipes de développement.

Ceci amène à une structuration différente des équipes travaillant en agile: elles doivent travailler ensemble, physiquement, et pour obtenir le maximum d’efficience, elles doivent être autosuffisantes. On entend par là être en mesure :

  • de résoudre elle-même les problèmes liés au développement (techniques, architecturaux, de performance, etc)
  • de s’auto-organiser pour atteindre ses objectifs (en gérant elle-même sa composition et son planning par exemple)
  • de négocier les objectifs des Sprints avec le Product Owner
  • d’organiser ses Sprints de façon autonome
  • d’améliorer sans cesse ses compétences et sa performance

Autre conséquence liée à l’autonomie de la Development Team: elle n’a pas besoin de manager. C’est aussi pourquoi le Scrum Master n’est pas un manager mais un leader; SCRUM entends par là qu’il mène une mission d’accompagnement et de facilitation; pas hiérarchique.

Principe n°2: Produit fonctionnel plus que documentation pléthorique

Cela ne veut pas dire: pas de documentation bien entendu. Mais cette documentation se déplace et change de forme. Le code doit être auto-portant pour permettre aux équipes de développer efficacement et de partager son code en cas de turn over. Les modes opératoires se transforment en vidéos d’utilisation mettant en situation l’utilisateur du développement. Comme l’agilité repose sur l’implication des utilisateurs (dans le grooming ou progressive refinement et dans les Sprint Reviews), les utilisateurs voient avancer le développement et se l’approprient mieux.

L’idée de « produit fonctionnel » amène aussi la question de la qualité des développements. En effet, le produit livré, même itérativement à la fin de chaque Sprint, doit être terminé et utilisable. Ceci pose la question de ce qui est « terminé » (en production? Sans bugs? Avec un nombre de bugs acceptable? Après le support de formation?). Ceci amène aussi le besoin de livrer un produit de qualité: il n’y a pas pire qu’un produit buggué passé en homologation aux utilisateurs.

Principe n°3: Collaboration du client plus que négociation du contrat

Bien sûr c’est une des dimensions fortes des méthodes agiles: on cherche à éviter les effets tunnel. Tout le monde a vécu les problèmes d’interprétation de diverses équipes qui se transmettent des informations par documents interposés. Le meilleur moyen de se comprendre c’est de se parler, pas de s’écrire (cf la littérature pléthorique sur la communication verbale/non verbale/gestuelle etc).

Il est aussi très difficile de préciser le périmètre d’un développement applicatif ex nihilo: qui est capable de spécifier sur 100 pages les besoins détaillés en début de projet, alors que les idées ne sont pas toujours très claires au moment du lancement? Personne. Il est bien plus efficace de co-construire les livrables et de faire des boucles de rétro-action courtes. Seeul le client/utilisateur peut dire ce dont il a envie, et le lui montrer est le meilleur moyen de lui faire exprimer. Montrer souvent, c’est avoir des retours fréquents.

Ce point pose la question de la durée des Sprints: un mois tel que préconisé par SCRUM. C’est à régler selon les projets mais la durée des Sprints ne peut pas être modifiée (perte d’efficience et déstabilisation). La bonne durée est à fixer en fonction de la capacité à produire de la Development Team et de son besoin d’obtenir des retours.

Principe n°4: Réactivité au changement plus que suivi d’un plan

Enfin, un dernier principe très fort: droit à l’erreur, mais une erreur rapide. Fail but fail fast. Avec le développement classique le tunnel peut durer plusieurs mois; en agile c’est au maximum un Sprint. En agile, le changement c’est le moteur de la méthodologie; les Sprints sont des outils pour rebondir sur les changements.

Le fonctionnement par Sprint pose quand même la question de la planification car agile ne veut pas dire aucune planification. Deux aspects: en début de Sprint on a bien un évènement qui s’appelle « Sprint Planning », mais dont la portée n’excède pas le Sprint qui vient. La planification plus long terme s’articule autour de la gestion des releases mais elle ne répond pas au besoin de planification d’un projet de développement long. Vous trouverez dans un article précédent une discution sur la problématique de la planification et de la visibilité pour les instances dirigeantes d’un projet de développement agile.

Ces différents principes, si on cherche à les implanter effectivement, bouleversent les habitudes de pilotage classique des projets de développement: les respecter est important pour la réussite d’un projet de développement agile.

Et si le meilleur atout d’une méthode agile, c’était une méthode classique?

Avez-vous déjà essayé de vendre à un DAF un projet de développement dont on ne connait ni les contours, ni les coûts ni la date de fin?

Évidemment, présenté comme ça c’est un peu brutal. Mais qu’est-ce que voit un décideur d’un projet agile si ce n’est exactement ça? Et je ne parle pas des financiers, à qui la démarche est le plus souvent totalement étrangère.

Bien sûr ce n’est pas ce que dit SCRUM (80% des projets de développement agiles s’appuient sur SCRUM). Mais dans les faits, c’est pourtant bien ce qui se passe car les entreprises ne sont pas toutes en mode agile. Elles ont besoin de visibilité, les différents acteurs ont du mal « payer pour voir »: il faut convaincre et pour convaincre il faut montrer.

Deux cas assez fréquents où il faut donner de la visibilité: lorsque l’entreprise souhaite expérimenter/adopter une méthode agile, et lorsqu’on a vécu un échec après l’avoir expérimenté. Dans les deux cas il y a une attente forte de contrôle.

Il n’y a pas dans SCRUM d’étape sur le contrôle. Les Sprint Reviews et Sprint Rétrospectives sont bien des jalons où des feedbacks sont générés respectivement sur les fonctionnalités et sur la méthodologie. Mais c’est très insuffisant pour (re)donner confiance et avoir de vraies perspectives.

Ce contrôle est d’ailleurs utile aux équipes qui ont souvent, elles-aussi, besoin de se rassurer. Pensons par exemple au Product Owner, qui porte seul la responsabilité de l’atteinte des objectifs du développement agile: que peut-il faire pour garantir l’alignement du développement avec les objectifs de l’entreprise? Comme va-t-il chercher le financement? Comment fait-il la preuve que ces objectifs ont été atteints? Comment formule-t-il ces objectifs? Comment fait l’équipe de développement, qui doit embarquer assez souvent des évolutions extérieures au projet agile? Comment l’équipe gère-t-elle la non-disponibilité des parties prenantes et leur motivation (rappel: le Scrum Master n’est pas un manager et la Development Team est auto-suffisante)?

Dans la vraie vie, la Dévelopment Team n’est pas dédiée; elle ne dispose pas de toutes les ressources nécessaires: parce qu’elles n’ont pas besoin d’être présentes tout au long du développement et/ou parce que ces ressources sont toujours mutualisées avec d’autres projets.

Autant de questions fondamentales qui n’ont pas de réponse dans SCRUM. Autant de sources de dysfonctionnement et les équipes ne sont pas armées pour y faire face.

Finalement de quoi parle-t-on? On parle de recentrer les équipes agiles sur leur cœur de métier: le développement. Mais développer une application ce n’est pas seulement écrire du code. C’est aussi gérer des risques, respecter une feuille de route, rendre compte d’un budget. Bref, c’est gérer un projet.

N’en déplaise aux puristes, la meilleure façon de gérer un projet de développement agile, c’est de l’encadrer avec une gestion de projets classique.

Je sais ça fait tâche. Mais c’est du bon sens: A moins que l’entreprise ne choisisse de consommer un certain budget « pour voir » et que le périmètre du développement soit vraiment restreint, faire du pure agile est très risqué.

Comment faire?

Tout le monde a depuis longtemps fait la correspondance entre classique et agile via les Sprints: les Sprints sont en agile ce que les Séquences sont en classique (pour PRINCE2 par exemple). Et finalement, l’équipe spécialiste de PRINCE2 c’est la Development Team de SCRUM. Mais comment réconcilier la vue court-terme de SCRUM avec la vue long terme de PRINCE2?

En fait, il y a un point de contact naturel: le Sprint Goal. A chaque début d’itération (Sprint Planning), la Development Team définit les objectifs du Sprint à venir dans un Sprint Goal. Ce Sprint Goal permet à l’équipe de développement de « garder le cap », et ne pas oublier les objectifs du Sprint pendant son exécution.

Ce Sprint Goal est un excellent moyen de confronter le périmètre à réaliser dans le projet et le périmètre réalisé dans le Sprint. Visuellement, c’est lui qui fait le lien dans un Plan Projet classique avec les objectifs de la Development Team. On a ainsi tous les outils pour donner de la visibilité à l’entreprise, voire au sponsor du projet de développement (rôle décrit nulle part dans SCRUM bien évidemment).

Alors? Est-ce que le meilleur atout d’une méthode agile, ce n’est pas une méthode classique?

En savoir plus: Retrouvez la formation Skills4All de préparation à la certification SCRUM Master ici: https://www.skills4all.com/formation-certification/gestion-de-projet/23-SCRUM-methode-agile/certification-professional-scrum-master-PSM1/

ITIL© à la Direction Générale: une drôle d’idée? Pas si sûr…

Bien sûr ITIL© c’est IT Infrastructure Library. Mais prenons un peu de hauteur.

Le transporteur qui cherche à traiter les dysfonctionnements sur ses camions, et à en comprendre les causes pour les éradiquer, ne fait-il pas de la gestion des incidents et des problèmes à la ITIL©? Sa gestion de parc auto-mobile ne pourrait-elle pas s’appeler CMDB? Pour gérer la saisonalité de son business, ne devrait-il pas utiliser la gestion de la demande? Gérer les évènements sur sa flotte serait certainement la meilleure façon d’améliorer la disponibilité de ses camions et la durée de vie de ses équipements… Pour assurer la satisfaction de ses clients, il gagnera certainement à implanter un processus de relation business appuyé sur des contrats de services.

On vient de parler, peut-être sans s’en rendre compte, 9 des processus ITIL© les plus connus. A-t-on parlé de serveurs? D’ordinateurs? D’applications?

Non.

Les principes sous-tendus par ITIL© sont bien plus larges que le seul domaine IT. Ce sont des principes qui soutiennent toute activité basée sur une relation client-fournisseur.

Depuis la version 3 certains processus sont vraiment en prise avec la stratégie de l’entreprise. On peut parler de gestion financière, de Stratégie des Services qui s’apparente à du marketing, de gestion des relations business qui ressemble trait pour trait au commercial et au portefeuille de services.

La gestion de portefeuille de services d’ITIL© pourrait apporter une grande valeur pour toutes les entreprises, quelque soit leur taille. Dans ce processus, explicité en détails dans le livre « Stratégie des Services », on explique comment piloter les investissements informatiques de l’entreprise, choisir les bons projets, les prioriser, et équilibrer ces investissements en balançant le risque et le ROI. Supprimez le mot « informatique » dans la phrase précédente et vous avez une gestion des investissements d’une entreprise à la mode MoP© (Management of Portfolios) qui traite exactement ce sujet au niveau de plus élevé de l’entreprise.

Autre processus ITIL© qui gagnerait à être prolongé à son bon niveau: la gestion des changements. Beaucoup de DSI l’ont implanté pour tenter de maîtriser les changements dans le système d’information. Mes ces changements sont une conséquence de changements dans le métier ou les processus de l’entreprise. Le même processus pourrait donc embarquer les changements « métier », car ils nécessitent une évaluation d’impact au même titre que les changement IT. Beaucoup de changements IT (même si ITIL© ne les décrits pas spécifiquement) patissent d’une définition insuffismament claire ou d’une évaluation insuffisamment travaillée au niveau du métier, avant de se traduire en changement dans le SI. On n’adresse d’ailleurs pas tous les changements de la même façon, car certains sont opérationnels (risque faible ou maîtrisé), tactiques (modification d’un processus métier) ou stratégiques (changement de métier). Les efforts ne sont bien sûr pas comparables. ITIL© nous décrit comment gérer ces différents niveaux de changement.

Encore une fois, on rejoint le référentiel MoP© qui décrit l’articulation entre la transformation de l’entreprise (à l’aide de projets et programmes) et les opérations courantes, qui sont l’ADN de l’entreprise.

Alors? S’inspirer d’ITIL© dans une Direction Générale: une idée saugrenue?

En savoir plus: Formez-vous à ITIL Foundation pour le meilleur prix. Retrouvez l’offre Skills4All sélectionnée pour vous: https://www.skills4all.com/course/index.php?categoryid=9

S’il-vous-plait, réfléchissons avant d’agile!

« Soyons agiles », « entreprise agile », « budgets agiles », « équipes agiles »… Arrêtons!

Arrêtons de penser que l’agilité est la réponse à tous les problèmes, mêmes ceux qui ne sont pas identifiés…

Les méthodes agiles, ça ne fonctionne pas pour tout: en fait, ça ne fonctionne bien que dans quelques cas de figure précis:

  • on ne sait pas définir précisément le produit/service à réaliser
  • ET qu’il peut être construit itérativement
  • ET qu’on accepte de le sortir alors qu’il n’est pas fini

Explicitons un peu ces 3 éléments.

On ne sait pas définir précisément le produit/service à réaliser

Vous savez décrire précisément le périmètre? N’utilisez pas une méthode agile! Il y a tous les outils nécessaires dans les méthodes classiques pour adresser les risques et les changements. Il y a un effort à fournir dans l’expression du besoin, mais que de temps gagné par la suite… Mais attention, ne pas savoir(vouloir) décire précisément le périmètre n’est pas une « excuse » pour passer en mode agile: les itérations (sprints) sont des phénomènes vivants difficiles à maitriser. Paradoxalement, le Product Owner responsable d’orienter/traduire les besoins des utilisateurs et les représenter, doit avoir une très bonne maîtrise du produit/service à développer. Ce rôle est central dans les méthodes agiles et les volontaires sont difficiles à recruter…

il peut être construit itérativement

même si un des slogans de l’agile est « on peut se tromper, mais le plus vite possible », les allers/retours et changements de directions en cours de développement sont déstabilisants et il vaut mieux les éviter. Etre agile, ça ne veut pas dire s’agiter: un temps de réflexion est nécessaire avant de se lancer. Il faut également que le produit/service puisse être constitué de briques agrégées les unes aux autres, avec des bases solides posées dès le début.. Sinon, gare aux rétro-pédalages douloureux. Ce socle initial est une question difficile à organiser en mode agile, car il nécessite au contraire de bien comprendre le périmètre à livrer. D’où l’importance du Product Owner.

On accepte de sortir le produit/service alors qu’il n’est pas fini

En effet, une composant centrale des méthodes agiles, c’est l’interaction avec le client/utilisateur. Il faut lui montrer rapidement quelque chose sur lequel il puisse réagir, rebondir et qu’ils puissent s’approprier. C’est une contrainte forte qui amène son lot de déconvenues: de la frustrations lorsque les livraisons ne suivent pas ou la qualité n’est pas au rendez-vous; de la démotivation lorsque les fonctionnalités demandés ne sont pas priorisées comme le souhaitent les utilisateurs; du septiscisme lorsque l’ergonomie ou le visuel n’est pas soigné, voire l’impasse lorsque les évolutions techniques ou de plate-forme ne sont jamais priorisées par les utilisateurs. Ceci implique une équipe d’utilisateurs forte, impliquée et motivée à 100%, prête à s’investir sur la durée et ouverte au dialogue!

Dans tous les cas, l’agilité nécessite une formation préalable, car ces méthodes changent radicalement de l’approche classique. C’est un petit investissement qui vous rendra de grands services..

En bref, et à moins que vous cherchiez à développer 3 pages de code d’une application non stratégique, posez-vous la question plutôt en ces termes: suis-je sûr de ne pas pouvoir utiliser une méthode classique?!

Retrouvez la formation Skills4All de préparation à la certification SCRUM Master ici: https://www.skills4all.com/formation-certification/gestion-de-projet/23-SCRUM-methode-agile/certification-professional-scrum-master-PSM1/