Méthode Agile

Chapitre 4:La méthode Scrum

Auteur :
Mme Ines AGREBI

Année Universitaire 2021-2022 1

 Plan
1. Introduction
2. Contexte Scrum
3. Vue d ’ensemble Scrum
4. 10 pratiques de base Scrum
5. Scrum: Les rôles
6. Vision du produit et Produit Backlog

2
 Introduction
• Scrum ne se considère pas comme une méthode mais comme un
cadre méthodologique
• Le cadre méthodologique Scrum est de loin la méthode Agile la plus
utilisée dans le monde.
• Elle bénéficie aujourd'hui de nombreux retours d'expérience
Les conférences
Les communautés
Les formations
Les blogs
Les outils
....
3
 Contexte Scrum
• Un 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.

• Dans ce cadre de développement, des équipes multifonctionnelles

réalisent des produits de manière itérative et incrémentale.

4
 Contexte Scrum
• Scrum est généralement quantifié de simple, pragmatique,
transparent et empirique.

• Scrum ne couvre que les aspects de gestion de projet, c'est souvent la

méthode eXtreme Programming (XP) qui vient compléter le vide
laissé en matière de pratiques de développement.

• XP apporte ainsi les pratiques de programmation en binôme, de

développement piloté par les tests (TDD ou Test Driven
Development), intégration continue, ....
5
Vue d’ensemble Scrum

6
Vue d’ensemble Scrum

7
 Vue d’ensemble Scrum
• Processus itératif
 Itération plus longues que d’autres méthodologies (30 jours)
• Equipe auto-gérée
 Pas de processus rigide
 Le développement est adapté empiriquement
• Réunion debout quotidiennement
• Démonstrations du système après chaque itération
• Planification impliquant le client après chaque itération

8
 10 Pratique de base Scrum
1. Vision claire et partagée
2. Product Backlog entretenu
3. Product Backlog priorisé en fonction de la valeur métier
4. Items de backlog triés par l’équipe
5. Daily Scrums
6. Sprints non perturbés ni par le Management ni par le(s) client(s)
7. L’Equipe ne délivre que des items «terminés»
8. Revue de Sprint collaborative
9. Rétrospective concentrée sur l’amélioration du travail et du processus de
l’équipe et de l’organisation
10. Burndown Charts (graphiques de reste-à-faire)
9
Scrum: Les Rôles

10
 Scrum: Les Rôles
Scrum définit seulement 4 rôles :
oLe Product Owner
oL'Equipe de Développement
oLe Scrum Master
oChickens

11
 Rôles: Product Owner
Product Owner (PO)

oUn représentant du client

oCelui qui porte la vision du produit à réaliser et travaille en interaction avec
l‘équipe de développement. Il s'agit généralement d'un expert du domaine
métier du projet.
oLe Product Owner (Directeur/Responsable Produit) est chargé de :
• Construire le Product Backlog.
• Ordonnancer les tâches en fonction de leur importance métier
• Répondre aux questions de l‘équipe de développement.
• Valider/Rejeter une fonctionnalité.
• Prendre des décisions importantes en temps voulu.
12
 Rôles: Product Owner
Product Owner (PO)

•Il pilote le projet d’un point de vue métier

•Il communique une vision claire du produit et défini ses
caractéristiques
•Il accepte ou rejette le produit à la fin de chaque Sprint
•Il s’assure que l’Équipe se concentre sur les items du Backlog de plus
forte valeur ajoutée
•Il a le même objectif que l’Équipe
•Il est responsable du Retour sur Investissement et des livraisons.
13
 Rôles: Product Owner
Compétences du Product Owner

oBonne connaissance du domaine métier

oMaîtrise des techniques de définition de produit
oCapacité à prendre les décisions rapidement
oEsprit ouvert au changement
oAptitude à la négociation

14
 Rôles: Equipe de Développement
L’Equipe de Développement

oGénéralement composée de 7 personnes (+ ou -2 )

oPlurifonctionnelle: expertise nécessaire pour fournir une version du produit
potentiellement livrable a chaque Sprint (analyse, développement, test,
conception d'interfaces, BD, architecture, ...)
oDéveloppe le produit et fournit des idées au PO pour le rendre meilleur
oAuto organisée (autogérée) : grand degré d'autonomie et de responsabilité
oDécide des éléments à implémenter dans un Sprint (liste proposée par le
PO), et des moyens pour réaliser cet objectif
15
 Rôles: Equipe de Développement
L’Equipe de Développement

• Elle délivre le produit et elle est responsable de sa qualité

• Elle travaille avec les utilisateurs-finaux, le client, le Product Owner
pour comprendre les exigences-métier.
• Elle s’engage volontairement
• Elle travaille continuellement avec le Product Owner pour définir la
direction stratégique du Produit.

16
 Rôles: Equipe de Développement
L’Equipe de Développement

oPas de titre de spécialiste (analyste fonctionnel, DBA, team leader,

concepteur IHM,..)
oCompétences sur différents domaines d'aller là où le travail se trouve
oCapacité d'apprentissage (atouts et volonté de progresser sur d'autres
spécialités)

17
 Rôles: Scrum Master
Le Scrum Master

oLe Scrum Master est la personne qui doit maîtriser Scrum et s'assurer que
ce dernier est correctement appliqué
oIl a donc un rôle de coach à la fois auprès du Product Owner et auprès de
l‘équipe de développement
oAgit comme pare-feu (firewall) pour s'assurer que l‘équipe n'est pas
interrompue par des requêtes venant de l'extérieur
oUn formateur et un coach plutôt qu'un manager ou un chef de projet :
• S'assure que l‘équipe est complètement fonctionnelle et productive
• Aider à supprimer les obstacles
• Facilite l'adoption des pratiques modernes du développement 18
 Rôles: Scrum Master
Compétences Scrum Master

oBonne connaissance de scrum

oAptitude à comprendre les aspects techniques
oFacilité à communiquer
oCapacité à guider
• Il forme et coache SCRUM
oTalent de médiateur • Il régule les obstacles
• Il anime les réunions
oGoût à être au service de l‘équipe • Il protège l’équipe
• Il est le gardien du process Scrum

19
 Rôles: Chikens
Chikens

oPersonnes qui ne participent pas directement au projet mais dont les

intérêts doivent être pris en compte
• utilisateurs, clients, gestionnaires…

20
 Rôles
Comment ces rôles travaillent-ils ensemble ?

oLe Scrum Master travaille avec le Product Owner

oLe Scrum Master travail avec la Development Team
oLe Product Owner travaille avec le client
oLa Development Team travaille avec l’utilisateur final
oLe Product Owner a besoin de connaître ce que le marché
(l’utilisateur final) souhaite.

21
Scrum- Cycle

24 heures

2 à 4 semaines

22
 Vision du produit et product backlog
Product backlog

Carnet de produit (product backlog (PB)):

• Contient des User Stories
• Appartient au propriétaire du produit
• Tout au long du projet, le PB centralise « tout ce qui peut être fait par
l'Equipe, par ordre de priorité ».
• fil d'attente des fonctionnalités qui seront sélectionnées au fur et à
mesure, au cours de chaque itération
Référentiel évolutif avec une démarche de recueil Dynamique :
• De nouvelles user stories peuvent être ajoutées et d'autres reportées,
annulées, subdivisées,
• Demandes de changements, défauts, évolutions qui viennent, en cours de
route,...
23
 Vision du produit et product backlog
Product backlog

Format :
« En tant que client,
je souhaite pouvoir ajouter un produit dans mon panier
afin de pouvoir l’acheter »
En tant que … (rôle)
Je peux…. (tâche)
Afin de …. (but)

• Une US = un résumé formaté, pour avoir une vision rapide de la demande

• Elle sera détaillée ensuite avec l’équipe 24
 Vision du produit et product backlog
Un Exemple de User Stories

« En tant que Pilote,

je peux régler le commutateur en mode « horizontal »
afin de maintenir les ailes à l'horizontal pour que l'avion reste sur sa
trajectoire »

• Rappel : les user stories proposées par le PO sont discutées avec

l’équipe pour lever toute ambiguïté de compréhension
25
 Vision du produit et product backlog
Règles pour écrire des User Stories Correctes

 REGLE 1 : rester simple (principe KISS)

 REGLE 2 : parler du QUOI (pas du COMMENT)
 REGLE 3 : rester dans le périmètre du projet (vision!), et dans le
champ de responsabilités de l’organisation / du service
 REGLE 4 : lever l’ambiguïté des termes
 REGLE 5 : pratiquer si possible la réécriture des US

26
Exemple 1:

Voici une user story définie pour un logiciel d’assurance auto :

En tant qu’internaute,
je peux naviguer sur le site, saisir mes informations personnelles et
celles du véhicule, et soumettre une demande en ligne,
Afin d’obtenir une couverture d’assurance automobile.

Qu’en pensez-vous ?

27
Comment procéder?
Ici on découpe en 3 User Stories :

 « En tant qu’internaute, je peux naviguer sur le site, Afin de choisir la

couverture d’assurance automobile qui me convient »

 « En tant qu’internaute, je peux saisir mes informations personnelles

et celles du véhicule, Afin de comparer les offres d’assurance
automobile »

 « En tant qu’internaute, je peux soumettre une demande d’assurance

automobile en ligne, Afin d’obtenir un contrat »

28
Exemple 2:

Pour une agence de voyage:

En tant qu’opérateur du Centre d’Appel,
je peux saisir au moins 12 réservations
par heure en période de forte activité
Afin de réduire le temps d’attente des
clients
En tant qu’agent de voyage,
je suis capable d’effectuer un minimum
de 12 demandes de voyages en 60 min
durant la partie de l’année la plus
chargée
Afin de minimiser les abandons
téléphoniques

Nouvelle proposition pour cette US:

En tant qu’agent de voyage,
je peux saisir au moins 12 réservations par
heure pendant le pic d’appels de la journée (hors vacances)
Afin de réduire les abandons téléphoniques dus à une
attente trop longue
29
 Vision du produit et product backlog
Planning game: Sprint Backlog

• Carnet de produit (Sprint Backlog)

• Appartient à l‘équipe
• Contient des tâches et un estimé de l'effort requis / restant
• Pour chaque PBI, une liste de tâches est créée, constituée de tous les
travaux nécessaires pour réaliser l‘élément
• 1er élément dans le PB + prioritaire pour le PO et poursuit vers le bas
de la liste jusqu‘à atteindre sa capacité maximale

30
 Vision du produit et product backlog
Sprint

• Développement en cycles de travail Sprints (pas + 4 semaines,

généralement 2), développement des fonctionnalités du backlog
sprint.
• Durée limitée : jamais prolongée que le travail termine ou non.
• Au début du Sprint, l'Equipe sélectionne des éléments (exigences du
client) dans une liste priorisée et s'accorde collectivement sur ce
qu'elle pense pouvoir livrer de manière tangible et réellement
terminée.
• Aucun nouvel élément n'est ajouté durant le Sprint : changement
pour le Sprint suivant 31
 Vision du produit et product backlog
Sprint

• Sprint 0 (mise en place des technologies) et au dernier Sprint

(livraison finale)

Objectif
• se focaliser sur un objectif relativement stable, clair et limite
• maintenir ou augmenter la productivité (cycle plus court), ...
Terminé
• système intégré, entièrement testé, documenté et potentiellement
déployable 32
Remarques:

 Les itérations sont bornées dans le temps

 Les réunions sont bornées dans le temps
 Tout est borné !
 Et donc le coût est prévisible et à moins de chance
d’être dépassé

33
 Vision du produit et product backlog
Mêlée quotidienne

Mêlée quotidienne ou “stand-up meeting”, point de contrôle

quotidien de l’équipe
Durée maximum : 15 minutes; Interventions régulées – 2 min. par
personne.

• La mêlée quotidienne se déroule à lieu et heure fixes déterminés par

l‘équipe de développement
• Au début le Scrum Master peut avoir à rappeler qu'il est l'heure de la
mêlée et animer cette dernière
34
 Vision du produit et product backlog
La revue du Sprint
• Inspection et adaptation de l'incrément de fonctionnalité du produit
• Participants : l'Equipe ; le Product Owner, le SrumMaster et toutes
parties prenantes en fonction du besoin (clients, utilisateurs, experts,
décideurs,...) conviées par le Product Owner.
• Durée : timebox d'une heure par semaine de Sprint.
• Objectif : regarder et d‘étudier ce qu'il se passe et ainsi permettre de
s'améliorer sur la base d‘évaluations, en cycles itératifs.
=> C'est un moyen pour le Product Owner de connaître la situation
actuelle du produit et de l'Equipe ; et pour l'Equipe de connaître la
situation actuelle du Product Owner et du métier.
35
 Vision du produit et product backlog
La rétrospective du Sprint

• Inspection et adaptation du processus et de l'environnement.

• Participants : l'Equipe, le SM, le PO (optionnel). Toute autre partie
prenante peut être invitée par l'Equipe (sinon non autorisée a
participer)
• Durée : timebox de 45 minutes par semaine de Sprint
• La Revue de Sprint permet d'inspecter et d'adapter le produit
=> L'Equipe s‘échange sur ce qui fonctionne bien et sur ce qui ne
fonctionne pas, et s'accorde sur des changements à expérimenter.

36
 Rappelez-Vous
 Une user story doit être implémentée sur une
seule itération
 Un sprint doit comporter au moins 4 US
 J’applique les principes KISS pour écrire les US
 La méthode de Réécriture permet de valider
mes US

37
 Rappelez-Vous

Sprint: Est une itération

Backlog: Est une liste de tâches ouvertes
Product backlog: Est une liste d’items ouverts pour livrer le produit
Sprint backlog: Est une liste de tâches ouvertes attribuées au Sprint
L’EQUIPE ou the Development TEAM: C’est l’équipe de développement
Scrum TEAM: Equipe + Scrum Master + Product Owner
Estimation meeting: C’est la réunion d’estimation
Sprint Planning Meeting: C’est la réunion de planification du sprint
Daily Scrum ou Stand-up Meeting: C’est la réunion journalière de 15’ où l’équipe inspecte et adapte, coordonne son effort
Sprint Review ou Revue de Sprint: C’est la réunion de fin de Sprint où tous les acteurs de projet se retrouvent pour
inspecter les délivrables du Sprint.

Rétrospective: C’est la réunion d’inspection et d’adaptation de la Scrum Team

38
Merci pour votre Attention

39