La méthode agile Scrum

Enseignante: Oumayma Gasmi

 • Intérêt des méthodes agiles
1

• Définition de la méthode agile

2

• Caractéristiques des méthodes agiles

3

• Les principes du manifeste agile

4

• La méthode agile Scrum

5

2
Intérêt des méthodes agile

3
 Pourquoi Agile?
Beaucoup de systèmes existants sont mal réalisés voir même jamais utilisés
car ils ne correspondent pas aux besoins du client !
⦁ « ce n’est pas ce que je voulais… »
⦁ « ça ne sert à rien… »
⦁ « comment je fais ça… »
⦁ « ce n’est pas le bon résultat… »
⦁ « je vous avais dis que je voulais ça… »

4
 Pourquoi Agile?

Ce que le client Ce qui a été Ce qui a été Ce dont le client

a expliqué compris réalisé avait réellement
besoin

5
 C au ses

➢ Le client ne sait pas toujours ce qu’il veut et n’exprime pas

toujours ces besoins clairement.

➢ L’informaticien ne comprend pas le client (et vice versa !).

➢ Le client ne connaît pas toujours l’informatique :il ne sait pas ce

qui est possible et ce qui ne l’est pas.

6
 Les problèmes potentiels
⦁ D ifficultés de communiquer
➢ difficulté d’être précis,cohérent,complet,…
➢ différences de culture :
• les utilisateurs ne sont pas des informaticiens…
• les informaticiens ne connaissent pas le domaine …

⦁ C omplexité du problème
➢ problème non formalisé
➢ problème complexe

7
Les méthodes agile
Définition

8
 Méthodes Agile
D es méthode dédiées à la gestion de projets informatiques.

✓ plus de valeur aux clients et aux utilisateurs.

✓ plus grande satisfaction aux membres de l’équipe dans leur travail.

9
 Méthodes Agile

« Une méthode agile est une approche itérative et incrémentale

pour ledéveloppementde logiciel, réaliséde manièretrès collaborative
par des équipes responsabilisées, appliquant un cérémonial minimal,qui
produisent un logiciel de grande qualitédans un délai contraint,
répondant aux besoins changeants des utilisateurs. » (Scott
Ambler)

10
Les méthodes agile
Caractéristiques

11
 Caractéristiques des méthodes agiles
Agilité :réponse rapide et flexible aux changements

Caractéristiques communes aux méthodes agiles:

✓ Itérations à durée fixe

✓ Développement évolutif

✓ Planification adaptive

✓ Livraisons incrémentales

12
 Itératif/incrémental
Incrémental

✓Développer des applications en étendant PROGRESSIVEMENT ses

fonctionnalités.
✓S’appuie sur une idée initiale complètement formée, que l’on construit ensuite
morceau par morceau, jusqu’à une livraison finale, complète.
✓Permet d’éviter de TOUT CONCEVOIR, de TOUT TESTER (faciliter de
correction et de changement).

13
 Itératif/incrémental
Itératif

✓Une itération est un cycle de développement complet.

✓Le but d’une itération est de produire une version stable, testée et partielle d’un
logiciel.

✓En procédant de manière itérative, il est possible de découvrir les erreurs et les
incompréhensions plus tôt.

14
 Itératif+incrémental

Incrémenta l

Itératif

Comme le système croît avec le temps de façon incrémentale, cette méthode de

développement est nommée développement itératif et incrémental.

15
 Agile = Itératif +Incrémental+Adaptatif

Acceptation des changements même tardifs dans le développement.

16
Les méthodes agile
Les principes

17
 Les principes du Manifeste Agile

✓ Satisfaire le client en livrant tôt et régulièrement des logiciels utiles.

✓ Accepter les changements, même tard dans le développement.

✓ Collaborer quotidiennement entre clients et développeurs.

✓ Communiquer par des conversations en face à face.

18
Méthodes Agile
Il existe plusieurs méthode agile:

⦁ Scrum
⦁ Extreme Programming (X P)
⦁ DSDM
⦁ Crystal
⦁ …

19
Exemple de méthode agile
Scrum

20
 S cru m ?
⦁ Le nom vient du rugby
⦁ Scrum utilise les valeurs et l’esprit d’équipe du rugby et les
adapte aux projets de développement

⦁ L’équipe travaille de façon collective,soudée vers un

objectif précis
21
Les éléments de Scrum

22
 Eléments de Scrum

Rôles Les réunions Artefacts

• Product Owner • Planification de • Product backlog
• Scrum Master sprint • Sprint backlog
• équipe • Daily meeting • Task board
• Revue de sprint • Burndown chart
• Rétrospective

23
Les rôles

24
Les rôles

25
 Les rôles

Product O wner :
✓ Représente le client

✓ Fournir une vision partagée du produit,

✓ Définir le contenu du produit,

26
 Les rôles

Scum Master :
✓ Veiller à la mise en application de Scrum: Il s’assure que l’agilité est
respectée par l’ensemble des équipes.
✓ Encourager l’équipe à apprendre, et à progresser, en fonction du contexte

du projet,
✓ faire en sorte d’éliminer les obstacles qui pourraient freiner l’avancement,

27
 Les rôles
⦁ L’équipe :

✓ Travail collaboratif: les décisions sont prises collectivement

✓ Contient toutes les compétences nécessaires pour terminer le

sprint (Designer, architecte, développeur, testeur…)

28
Le product backlog

29
 P r o d u c t b acklog

✓ Donne une vision sur le produit

✓ Représente une liste de fonctionnalités rangés par priorité: C’est

la liste des éléments que l’on veut réaliser dans le projet

✓ C’estle product owner qui est responsable de la gestion du

product backlog, notamment de son organisation et de sa
priorisation.

30
 P r o d u c t b acklog
Les éléments

➢ Feature: regroupant un besoin fonctionnel pouvant être découpé

de façon plus granulaire sous forme de User Stories.

➢ User story: Une demande fonctionnelle d’un utilisateur, écrite en

langage naturel

➢ Priorité: Sur chaque user story on donne une valeur de priorité qui
permet ranger les user stories par ordre d’importance.

31
 P r o d u c t b acklog
User story
⦁ La priorité
⦁ Déterminer sur quoi on va commencer à travailler
⦁ Consiste à mettre un N ° de priorité unique par user story

⦁ on peut utiliser la priorisation MoSCoW :

⦁ Must have – fonctionnalité obligatoire
⦁ Should have – fonctionnalité qu’il serait très utile d’avoir
⦁ Could have – fonctionnalité qu’il serait intéressant d’avoir
⦁ Would like – fonctionnalité optionnelle sympathique

32
 P r o d u c t b acklog
Exemple 1

La valeur de priorité de 1 à 100: la user story ayant une priorité 100

est la plus prioritaire.

33
 P r o d u c t b acklog
Exemple 2

La priorité est calculée selon les deux valeurs BV et C.

Priorité= Business value (BV)/ complexité (C)

-Business value : valeur attribuée par le client & Product Owner Il y a des user stories qui
apportent le plus de valeur business (Business Value) ; c'est-àdire qui apportent un R.O.I (retour sur
investissement) positif ou très important à l’entreprise.

-Complexité : c’est une complexité technique de la réalisation de la user story attribuée par les
développeurs.

34
 P r o d u c t b acklog
User story
Contenu d’une User Story
• Un numéro unique décrivant une priorité: Déterminer sur quoi on va
commencer à travailler

• Un chiffre indiquant la complexité technique de réalisation

• Les conditions de validation :
⦁ les données de test et les résultats attendus

• O n peut y trouver aussi

⦁ l’estimation du temps de réalisation (en heure)

35
 P r o d u c t b acklog
User story

⦁ Modèle de rédaction: En tant que…(rôle), je souhaite…(tâche) afin

de…(but)

⦁ Principe : être précis à court terme

⦁ Exemple: « En tant que client, je souhaite pouvoir ajouter un produit

dans mon panier afin de pouvoir l’acheter »

36
 P r o d u c t b acklog
User story

⦁ La rédaction d’une User Story se fait en trois étapes incrémentales appelées

les 3C (Carte, Conversation et Confirmation).

⦁ Ces étapes assurent :

✓ Une description du besoin
✓ Une négociation en vue d’une définition du besoin

✓ Une définition des critères d’acceptabilité.

37
 P r o d u c t b acklog
User story
➢ Carte
⦁ Les story sont écrits sur des cartes
⦁ Les cartes peuvent être annotées avec des estimations, commentaires,etc.

➢ Conversation
⦁ Les détails derrières les cartes peuvent être étudiés durant les conversations avec le product
owner

➢ Confirmation
⦁ La user story est confirmée par des tests d’acceptation rédigés au même moment que celle-ci
⦁ (on peut écrire les tests d’acceptation au dos de la carte)

⦁ La validation des tests confirme que les user stories ont été développés correctement

38
 P r o d u c t b acklog
User story
Exemple : site d’un restaurant

39
 P r o d u c t b acklog
User story
Exemple :

40
 P r o d u c t b acklog
User story

Intérêt des user stories:

✓ Les user stories sont compréhensibles: les développeurs et les clients

les comprennent

✓ Support et encourage le développement itératif

✓ Les user stories ont les bonnes tailles pour les plannings

41
Sprint

42
 Sprint
✓Un projet utilisant Scrum est composé d'une suite d'itérations courtes de l'ordre
de 3 à 6 semaines appelées sprints.

✓A la fin d'un sprint, l'équipe livre au client un incrément de logiciel fini

potentiellement livrable.

43
Sprint plannig

44
 Sprint planning
• Une fois que le Product Backlog est suffisamment complet et
ordonnancé, on peut planifier un sprint.

• Au cours de cette réunion l’équipe scrum se charge de :

✓Sélectionner les US à réaliser sur le sprint.
✓Découper chaque user story en des tâches de développement
✓Répartir les tâches entre l’équipe
✓Estimer la durée nécessaire pour réaliser chaque tâches

45
 Sprint Backlog
Les tâches de développement sont centralisées dans le Sprint Backlog: Le
Sprint Backlog représente l'ensemble des tâches que l'équipe de développement
s'engage à produire au cours du sprint.

Exemple de sprint backlog

46
 Task board (tableau des tâches)
Les tâches de développement sont ajoutées au task board qui est un outil de
management visuel utilisé par les équipes Scrum pour suivre l’avancement des
tâches au cours d’un sprint.

Task board

47
Daily scrum

48
 Daily scrum
✓On l’appelle également mêlée quotidienne

✓C’est une réunion de 15 minutes.

✓Durant cette réunion l’équipe présente ce

qu’elle a fait la veille, ce qu’elle compte faire
aujourd’hui et les éventuelles difficultés
qu’elle a rencontrées.

✓Le Scrum Master est ainsi immédiatement au

courant des obstacles rencontrés et de
l’avancement du sprint
Photo d'une mêlée quotidienne

49
Burndown Chart

50
 Burndown Chart
Le Burndown Chart est un indicateur d’avancement du sprint en cours. Il s’agit
de tracé la charge de travail restante (l’axe vertical) en fonction du temps (l’axe
horizental).

Exemple de Burndown Chart de Sprint

51
Sprint review

52
 Sprint review

✓Se fait à la fin de chaque sprint.

✓Durant cette réunion l’équipe

présente ce qu’elle a fait pendant le
sprint.

✓Suite à cette démonstration le

product Owner donne un feedback aux
développeurs, il accepte ou refuse les
fonctionnalités présentées.
Photo d'une revue de sprint

53
Rétrospective

54
 Rétrospective

✓ C’est une réunion qui clôture le sprint.

✓ Permet à l’équipe Scrum de faire le bilan et le retour d’expérience sur le

sprint.

✓ Permet à l’équipe de s’améliorer de manière continue.

✓ Le but de cette réunion est de voir et de changer ce qui n’a pas marché, de
capitaliser ce qui a marché et de proposer de nouvelles choses pour que le
processus marche encore mieux.

✓ L’équipe apprend de ses erreurs pour faire encore mieux au prochain sprint

55
Les outils

56
 les outils
Des Outils développés pour le suivi des processus et des développements
avec une méthode agile
JIRA Trello

57