Genèse :Méthodes Agile
 Au début années 1990, les maîtrises
d’oeuvre informatique appliquent des
méthodes héritées de la « crise du
logiciel ». Les normes habituelles sont
:
 des normes tels que DOD2167, ISO
12207...
 des cycles de type MERISE, en V ou
en cascade.
 CMMI. 1
1

Cycle en V
2
2

Méthodes classique de gestion de projet :
Inconvénients:
 Phase de planification trops
importante
 Non adaptation aux changements
 Equipe de développement=facteur de
production et non comme ressource
3

Définition du dictionnaire
l'agilité comme :
 « Habilité à bouger rapidement de
façon légère et gracieuse,
caractéristique de ce qui s’adapte
facilement » (webster)
 « Synonyme de légèreté de souplesse
, facilite a se mouvoir »
 « Capacité a réagir promptement »
4

Méthode Agile de GP: Scrum
 SCRUM tient son origine du terme
sportif de rugby signifiant : mêlée.
 la méthodologie demande à ses
acteurs d'être soudés dans
l'accomplissement d'un projet, dans
l'atteinte d'un but.
5

SCRUM :Méthode agile
de gestion de projet,
utilisée notamment en développement logiciel.
Scrum
Scrum est processus agile de gestion de projet
pour construire un logiciel de façon
incrémentale, itérative et adaptative.
6

D’autres méthodes Agiles
?
7

Nous abordons:
8

9

Origine: Manifeste Agile
 Le Manifeste pour le
développement agile de
logiciels est un texte rédigé par dix-
sept experts aux Etat-unis du
développement d'applications
informatiques sous la forme de
plusieurs méthodes dites agiles.
10

 Ces experts estimaient que le
traditionnel cycle de développement
en cascade ne correspondait plus aux
contraintes et aux exigences des
organisations en évolution rapide.
 Les méthodes agiles ne sont pas
apparues avec l’Agile manifesto qu’en
2001 par l'Agile Alliance.
11

4 Valeurs
12

12 Principes
13

Activités1: Classer ces 12
principes en trois axes
Culturel(Mindset) Satisfaction client
Performance
opérationnelle
14

15

Principaux acteurs
16

Product Owner
C’est le représentant du client, il :
 Définit les fonctionnalités du produit.
 Décide des dates de livraison et de
leur contenu.
 Est responsable de la rentabilité du
produit (ROI).
 Priorise les fonctionnalités en fonction
de la valeur métier.
17

Product Owner
 Ajuste les fonctionnalités et leur
priorité avant chaque planification
d’itération.
 Accepte ou rejette les fonctionnalités
réalisées.
 Anime la réunion de planification de
sprint.
18

Scrum Master
 Le Scrum Master appartient à l’équipe
de développement il :
oS’assure que l’équipe est pleinement
opérationnelle et productive.
oÉtablit une collaboration étroite entre
l’ensemble des rôles et fonctions.
19

Scrum Master
 Animateur, facilitateur d'une équipe
Scrum.
 Protège l’équipe des interférences
extérieures.
 Assure le suivi du processus
20

Equipe de développement
 Réalise les fonctionnalités du produit.
 Présente au Product Owner les
résultats de son travail sous forme de
démonstrations.
 Maintient à jour les spécifications
détaillées du produit.
 Package et livre le produit.
21

 Un sprint aboutit toujours à la livraison
d’un produit partiel fonctionnel.
 Pendant ce temps, le ScrumMaster a
la charge de former le propriétaire du
produit, l’équipe et l’organisation
entière à la méthode Scrum.
22

Répartition des roles dans
scrum
 Pas de rôle bien déterminé : architecte,
développeur, testeur
 Tous les membres de l’équipe apportent
leur savoir
 Taille réduite de 6 à 10 personnes en
général
23

24

25

26

27

Daily Scrum meeting
28

Daily Scrum
29

Le Sprint planing
 Qu’est-ce qui sera livré ? Pourquoi
?
 A partir du Backlog priorisée par le PO
 Travail collaboratif pour bien
comprendre les items susceptibles
d’être réalisés
 C’est l’équipe qui évalue ce qui peut
être réalisé dans le sprint en fonction
de ses performances passées
 L’objectif du sprint est défini 30

Le Sprint planing
 Comment le travail sera-t-il accompli ?
 Sprint Backlog constitué des items
retenus et du plan pour les réaliser
 Le PO peut participer pour clarifier la
compréhension des items à développer
31

32

33

34

Sprint Retrospective
 Durée = 3h
 Une opportunité pour l'équipe Scrum de s’auto-inspecter et
de créer un plan d'améliorations à adopter au cours du
prochain Sprint.
 Le but de la rétrospective de Sprint est de :
 Inspecter la manière dont le dernier Sprint s’est déroulé
en ce qui concerne les personnes, les relations, les
processus et les outils
 Identifier et ordonner les principaux éléments qui ont
bien fonctionné et des améliorations potentielles
 Créer un plan pour mettre en œuvre des améliorations
sur la façon dont l'équipe Scrum fait son travail.
35

36

37

38
Scrum board

Le Sprint Backlog
Pourquoi ? Quels sont les Objectifs ?
 Définir l’objectif du Sprint
 Définir le contenu du Sprint (les items du Backlog de
Produit) (c’est la partie 1 du sprint planning)
 Décomposer (le cas échéant) ces Items en tâches, elles-
mêmes estimées en heures (c’est la partie 2 du sprint
planning)
Quand ?
 Le Premier jour du Sprint (Ex: Lundi matin mais cela peut être
un autre jour si le sprint démarre un autre jour)
Combien de temps ?
 Au maximum 2h pour un sprint d’une durée de 2 semaines.
S’il est bien préparé, il est court et efficace notamment sur la
partie 1.
39

Qui participe?
 Equipe – Scrum Master mais aussi le PO et ses soutiens
(Experts techniques …) sur demande de l’équipe.
En sortie ?
 L’objectif du sprint est défini et partagé
 Le périmètre du sprint (Items de backlog de produit) est défini
et partagé
 Le Backlog de sprint (Items de backlog de produit du sprint +
tâches associées éventuellement estimées en heures si cela
peut aider l’équipe) est créé et affiché sur le Board
40

Le Product incrément
41

42

Timeboxing
 Les projets en mode agile utilisent le concept
de la timebox. La taille de l’équipe et la durée
de l’itération sont fixées a priori.
 Ensuite vient le choix des fonctionnalités/User
Stories a développer dans une itération
donnée.
 Chaque itération ayant une durée pré-
déterminée, vous n’initialisez seulement ce que
vous êtes en capacité de terminer au cours de
l’itération, étant donné la capacité disponible,
c’est-à-dire le nombre de personnes 43

44

Estimation des taches
45

Burndown Chart
46

47

48

Retenons
49

Principe de base
 focaliser l’équipe sur une partie
limitée et maîtrisable des
fonctionnalités à réaliser ou users
stories
 (ces dernières étant identifiées et
priorisées dans un document qui
porte le nom de Backlog du produit).
 Ces incréments se réalisent
successivement lors de périodes de
durée fixe de 1à 4 semaines,
50

sprint
• Bloc de temps aboutissant à créer un
incrément du produit potentiellement
livrable.
• C'est le terme utilisé dans Scrum pour
itération.
• Aux débuts de Scrum, un sprint durait
30 jours. La pratique actuelle est de 2
à 4 semaines
51

 Chaque sprint possède,
préalablement à son exécution, un but
à atteindre, défini par le propriétaire
du produit, à partir duquel sont
choisies les fonctionnalités à
implémenter dans cet incrément (ce
sera le backlog du sprint).
52

Processus itératif et cycle en
V
53

54

55

Comparaison Agile-Scrum
56

Références
 https://agiliste.fr/introduction-
methodes-agiles/
57