Introduction aux

Méthodes Agiles
Et à SCRUM
1
Objectifs de la présentation

Compren dre les principes fon damentaux des métho des

agiles

Se familiariser avec le ca dre Scrum

Identifier les rôles, les artefacts et les événements clés

de Scrum

2
Plan de la présentation

1. Pourquoi l’agilité ?
2. Fondamentaux, Principes et valeurs des méthodes agiles
3. Introduction à Scrum
4. Artefacts de Scrum
5. Rituels de Scrum
6. Organisation Scrum
7. Pratiques Scrum
8. Questions

3
 01

Pourquoi
l’agilité ?

4
Le Triangle de la gestion de projet (Rappel) 01

Perimètre
Spécification
Objectifs :

● Livrer dans les délais

→ Respecter le planning

● Maitriser les dépenses

→ Respecter le budget
Qualité
Processus
● Faire le bon produit
→ Respecter la définition du besoin

● Bien faire le produit

Délai Coût → Respecter le RAQ
Planning Budget

5
Méthodes De Développement 01
Méthodes Prédictives Méthodes Adaptatives
(En cascade) (Agiles)
Fixe Périmètre Délai Coût

Qualité

Qualité

Variable Délai Coût Périmètre

6
Cycle en V 01

Analyse des besoins Recette

V
Cahier des Charges

V
Spécifications Tests de validation

V
V
Conception
Tests d’intégration

V
V
Architecturale

Conception
Tests unitaires

V
détaillée

V
Codage

7
 Cycle en V: Problématique 01
Client Client
Analyse des besoins Recette

V
Cahier des Charges

V
Spécifications Tests de validation

V
V
Conception
Tests d’intégration

V
V
Architecturale

Conception
Tests unitaires

V
détaillée

V
Codage

8
Cycle en V : Tentative de solution 01
04

Analyse des besoins Recette

V
Cahier des Charges

V
Spécifications Tests de validation

V
V
Revue de Revue de
Spécification Validation
Conception
Tests d’intégration

V
V
Architecturale
Revue de
Conception
Conception
Tests unitaires

V
détaillée

V
Codage

9
Processus itératif 01

Etalement des livraisons

Spécification
du PL

Conception du PL Intégration continue

et des Versions
Validation progressive
Spécification

Conception
Préliminaire
V1 Validation

Intégration
Feed back Client
Conception Tests
Détaillée Unitaires

Codage

Spécification
V2 Validation

Conception Intégration
Préliminaire

Conception Tests
Détaillée Unitaires

Codage

Spécification
V3 Validation

Conception Intégration
Préliminaire

Conception Tests
Détaillée Unitaires

Codage

Spécification
V4 Validation

Conception Intégration
Préliminaire

Conception Tests
Détaillée Unitaires

Codage

10
Développement itératif et incrémental 01

Production de versions successives répondant

« De plus en plus et de mieux en mieux » au besoin

Version n
+ nouvelles fonctions
+ améliorations
+ correction de bugs V1
________________________________________
= Version n+1

11
Développement itératif et incrémental 01

Production de versions successives répondant

« De plus en plus et de mieux en mieux » au besoin

Version n
+ nouvelles fonctions
+ améliorations
+ correction de bugs V2
________________________________________
= Version n+1

12
Développement itératif et incrémental 01

Production de versions successives répondant

« De plus en plus et de mieux en mieux » au besoin

Version n
+ nouvelles fonctions
+ améliorations
+ correction de bugs V3
________________________________________
= Version n+1

13
Développement itératif et incrémental 01

Production de versions successives répondant

« De plus en plus et de mieux en mieux » au besoin

Version n
+ nouvelles fonctions
+ améliorations
+ correction de bugs V4
________________________________________
= Version n+1

14
Développement itératif et incrémental 01

Production de versions successives répondant

« De plus en plus et de mieux en mieux » au besoin

Version n
+ nouvelles fonctions
+ améliorations
+ correction de bugs V5
________________________________________
= Version n+1

15
Développement itératif et incrémental 01

Production de versions successives répondant

« De plus en plus et de mieux en mieux » au besoin

Version n
+ nouvelles fonctions
+ améliorations
+ correction de bugs V6
________________________________________
= Version n+1

16
Agilité 01

Agilité: Aptitude à s'adapter pour une

entreprise ou une organisation
Méthodes agiles: Ensemble de principes et
de pratiques pour le développement de
logiciel ou de système; basé sur des
techniques de production légères
permettant d’apporter rapidement au
client de la valeur « métier » puis
d’augmenter celle-ci progressivement en
ajoutant fréquemment des incréments

17
 02

Fondamentaux,
Principes et
valeurs des
méthodes agiles

18
 02
Bref historique
Les méthodes de développement logiciel dites « itératives et
incrémentales » existent depuis longtemps:
1986 : Modèle de la spirale de B.W. Boehm
1991: Méthode RAD de James Martin
1995: SCRUM
1996: eXtrem Programming
2001: Manifeste Agile = Texte écrit par 17 figures éminentes du
développement logiciel
" Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce
travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs
communes."

19
Quelques méthodes agiles 02

SCRUM Focalisation de l’équipe sur des itérations courtes (Sprints)

Kanban Système visuel qui se concentre sur l'amélioration continue et la flexibilité
XP (eXtrem Programming) Ensemble de pratiques de développement de logiciel

Lean Méthode TOYOTA: élimination des gaspillages et l'optimisation du flux de travail.

Crystal Famille de méthodes adaptées à la taille et à la complexité spécifiques du projet

DSDM (Dynamic Systems Development Method) Méthode UK, Schéma directeur et réversibilité

FDD (Feature Driven Development) Définition d’itération guidée par la « Business value »

Agile Unified Process Structure légère + bonnes pratiques

20
 02
Manifeste Agile

Texte rédigé par 17 experts reconnus pour leurs apports respectifs au

développement d'applications informatiques sous la forme de plusieurs méthodes dont
les plus connues sont Extreme Programming et Scrum

Valeurs et principes du Manifeste Agile défendus et promus par

l‘ Agile Alliance
[Link]

Principes:
Abandon du cycle de développement en cascade qui ne correspond
plus aux nouveaux besoins applicatifs
Style de conduite de projet itératif et incrémental
Autonomie des ressources humaines impliquées dans la
spécification, la production et la validation
Intégration et test en continu

21
 02
Les 4 valeurs du Manifeste Agile

Personnes
Processus
& interactions
& outils

LogicielDocumentation
exécutable

Collaboration
Strict respect
avec d’un
le client
contrat

Adaptationfigée
Définition au changement
au début du projet

22
 02
Les 12 principes du Manifeste
1. Satisfaire le client en livrant régulièrement de nouvelles fonctionnalités à grande valeur ajoutée 1

2. Accepter le changement demandé même tardivement

2
3
3. Livrer fréquemment (2 sem./ 2 mois) un produit opérationnel
4

4. Encourager la collaboration du client et de l’équipe

5
5. Construire les projets autour de personnes motivées
6. Privilégier le dialogue en face à face 6

7. Mesurer l’avancement au travers d’un produit opérationnel

7
8. Adopter un rythme de production durable 8

9. Porter une attention continue à l'excellence technique et à la qualité du travail 9

10. Privilégier la simplicité 10

11. Laisser les développeurs s'auto-organiser et les y aider 11

12. Réfléchir à ses pratiques et les ajuster fréquemment

12

23
Processus agile 02

En plus d’être itératif et incrémental, un

processus agile est caractérisé par
des itérations courtes et régulières
un client qui fait partie de l'équipe
une capacité au changement
une forte implication des membres de
l’équipe dans la conduite du projet
des pratiques d'ingénierie permettant de
garantir la qualité du code

24
Planification d’une itération 02

Avant de commencer une itération…

Ses objectifs particuliers doivent être établis
o en concertation avec le client
o en fonction des objectifs généraux du projet (= sous-ensemble de fonctionnalités)
o en tenant compte des résultats des précédentes itérations et des priorités actualisées
o en y intégrant la reprise des fonctionnalités existantes
o en décidant de ce qui sera livré à la fin de l’itération (livrables)

Sa durée doit être fixée et la charge de travail qu’elle représente doit être estimée

Des critères d’évaluation doivent être définis pour valider ses résultats

25
Définition des itérations 02

Combien d ’itérations sont nécessaires pour un PIC ?

• En général, 4 à 10 itérations sont planifiées sur l’année (2 à 5 par
semestre)

Est-ce que les itérations ont toutes la

même durée ?
• C’est souhaitable pour réguler la charge et
le rythme de travail mais …
• La durée d’une itération peut néanmoins
varier en fonction de la phase du projet.
Par exemple, les itérations de début et de
fin de projet peuvent être plus courtes que
les autres.

26
 03

Introduction
A
Scrum

27
Scrum = mêlée 03

Avancer collectivement,
à la manière d’une équipe de rugby
(≠ course de relais)
Stratégie qui utilise et valorise les
compétences individuelles dans le
cadre d’un effort collectif
Capacité à s’adapter aux situations
Actions planifiées de manière
dynamique

28
L’itération SCRUM = Le Sprint 03

Product Incrément
Sprint Backlog Sprint
Backlog Produit

29
Le cadre de travail SCRUM Standard 03

Le Product Backlog (≈ Carnet de Produit)

est une liste de toutes les fonctionnalités qu’on retrouvera dans le produit
peut évoluer pendant le projet et doit être priorisé en fonction des attentes du client ou
des utilisateurs

Product Incrément
Sprint Backlog Sprint
Backlog Produit

30
Le cadre de travail SCRUM Standard 03

Le Sprint Backlog (≈ Carnet de Sprint)

est une liste des fonctionnalités qu’on veut implémenter dans l’incrément du produit
n’est pas censé évoluer pendant le sprint et doit donc être planifié de façon détaillée avant le
début de celui-ci

Product Incrément
Sprint Backlog Sprint
Backlog Produit

31
Le cadre de travail SCRUM Standard 03

La durée d’un sprint

Si possible toujours la même
Généralement 2 semaines

1à4
semaines

Product Incrément
Sprint Backlog Sprint
Backlog Produit

32
Le cadre de travail SCRUM Standard 03

La durée
Les d’un sprint
cérémonies Daily scrum
4Sitypes
possible
de toujours
réunions la même
Rituels clés rythmant
Généralement les sprints
2 semaines
24 h

Sprint Planning Sprint RETROSPECTIVE

1à4
semaines
Sprint REVIEw

Product Incrément
Sprint Backlog Sprint
Backlog Produit

33
 Le cadre de travail SCRUM pour un PIC 03

Equipe à temps partiel

Daily scrum
Durée des sprints plus longue (pour avoir
le temps de créer de la valeur)
Daily Scrum moins fréquents (= 1 jour / 2)

Sprint Planning Sprint RETROSPECTIVE

Sprint REVIEw

Product Incrément
Sprint Backlog Sprint
Backlog Produit

34
 04

Actefacts
De Scrum

35
 04
Le product backlog. (≈ Carnet de Produit)
Le product backlog est une liste hiérarchisée d’items
qui tient lieu de spécification.
Product
Chaque item formalise le besoin d’un utilisateur ou du Backlog
client et est rédigé selon une terminologie métier et
non technique
Sprint
Chaque item a une valeur « métier »qui peut évoluer
Backlog
en cours de projet en fonction des feedbacks des
utilisateurs
Avant chaque sprint, un sprint backlog est constitué
en extrayant les items les plus importants du product
backlog (Backlog grooming ou Backlog refinement.)

36
 04
User stories (récit utilisateur)
Description générale et informelle, d'une fonctionnalité
selon le point de vue de son utilisateur final.
Traduit un besoin fonctionnel à satisfaire par le produit Il était une
fois …
Est le principal type d’item constituant le Product Backlog
Est censée apporter de la valeur au client.
Peut être exprimée en une phrase sous la forme:
« En tant que [WHO?] » : A QUI est destinée cette fonctionnalité ? Quel est l’utilisateur?
« je veux [WHAT?] » : QUE veut-il faire (indépendamment du comment) ? Quelle est son
objectif ?
« afin de [WHY?] » : POURQUOI veut-il le faire? Quel est le problème à résoudre ? Quel
résultat veut-il obtenir ? Quelle est la valeur « métier » de la fonctionnalité ?

37
 04
Les trois C
l Card → l'histoire est courte . Elle peut être
rédigée sur un post-it = Carte KANBAN

l Conversation → les détails de l'histoire sont q u e c lient,

E n ta n t
i r c h o is ir u n
discutés avec le client et avec les membres v e u x p o uv o
je v raison
d e l i rer à
mo de a i re l i v
de l’équipe af i n d e me f
n s u n po int
m i c i le ou da
do
l Confirmation → l'histoire peut être validée relais.

par des tests d'acceptation (décrits au dos

du post-it après la discussion)

38
 04
INVEST
Principales qualités d'une bonne user story (mnémonique)
I comme « Indépendant » : l’implémentation de la fonctionnalité peut être planifiée de
façon autonome.
N comme « Négociable » : le contenu détaillé n'est pas « gravé dans le marbre »; il
peut encore être discuté avec le client.
V comme « Valeur »: la fonctionnalité a une valeur « métier » c.a.d. est utile, a de
l’importance pour l’utilisateur final.
E comme « Estimable »: on est capable d’évaluer l’effort requis pour réaliser la story.

S comme « Small » (petit): toute la story doit pouvoir être réalisée en un seul sprint.

T comme « Testable »: des critères d'acceptation peuvent être définis sans ambiguïté.

39
 04
Synthèse des user stories

En tant que… je veux … Afin de ..

bibliothécaire connaitre la liste des fournisseurs pouvoir les contacter en priorité pour
agréés réduire les coûts.
bibliothécaire pouvoir commander chez le fournisseur acquérir de nouveaux livres chez le
de mon choix meilleur fournisseur.
bibliothécaire associer un compte d’imputation à une vérifier que le budget disponible est
commande compatible.
bibliothécaire pouvoir enregistrer une livraison solder la commande associée et ajouter
les livres reçus dans le catalogue.
abonné retrouver un livre dans le catalogue à de pouvoir retrouver un livre dont j’ai
partir d’un mot de son titre entendu parler.
abonné retrouver des livres dans le catalogue à de pouvoir retrouver les livres écrits
partir de leur auteur par un auteur que j’ai apprécié.

40
 04
Technical story
L’utilisateur peut aussi faire partie de l’équipe (client interne)

a e n g ineer
e a r ch itecte a n t q ue dat d o n n ées
qu En t s
En tant ir co m ment x tr a iter le
j e ve u x
sa v o
ew ork Fx j e ve u
ne le f
r am
r dans antes
n ct io n in tég re manqu méliorer les èle
fo
d e p o uvo ir l’ afin d
’a
d u mo d
afin e ch n ique. man c e s
la so lut
ion t perfor
tif.
préd ic
er
e ng ine
loppeur u e data es
que d év e
r un t a nt q in er l s
En tant r la n c e En élim s valeur
v e u x p o uv o i io n c o ntinue u x
j e ve ons et le
e t
j ’intégra er, et l
pipe l in e d
rer, d’a
s s em b l do ub ntes r les
é n é ra r e dèle
afin d e g
o u v e l item aber a m é lio m o
r un n d’ du
de tes te afin mances
r
pro duit
. perfo tif.
ic
préd

41
 04
EPIC (Epopée)
Quand la story n’est pas assez « SMALL » pour être
réalisée en un seul sprint
u e client,
E n ta n t q
r re ch e rcher
p o uv o i
User j e v e u x
t relais
e n f o n ction
EPIC s tories u n p o in
lo c alisatio
n
de s a
é cu p é r er mon
r
afin de e ch e z mo i.
lient, ès d
t q u e c cher un co lis pr
E n ta n re c he r
v e u x p o uvo ir
je
po int re
lais
n er celui où ,
sélect io n
de m a u e client
afin de c o l is En t a n t q
e c h ercher
c u pérer le p o uv o ir r
j’ira i r é
j e ve u x s e n fo nction
co m man
de. t relai verture
un po in e s d ’ o u
orair o lis
de ses h cupérer mon c
ré
afin de u is d is ponible.
e s
quand j

42
 04
FEATURE ou thème (Fonctionnalité)
Les user stories et les EPICs qui se Authentification
rapportent à une même fonctionnalité
peuvent être regroupées en Features. teur
que visi ercher
E n t ant u v oir rech ient
j e veu x p o
p t e E n t a n t que cl
n com s x pouvoir
Commande créer u
af i n
r
d
m
’e
a
n
ti
r
o
e g i s
ns persom’aut
e eveue
trer jm
n n e llhe s.
n
l
t
e
i
t
f i
u
e r
n mot de
n
avec mo sse
pa
i n fo @e-mai mon
d ’a c c é de r à
af in
, nt, compte
a n t q u e client li se r t a n t que clie chercher
En t visua En voir re
pouvoir eux pou s
j e veux n i e r j e v
relai
er le pa n point celui
et valid i d e r l a u
é le c tionner
v a l
af in d e s colis
af in de cu p érer le
Navigation
e . i ré
comman
d où j’ira de .
omman
de ma c
nt,
t q u e client, t a n t que clie er un
n
E n t an ner un
élection ue et
E
veux sé
lectionn
x s j e ment nt,
je v e u
catalog de paie de. a n t que clie cheercclhiernt,
prod u i t d u a i re s m o d e comman En t
tairntrequ guier rech her t,
bre d’ex
e m p l p a ss e r
j e veux
Eu
po nvo qeurec clien éder
un nom panier af in de c a ta
p ol o
uv no t a n t
e txalpooguuveoir acc
s le uijte dvueux saEdfuicc ha
à dépos
er d a n un prod suaplrio e r
s du j ei t v e u fiche i chois
i
le passe
r vi n
afin de u . n de visu a lirsaeyrosna que j’a le
af in de iva efi au rir
e parcou duits
de . descript v e . n d
comman descr i pt i a f i
ue de p
ro
catalog
bles.
disponi

43
 04
Personna
Permet de mieux comprendre le Marie, gestionnaire des comptes
comportement et les besoins d’un Contexte
type donné d’utilisateur en
analysant: • 32 ans
• Comptable de formation
• Les différents types d’utilisateurs ( âge, • Site préféré:
[Link]
genre, profession, catégorie, etc.) • Bon niveau d’anglais
• L’expertise du domaine • Partage son bureau avec
plusieurs personnes
• Les préférences marquées
• La manière d’utiliser l’application Comportements Besoins induits
• Les besoins « métier » • Commence tôt le matin • Accès rapide aux fonctions
• Utilise beaucoup Internet • Raccourcis pour les
Peut être rédigé avec le concours dans son travail et dans sa
vie privée.
fonctions principales.

des utilisateurs finaux • A horreur de rester bloquée

• Accès protégé aux
données sensibles.
pour un problème • Hot-line de 8h à 20h
Peut aider à la conception des informatique.
• Veux pouvoir contacter les
• Accès à un annuaire des
clients + gestion de
interactions homme-machine clients facilement en cas
de problème.
conversations.
(ergonomie)

44
 04
Tache

Les user stories peuvent être déclinées en

Tâches afin de définir le travail technique
que l’équipe devra réaliser pour pouvoir Feature ou Thème
délivrer la fonctionnalité associée:
• Etudes techniques de conception
• Choix de composants EPIC 1 EPIC 2
• Programmation
• Intégration
• Tests Story 1.1 Story 1.2 Story 0.1 Story 2.1 Story 2.2
• Déploiement
• Etc.
q Tâche 1.1.1 q Tâche 1.2.1 q Tâche 0.1.1 q Tâche 2.1.1 q Tâche 2.2.1
q Tâche 1.1.2 q Tâche 1.2.2 q Tâche 0.1.2 q Tâche 2.1.2 q Tâche 2.2.2
q Tâche 1.1.3 q Tâche 0.1.3 q Tâche 2.1.3 q Tâche 2.2.3
q Tâche 0.1.4 q Tâche 2.2.4
q Tâche 2.2.5

45
 04
Description d’un ITEM
ID: #11 Type: User story Priorité : Indispensable Estimation : 8
Formulation : En tant que client je veux pouvoir m’authentifier avec mon @e-mail et un mot de passe afin d’accéder à mon
compte.
Definition of Ready :
• Charte graphique validée par le client • LDAP installé sur le serveur
Exigences et règles métiers :
• Si l’utilisateur n’est pas encore client le système lui propose de créer un compte.
• Le mot de passe doit être constitué d’au moins 8 caractères dont 2 numériques et 1 spécial.
• L’adresse e-mail sera utilisée pour toutes les correspondances et le changement de mot de passe.
Tests d’acceptation :
• Étant donné que je suis un utilisateur non connecté »sur la page de connexion Lorsque je remplis les champs « e-mail» et
«Mot de passe» avec mes informations d'authentification et que je clique sur le bouton « Connexion » Alors le système me
donne accès à mon compte.
• Étant donné que je suis un utilisateur non connecté »sur la page de connexion Lorsque je remplis les champs « e-mail»
avec une adresse e-mail incorrecte et que je clique sur le bouton « Connexion » Alors le système me signale que l’adresse
est inconnue et me propose de créer un compte
• …
Definition of Done :
• Revue de code effectuée • Documentation à jour
• Tests d’acceptation tous OK • Charte graphique respectée
Tâches :
1. Créer l’annuaire LDAP et des utilisateurs de test
2. Créer la page de login
3. Développer le module de contrôle de validité du mot de passe

46
 05

Rituels

De Scrum

47
Cérémonies 05

Daily scrum

Sprint Planning

Sprint REVIEw

Sprint RETROSPECTIVE

Product Incrément
Sprint Backlog Sprint
Backlog Produit
48
Sprint Planning 05

Réunion organisée au début de

chaque sprint En ta
n t qu
t,
clien x pouvo
eu
e
ir
je v

Entre 1h et 2h par semaine de

et
liser r
visua le panie
er
valid lider
d e va nde.
afin a
la c
omm

sprint
Vise à fixer un objectif commun
générant de la valeur pour
l'utilisateur et à définir le sprint
backlog en estimant l’effort
80% du travail en amont (backlog 3 questions essentielles :
grooming) et 20 % en séance • Quels items?
• Quel effort?
• Par qui?
49
Daily Scrum 05

???
Réunion organisée tous les
jours (ou tous les 2 jours)
5 à 10 minutes (debout)
Pas fait pour résoudre
mais plutôt pour identifier
les problèmes
3 questions essentielles :
• Qu’est ce que j’ai fait hier?
• Qu’est ce que je fais aujourd’hui?
• Quels sont les problèmes?
50
Sprint Review 05

Réunion organisée à la fin

de chaque sprint
Pas plus de 4h le
Livrab

Participation du client et de
toute l’équipe
Pour valider le résultat du
sprint et recueillir le
feedback du client Format de la réunion :
• Présentation
• Démonstration
• Livraison & acceptation
51
Sprint rétrospective 05

Réunion organisée à la fin de

chaque sprint
Pas plus de 2h
Participation de toute
l’équipe mais pas du client
Pour évaluer la performance
de l’équipe pendant le sprint
et identifier les points Ce qu’il faut / on pourrait :
d’amélioration possibles • continuer de faire
• arrêter de faire
• prévoir de faire
52
 06

Organisation
Scrum

53
 06
Le Product Owner

Est responsable du product backlog

Fait partie intégrante de l’équipe
t
duc
Pro log
Est chargé de répondre aux besoins du B ac
k

client
Définit les priorités et ajuste les
fonctionnalités pour chaque sprint
Choisit la date et le contenu de la release
Est responsable du retour sur investissement

54
Le Scrum master 06

Organise et anime les cérémonies

Est responsable de faire appliquer les valeurs
et les pratiques de Scrum
Aide à la résolution des problèmes et au
contournement des obstacles
Encourage l’amélioration continue des
performances de l’équipe
Facilite la coopération entre tous les acteurs
du projet
Protège l'équipe des interférences extérieures

55
L’équipe 06

Groupe interfonctionnel
Possédant les différentes compétences
nécessaires pour mener à bien le projet
Auto-organisé et autonome pour planifier
et gérer son travail
Collaborative et flexible
Collectivement responsable de la réussite
ou de l’échec du projet
Attaché à la qualité et à la satisfaction
du client

56
 06
Organisation PIC
+ Organisation Scrum

Chef PIC

Unité P3 & Tuteurs

Client t
duc
Pro log
k
Bac

Chef PIC Adjoint

Product Owner Scrum Master

Equipe PIC

57
 06
Organisation PIC

Chef PIC

Unité P3 & Tuteurs

Client t
duc
Pro log
k
Bac

Chef PIC Adjoint

Product Owner Scrum Master

Option 1:
Interface client en
binôme

Equipe PIC

58
 r av ail
d e t 06
Organisation PIC o s s e c h arge
ro jet
G r de p
duc
Pro log
Bac
k
t

⚠ en déb u t

Chef PIC

Unité P3 & Tuteurs

Client t
duc
Pro log
k
Bac

Chef PIC Adjoint

Product Owner Scrum Master

Option 2:
Interface client unique

Equipe PIC

59
 06
Organisation PIC

Chef PIC
uct
P r od g
lo
Bac k

Unité P3 & Tuteurs

Client t
duc
Pro log
k
Bac

Chef PIC Adjoint

Product Owner Scrum Master

Option 3 :
Préparation option 2
pour le S2
Equipe PIC

60
 07

Pratiques
Scrum

61
 07
Estimation et Planning Poker
How many?
Estimation = Quantification de l'effort à
Who, fournir en story points
Sprint Backlog
What,
Estim.
Why. US Valeur

8 5 8 6
Scrum Master

nt,
e clie
n t qu
En ta voir der
x pou li
je v euliser et va e
d
visua ier afin
n
le pa
er la
valid e.
and
comm

ProductOwner Equipe

[Link]
62
Spike 07

Quand une story ne peut pas être estimée sans une étude
exploratoire préalable (trop d’incertitude)

Item du backlog sans effort estimé ni valeur attendue

Doit permettre de définir une solution « théorique »
(PoC, document, présentation, etc.) pour laquelle
l’effort à réaliser peut être estimé
Obligatoirement limité dans le temps («timeboxing »)
avec durée < 2 jours
Résultat examiné en Sprint Review
Réponse possible quand le DoR d’une story ne peut être défini

63
 07
Scrum board
Tableau à 3 colonnes dans lequel sont disposées les cartes Kanban
A faire En cours Terminé
En tant que client,
je veux pouvoir
visualiser et valider le
panier
afin de valider la En tant que client, En tant que visiteur je
commande. je veux pouvoir visualiser veux pouvoir rechercher
et valider le panier créer un compte afin
En tant que client, je afin de valider la
veux sélectionner un d’enregistrer mes
commande. informations
produit du catalogue et
un nombre d’exemplaires personnelles.
à déposer dans le panier
afin de le passer
commande. En tant que client je
En tant que client,
veux pouvoir
En tant que client, je veux pouvoir
m’authentifier avec
je veux sélectionner accéder au rayon que
mon @e-mail et un mot
un mode de paiement j’ai choisi afin de
de passe afin d’accéder
afin de passer parcourir le catalogue
à mon compte
commande de produits disponibles.
En tant que client,
je veux pouvoir
rechercher un point
relais en fonction de sa
localisation
afin de récupérer mon
colis près de chez moi.

En tant que client,

je veux pouvoir
rechercher un produit
du catalogue afin de
visualiser sa fiche
descriptive.
Scrum
Master

64
Burndown chart d’un sprint 07

65
Le Sprint 0 07

La première itération est généralement la plus difficile

car elle nécessite
le déploiement et les réglages des outils de production
l’organisation de l’équipe et l’appropriation des rôles
et elle est souvent marquée par
des besoins de formation
des difficultés de « rodage »
des erreurs de débutants , etc.

Les équipes non aguerries sont généralement trop optimistes ...

66
Sprints et livraisons 07

67
 07
Scrum à grande échelle
Direction Projet
Une équipe SCRUM = 7 ± 2 personnes Bac kl
og

Projet à grande échelle

⟹ collaboration de plusieurs équipes Client CP PO SM

Nécessité d’une coordination globale

Mutualisation possible de certains
rôles
Possibilité d’organisation multi-niveaux
Equipe 1 Equipe 3
(SCRUM de SCRUM … de SCRUM)
SCRUM a été utilisé pour des projets
de + de 500 personnes
Equipe 2
68
Les 3 piliers de Scrum

Transparence :
o Tous les aspects du processus doivent être visibles pour l'équipe Scrum, les parties prenantes
externes et toute personne impliquée dans le projet.
o La transparence favorise la confiance et permet de prendre des décisions informées.

Inspection :
o Le travail réalisé doit être examiné régulièrement pour détecter les écarts par rapport aux
référentiels.
o L'inspection permet à l'équipe de s'assurer que le travail est conforme aux attendus et d'identifier
les opportunités d'amélioration.

Adaptation :
o Les processus et le produit doivent être ajustés en fonction des résultats de l'inspection.
o L'adaptation est une composante clé de l'approche itérative de Scrum, permettant une réactivité
aux changements.

69