Cours sur les Méthodes Agiles

Introduction : Pourquoi l’Agilité ?

Dans un monde incertain et changeant, surtout dans les domaines innovants comme la science des données ou l’IA et même l’informatique en général, les méthodes traditionnelles de gestion de projet ne suffisent plus.
L’agilité est mieux adaptée : elle permet de tester et d’ajuster régulièrement les idées, favorise la collaboration et transforme le changement en opportunité plutôt qu’en problème.

changements <> problèmes

Première définition :

L’agilité est une façon de gérer les projets qui mise sur l’adaptation rapide, le travail en équipe et l’amélioration continue, pour mieux répondre à un environnement changeant.

Mais avant de voir ce que sont les méthodes agiles regardons ce qui existait avant dans le domaine de la gestion de projet.

La méthode en cascade (ou gestion séquentielle des projets)

La méthode en cascade, également appelée Waterfall, est l’un des premiers modèles utilisés pour gérer les projets informatiques. Elle repose sur une organisation séquentielle et linéaire des différentes étapes du projet.

Le processus est généralement divisé en phases distinctes :

Analyse des besoins : recueil et formalisation des attentes du client.
Conception : élaboration de l’architecture et des spécifications détaillées.
Développement : réalisation technique et écriture du code.
Tests et validation : vérification du bon fonctionnement par rapport au cahier des charges.
Déploiement et maintenance : mise en production et corrections éventuelles.

Chaque phase doit être entièrement achevée avant de passer à la suivante, avec peu de retours en arrière possibles. Cette approche favorise la planification rigoureuse et la documentation complète, mais elle présente une grande rigidité.

Son principal inconvénient est que les problèmes ou incompréhensions ne sont souvent détectés qu’en fin de projet, lors des tests ou de la livraison. Cela peut générer un écart important entre le produit livré et les besoins réels du client, surtout si ces besoins ont évolué au cours du temps.

La méthode en cascade reste adaptée à des projets stables et bien définis dès le départ, mais elle est moins efficace pour les projets informatiques modernes, où l’incertitude et l’évolution des besoins sont fréquentes.

Les Limites des Méthodes Traditionnelles (Cycle en V)

Le cycle en V est une évolution de la méthode en cascade, utilisée dans la gestion de projet informatique et dans l’ingénierie logicielle. Il conserve une approche séquentielle, mais introduit une logique de validation à chaque étape.

Principe

Le cycle en V se lit comme un V :

Phase descendante (à gauche du V) : analyse des besoins, spécifications fonctionnelles, conception générale puis conception détaillée.
Phase montante (à droite du V) : codage, puis une série de tests correspondant aux phases de conception :
- tests unitaires (vérifient chaque module),
- tests d’intégration (vérifient l’assemblage des modules),
- tests de validation (vérifient que le produit correspond aux spécifications),
- tests d’acceptation (vérifient la conformité avec les besoins du client).

Ainsi, chaque étape de conception est associée à une étape de validation.Inconvénients :

La rigidité de l’approche : Une fois le plan initial validé, il devient extrêmement difficile et coûteux d’intégrer des nouveautés ou de modifier les exigences, même si le contexte du marché a changé.
La validation et la recette tardives : Le client ne découvre et ne valide le produit final qu’à la toute fin du cycle. Tout malentendu sur les besoins n’est découvert que très tard, lorsque les corrections sont complexes et onéreuses.
Le risque de mauvaise interprétation des besoins : Cette validation tardive mène fréquemment à une mauvaise interprétation des souhaits du client, entraînant des dépassements de délais, de budgets, et dans de nombreux cas, l’abandon pur et simple du projet.
La production d’une documentation pléthorique : Une énergie considérable est consacrée à la rédaction de spécifications détaillées qui, en raison de l’évolution naturelle du projet, deviennent rapidement obsolètes ou inutiles.

L’Agilité en Action : Une Analogie Concrète

Pour bien comprendre la différence fondamentale, imaginons deux équipes chargées de construire un vaisseau spatial cargo en un an.

L’équipe traditionnelle (Cycle en V) passe les premiers mois à rédiger un cahier des charges ultra-précis. Chaque boulon, chaque circuit est planifié avant que la première pièce ne soit assemblée. Le client ne verra le vaisseau qu’une fois celui-ci entièrement terminé.

L’équipe Agile, quant à elle, sélectionne quelques exigences fondamentales et, après quelques semaines, livre un premier prototype : un simple engin de transport terrestre. Ce n’est pas un vaisseau spatial, mais il est fonctionnel. Le client peut le voir, le tester et donner un premier avis très tôt. L’équipe améliore ensuite ce prototype par itérations successives.

Soudain, une guerre intergalactique éclate. Le marché change : le besoin n’est plus le transport de masse, mais le transport sécurisé d’objets de valeur. L’équipe Agile, grâce à ses cycles courts, s’adapte immédiatement. Elle repriorise les fonctionnalités pour ajouter un système de défense et des capacités de furtivité. Peu après, le budget du projet est drastiquement réduit. L’équipe Agile se concentre alors sur les fonctionnalités essentielles pour livrer un produit viable dans les nouvelles contraintes.

À la fin de l’année, l’équipe Agile livre un vaisseau plus petit que prévu, mais parfaitement fonctionnel, viable commercialement et adapté aux nouveaux besoins du marché. De son côté, l’équipe traditionnelle, dont le plan rigide ne pouvait intégrer ces changements, se retrouve avec un vaisseau inachevé et déjà obsolète, car les travaux ont dû s’arrêter avant la fin.

Cette analogie illustre la force principale de l’agilité : sa capacité à accueillir le changement et à s’adapter en continu pour livrer de la valeur, quelles que soient les turbulences du projet.

Les Fondements de l’Agilité : Le Manifeste Agile

En 2001, dix-sept experts du développement logiciel se sont réunis pour formaliser une nouvelle façon de penser la création de produits. De cette rencontre est né le Manifeste Agile, un texte fondateur qui consacre officiellement le terme « Agile ». Plus qu’un simple document, il représente une rupture culturelle, plaçant l’humain, la collaboration et la valeur apportée au client au cœur du processus de développement.

Les Quatre Valeurs Fondamentales

Le manifeste repose sur quatre valeurs clés qui guident la philosophie agile. Chaque valeur met en lumière une priorité, sans pour autant nier l’importance des éléments de droite.

Individus et interactions plutôt que processus et outils : L’accent est mis sur la communication directe et la collaboration entre les membres de l’équipe. Les meilleurs outils et les processus les plus stricts ne remplaceront jamais des échanges humains fluides et efficaces pour résoudre les problèmes.
Fonctionnalités opérationnelles plutôt que documentation exhaustive : La priorité absolue est de livrer rapidement un produit qui fonctionne et apporte de la valeur. Une documentation détaillée est utile, mais elle ne doit jamais prendre le pas sur la création de fonctionnalités tangibles et utilisables.
Collaboration avec le client plutôt que contractualisation des relations : L’agilité promeut un partenariat continu et étroit avec le client. Plutôt que de se retrancher derrière les termes rigides d’un contrat, l’objectif est de travailler ensemble pour comprendre et satisfaire au mieux les besoins des utilisateurs.
Acceptation du changement plutôt que conformité aux plans : Dans un projet agile, le changement n’est pas un obstacle à éviter, mais une opportunité d’améliorer le produit et d’apporter une valeur ajoutée supplémentaire. La capacité à s’adapter est plus importante que le suivi aveugle d’un plan initial.

Les Douze Principes Directeurs

Ces quatre valeurs sont déclinées en douze principes qui servent de guide pratique pour la mise en œuvre de l’agilité. Pour plus de clarté, nous pouvons les regrouper par thèmes :

Centrés sur le Client et la Valeur :
- Satisfaire le client en priorité par des livraisons rapides et continues de logiciel utile.
- Accueillir favorablement les demandes de changement, même tard dans le projet.
- Livrer fréquemment du logiciel opérationnel, sur des cycles de quelques semaines à quelques mois.
- Mesurer l’avancement en termes de fonctionnalités opérationnelles.
Centrés sur l’Équipe et la Collaboration :
- Assurer une coopération quotidienne et permanente entre le client (ou son représentant) et l’équipe.
- Construire des projets autour d’individus motivés, leur fournir l’environnement et le soutien nécessaires, et leur faire confiance pour réaliser le travail.
- Privilégier la conversation en face à face comme méthode de communication la plus efficace.
- Responsabiliser les équipes et favoriser leur auto-organisation.
- Les meilleures architectures, exigences et conceptions émergent d’équipes auto-organisées.
Centrés sur l’Excellence Technique et la Simplicité :
- Travailler à un rythme soutenable et constant, que les équipes peuvent maintenir indéfiniment.
- Porter une attention continue à l’excellence technique et à la bonne conception.
- Faire simple : la simplicité est la meilleure façon de garantir l’évolutivité future du système.
- Ajuster régulièrement ses processus et son comportement pour être plus efficace (amélioration continue).

Notre plus haute priorité est de satisfaire le client par la livraison rapide et continue de logiciel utile.
Accueillir favorablement les changements de besoins, même tard dans le développement.
Livrer fréquemment un logiciel opérationnel, toutes les deux semaines à deux mois.
Les utilisateurs et les développeurs doivent travailler ensemble quotidiennement.
Construire les projets autour d’individus motivés.
La méthode la plus efficace de communication est le face-à-face.
Un logiciel opérationnel est la principale mesure de progression.
Les processus agiles favorisent un rythme de développement soutenable.
Une attention continue à l’excellence technique et à la conception améliore l’agilité.
La simplicité est essentielle.
Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
À intervalles réguliers, l’équipe réfléchit et ajuste son comportement pour gagner en efficacité.

Ensemble, ces valeurs et principes forment le socle sur lequel reposent toutes les méthodes et cadres de travail agiles.

Scrum : Le Cadre de Travail Agile le Plus Répandu

Scrum n’est pas une méthode prescriptive qui dicte comment travailler, mais un cadre de travail (framework) léger. Son objectif est simple et puissant : « produire la plus grande valeur métier dans la durée la plus courte ». Pour y parvenir, Scrum s’appuie sur une approche de développement itérative et incrémentale, où le travail est découpé en cycles courts appelés sprints.

Les Trois Piliers de Scrum

Le fonctionnement de Scrum est fondé sur un modèle de contrôle empirique qui repose sur trois piliers fondamentaux :

Transparence : Tous les aspects du projet doivent être visibles pour tous les acteurs impliqués. Un langage commun et des artefacts clairs permettent à chacun de partager une même compréhension de l’avancement et des objectifs.
Inspection : Les différents artefacts et la progression vers les objectifs doivent être inspectés fréquemment, mais sans nuire au travail, afin de détecter rapidement toute variation ou dérive indésirable.
Adaptation : Si une inspection révèle une dérive, le processus doit être ajusté. Scrum fournit des événements spécifiques (les « rituels ») pour permettre à l’équipe de s’adapter et de corriger le tir, favorisant ainsi l’amélioration continue.

L’Équipe Scrum : Rôles et Responsabilités

Une équipe Scrum est auto-organisée et pluridisciplinaire. Elle est composée de trois rôles distincts et complémentaires :

Le Product Owner (Propriétaire du Produit) : Il est le représentant du client et des utilisateurs. Sa principale responsabilité est de maximiser la valeur du produit développé. Pour cela, il définit, priorise et gère la liste des fonctionnalités à développer (le Product Backlog). Il est la seule personne habilitée à décider de l’orientation du produit.
Le Scrum Master (Maître de Mêlée) : Il est le garant du processus Scrum. Il n’est pas un chef de projet traditionnel, mais un « leader au service de l’équipe ». Son rôle est de faciliter les événements, d’aider l’équipe à être pleinement fonctionnelle et productive, d’éliminer les obstacles et de la protéger des interférences extérieures.
L’Équipe de Développement : C’est un groupe de 3 à 9 personnes qui possèdent toutes les compétences nécessaires pour transformer les éléments du backlog en un produit fonctionnel. Elle est auto-organisée, ce qui signifie qu’elle choisit elle-même la meilleure façon de réaliser son travail. L’équipe ne comporte pas de rôles prédéfinis et toutes les décisions sont prises ensemble. Elle est responsable de livrer un incrément de produit potentiellement livrable à la fin de chaque sprint.

Les Événements Scrum (Rituels)

La vie d’un projet Scrum est rythmée par une série d’événements contenus dans des « boîtes de temps » (time-boxes) pour garantir une régularité et une efficacité maximales.

Le Sprint : C’est le cœur de Scrum. Il s’agit d’une itération de travail d’une durée fixe d’un mois maximum (souvent deux semaines), durant laquelle un incrément de produit « fini » et utilisable est créé. Un nouveau sprint démarre immédiatement après la conclusion du précédent.
La Mêlée Quotidienne (Daily Scrum) : Une réunion de 15 minutes maximum, chaque jour, pour l’Équipe de Développement. Elle permet de synchroniser le travail et de planifier la journée. Seule l’équipe de développement intervient ; toute autre personne peut assister mais ne peut pas intervenir. Chaque membre répond à trois questions : Qu’ai-je fait hier ? Que vais-je faire aujourd’hui ? Quels sont mes obstacles ?
La Réunion de Planification du Sprint (Sprint Planning) : Se déroule en début de sprint pour planifier le travail à effectuer. D’une durée maximale de 8 heures pour un sprint d’un mois, l’équipe Scrum y collabore pour définir un objectif et sélectionner les éléments du Product Backlog qui seront réalisés.
La Revue de Sprint (Sprint Review) : A lieu à la fin du sprint pour inspecter l’incrément de produit. D’une durée maximale de 4 heures pour un sprint d’un mois, l’équipe de développement présente ce qui a été accompli aux parties prenantes pour obtenir leur feedback, qui alimentera la suite du projet.
La Rétrospective du Sprint (Sprint Retrospective) : C’est le dernier rituel du sprint. D’une durée maximale de 3 heures pour un sprint d’un mois, l’équipe Scrum inspecte son propre fonctionnement (processus, outils, relations) et élabore un plan d’amélioration concret à mettre en œuvre dès le prochain sprint.

Les Artefacts Scrum

Les artefacts de Scrum sont conçus pour maximiser la transparence des informations clés du projet.

Le Carnet de Produit (Product Backlog) : C’est la source unique des besoins pour le produit. Il s’agit d’une liste ordonnée et dynamique de tout ce qui est souhaité : fonctionnalités, améliorations, correctifs. Il est géré et priorisé par le Product Owner.
Le Carnet de Sprint (Sprint Backlog) : Il contient l’ensemble des éléments du Product Backlog que l’Équipe de Développement a sélectionnés pour le sprint en cours, ainsi que le plan pour les réaliser. Il est géré par l’Équipe de Développement et donne une vision en temps réel du travail restant.
L’Incrément de Produit : C’est la somme de tous les éléments du Product Backlog terminés lors du sprint en cours et de tous les sprints précédents. À la fin d’un sprint, le nouvel incrément doit être « fini », c’est-à-dire dans un état utilisable et potentiellement livrable.

Ces piliers, rôles, événements et artefacts forment un système cohérent et interdépendant qui permet de gérer la complexité et l’incertitude de manière structurée et adaptative.

Autres Approches Agiles Pertinentes

Il est essentiel de comprendre qu’être agile ne signifie pas nécessairement faire du Scrum. L’agilité est une philosophie, et plusieurs cadres de travail existent pour la mettre en pratique. Chacun a ses forces et peut être plus ou moins adapté au contexte d’un projet ou d’une équipe. Il est même courant de combiner des pratiques issues de différentes approches.

Extreme Programming (XP)

L’Extreme Programming (XP) est une méthode agile fortement orientée vers la réalisation technique et la qualité du code. Son principe fondateur est simple : identifier les bonnes pratiques de développement logiciel et les pousser à l’extrême. XP est particulièrement pertinent pour les équipes techniques cherchant à construire des produits robustes et maintenables.

Voici cinq de ses pratiques clés :

Programmation en binôme (Pair Programming) : Le code est écrit à deux sur un même poste. Le premier, appelé driver (ou pilote), tient le clavier. Le second, appelé partner (ou copilote), est là pour l’aider, suggérer des améliorations et détecter les problèmes en temps réel. Cette pratique améliore drastiquement la qualité du code et favorise un partage constant des connaissances.
Intégration Continue : Les modifications de code sont intégrées à la base de code principale très fréquemment (plusieurs fois par jour). Cela permet de détecter les conflits et les problèmes d’intégration immédiatement, évitant ainsi la phase d’intégration longue et douloureuse des méthodes traditionnelles.
Tests Unitaires (Test-Driven Development) : Le principe est d’écrire un test automatisé avant d’écrire le code de production correspondant. Le code n’est considéré comme terminé que lorsque le test passe. Cela garantit une couverture de tests élevée et une grande confiance lors des modifications ultérieures.
Conception Simple : Toujours choisir la solution la plus simple qui répond au besoin actuel. Il faut résister à la tentation d’anticiper des besoins futurs complexes qui pourraient ne jamais se matérialiser, car une application simple est plus facile à faire évoluer.
Refactoring (Remaniement du code) : C’est l’art d’améliorer la structure interne du code sans en changer le comportement externe. Cette pratique est menée en continu pour garder le code propre, compréhensible et facile à maintenir, ce qui permet aux développeurs d’avancer plus vite sur le long terme.

Kanban

Kanban est une approche agile alternative puissante, particulièrement adaptée aux équipes qui gèrent un flux de travail continu, comme la maintenance ou le support. Contrairement à Scrum qui est basé sur des itérations (sprints), Kanban se concentre sur la gestion d’un flux continu. Ses objectifs principaux sont de visualiser le travail, de limiter le travail en cours (WIP – Work In Progress) pour éviter les goulots d’étranglement, et de maximiser l’efficacité du flux de livraison. C’est un excellent outil pour les équipes traitant un grand nombre de demandes non planifiées, où la structure rigide d’un sprint serait inadaptée.

Le choix entre Scrum, XP, Kanban ou une approche hybride dépend entièrement du contexte du projet, de la culture de l’entreprise et de la maturité de l’équipe.

L’Agilité en Pratique : Planification et Suivi

L’agilité transforme radicalement la manière dont la planification et le suivi sont abordés. On abandonne la planification rigide et détaillée réalisée en amont au profit d’une planification adaptative et continue, centrée sur la livraison de valeur. Pour ce faire, les équipes agiles s’appuient sur des outils simples, visuels et collaboratifs.

Formaliser le Besoin : Les User Stories

Une User Story (ou scénario utilisateur) est une description simple et courte d’une fonctionnalité, racontée du point de vue de la personne qui désire cette nouvelle capacité. Elle est généralement formulée pour répondre aux questions : Qui ? Quoi ? Pourquoi ? Par exemple, le format classique est : « En tant que [type d’utilisateur], je veux [réaliser une action] afin de [obtenir un bénéfice] ». L’ensemble de ces « stories » constitue le Product Backlog, une liste vivante des besoins du produit.

La méthode MoSCoW

La méthode MoSCoW est un outil de priorisation utilisé dans les projets agiles pour trier les besoins ou les fonctionnalités selon leur importance.
L’acronyme signifie :

M – Must have : indispensable, obligatoire. Le projet ne peut pas fonctionner sans.
S – Should have : important, mais pas vital. Peut être décalé si nécessaire.
C – Could have : optionnel, “nice to have”. Améliore l’expérience mais pas essentiel.
W – Won’t have (for now) : non retenu dans ce projet/sprint, éventuellement pour plus tard.

Exemple avec un site e-commerce :

Must : ajouter un produit au panier, payer en ligne.
Should : trier les produits par prix.
Could : mettre un avis sur un produit.
Won’t : partager un produit sur TikTok.

Estimer l’Effort : Le Planning Poker

Le Planning Poker est une technique de gamification collaborative utilisée pour estimer l’effort (taille, complexité, incertitude) nécessaire pour réaliser les User Stories. Le processus favorise la discussion et le partage des connaissances :

Le Planning Poker est une technique agile utilisée pour estimer la complexité ou l’effort nécessaire à la réalisation des User Stories.
C’est un jeu collaboratif qui permet à toute l’équipe de donner son avis et de converger vers une estimation commune.

Le Product Owner présente une User Story à l’équipe.
L’équipe de développement en discute et pose des questions pour clarifier tous les aspects.
Chaque membre choisit secrètement une carte d’une valeur correspondant à son estimation (souvent issue de la suite de Fibonacci : 1, 2, 3, 5, 8, 13…).
Tout le monde révèle sa carte en même temps. Les estimations les plus basses et les plus hautes sont expliquées, ce qui permet de mettre en lumière des compréhensions différentes du travail à faire. Le processus est répété jusqu’à ce que l’équipe arrive à un consensus.

Mesurer le Rythme : La Vélocité

La vélocité est une mesure de la quantité de travail (exprimée en « points » d’effort issus du Planning Poker) que l’équipe de développement est capable de réaliser au cours d’un sprint. Il ne s’agit pas d’un indicateur de performance à comparer entre les équipes, mais d’un outil de planification interne. En se basant sur la vélocité moyenne des sprints précédents, l’équipe peut prévoir de manière plus réaliste la quantité de travail qu’elle peut embarquer dans les sprints futurs.

Suivre l’Avancement : Le Burndown Chart

Le Sprint Burndown Chart est un graphique simple qui montre l’évolution du « reste à faire » (en points ou en heures) jour après jour au cours d’un sprint. Il permet à l’équipe de visualiser en un coup d’œil son avancement par rapport à son objectif. Si la courbe du « reste à faire » ne descend pas comme prévu, c’est un signal pour l’équipe qu’elle doit s’adapter pour atteindre son but. Il est crucial de noter que c’est un outil pour l’équipe, destiné à favoriser son auto-organisation, et non un outil de reporting pour le management.

Ces outils pratiques ne sont pas des fins en soi, mais des moyens pour soutenir la transparence, la collaboration et l’adaptation continue, qui sont au cœur de la philosophie agile.

Conclusion : Plus qu’une Méthode, un État d’Esprit

Au terme de ce parcours, il est essentiel de retenir que l’agilité est bien plus qu’un ensemble de méthodes, de rituels et d’outils. C’est avant tout un changement de culture et d’état d’esprit (mindset). Adopter l’agilité, c’est embrasser des concepts comme l’auto-organisation des équipes, la confiance mutuelle, le courage de s’adapter et un engagement profond envers l’amélioration continue.

Le succès d’une transformation agile ne se mesure pas à la rigueur avec laquelle les rituels sont appliqués, mais à l’adhésion sincère aux valeurs et principes du Manifeste. Cela implique un changement fondamental de perspective : passer d’une approche projet, focalisée sur la livraison d’un périmètre fixe dans un temps et un budget donnés, à une approche produit, centrée sur la maximisation continue de la valeur et de l’impact d’une solution vivante. Le plus grand défi est d’éviter le « faux agile » : une situation où une organisation adopte les pratiques en surface, mais conserve une culture de commandement et de contrôle, exploitant les personnes au lieu de les responsabiliser. La véritable agilité met l’humain au cœur du système pour libérer la créativité et générer un maximum de valeur. La transformation d’une organisation entière est un chemin complexe, mais l’adopter avec authenticité est la clé pour prospérer dans un monde en perpétuel changement.

TP Agile – User Stories et Priorisation MoSCoW

Objectifs du TP

Découvrir comment exprimer les besoins d’un utilisateur en méthode agile.
Apprendre à rédiger des User Stories.
Savoir prioriser ces besoins avec la méthode MoSCoW.
Organiser les fonctionnalités dans des sprints comme en Scrum.

1. Contexte du TP

Vous êtes répartis en 4 groupes. Chaque groupe travaille sur un projet différent. Votre mission est de définir les besoins utilisateurs sous forme de User Stories, puis de les prioriser et de les organiser en sprints.

2. Contexte des projets (1 par groupe)

🔹 Groupe 1 – Application de gestion de bibliothèque

Une université souhaite développer une application permettant aux étudiants de rechercher, réserver et emprunter des livres. L’objectif est de faciliter l’accès aux ouvrages et de réduire les files d’attente à la bibliothèque.

Exemples de User Stories :

En tant qu’étudiant, je veux rechercher un livre par titre afin de le trouver rapidement.
En tant que bibliothécaire, je veux gérer les retours de livres afin de mettre à jour le stock.

🔹 Groupe 2 – Site e-commerce de vêtements

Une petite boutique veut créer un site en ligne pour vendre des vêtements et accessoires. Le site doit permettre aux clients de parcourir le catalogue, gérer un panier et finaliser une commande en ligne.

Exemples de User Stories :

En tant que client, je veux ajouter un produit au panier afin de préparer mon achat.
En tant que client, je veux recevoir un email de confirmation afin de garder une preuve de mon achat.

🔹 Groupe 3 – Application mobile de covoiturage

Une start-up veut développer une application mobile pour mettre en relation des conducteurs et des passagers pour partager des trajets. L’objectif est de réduire les coûts et de favoriser la mobilité durable.

Exemples de User Stories :

En tant que passager, je veux rechercher un trajet afin de trouver un conducteur qui va dans ma direction.
En tant que conducteur, je veux publier une annonce de trajet afin de trouver des passagers.

🔹 Groupe 4 – Plateforme de gestion d’événements

Une association souhaite une plateforme en ligne pour organiser ses événements (conférences, concerts, ateliers). Les utilisateurs doivent pouvoir consulter le programme, s’inscrire aux événements et recevoir des notifications.

Exemples de User Stories :

En tant qu’utilisateur, je veux consulter le programme afin de choisir les événements qui m’intéressent.
En tant qu’organisateur, je veux gérer les inscriptions afin de suivre le nombre de participants.

3. Travail à réaliser

Étape 1 – Rédiger des User Stories

Travaillez en groupe.
Rédigez entre 5 et 8 User Stories (autre que ceux des exemples) en utilisant le format :

En tant que [utilisateur], je veux [fonctionnalité], afin de [bénéfice/valeur]

Conseils :

Soyez clairs et concis.
Évitez le jargon technique.
Pensez toujours du point de vue de l’utilisateur.

Étape 2 – Mise en commun

Chaque groupe présente 1 ou 2 User Stories à la classe.
Discussion collective :
- La User Story est-elle claire ?
- Est-elle pertinente ?
- Peut-on l’améliorer ?

Étape 3 – Prioriser avec MoSCoW

Classez vos User Stories dans 4 catégories :

Must have : indispensable, obligatoire.
Should have : important, mais pas vital.
Could have : optionnel, valeur ajoutée.
Won’t have (for now) : non retenu pour l’instant.

Justifiez vos choix :

Pourquoi cette fonctionnalité est-elle un “Must” ?
Quelle valeur métier apporte-t-elle ?

Étape 4 – Simulation de Sprint Planning

Organisez vos User Stories priorisées en sprints (sur tableau, post-its ou Miro) :
- Sprint 1 = Must.
- Sprint 2 = Should.
- Sprint 3 (ou backlog futur) = Could.
Les Won’t restent de côté.

Vérifiez :

Est-ce que le Sprint 1 est réalisable rapidement ?
Peut-on livrer une première version utilisable du produit ?
Certaines stories manquent-elles de détails ?

Étape 5 – Restitution finale

Exemple de backlog pour une application mobile de suivi sportif :

ID	User Story	Priorité (MoSCoW)	Sprint prévu
US1	En tant qu’utilisateur, je veux créer un compte afin de sauvegarder mes entraînements.	Must	Sprint 1
US2	En tant qu’utilisateur, je veux enregistrer la durée et la distance de mon jogging afin de suivre mes performances.	Must	Sprint 1
US3	En tant qu’utilisateur, je veux consulter un tableau de bord afin de voir l’évolution de mes progrès.	Must	Sprint 1
US4	En tant qu’utilisateur, je veux définir des objectifs hebdomadaires afin de rester motivé.	Should	Sprint 2
US5	En tant qu’utilisateur, je veux recevoir une notification quand j’atteins mon objectif afin de célébrer mes progrès.	Should	Sprint 2
US6	En tant qu’utilisateur, je veux partager mes résultats avec mes amis afin de comparer mes performances.	Could	Sprint 3
US7	En tant qu’utilisateur, je veux connecter mon application à ma montre connectée afin d’importer automatiquement mes données.	Could	Sprint 3
US8	En tant qu’utilisateur, je veux voir des conseils personnalisés d’entraînement afin d’améliorer mes performances.	Won’t (for now)	—

- Sprint 1 : base indispensable → compte, enregistrement de séances, tableau de bord.
- Sprint 2 : fonctionnalités motivantes → objectifs, notifications.
- Sprint 3 : fonctionnalités sociales et techniques → partage, synchronisation avec objets connectés.
- Won’t : mis de côté (fonction avancée non prioritaire).

Chaque groupe présente son backlog priorisé et son organisation en sprints.
Comparaison des choix entre les groupes.
Discussion :
- Quels sont les points communs ?
- Quelles différences selon le type de projet ?

Étape 6 – Débrief

Questions de réflexion :

Qu’avez-vous trouvé facile ou difficile dans la rédaction des User Stories ?
Est-il simple de décider des priorités avec MoSCoW ?
En quoi cette méthode est-elle différente de la gestion de projet en cascade ?

Ce contenu est réservé aux membres du site. Si vous êtes un utilisateur existant, veuillez vous connecter. Les nouveaux utilisateurs peuvent s'inscrire ci-dessous.