← Parcours PMP
🔁

Agile, hybride & approches de livraison

Cœur de l'examen
🧠Comprendre en lisant n'est pas savoir écrire.🧠Un module est fini quand tu peux le reproduire fenêtre fermée.🧠Écris le problème en français avant d'écrire du code.🧠Une question impossible cache trois questions faciles.🧠Retape le code à la main. Puis referme et réécris-le.🧠Essaie d'abord, cherche ensuite.🧠Cherche « comment on écrit ça », jamais « qu'est-ce que je dois faire ».🧠Pour comprendre du code, casse-le.⌨️Une fonction qui plante sur un cas limite n'est pas finie.⌨️Si un bloc a un nom clair, il mérite d'être une fonction.⌨️Savoir lire une erreur vaut plus que connaître dix méthodes.⌨️Diagnostiquer, c'est éliminer dans l'ordre — pas essayer au hasard.⌨️Une optimisation sans mesure avant/après est une croyance.🔍Regarde le fichier avant de le charger.🔍Une performance anormalement bonne est une hypothèse à réfuter.🔍Cette valeur existe-t-elle à l'instant où je dois prédire ?🔍fit sur le train, transform partout.🔍Un chiffre qu'on ne sait pas raconter est un chiffre qu'on n'a pas compris.🔍Un graphique sans question n'a rien à dire.🤖Un score d'entraînement parfait n'est jamais une bonne nouvelle.🤖Le jeu de test ne se regarde qu'une fois.🤖Plus tu essaies de configurations, plus ton meilleur score est optimiste.🤖Un seuil de décision est un arbitrage économique, pas un réglage technique.🤖Commence toujours par une baseline. Note son score.🤖Le meilleur modèle n'est pas le plus précis, c'est celui qu'on peut maintenir.🚀Un modèle en production n'est pas un livrable, c'est un système vivant.🚀Un secret publié est un secret compromis.🚀Pour chaque permission : que se passe-t-il si cette machine est compromise ?🚀Un post-mortem qui cherche un coupable ne produit aucune amélioration.🚀« Nous n'utilisons pas cette variable » n'est pas une garantie d'équité.🚀Rends l'arbitrage explicite et chiffré. Ne le tranche pas en silence.🚀Un résultat qu'on ne sait pas reproduire est une anecdote.

🎯 Objectifs d'apprentissage

À l'issue de ce module, tu seras capable de :

  • 01Choisir entre Scrum, Kanban et hybride selon le contexte projet
  • 02Animer les cérémonies agiles et en tirer des décisions
  • 03Adapter le reporting EVM à un contexte agile

Prérequis

Module Process

📖 Lectures de référence

Sélection d'expert — les ressources gratuites sont signalées.

Agile Practice Guide

Payant

PMI & Agile Alliance

Inclus dans l'adhésion PMI. Co-écrit avec l'Agile Alliance — c'est la vision agile que l'examen évalue.

Scrum Guide 2020

Gratuit

Schwaber & Sutherland

Gratuit, 13 pages, par les créateurs de Scrum. À lire intégralement au moins deux fois.

Valeurs, principes Agile & Scrum

⏱ 35 min

L'agilité privilégie la livraison itérative de valeur et l'adaptation au changement.

Le Manifeste Agile — 4 valeurs

→ Les individus et leurs interactions plutôt que les processus et les outils.

→ Un logiciel/produit qui fonctionne plutôt qu'une documentation exhaustive.

→ La collaboration avec le client plutôt que la négociation contractuelle.

→ L'adaptation au changement plutôt que le suivi d'un plan figé.

(+ 12 principes : livraisons fréquentes, accueil du changement, équipes motivées et auto-organisées, simplicité, rythme soutenable, amélioration continue.)

Scrum — le framework le plus courant

→ Rôles : Product Owner (porte la valeur et le backlog), Scrum Master (servant leader, facilite, retire les obstacles), Équipe de développement (auto-organisée).

→ Sprint : itération courte et de durée fixe (1 à 4 semaines) produisant un incrément « done ».

→ Backlog produit : liste ordonnée des besoins, gérée par le PO. Backlog de sprint : ce que l'équipe s'engage à livrer.

Rôle du chef de projet en agile : souvent celui de Scrum Master / facilitateur — il sert l'équipe, il ne commande pas.

Ressource : Agile Practice Guide (PMI) https://www.pmi.org/learning/exam-prep ; vidéos agile — Andrew Ramdayal https://www.youtube.com/AndrewRamdayal

✍️ Exercices de la leçon

2 exercices

Fais-les dans l'ordre, dans un vrai fichier .py — pas dans ta tête. Ne déplie la correction qu'après avoir écrit quelque chose, même faux.

🔧

Exercice A — Qui décide quoi dans Scrum

Application directe · Tu appliques ce que tu viens de lire.

Pour chacune de ces huit décisions, dis qui décide : le Product Owner, le Scrum Master, l'équipe de développement, ou personne seul.

  1. 1.L'ordre des éléments du backlog produit.
  2. 2.Le nombre d'éléments pris dans le sprint.
  3. 3.La façon technique d'implémenter une fonctionnalité.
  4. 4.La durée du sprint.
  5. 5.Si un incrément est « terminé » selon la definition of done.
  6. 6.L'annulation d'un sprint.
  7. 7.Le contenu de la definition of done.
  8. 8.Si une nouvelle demande urgente entre dans le sprint en cours.

Puis : quelle est l'erreur de rôle la plus fréquente chez un chef de projet qui passe à Scrum ?

🧩

Exercice B — Le Product Owner absent depuis trois sprints

Cas situationnel · Aucune grille fournie : à toi de raisonner et de justifier.

Cas situationnel.

Ton Product Owner est un directeur métier très pris. Depuis trois sprints :
- il ne vient plus au sprint planning, il envoie une liste par mail la veille
- il n'assiste à aucune revue de sprint
- il répond aux questions de l'équipe en 3 à 4 jours
- l'équipe a pris l'habitude de « décider à sa place » quand elle est bloquée

Résultat : deux fonctionnalités livrées ont été refusées à la revue trimestrielle, parce qu'elles ne correspondaient pas au besoin.

  1. 1.quel est le problème de fond, et ce n'est pas l'absence du PO
  2. 2.quelles sont les conséquences déjà visibles, au-delà des deux refus
  3. 3.quelle est ta première action ?
  4. 4.quelles options concrètes envisages-tu si son agenda ne peut pas changer ?
  5. 5.qu'est-ce que l'équipe doit arrêter de faire, et pourquoi c'est difficile ?

Le point 5 est contre-intuitif : ce que fait l'équipe est bien intentionné et aggrave le problème.

🤖

Question sur cette leçon ? Clique sur 💬 Demander au tuteur en bas à droite.