Fiche de révision : Gestion de Projet Agile et Scrum

📋 Plan du Cours

1. Enjeux du projet
2. Management d’équipe projet
3. Planification du projet
4. Pilotage et risques
5. Outils de suivi projet
6. Méthodes agiles et Scrum
7. Mise en pratique agile
8. Story mapping et releases

📖 1. Enjeux du projet

🔑 Notions clés & Définitions

• Projet : Un projet vise un objectif unique, démarre et se termine clairement, et mobilise des ressources dédiées par opposition à l’opérationnel récurrent.
• Carré Coût-Délai-Qualité-Périmètre : Un cadre des enjeux où coût, délai, qualité et périmètre se contraignent mutuellement, ce qui rend tout arbitrage risqué pour le reste.
• Cycle de vie d’un projet : Un projet suit des étapes successives allant du cadrage initial jusqu’à la clôture, avec une phase d’exécution entre les deux.

📝 Points essentiels

• Un projet se distingue de l’opérationnel récurrent car il a une fin et des ressources spécifiées pour atteindre un objectif unique.
• Tout projet est limité par trois contraintes : délai, coût et qualité.
• Améliorer une contrainte (délai, coût ou qualité) détériore forcément au moins une autre contrainte.
• Le périmètre fait partie des enjeux à arbitrer avec coût, délai et qualité.
• Le cycle de vie indiqué est : cadrage (initier) → planification → exécution et clôture (livrer).

📖 2. Management d’équipe projet

🔑 Notions clés & Définitions

• Styles de management : Les styles de management sont des façons d’adapter le pilotage du chef de projet selon la situation, notamment le besoin de décision et le niveau d’autonomie de l’équipe.
• Sponsor projet : Le sponsor est l’acteur qui finance le projet et le valide, ce qui lui donne un rôle de décision au plus haut niveau.
• Modèle de Tuckman : Le modèle de Tuckman décrit l’évolution d’une équipe en étapes allant de la découverte initiale jusqu’à la dissolution en fin de projet.
• Objectifs SMART : Les objectifs SMART rendent les buts plus clairs et atteignables en utilisant des critères précis pour guider l’action de l’équipe.

📝 Points essentiels

• Le management directif sert à décider vite quand la situation l’exige tandis que le management participatif sert à mobiliser l’équipe et que le management délégatif s’applique quand l’équipe est mature et autonome.
• Le sponsor apporte le financement et valide le projet, le chef de projet coordonne le travail, l’équipe exécute et les parties prenantes subissent ou influencent les effets du projet.
• Le modèle de Tuckman commence par Forming où l’équipe apprend à se connaître, puis Storming fait émerger tensions et désaccords.
• Le modèle de Tuckman passe ensuite par Norming pour clarifier les rôles et collaborer efficacement, puis Performing pour atteindre une productivité optimale.
• Le modèle de Tuckman se termine par Adjourning, quand le projet finit et l’équipe se dissout avec un mélange de réussite et de tristesse.
• La motivation progresse quand la reconnaissance et la communication entretiennent l’engagement, avec des objectifs SMART clairs et atteignables.

💡 Astuce mémo

Tuckman : Forming→Storming→Norming→Performing→Adjourning (FSNPA).

📖 3. Planification du projet

🔑 Notions clés & Définitions

• Gestion des coûts : La gestion des coûts regroupe les méthodes pour estimer, suivre et maîtriser les dépenses du projet jusqu’à la fin.
• CBTE : CBTE est un outil de pilotage qui aide à mesurer l’avancement du projet à travers les notions budgétaires, de délais et de temps.
• Valeur acquise : La valeur acquise permet d’évaluer la valeur du travail réellement réalisé par rapport au budget prévu pour le moment considéré.
• Arbitrages et priorisation : Les arbitrages et la priorisation servent à choisir ce qui est fait en premier pour maîtriser simultanément délais et ressources.
• Tableaux de bord KPI : Les tableaux de bord KPI regroupent des indicateurs pour visualiser l’état du projet et guider les décisions.

📝 Points essentiels

• La maîtrise des délais et des ressources passe par des arbitrages et une priorisation du travail à réaliser.
• Le suivi budgétaire s’appuie notamment sur la logique de valeur acquise pour comparer prévu et réalisé.
• CBTE sert de cadre pour piloter l’avancement en reliant coûts et calendrier.
• Les tableaux de bord KPI projet permettent de suivre la performance via des indicateurs reconnus.
• L’externalisation des activités peut apporter des avantages mais présente aussi des limites à évaluer avant de décider.

📖 4. Pilotage et risques

🔑 Notions clés & Définitions

• Système de pilotage : Le système de pilotage regroupe des jalons, des comités et du reporting pour contrôler l’avancement et orienter les décisions.
• Matrice des risques : La matrice des risques classe chaque risque selon sa probabilité et son impact pour prioriser les actions de maîtrise.
• AMDEC : L’AMDEC est une méthode de repérage et d’analyse des risques techniques et organisationnels afin d’améliorer la sécurité et la fiabilité.
• Suivi d’avancement : Le suivi d’avancement utilise des indicateurs pour repérer les dérives et ajuster la conduite du projet.

📝 Points essentiels

• Le pilotage repose sur des jalons, des comités et un reporting pour encadrer l’évolution du projet.
• Le suivi d’avancement s’appuie sur des indicateurs afin de détecter rapidement les dérives.
• L’identification des risques peut utiliser SWOT et PESTEL pour cadrer l’environnement et les vulnérabilités.
• L’analyse de causes peut s’appuyer sur Ishikawa et Porter pour structurer la réflexion avant de traiter les risques.
• La matrice des risques combine probabilité × impact pour prioriser les risques à traiter en premier.
• Une approche itérative et incrémentale, comme en Scrum, vise à améliorer la prédictibilité et le contrôle du risque.

💡 Astuce mémo

Matrice des risques = Probabilité × Impact : tu « choisis » ce qui fait le plus mal et qui arrive le plus souvent.

📖 5. Outils de suivi projet

🔑 Notions clés & Définitions

• Daily Scrum : Événement Scrum quotidien où l’équipe inspecte la progression vers l’objectif de Sprint et ajuste le plan si besoin.
• Sprint Review : Réunion de fin de Sprint centrée sur l’inspection du résultat produit et la discussion des adaptations futures avec les parties prenantes.
• Sprint Retrospective : Cérémonie de clôture du Sprint où la Scrum Team analyse son fonctionnement et choisit des améliorations d’efficacité et de qualité.
• Burndown chart : Graphique de suivi qui montre l’évolution du travail restant pour estimer l’avancement vers l’objectif du Sprint.

📝 Points essentiels

• Le suivi projet mesure l’écart entre le prévu et le réalisé, grâce à des indicateurs, un burndown chart et des tableaux de bord pour anticiper les dérives.
• Le Daily Scrum ne dure pas plus de 15 minutes et se tient à la même heure et au même lieu pour réduire la complexité de coordination.
• Le Daily Scrum est structuré par les développeurs et sert à inspecter la progression vers l’objectif de Sprint puis à adapter le Sprint Backlog si nécessaire.
• La Sprint Review est limitée à 4 heures maximum pour un Sprint d’un mois et vise l’inspection du résultat puis la discussion des adaptations futures et de la progression vers l’objectif de Produit.
• La Sprint Retrospective est limitée à 3 heures maximum pour un Sprint d’un mois et peut produire des changements ajoutés au Sprint Backlog pour le prochain Sprint.

📖 6. Méthodes agiles et Scrum

🔑 Notions clés & Définitions

• User Story : Description courte d’une fonctionnalité vue du point de vue de la personne qui la demande, généralement un utilisateur ou un client.
• Card Conversation Confirmation : Format 3C qui structure une User Story via une carte écrite, une discussion autour du besoin et une confirmation par des critères d’acceptation.
• Critères d’acceptance GIVEN WHEN THEN : Format de test attendu qui décrit un scénario d’utilisation avec une condition, une action et un résultat observé.
• Story Points : Unité d’estimation de complexité servant à chiffrer la quantité d’effort et l’incertitude d’une User Story.

📝 Points essentiels

• La Sprint Retrospective conclut le Sprint et est limitée à 3 heures maximum pour un Sprint d’un mois, avec une durée réduite pour des Sprints plus courts.
• Une User Story suit le schéma As A <Who> I Want <What> So That <Why> pour exprimer le besoin du point de vue de l’utilisateur.
• Les critères d’acceptance utilisent le triplet GIVEN <condition> WHEN <action> THEN <outcome> pour préciser ce qui doit être validé.
• L’estimation en Story Points est réalisée par l’équipe de développement à l’aide d’une suite de Fibonacci afin de refléter que plus c’est gros, plus il y a d’inconnu.
• Chronologie : 1997 Kent Beck introduit les User Stories chez Chrysler C3, 2001 Ron Jeffries propose les 3C, 2004 Mike Cohn formalise le style As A I Want So That.
• Les conclusions de la Sprint Retrospective peuvent générer des changements, qui peuvent être ajoutés au Sprint Backlog du prochain Sprint dès que possible.

📖 7. Mise en pratique agile

🔑 Notions clés & Définitions

• Critères d’acceptance : Des conditions testables formulées en Given Quand Alors qui précisent quand la User Story est considérée comme conforme.
• Backlog JIRA : Une liste structurée des User Stories à implémenter, utilisée pour piloter et ordonner les travaux dans l’outil JIRA.
• Sprint agile : Un intervalle de temps de développement planifié pour livrer un ensemble de User Stories, avec un objectif pour l’itération.

📝 Points essentiels

• Une User Story suit le format En tant que Je veux que Afin de, puis ses critères d’acceptance utilisent Given Lorsque Alors.
• Le Story Point Estimate est généralement renseigné par l’équipe de développement, avec une estimation basée sur une suite de Fibonacci modifiée.
• Pour le backlog JIRA, ne lister que les tâches réellement développées (pas les activités d’organisation comme animer des réunions).
• Dans l’étude de cas, le site ouvre le 1er janvier 2026 et les participations ferment le 31 mars 2026, avec un message « trop tard… » à partir du 1er avril 2026.
• La création du 1er sprint se fait avec une durée de 3 semaines et une limite de 10 story points, puis un 2nd sprint avec un maximum de 10 story points (+/-).

💡 Astuce mémo

Template mémorisation : En tant que / Je veux que / Afin de → puis Given / Lorsque / Alors pour prouver l’acceptation.

📖 8. Story mapping et releases

🔑 Notions clés & Définitions

• Story mapping : Technique de Product Owner qui remet de l’ordre dans le backlog pour définir un planning de livraison par étapes.
• Backlog : Ensemble des user stories planifiées à exécuter, regroupées puis ordonnées pour construire un enchaînement de livraisons.
• Fonctionnalités : Regroupement de user stories qui partage un même thème, placé en colonne pour faciliter l’ordonnancement.
• Releases : Mises en production planifiées, déclinées en versions (MVP puis ajouts), qui structurent la livraison des user stories.

📝 Points essentiels

• Le story mapping sert à ordonner les user stories et à construire le planning des livraisons (MVP, version 2, etc.) à partir du backlog.
• Dans le story mapping, on regroupe les user stories par colonnes correspondant à des fonctionnalités.
• Pour chaque colonne, les user stories sont ordonnées dans l’ordre chronologique du début vers la fin.
• On ajoute une ligne par release pour visualiser quoi livrer en production à chaque étape.
• La release du 1er janvier correspond au MVP, la suivante ajoute ce qui pourrait venir dans un second temps, et l’affichage des gagnants n’est attendu qu’après.
• Dans l’exemple, l’ordre des dates est 1er janvier (ouverture), 31 mars (clôture + message trop tard), 1er avril (tirage sans dévoiler, site ouvert), 1er mai (affichage des gagnants).

💡 Astuce mémo

MVP en premier : lignes = releases, colonnes = thèmes, et on déroule chaque colonne dans le temps (du 1er début vers la fin).

📅 Repères chronologiques

1. 1997Introduction des User Stories par Kent Beck (XP) au sein de Chrysler C3 Project (Detroit).
2. 2001Ron Jeffries propose les 3C (Card, Conversation, Confirmation).
3. 2004Mike Cohn formalise le style « As A User … I Want … So That … ».
4. 2001Manifeste Agile (4 valeurs & 12 principes).
5. 2026Étude de cas : ouverture du site et jalons de concours (1er janvier, 31 mars, 1er avril, 1er mai/1er juillet selon l’évolution décrite).

📊 Tableaux de synthèse

Contraintes du projet

⚠️ Pièges & confusions fréquents

1. Confondre « projet » et « opérationnel récurrent » : un projet a un début/une fin clairs et des ressources dédiées, pas l’opérationnel.
2. Croire qu’on peut « améliorer une contrainte » sans effets sur les autres : le délai/coût/qualité se contraignent mutuellement.
3. Mélanger les rôles : le sponsor finance et valide, le chef de projet coordonne, l’équipe exécute, les parties prenantes subissent/influencent.
4. Interpréter mal Tuckman : Former ne signifie pas « tout va bien », c’est l’étape de découverte avant les tensions (Storming).
5. Doser la planification Scrum : ne pas respecter les timeboxes (Daily <=15 min, Sprint Review <=4h, Retrospective <=3h).
6. Écrire une User Story sans format attendu : confondre « As A / I Want / So That » et les critères d’acceptation GIVEN/WHEN/THEN.
7. Se tromper dans le story mapping JIRA : ajouter des activités non-développées (ex : organiser des réunions) alors que seules les tâches réellement développées doivent figurer.

✅ Checklist Examen

1. Définir un projet et donner en quoi il s’oppose à l’opérationnel récurrent (objectif unique, début/fin, ressources dédiées).
2. Expliquer le carré Coût–Délai–Qualité–Périmètre et pourquoi améliorer une contrainte détériore forcément au moins une autre.
3. Donner la séquence du cycle de vie : cadrage → planification → exécution → clôture (et ce que recouvre chaque étape).
4. Associer les styles de management au bon contexte : directif (décider vite), participatif (mobiliser), délégatif (équipe mature/autonome).
5. Énumérer les rôles et responsabilités : sponsor (finance/valide), chef de projet (coordonne), équipe (exécute), parties prenantes (impactées).
6. Réciter et caractériser Tuckman : Forming → Storming → Norming → Performing → Adjourning (découverte, tensions, rôles/coopération, performance, dissolution).
7. Formuler l’intérêt des objectifs SMART et relier motivation à reconnaissance + communication.
8. Identifier les éléments du pilotage : jalons, comités, reporting, puis relier suivi d’avancement à indicateurs/dérives.
9. Pour les risques, relier chaque outil à son but : SWOT/PESTEL (environnement), Ishikawa/Porter (causes/pression), AMDEC (risques techniques/organisationnels), matrice (probabilité × impact).
10. Calculer ou interpréter la valeur acquise (logique CBTE/CBTP/CRTE) et conclure sur retard/surcoût via les comparaisons CBTE–CBTP et CBTE–CRTE.
11. Expliquer PERT (réseau de tâches, dépendances, chemin critique via marges nulles) et le principe du Gantt (barres = activités/durée).
12. Maîtriser Scrum : citer empirisme/Lean, décrire le Sprint (<=1 mois, objectifs/qualité), puis les événements (Daily <=15 min, Review <=4h, Retrospective <=3h) et leur objectif.
13. Rédiger une User Story au bon format (As A <Who> I Want <What> So That <Why>) et écrire au moins un critère d’acceptation en GIVEN/WHEN/THEN.
14. Expliquer l’estimation en Story Points (Fibonacci modifiée, équipe dev estime) et le fonctionnement du backlog (story mapping : colonnes = fonctionnalités, lignes = releases/MVP + versions).