GESTION DE PROJETS

INFORMATIQUES

IAI-TOGO
ENSEIGNANT : AMEVOR
CONTACT : 91259337 ANNÉE SCOLAIRE : 2022-2023
Email : kjamevor@gmail.com AUDITEURS : ETUDIANTS GLSI
4. LA MÉTHODE SCRUM

2
4.0. OBJECTIFS

❑ Qu’est-ce que la méthode SCRUM (Définition, historique…)

❑ Les trois piliers de la méthode SCRUM

❑ Les caractéristiques d’une équipe SCRUM (Le Product Owner (PO),

l’équipe de développement, le SCRUM Master)

❑ Le Product Backlog

❑ Les évènements SCRUM (Sprint Planning, les mêlées quotidiennes, la

rétrospective de Sprint, les phases de tests en SCRUM)

❑ Les commandements du SCRUM Master

3
4.1. DÉFINITION

Cadre de travail permettant de répondre à des problèmes

complexes et changeants, tout en livrant de manière
productive et créative des produits de la plus grande valeur
possible.
❑ Léger
❑ Simple à comprendre
❑ Difficile à maîtriser

4
4.2. QU’EST-CE QUE SCRUM?
❑ Utilisé depuis le début des années 1990 pour gérer le développement de
produits complexes.
❑ C’est un recueil de bonnes pratiques pour l’application de divers
procédés et techniques de développement.
❑ Scrum se compose de plusieurs éléments que sont :
➢ L’Équipe Scrum et ses rôles associés
➢ Les événements
➢ Les artéfacts
➢ Les règles.
❑ Les règles de Scrum sont les modalités qui lient événements, rôles et
artefacts entre eux et qui vont leur permettre de se dérouler de la
meilleure des manières possibles. 5
4.2. QU’EST-CE QUE SCRUM?
❑ Scrum se base sur la théorie du contrôle empirique de processus, ou
l’empirisme.
❑ L’empirisme soutient que les connaissances proviennent de l’expérience
et d’une prise de décision basée sur des faits connus.
❑ Scrum utilise une approche itérative et incrémentale pour optimiser la
prédictibilité et pour contrôler le risque.
❑ Trois piliers soutiennent l’implémentation d’un contrôle empirique de
processus :
➢ La transparence
➢ L’inspection
➢ L’adaptation.
6
4.3. LES TROIS PILIERS : LA TRANSPARENCE
❑ Les aspects importants du processus doivent être visibles à ceux qui sont
responsables des retombées (mais aussi au niveau des autres membres de
l’équipe)
❑ La transparence requiert la définition d’un standard commun pour ces
aspects importants afin que les observateurs partagent une
compréhension commune de ce qui est observé.
❑ À titre d’exemple :
➢ Un langage commun décrivant le processus doit être partagé par tous les
participants.
➢ Ceux qui effectuent le travail et ceux qui en acceptent le résultat doivent
partager une définition commune de « Terminé ».

7
4.3. LES TROIS PILIERS : L’INSPECTION

❑ Les utilisateurs de Scrum doivent fréquemment inspecter

les artéfacts Scrum et l’état d’avancement par rapport à
un objectif de Sprint (Sprint Goal) afin de détecter les
écarts indésirables.
❑ La fréquence de ces inspections ne doit pas gêner le
travail en cours et elles doivent être bénéfiques
lorsqu’elles sont effectuées.
❑ C’est pourquoi elles doivent être faites de manière
diligente sur les lieux du travail (pas à distance) par les
personnes qualifiées
8
4.3. LES TROIS PILIERS : L’ADAPTATION
❑ Si un inspecteur détermine qu’un ou plusieurs aspects du processus
dérivent hors des limites acceptables, et que le produit qui en résulte sera
inacceptable, le processus ou le matériel utilisé par le processus doit être
ajusté.
❑ Un ajustement doit être fait dès que possible afin de minimiser le risque
d’autres dérives.
❑ Scrum prescrit quatre occasions formelles d’inspection et d’adaptation :
➢ Planification de Sprint (Sprint Planning)
➢ Mêlée quotidienne (Daily Scrum)
➢ Revue de Sprint (Sprint Review)
➢ Rétrospective de Sprint (Sprint Retrospective)
9
4.3. LES TROIS PILIERS : L’ADAPTATION

10
4.4. L’ÉQUIPE SCRUM (SCRUM TEAM)
❑ L’Équipe Scrum comprend :
➢ Un Scrum Master
➢ Un propriétaire de produit (Product Owner),
➢ Une Équipe de Développement (Development Team)

❑ L’idée est que les équipes Scrum (Scrum Teams) soient autoorganisées et
pluridisciplinaires.
❑ Les équipes auto-organisées choisissent la meilleure façon d’accomplir
leur travail au lieu d’être dirigées par des personnes externes à l’équipe.
❑ Les équipes pluridisciplinaires ont (normalement) toutes les compétences
nécessaires pour effectuer le travail sans dépendre de personnes
n’appartenant pas à l’équipe.
11
4.4. L’ÉQUIPE SCRUM (SCRUM TEAM)

12
 LE PRODUCT OWNER
❑ Le Product Owner est responsable de maximiser la valeur du produit et du
travail de l’Équipe de Développement.
❑ Le Product Owner est la seule personne responsable de gérer le carnet
de produit (Product Backlog) :
➢ Exprimer clairement les items du Product Backlog ;
➢ Ordonner les items du Product Backlog pour mieux réaliser les objectifs et
missions ;
➢ Optimiser la valeur du travail effectué par l’Équipe de Développement ;
➢ S’assurer que le Product Backlog est visible, transparent, et clair pour tous, et
qu’il montre ce sur quoi l’Équipe de Développement travaillera
prochainement ;
➢ S’assurer que l’Équipe de Développement comprend adéquatement les items
du Product Backlog 13
 LE PRODUCT OWNER
❖ Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer
à l’Équipe de Développement. Toutefois, le Product Owner demeure responsable de
ces dernières.
❖ Le Product Owner est une personne, et non un comité. Il peut représenter les désirs
d’un comité dans le Product Backlog, mais ceux qui veulent changer la priorité d’un
item du Product Backlog doivent d’abord consulter le Product Owner.
❖ Tous les intervenants de l’entreprise doivent respecter ses décisions.
❖ Les décisions du Product Owner sont visibles dans le contenu et l’ordonnancement du
Product Backlog. Nul n’est permis de demander à l’Équipe de Développement de
travailler à partir d’un autre ensemble de besoins, et il n’est pas permis à l’Équipe de
Développement de suivre les instructions d’une autre personne.

14
 LE PRODUCT BACKLOG
❑ Le Backlog de produit est en gros une liste priorisée d'exigences, d'histoires, de caractéristiques ou
autre.

❑ Chaque « histoire » possède les éléments suivants :

➢ ID : identifiant unique
➢ NOM : par exemple Voir l’historique des transactions
➢ Importance : importance attribuée par le product owner (plus le nombre est élevé, et plus
l’histoire est importante)
➢ Estimation initiale : l'évaluation initiale de l'équipe sur la quantité de travail qui est nécessaire pour
implémenter cette histoire par rapport aux autres histoires. L'unité est les points d'histoire et
correspond habituellement à peu près à des « jours-hommes idéaux »
➢ Comment le démontrer : une description succincte de comment cette histoire sera démontrée à
la démo de fin d'itération. «Authentification, cliquez sur « transactions ». Faire un dépôt. Revenir
aux transactions, vérifier que le nouveau dépôt apparaît.».

15
EXEMPLE DE PRODUCT BACKLOG

16
EXEMPLE DE PRODUCT BACKLOG

17
 L’ÉQUIPE DE DÉVELOPPEMENT

❑ Ensemble de professionnels qui vont livrer à chaque Sprint un

incrément et une version potentiellement livrable du produit.
❑ Gère elle-même son propre travail => comment? A quelle
heure?

❑ Taille optimale de l’équipe de développement : entre 3 et 8

personnes

18
 L’ÉQUIPE DE DÉVELOPPEMENT : CARACTÉRISTIQUES
❑ Elle est auto-organisée. Nul (même pas le Scrum Master) n’indique à l’Équipe de
Développement comment transformer les items du Product Backlog en incréments de
fonctionnalités potentiellement livrables.

❑ Elle est pluridisciplinaire

❑ Scrum ne reconnaît aucun titre aux membres de l’Équipe de Développement autre que
celui de développeur, indépendamment du travail effectué par cette personne ;
❑ Scrum ne reconnaît pas d’équipes à l’intérieur de l’Équipe de Développement
indépendamment des domaines spécifiques qui doivent être couverts tels que l’exécution
de tests ou l’analyse fonctionnelle;
❑ Les membres de l’Équipe de Développement peuvent détenir individuellement des
compétences et des centres d’intérêt spécifiques, mais c’est l’Équipe de Développement
dans son ensemble qui est tenue responsable.

19
 SCRUM MASTER
❑ Le Scrum Master est responsable de s’assurer que Scrum est compris et mis en œuvre.
• L’Équipe Scrum doit adhérer à la théorie, aux pratiques et aux règles.
• Le Scrum Master aide ceux qui sont externes à l’Équipe Scrum à comprendre quelles
sont les interactions bénéfiques ou non avec l’Équipe Scrum.
❑ Le Scrum Master sert le Product Owner de plusieurs façons :
• Trouver des techniques de gestion efficace du Product Backlog
• Aider l’Équipe Scrum à comprendre la nécessité d’avoir des items de Product
Backlog clairs et concis ;
• Comprendre la planification de produit dans un contexte empirique
• S’assurer que le Product Owner sait comment constituer le Product Backlog pour
maximiser la valeur du produit ;
• Comprendre et mettre en œuvre l’agilité ;
• Faciliter les événements Scrum lorsque requis ou demandé.

20
 SCRUM MASTER (SUITE)
❑ Le Scrum Master au service de l’Équipe de Développement :
• Aider l’Équipe de Développement à développer son auto-organisation et sa
pluridisciplinarité ;
• Aider l’Équipe de Développement à créer des produits de grande valeur ;
• Éliminer les obstacles au progrès de l’Équipe de Développement ;
• Faciliter les événements Scrum lorsque demandé ou requis ;
• Accompagner l’Équipe de Développement dans les environnements organisationnels
où Scrum n’est pas encore entièrement adopté et compris.
❑ Le Scrum Master rend service à l’organisation de plusieurs façons :
• Accompagner l’organisation dans son adoption de Scrum ;
• Planifier les mises en œuvre de Scrum dans l’organisation ;
• Aider les employés et parties prenantes à comprendre et à mettre en œuvre Scrum et
le développement empirique de produit ;
• Causer des changements qui augmentent la productivité de l’Équipe Scrum ;
• Collaborer avec d’autres Scrum Master pour améliorer l’efficacité de l’utilisation de
Scrum dans l’organisation. 21
 LES ÉVÈNEMENTS
❑ Les événements prescrits par Scrum créent de la régularité et
minimisent la nécessité d’autres réunions non prévues.
❑ Chaque événement a une durée maximale et une fois le Sprint
commencé, sa durée est fixe et ne peut être écourtée ou
prolongée.
❑ Mis à part le Sprint, qui contient tous les autres événements,
chaque événement de Scrum est une occasion d’inspecter et
d’adapter quelque chose.

❑ Permettre transparence et inspection.

22
LES ÉVÈNEMENTS

23
 LE PLANNING DE SPRINT
❑ Le planning de sprint est une réunion critique, probablement l'événement
le plus important dans Scrum.
❑ Concrètement, à la fin de cette réunion on doit avoir :
• Un but pour le sprint.
• Une liste des membres d'équipe (et de leur niveau d'engagement, si ce
n'est pas 100%).
• Un backlog de sprint (= une liste des histoires incluses dans le sprint).
• Une date bien définie pour la démonstration.
• Une heure et un lieu bien définis pour la mêlée quotidienne.

24
 LE PLANNING DE SPRINT (SUITE)
❑ Prévoir systématique un ordre du jour pour la réunion du SPRINT planning.
❑ Par exemple :
• Réunion de planning de sprint : 13:00 - 17:00 (10 minutes de pause toutes les heures)
• 13:00 - 13:30. Le directeur de produit décrit le but du sprint et résume le backlog de
produit. Le lieu, la date et l'heure de la démonstration sont fixés.
• 13:30 - 15:00. L'équipe fait les estimations en temps, et décompose les éléments selon
les besoins. Le directeur de produit met à jour les niveaux d'importance selon les
besoins. Les éléments sont clarifiés. « Comment démontrer » est explicité pour chacun
des éléments les plus importants.
• 15:00 - 16:00. L'équipe sélectionne les histoires à inclure dans le sprint. Elle fait les
calculs de vélocité pour se confronter à la réalité.
• 16:00 - 17:00. On choisit le lieu et l'heure pour la mêlée quotidienne (s'ils sont différents
du dernier sprint). On poursuit la décomposition des histoires en tâches.

25
LE PLANNING DE SPRINT - BACKLOG

L'une des activités

principales de la réunion
de planning de sprint est
de décider quelles
histoires inclure dans le
sprint. Plus précisément,
quelles histoires du
backlog de produit il
faut copier dans le
backlog de sprint.
26
 LE PLANNING DE SPRINT - BACKLOG
❑ La plupart des réunions de planification de sprint se déroulent en se basant sur les
histoires du backlog de produit. On les estime, on redéfinit leur priorités, on les clarifie, on
les découpe, etc...

❑ Comment faisons-nous ça en pratique ?

❑ Les estimations en temps sont généralement plus facile à faire (et plus précis) si une
histoire est découpée en tâches.
❑ Physiquement, nous faisons cela en ajoutant de petits post-its sous chaque histoire,
chaque post-it
correspondant à une tâche de cette histoire.

27
LE PLANNING DE SPRINT - BACKLOG

28
 LE PLANNING DE SPRINT - BACKLOG
❑ Les histoires ne devraient pas être trop petites ou trop grosses (en termes
d'estimations)
❑ Il est presque toujours possible de couper une grosse histoire en plusieurs
histoires plus petites.
❑ Normalement nous nous efforçons d'avoir des histoires pesant de 2 à 8
jours-hommes. Notre vélocité est habituellement autour de 40-60 pour
une équipe typique, ce qui nous donne quelque chose comme environ 10
histoires par sprint. Quelquefois cela descend à 5 et quelquefois cela
monte à 15. Cela reste un nombre de fiches cartonnées gérable.

29
 LE PLANNING DE SPRINT - RÉSUMÉ

1 : Un but de sprint et une date de démo.

2 : Liste des histoires que l'équipe a acceptées.
3 : Estimations remplies pour chaque histoire.
4 : « Comment démontrer » rempli pour chaque histoire du sprint.
5 : Les calculs de vélocité et de ressources, pour vérifier la vraisemblance de votre
plan de sprint.
6 : une heure et un lieu bien définis pour la mêlée quotidienne.

7 : Les histoires découpées en tâches.

30
 LES MÊLÉES QUOTIDIENNES
❑ La mêlée quotidienne (Daily Scrum) est un événement limité à 15 minutes au cours duquel
l’Équipe de Développement synchronise ses activités et crée un plan pour les prochaines 24
heures.
❑ Pour ce faire, l’équipe inspecte le travail effectué depuis la dernière mêlée quotidienne et
envisage le travail qui peut être réalisé d’ici à la prochaine.
❑ La mêlée a lieu tous les jours à la même heure et au même endroit afin de réduire la
complexité. Durant la réunion, les membres de l’Équipe de Développement décrivent :
• Ce qu’ils ont réalisé hier qui a aidé l’Équipe de Développement à atteindre l’objectif du
Sprint
• Ce qu’ils réaliseront aujourd’hui pour aider l’Équipe de Développement à atteindre
l’objectif du Sprint ;
• Les obstacles qui, selon eux, les empêchent ou empêche l’Équipe de Développement
d’atteindre l’objectif du Sprint.

31
 LES MÊLÉES QUOTIDIENNES
❑ Pendant que chaque personne décrit ce qu'elle a fait hier et ce qu'elle va faire aujourd'hui,
elle déplace les post-its sur le tableau des tâches.
❑ Quand elle décrit une tâche non planifiée, elle colle un post-it pour ça.

❑ Quand la personne met à jour son estimation de temps, elle écrit la nouvelle estimation
sur le post-it et raye l'ancienne valeur.

32
 EVOLUTION DU BACKLOG DE SPRINT
Voici le format le plus efficace pour les backlogs de sprint : un tableau des tâches sur le mur !

33
EVOLUTION DU BACKLOG DE SPRINT

34
 EVOLUTION DU BACKLOG DE SPRINT
Après la première mêlée quotidienne, le tableau des tâches devrait ressembler à ça :

35
 EVOLUTION DU BACKLOG DE SPRINT
Après quelques jours :

36
LE BURNDOWN CHART

Cette courbe montre que :

• Le premier jour du sprint, le 1er août, l'équipe a estimé
qu'il y avait approximativement 70 points d'histoire de
reste à faire. C'est en fait la vélocité estimée du sprint
entier.
• Le 16 août l'équipe estime qu'il y a approximativement
15 points d'histoire de reste à faire. La ligne de
tendance en pointillés montre qu'ils sont sur la bonne
voie, c'est-à-dire qu'à ce rythme ils auront tout fini d'ici
la fin du sprint.
• Les weekends sont exclus

37
LES PROBLÈMES POSSIBLES DU TABLEAU DES TÂCHES

38
LES PROBLÈMES POSSIBLES DU TABLEAU DES TÂCHES

39
LES PROBLÈMES POSSIBLES DU TABLEAU DES TÂCHES

40
LES PROBLÈMES POSSIBLES DU TABLEAU DES TÂCHES

41
 LES RÉTROSPECTIVES DE SPRINT
Format :

❑ 1 à 3 heures selon le volume de discussions qui est anticipé.

❑ Participants : le product owner, l'équipe complète, et le scrum master.
❑ Pièce fermée, un coin avec un canapé confortable, un patio, ou une place du même style. Du moment que
nous pouvons discuter sans être dérangés.
❑ Quelqu'un est désigné comme secrétaire.
❑ Le Scrum master montre le sprint backlog et, avec l'aide de l'équipe, résume le sprint. Les évènements et
décisions importantes, etc.
❑ «Tours de table». Chaque personne a une chance de dire, sans être interrompu, ce qu'elle pense être bien,
ce qu'elle pense qui peut être mieux, et ce qu'elle pense qui devrait être différent pour le prochain sprint.

❑ Nous comparons la vélocité estimée et la vélocité effective.

42
LES RÉTROSPECTIVES DE SPRINT

43
 LES RÉTROSPECTIVES DE SPRINT
❑ Bien : Si nous pouvions refaire le même sprint, nous ferions ces choses exactement
pareil.
❑ Peut mieux faire : Si nous pouvions refaire le même sprint, nous ferions ces choses
différemment.

❑ Améliorations : Idées concrètes pour s'améliorer dans le futur.

44
 LES RÉTROSPECTIVES DE SPRINT - EXEMPLES
❑ « Nous devrions passer plus de temps à décomposer les histoires en sous-éléments et
tâches »
❑Actions typiques : aucune. L'équipe règlera ça probablement d'elle-même à la prochaine
réunion de planification de sprint. Si cela se répète, prévoyez plus de temps pour le sprint
planning.
❑« Trop de dérangements extérieurs »
❑Demandez à l'équipe de bien noter les dérangements pendant le prochain sprint. Qui les
dérange, combien de temps. Ca aidera à résoudre le problème plus tard.
❑Demandez à l'équipe d'essayer de rediriger tous les dérangements vers le Scrum master ou
le Product Owner.
❑Demandez à l'équipe de désigner une personne comme « gardien », tous les dérangements
sont redirigés vers lui, ainsi le reste de l'équipe peut se concentrer. Ce peut être le Scrum
master ou quelqu'un à tour de rôle.
45
 LES RÉTROSPECTIVES DE SPRINT - EXEMPLES
❑ « Nous nous sommes trop engagés et nous n'avons terminé que la moitié du
travail »
• Actions typiques : aucune. L'équipe ne s'engagera probablement pas trop au
prochain sprint. Ou du moins pas autant que cette fois.
❑« Notre bureau est trop bruyant et bordélique »
➢ Essayez de créer un meilleur environnement, ou déménagez l'équipe. Louez une
chambre d'hôtel. Ce que vous voulez.
➢ Si ce n'est pas possible, dîtes à l'équipe de réduire leur facteur de focalisation, et
indiquez clairement que c'est à cause du bruit et du désordre. En espérant que le
directeur de produit
commencera à harceler la direction à ce sujet.

46
 LES COMMANDEMENTS DE SCRUM MASTER
❑ Envoyer un e-mail à chacun pour annoncer qu’un nouveau Sprint a démarré. Y inclure le but du
Sprint ainsi qu'un lien vers la page d'information du Sprint.
❑ Mettre à jour le document des statistiques du Sprint. Ajouter votre vélocité estimée, la taille de
l'équipe, la durée du Sprint, etc.
❑ S'assurer que la Mêlée quotidienne commence et finit à l'heure.
❑ S'assurer que les histoires sont ajoutées/supprimées du Sprint Backlog autant que nécessaire pour respecter le planning du
Sprint (et que le product owner en est informé).0
❑ S'assurer que l'équipe tient le Backlog et le Burndown du Sprint à jour.
❑ S'assurer que les problèmes/obstacles sont résolus ou communiqués au directeur de produit et/ou au responsable du
développement.
❑ Organisez une démonstration publique à l'issue du Sprint (Tout le monde devrait être informé de la tenue de la démonstration
un ou deux jours avant.)
❑ Organisez une rétrospective du Sprint en présence de toute l'équipe et du directeur de produit. Invitez également le
responsable du développement afin qu'il puisse propager les leçons apprises.
❑ Mettez à jour le document des statistiques du Sprint. Ajoutez-y la vélocité effective ainsi que les points clés de la rétrospective.

47