Agile et hybride : mener un projet en Scrum

Pendant des mois, vous avez planifié la plateforme de cours en ligne d’un bloc : tout prévoir, puis tout exécuter. Mais les formateurs changent d’avis, les apprenants découvrent des besoins en testant, la direction ajoute une demande en cours de route. Le plan rigide craque. C’est exactement le problème que l’approche agile résout — et que l’examen PMP teste désormais à parts presque égales avec le prédictif. Ici, nous menons une partie du projet en Scrum et nous assumons un fonctionnement hybride.

🎯 Ce que vous allez apprendre

• Distinguer les approches prédictive, agile et hybride, et choisir la bonne selon le contexte.
• Mettre en place les rôles, artefacts et événements de Scrum sur un projet réel.
• Construire un backlog produit priorisé et planifier un sprint.
• Lire un graphique d’avancement (burndown) et animer une rétrospective utile.

🛠️ Ce que vous allez construire

À la fin, vous aurez un backlog produit priorisé pour la plateforme, un premier sprint planifié avec son objectif, et la trame des événements Scrum adaptés à une petite équipe. Vous saurez aussi justifier pourquoi une partie du projet reste pilotée en prédictif.

Prérequis

• Un tableau (physique ou tableur) à trois colonnes : à faire, en cours, fait.
• Test express : si vous savez écrire un besoin du point de vue de l’utilisateur (« en tant que… je veux… afin de… »), vous êtes prêt.
• ⏱️ Temps estimé : ~55 minutes.

Étape 1 — Choisir entre prédictif, agile et hybride

Le PMBOK 7 ne sacralise aucune méthode : il parle de cycle de vie et invite à choisir selon le contexte. L’approche prédictive (en cascade) convient quand le besoin est stable et bien connu : on planifie tout, on exécute. L’approche agile convient quand le besoin est flou ou évolutif : on livre par petits incréments, on s’ajuste à chaque cycle. Entre les deux, l’approche hybride combine les deux selon les parties du projet.

Pour la plateforme, la décision se prend par morceau. L’infrastructure technique (hébergement, installation) est bien définie : prédictif. La conception des parcours pédagogiques et de l’interface, elle, gagne à être testée et ajustée avec les formateurs : agile. D’où un projet hybride. Savoir justifier ce découpage est précisément ce que l’examen attend : pas réciter une méthode, mais choisir la bonne au bon endroit.

✅ Point d’étape — Vous devez pouvoir dire, pour chaque grande partie de votre projet, si elle relève du prédictif ou de l’agile, et pourquoi. Si tout tombe dans une seule case, interrogez-vous : peu de projets réels sont purs.

Étape 2 — Installer les rôles Scrum

Scrum est le cadre agile le plus répandu ; si vous voulez l’approfondir au-delà de ce que l’examen exige, le cadre Scrum expliqué en détail détaille chaque événement et artefact. Il repose sur trois responsabilités (le terme « rôle » a été remplacé par « responsabilité » dans le Guide Scrum récent, mais l’idée demeure). Le Product Owner porte la valeur : il décide quoi construire et dans quel ordre, en représentant les besoins des formateurs et apprenants. L’équipe de développement (les Developers) réalise l’incrément. Le Scrum Master est un facilitateur : il aide l’équipe à appliquer Scrum, lève les obstacles, protège la concentration — il n’est pas un chef qui commande.

Sur une petite équipe, une personne peut cumuler, mais avec prudence : mélanger Product Owner (qui veut plus) et Scrum Master (qui protège le rythme) crée une tension de rôles. Pour la plateforme, le responsable pédagogique fait un Product Owner naturel : il sait ce qui sert l’apprentissage.

✅ Point d’étape — Vous devez avoir nommé un Product Owner et un Scrum Master, même en cumul. Pour vérifier : une seule personne décide des priorités (le Product Owner), sinon le backlog devient un champ de bataille.

Étape 3 — Construire le backlog produit

Le backlog produit est la liste ordonnée de tout ce qui pourrait être construit, exprimée en valeur pour l’utilisateur. On écrit chaque élément sous forme de récit utilisateur (user story) : « en tant que [rôle], je veux [action] afin de [bénéfice] ». Cette formulation force à penser au bénéfice, pas à la fonctionnalité pour elle-même.

Backlog (extrait, du plus prioritaire au moins)
1. En tant que formateur, je veux créer un cours afin de publier mon contenu.
2. En tant qu'apprenant, je veux m'inscrire à un cours afin d'y accéder.
3. En tant qu'apprenant, je veux suivre ma progression afin de savoir où j'en suis.
4. En tant que formateur, je veux voir les inscrits afin de suivre ma classe.

L’ordre n’est pas anodin : il reflète la valeur. Le Product Owner place en haut ce qui apporte le plus, le plus tôt. On peut estimer l’effort de chaque récit en points (une mesure relative de complexité, pas des heures), ce qui aide ensuite à doser un sprint sans surcharger l’équipe.

✅ Point d’étape — Vous devez avoir un backlog ordonné de récits utilisateurs, le plus précieux en tête. Pour vérifier : chaque ligne dit un bénéfice, pas seulement une tâche technique.

Étape 4 — Planifier et dérouler un sprint

Le sprint est un cycle court et de durée fixe (une à quatre semaines) au terme duquel on livre un incrément utilisable. Tout commence par la planification de sprint : l’équipe choisit, dans le haut du backlog, ce qu’elle s’engage à terminer, et formule un objectif de sprint clair. Pour notre premier sprint de deux semaines : « permettre à un formateur de créer un cours et à un apprenant de s’y inscrire ».

Pendant le sprint, l’équipe se synchronise chaque jour lors de la mêlée quotidienne (daily), quinze minutes pour dire ce qui avance et ce qui bloque. À la fin, deux événements : la revue de sprint, où l’on montre l’incrément aux formateurs pour recueillir leur retour, et la rétrospective, où l’équipe améliore sa façon de travailler. Ce rythme régulier remplace le grand plan figé par une suite de petits engagements tenus.

✅ Point d’étape — Votre sprint doit avoir un objectif en une phrase et un périmètre tenable. Pour vérifier : à la fin, vous devez pouvoir montrer quelque chose qui marche, pas un travail à moitié fait sur dix sujets.

Étape 5 — Suivre l’avancement et vérifier

Le graphique d’avancement (burndown) trace le travail restant jour après jour. Une ligne qui descend régulièrement vers zéro à la date de fin signale un sprint sain. Une ligne qui stagne révèle un blocage ; une ligne qui remonte signale qu’on a ajouté du travail en cours de route — à éviter pendant un sprint. Ce graphique tient sur une feuille et se met à jour en une minute par jour.

La vérification finale du sprint repose sur la définition de « terminé » (Definition of Done) : un critère partagé qui dit ce que « fait » veut dire (testé, documenté, mis en ligne…). Un récit n’est « terminé » que s’il satisfait cette définition — pas « presque ». C’est ce garde-fou qui empêche l’accumulation de travail à moitié fini, le poison silencieux des projets.

✅ Point d’étape — À la fin du sprint, chaque récit annoncé est soit « terminé » au sens de la Definition of Done, soit renvoyé au backlog. Pas d’entre-deux.

🐞 Pièges fréquents

🌍 Sur le terrain

L’agile ne demande pas d’outil coûteux : un tableau au mur avec des fiches, ou un simple tableur partagé, suffit pour une petite équipe. Son vrai bénéfice dans un contexte aux ressources limitées est de livrer de la valeur tôt : plutôt que d’attendre douze semaines pour découvrir que la plateforme ne correspond pas aux attentes, on montre un incrément dès la deuxième semaine et on corrige tant que c’est peu coûteux. Cette boucle de retour rapide est aussi une excellente réponse aux risques d’incertitude vus précédemment.

✅ Récapitulatif

Vous avez choisi une approche hybride pour la plateforme, installé les responsabilités Scrum, construit un backlog de récits utilisateurs priorisés, planifié un sprint avec un objectif clair, et appris à suivre l’avancement par le burndown et la Definition of Done. Vous ne subissez plus les changements : vous les intégrez à un rythme maîtrisé. C’est l’état d’esprit que l’examen PMP attend sur toute sa moitié agile et hybride.

🧾 Aide-mémoire

💪 À vous de jouer

La direction demande en plein sprint d’ajouter une page de statistiques. Que fait le Product Owner ?

Mesurer le rythme avec la vélocité

Au bout de quelques sprints, une question revient : « à ce rythme, quand aura-t-on tout livré ? » La réponse repose sur la vélocité : la quantité de travail, mesurée en points, que l’équipe termine réellement par sprint. Si l’équipe boucle en moyenne 20 points par sprint et qu’il reste 80 points dans le backlog, il reste environ quatre sprints. C’est une projection, pas une promesse, mais elle vaut bien mieux qu’une date sortie du chapeau.

La vélocité a une vertu cachée : elle se mesure, elle ne se décrète pas. On ne « fixe » pas une vélocité de 25 pour aller plus vite ; on observe celle que l’équipe atteint, sprint après sprint, et elle se stabilise d’elle-même. Vouloir la gonfler artificiellement ne fait que dégrader la qualité ou épuiser l’équipe. Pour la plateforme, suivre la vélocité sur trois ou quatre sprints donne une base réaliste pour annoncer une date de mise en ligne crédible à la direction.

Attention toutefois à ne pas en faire un instrument de comparaison entre équipes : les points sont relatifs à chaque équipe, jamais transférables. Comparer la vélocité de deux équipes revient à comparer des échelles différentes — un non-sens qui pousse, en plus, à l’inflation des estimations.

Hybride : faire cohabiter prédictif et agile

Sur la plateforme, l’infrastructure technique avance en prédictif pendant que l’interface se construit en sprints. Encore faut-il articuler les deux sans qu’ils se gênent. La clé est de définir des points de rendez-vous : des moments où la partie agile et la partie prédictive se synchronisent. Par exemple, l’incrément du sprint 2 (inscription des apprenants) ne peut être testé que si l’hébergement, livré en prédictif, est prêt — ce jalon devient une dépendance partagée à surveiller.

L’hybride réussi n’est pas un compromis mou où l’on fait « un peu des deux » sans rigueur. C’est un découpage assumé, où chaque partie suit la méthode qui lui convient, avec des interfaces clairement définies entre elles. Le chef de projet garde une vue d’ensemble — l’échéancier global, le budget, les risques — pendant que l’équipe produit gère son backlog au rythme des sprints. Cette combinaison est aujourd’hui la réalité de la majorité des projets, et c’est précisément pour cela que l’examen lui accorde une place de premier plan.

Tutoriels frères

• Gestion des risques : registre et matrice — l’itératif comme réponse à l’incertitude.
• Réussir l’examen PMP : éligibilité et stratégie — la place de l’agile dans l’épreuve.

Pour aller plus loin

• 🔝 Retour à la vue d’ensemble : Certification PMP : préparer le management de projet
• Référentiel officiel : PMBOK Guide — Project Management Institute

FAQ

Q : Quelle part de l’examen PMP porte sur l’agile ?
R : Environ la moitié des questions concernent des approches agiles ou hybrides, l’autre moitié le prédictif. Négliger l’agile, c’est se priver d’un gros bloc de points.

Q : Scrum impose-t-il un sprint de deux semaines ?
R : Non. La durée est fixe mais choisie par l’équipe, généralement entre une et quatre semaines. L’essentiel est la régularité et le fait de livrer un incrément à chaque cycle.

Q : Peut-on être hybride sans faire « à moitié » les deux ?
R : Oui, à condition de découper proprement : telle partie en prédictif, telle autre en agile, avec des règles claires d’articulation. L’hybride mal pensé, lui, cumule les inconvénients des deux.