Chapitre 616 minDébutant
Méthode agile et Scrum : rôles, événements, artefacts
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- résumer les valeurs du Manifeste agile ;
- dire qui fait quoi dans une Scrum Team ;
- décrire les cinq événements de Scrum et leur durée maximale ;
- expliquer les trois artefacts et leurs engagements.
4 exercices corrigés1 schéma
Une méthode agile mène un projet par itérations courtes de quelques semaines : à chaque itération, l'équipe livre une partie utilisable du produit, la montre au client et ajuste la suite selon ses retours, au lieu de tout planifier au départ et de livrer une seule fois à la fin. Scrum est le cadre agile le plus répandu : une petite équipe avec trois responsabilités (Product Owner, Scrum Master, Developers), des cycles appelés sprints, cinq événements et trois artefacts. Ce chapitre présente les valeurs agiles, puis Scrum tel que le définit sa référence officielle, le Scrum Guide de novembre 2020, toujours en vigueur.
Le Manifeste agile
En février 2001, dix-sept praticiens du développement logiciel se réunissent dans l'Utah et publient le Manifeste pour le développement agile de logiciels. Il tient en quatre valeurs, chacune de la forme « nous valorisons davantage A que B » :
- les individus et leurs interactions plus que les processus et les outils ;
- des logiciels opérationnels plus qu'une documentation exhaustive ;
- la collaboration avec les clients plus que la négociation contractuelle ;
- l'adaptation au changement plus que le suivi d'un plan.
Le manifeste précise que les éléments de droite gardent de la valeur : l'agilité n'interdit ni la documentation, ni les contrats, ni les plans. Elle dit ce qui l'emporte quand il faut choisir. Douze principes complètent ces valeurs ; retiens-en l'esprit : livrer souvent un logiciel qui fonctionne (toutes les quelques semaines), accepter les changements de besoin même tard, faire travailler ensemble chaque jour les gens du métier et les développeurs, mesurer l'avancement par le logiciel opérationnel, tenir un rythme soutenable, et s'arrêter régulièrement pour s'améliorer.
Itératif et incrémental
Deux mots résument la mécanique agile. Incrémental : le produit grandit par morceaux, chacun utilisable. Itératif : on revient sur ce qui existe pour l'améliorer selon les retours. Pour Prêt'Matos, l'équipe ne livre pas « la base de données » au sprint 1 et « les écrans » au sprint 3 : au sprint 1, un salarié peut déjà se connecter et voir le catalogue ; au sprint 2, il réserve ; au sprint 3, il reçoit un rappel. À chaque fin de sprint, Nadia Faure essaie le produit et dit ce qu'il faut changer.
| Approche prédictive | Approche agile | |
|---|---|---|
| Planification | Tout au début, en détail | En continu : détaillée pour le sprint, grossière au-delà |
| Livraison | Une fois, à la fin | À chaque itération, un incrément utilisable |
| Retour du client | À la recette | À chaque fin d'itération |
| Changement de besoin | Coûteux, géré par avenant | Attendu, intégré au backlog |
| Ce qui est fixé | Le périmètre ; on estime le temps et le coût | Le temps et l'équipe ; c'est le périmètre qui s'ajuste |
| Mesure de l'avancement | Les tâches terminées, le pourcentage du planning | Le produit qui fonctionne |
Scrum en une phrase
Le Scrum Guide, écrit par les créateurs de Scrum, Ken Schwaber et Jeff Sutherland, le définit ainsi : « Scrum est un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. » Concrètement, le Product Owner ordonne le travail à faire dans le Product Backlog ; la Scrum Team en transforme une sélection en un incrément de valeur pendant un sprint ; l'équipe et les parties prenantes inspectent le résultat et s'adaptent pour le sprint suivant ; et on recommence.
Scrum repose sur l'empirisme : on décide à partir de ce qu'on observe. Trois piliers le font tenir :
- la transparence : le travail et son avancement sont visibles de tous ceux qui le font et de ceux qui le reçoivent ;
- l'inspection : on examine souvent le produit et la progression vers l'objectif, pour repérer les écarts ;
- l'adaptation : dès qu'un écart est repéré, on ajuste le produit ou la façon de travailler.
Le guide ajoute cinq valeurs que l'équipe s'efforce de vivre : engagement, focus, ouverture, respect et courage.
La Scrum Team et ses trois responsabilités
La Scrum Team est une petite équipe, en général de dix personnes au plus, sans sous-équipes ni hiérarchie, entièrement tournée vers un objectif : l'Objectif de Produit. Elle est pluridisciplinaire (elle a toutes les compétences pour livrer) et autogérée (elle décide en interne qui fait quoi, quand et comment). Le guide y distingue trois responsabilités.
| Responsabilité | De quoi il est redevable | Ce qu'il ne fait pas |
|---|---|---|
| Product Owner | Maximiser la valeur du produit ; formuler l'Objectif de Produit ; créer, ordonner et rendre transparent le Product Backlog | Il ne dit pas aux Developers comment travailler ; ce n'est pas un comité, c'est une seule personne |
| Scrum Master | La mise en place de Scrum et l'efficacité de l'équipe : il accompagne l'équipe dans l'autogestion, fait lever les obstacles, veille à ce que les événements aient lieu et respectent leur durée, aide le Product Owner à gérer le backlog | Ce n'est ni un chef de projet ni un supérieur hiérarchique : c'est un leader « au service » de l'équipe |
| Developers | Créer le Sprint Backlog, respecter la Definition of Done, adapter leur plan chaque jour vers l'Objectif de Sprint, se tenir mutuellement responsables | Ils ne choisissent pas seuls l'ordre des priorités du produit : c'est le Product Owner |
Le mot « Developers » désigne toute personne qui construit l'incrément : développeurs, mais aussi testeurs, administrateurs, designers. Dans Prêt'Matos, les Developers sont Lina, Yanis et Moussa ; Nadia Faure est Product Owner ; Yanis tient aussi le rôle de Scrum Master, ce qui arrive souvent dans les petites équipes.
Les cinq événements
Chaque événement est une occasion formelle d'inspecter et d'adapter. Le guide fixe une durée maximale à chacun, pour un sprint d'un mois ; pour un sprint plus court, l'événement est « généralement plus court ».
| Événement | Quand | Durée maximale (sprint d'un mois) | Qui | Ce qu'on y fait |
|---|---|---|---|---|
| Sprint | En continu : un sprint commence dès la fin du précédent | Un mois ou moins, durée fixe | Toute la Scrum Team | Le conteneur de tous les autres événements ; on y transforme des idées en un incrément |
| Sprint Planning | Au début du sprint | 8 heures | Toute la Scrum Team, et des invités si besoin | Pourquoi ce sprint est-il important (l'Objectif de Sprint) ? Que peut-on faire ? Comment le travail sera-t-il réalisé ? |
| Daily Scrum | Chaque jour ouvré, même heure, même lieu | 15 minutes | Les Developers | Inspecter la progression vers l'Objectif de Sprint et adapter le plan de la journée |
| Sprint Review | À la fin du sprint, avant la rétrospective | 4 heures | La Scrum Team et les principales parties prenantes | Inspecter le résultat du sprint, discuter de la suite, ajuster le Product Backlog |
| Sprint Retrospective | Elle clôt le sprint | 3 heures | La Scrum Team | Examiner comment le sprint s'est passé (personnes, outils, méthode, Definition of Done) et choisir des améliorations |
Quelques précisions qui tombent souvent :
- Le Daily Scrum n'est pas une réunion de compte rendu au chef. Les Developers se coordonnent entre eux. Le format des trois questions (qu'ai-je fait hier, que vais-je faire aujourd'hui, qu'est-ce qui me bloque) a été retiré du guide en 2020 : il reste un format possible, mais l'équipe choisit la structure qu'elle veut, du moment qu'elle produit un plan pour la journée.
- La Sprint Review n'est pas une démonstration figée. C'est une séance de travail : on montre ce qui fonctionne, on recueille les réactions et on modifie le backlog en conséquence.
- La rétrospective porte sur la façon de travailler, la review sur le produit. La première améliore l'équipe, la seconde améliore ce qu'elle construit.
- Seul le Product Owner peut annuler un sprint, si l'Objectif de Sprint devient obsolète.
Le guide ne fait pas de l'affinement du Product Backlog un événement mais une activité continue : découper les éléments, les préciser, les estimer. Beaucoup d'équipes y consacrent une séance régulière en milieu de sprint.
Les trois artefacts et leurs engagements
Un artefact représente du travail ou de la valeur, et le rend visible. Depuis 2020, chacun est associé à un engagement qui dit vers quoi il tend.
| Artefact | Ce que c'est | Qui en est responsable | Engagement |
|---|---|---|---|
| Product Backlog | La liste ordonnée et évolutive de tout ce qui est nécessaire pour améliorer le produit ; l'unique source du travail de l'équipe | Le Product Owner | L'Objectif de Produit : l'état futur visé, la cible à long terme |
| Sprint Backlog | L'Objectif de Sprint (le pourquoi), les éléments choisis pour le sprint (le quoi) et le plan pour les réaliser (le comment) ; mis à jour tout au long du sprint | Les Developers | L'Objectif de Sprint : l'unique but du sprint |
| Increment | Un pas concret et utilisable vers l'Objectif de Produit, qui s'ajoute aux incréments précédents | Toute la Scrum Team | La Definition of Done : la description formelle de l'état d'un incrément qui satisfait les exigences de qualité |
Un élément qui ne respecte pas la Definition of Done ne fait pas partie de l'incrément : il n'est ni livré ni présenté à la Sprint Review, et il retourne dans le Product Backlog. Voici la Definition of Done de Prêt'Matos :
- le code est relu et fusionné par une pull request ;
- les tests automatisés passent dans le pipeline d'intégration continue ;
- la fonctionnalité est déployée sur le serveur de recette ;
- les critères d'acceptation sont vérifiés par la Product Owner ;
- la documentation utilisateur est mise à jour si l'écran a changé.
Les deux premières lignes s'appuient sur les pull requests et l'intégration continue du cours Git.
Un sprint de Prêt'Matos, du premier au dernier jour
L'équipe a choisi des sprints de deux semaines (dix jours ouvrés). Voici le sprint 2.
- Lundi, jour 1, Sprint Planning (2 heures). Nadia rappelle l'Objectif de Produit : « les salariés réservent eux-mêmes le matériel, sans tableur ni courriel, d'ici fin mars ». Elle propose les éléments en tête du backlog. Les Developers en retiennent trois, pour 13 points, alors qu'ils n'en ont terminé que 8 au sprint 1 : un pari optimiste, qu'on retrouvera sur le burndown du chapitre 10 (la vélocité). Ensemble, ils écrivent l'Objectif de Sprint : « un salarié peut réserver un matériel et la logistique enregistre sa sortie et son retour ». Les Developers découpent chaque élément en tâches d'une journée au plus.
- Chaque matin à 9 h 15, Daily Scrum (15 minutes, debout devant le tableau). Jour 4 : Lina signale qu'elle attend un accès au serveur de recette ; Moussa le lui donne dans l'heure. Yanis, en tant que Scrum Master, veille seulement à ce que la réunion reste courte et utile.
- Mercredi, jour 8, affinement (1 heure). L'équipe et Nadia précisent et estiment les éléments du sprint suivant.
- Vendredi, jour 10, Sprint Review (1 heure). Nadia et deux salariés essaient la réservation sur le serveur de recette. Ils demandent de pouvoir prolonger un prêt : Nadia l'ajoute au backlog. L'élément « voir et annuler mes réservations » n'est pas terminé (il manque les tests) : il n'est pas présenté et retourne dans le backlog.
- Vendredi, jour 10, Sprint Retrospective (45 minutes). L'équipe constate que les revues de code s'accumulent le jeudi. Première amélioration : chaque pull request est relue dans la demi-journée, et cette règle est ajoutée au Sprint Backlog suivant. Deuxième amélioration : planifier autour de la vélocité observée plutôt que d'un rythme espéré.
Ce que Scrum ne dit pas
Le guide est volontairement incomplet. Beaucoup de pratiques qu'on associe à Scrum n'y figurent pas : les user stories, l'estimation en points, le planning poker, la vélocité, le burndown chart (cité comme une pratique possible parmi d'autres). Ce sont des pratiques complémentaires, très répandues, que le chapitre suivant présente. Retiens la nuance : si un sujet te demande « les rôles, événements et artefacts de Scrum », la réponse vient du guide ; « user story » et « vélocité » sont des outils que les équipes Scrum utilisent souvent.
Quand plusieurs équipes travaillent sur le même produit, elles partagent le même Objectif de Produit, le même Product Backlog et le même Product Owner ; des cadres comme LeSS ou SAFe organisent Scrum à grande échelle, mais ils dépassent le BTS.
Exercices
Exercice 1 sur 4 Qui décide ? Réussi À revoir
Pour chaque phrase entendue dans l'équipe Prêt'Matos, dis qui a la responsabilité de la décision : Product Owner, Scrum Master ou Developers.
- « On fait le rappel par courriel avant l'export CSV. »
- « Pour la réservation, on découpe en trois tâches : la table, l'API et l'écran. »
- « Je m'occupe d'obtenir l'accès au serveur de recette qui bloque Lina. »
- « Ce sprint, on ne peut pas prendre plus de 13 points. »
- « Les statistiques pour la direction passent en bas du backlog. »
Voir la réponseMasquer la réponse de l'exercice 1
- Product Owner : c'est l'ordre du backlog.
- Developers : c'est le comment.
- Scrum Master : il fait lever un obstacle (même si, dans les faits, c'est Moussa qui donne l'accès, le Scrum Master veille à ce que l'obstacle soit traité).
- Developers : ils sélectionnent ce qu'ils peuvent réaliser dans le sprint, en discutant avec le Product Owner.
- Product Owner : c'est encore l'ordre du backlog.
Tu avais trouvé ?
Exercice 2 sur 4 Quel événement ? Réussi À revoir
Nomme l'événement Scrum décrit, et sa durée maximale pour un sprint d'un mois.
- L'équipe se demande pourquoi les tests ont été faits au dernier moment et décide d'écrire les tests avec le code.
- La Product Owner et les utilisateurs essaient la nouvelle version et demandent une modification.
- Les Developers font le point devant le tableau et réorganisent leur journée.
- L'équipe fixe l'objectif des deux prochaines semaines et choisit les éléments du backlog.
Voir la réponseMasquer la réponse de l'exercice 2
- Sprint Retrospective, 3 heures au plus.
- Sprint Review, 4 heures au plus.
- Daily Scrum, 15 minutes.
- Sprint Planning, 8 heures au plus.
Tu avais trouvé ?
Exercice 3 sur 4 Repère les erreurs Réussi À revoir
Un étudiant décrit ainsi le fonctionnement de son équipe : « Notre chef de projet, le Scrum Master, distribue les tâches à chacun le lundi. Nos sprints durent deux semaines, mais quand on n'a pas fini, on rajoute quelques jours. Chaque matin, on fait un point d'une demi-heure où chacun explique au Scrum Master ce qu'il a fait. Le client voit l'application à la fin du projet, pendant la recette. » Relève quatre écarts avec Scrum et corrige-les.
Voir la réponseMasquer la réponse de l'exercice 3
- Le Scrum Master n'est pas un chef de projet et ne distribue pas les tâches : les Developers s'organisent eux-mêmes et créent leur Sprint Backlog.
- La durée d'un sprint est fixe : ce qui n'est pas terminé retourne au Product Backlog, on ne prolonge pas le sprint.
- Le Daily Scrum dure 15 minutes au plus et sert aux Developers à se coordonner entre eux, pas à rendre compte au Scrum Master.
- Le client (le Product Owner et les parties prenantes) voit le produit à chaque Sprint Review, pas seulement à la fin : c'est tout l'intérêt de l'approche.
Tu avais trouvé ?
Exercice 4 sur 4 Les engagements Réussi À revoir
- Associe chaque artefact à son engagement : Product Backlog, Sprint Backlog, Increment ; Definition of Done, Objectif de Produit, Objectif de Sprint.
- Rédige un Objectif de Sprint pour le sprint 3 de Prêt'Matos, qui contient le rappel par courriel la veille du retour, la liste des prêts en retard et l'export CSV de l'historique.
Voir la réponseMasquer la réponse de l'exercice 4
- Product Backlog → Objectif de Produit ; Sprint Backlog → Objectif de Sprint ; Increment → Definition of Done.
- Par exemple : « La logistique suit les retours sans tableur : les emprunteurs sont relancés la veille, les retards sont visibles d'un coup d'œil et l'historique s'exporte. » Un bon Objectif de Sprint dit pourquoi le sprint compte, en une phrase compréhensible par les parties prenantes, et non la liste des éléments.
Tu avais trouvé ?