1

AGILE ET SCRUM
https://www.lexpert-formation.fr/pourquoi-se-former-aux-methodes-agiles
 Le Manifeste Agile
2

 En 2001, 17 ténors de l’agilité identifient 4 principes de base,

communs à toutes les démarches agiles.
 Cherchant par la pratique et l’entraide de meilleures façons de
développer des logiciels, nous en sommes venus à valoriser :
 Les hommes et leur interaction plus importants que les processus et
outils.
 Un logiciel opérationnel plus important qu’une documentation
complète.
 La collaboration plus importante que la contractualisation.
 L’acceptation du changement plus importante que la planification figée.
 Si on accorde une valeur aux éléments à droite, ceux de gauche nous
paraissent avoir une valeur encore plus grande.
http://agilemanifesto.org
 Introduction
3

Voici comment le
client a exprimé
son besoin
 Introduction
4

Voici comment
l’analyste a
compris le besoin
 Introduction
5

Voici comment le
concepteur a
conçu le projet
 Introduction
6

Voici comment le
programmeur a
écrit le code
 Introduction
7

Voici ce que les

béta testeurs ont
reçu
 Introduction
8

Voici les
fonctionnalités
installées
 Introduction
9

Voici comment le
commercial a
décrit le futur
système
 Introduction
10

Voici comment le
projet a été
documenté
 Introduction
11

Voici ce qui a été

facturé au client
 Introduction
12

Voici le support
fournit aux
utilisateurs
(HelpDesk)
 Introduction
13

Voici comment
fonctionne le
système en
charge
 Introduction
14

Voici comment
les mises à jour
sont installées
 Introduction
15

Voici la version
Open Source du
système
 Introduction
16

Et enfin
Voici le véritable
besoin de
l’utilisateur
 Synthèse
17
 Scrum signifie :
18
 Scrum en images
19
 Scrum en images
20
 Scrum en images
21
 Scrum en images
22
 Scrum en images
23
 Scrum en images
24
 Scrum en images
25
 Scrum en images
26
 Scrum en images
27
 Scrum en images
28
 Scrum en images
29
 Scrum en images
30
 L’organisation avec Scrum
31

https://www.sooyoos.com/publication/methodes-agiles/
 Pratique de Scrum - vue d’ensemble
32
3 rôles

Product Owner Scrum Master L’équipe

3 artéfacts

Scrum board

backlog burndown chart produit

3 réunions

planification de sprint Daily Scrum revue de sprint rétrospective

 Organisation du travail dans Scrum
33

Diviser l’organisation en petites équipes

multidisciplinaires et auto-organisées.

Diviser le travail en une liste de

petits livrables concrets.
Trier cette liste par priorité et estimer
la taille relative de chaque élément.
 Itérations et livraisons successives
34

 Diviser le temps en petites itérations de durée fixe (appelées

des sprints et durant habituellement de 1 à 4 semaines).
 Faire une démonstration à l’issue de chaque sprint avec un
produit potentiellement livrable.
 Optimiser le planning de la version et mettre à jour les priorités
en collaboration avec le client, sur la base de ce que vous avez
appris après chaque sprint (à travers la démo).
 Optimiser le processus en organisant une rétrospective après
chaque sprint.
 Cycle de vie Scrum (vue globale)
35

Sprint 0
 Atelier Coin Toss
Démarche itérative et incrémentale
36

 Équipes :
 2 équipes de 6 ou 7 personnes.
 Pour chaque équipe :
◼ 4 personnes pour représenter le cycle de vie.
◼ 2 personnes pour chronométrer.
◼ 1 personne pour gérer le tableau des valeurs et noter les temps.
 Matériel :
 Récupérer les boites de pièces de monnaie. Une boite par équipe.
 Préparer au tableau la structure pour noter les résultats :
1ère phase Toutes les phases Somme rapportée ?
Cascade
Agile simple
Agile & Kanban
Vrai Agile
 Atelier Coin Toss
Démarche itérative et incrémentale
37

 Règles (suite) :
 Chacune des 4 personnes représente une étape du cycle de vie logiciel :
◼ Spécification
◼ Conception
◼ Codage
◼ Test
 1 personne chronomètre le temps de la première étape.
 1 personne chronomètre le temps total.
 Une personne note les valeurs au tableau.
 Un tas de pièces de monnaie représente un ensemble fonctionnalités à
développer.
 Chaque pièce est une fonction.
 La valeur de la pièce représente la valeur de la fonction.
 Une pièce tournée est une fonction terminée.
 Atelier Coin Toss
Démarche itérative et incrémentale
38

 Premier tour : Projet classique (cascade)

 Chaque phase (personne) doit retourner toutes les pièces avant
de les passer à la phase (personne) suivante.
 Chronométrer le temps de la première personne.

 Chronométrer le temps total.

 Calculer la somme rapportée (valeur des pièces).

 Atelier Coin Toss
Démarche itérative et incrémentale
39

 Deuxième tour : Projet Agile simple

 Chaque pièce retournée peut être passée à la phase suivante.
 On n’attend pas que toutes les pièces soient retournées.

 Tout le monde travaille en même temps.

 Chronométrer le temps de la première fonction livrée.

 Chronométrer le temps total.

 Calculer la somme rapportée (valeur des pièces).

 Atelier Coin Toss
Démarche itérative et incrémentale
40

 Troisième tour : Projet Agile & Kanban

 L’idée est d’introduire une règle Kanban au fonctionnement Agile.
 On place un post-it entre chaque phases (personnes) : Il devient le
point de passage des fonctionnalités (les pièces).
 On ne peut placer que 2 pièces sur le point de passage.

 Le but est de réguler le flux.

 Chronométrer le temps de la première fonction livrée.

 Chronométrer le temps total.

 Calculer la somme rapportée (valeur des pièces).

 Atelier Coin Toss
Démarche itérative et incrémentale
41

 Quatrième tour : Projet en vrai Agile

 Nous rajoutons une contrainte de temps.
 Le projet s’arrête après 20 secondes.

 La personne qui représente la première phase peut choisir les

pièces à retourner en fonction de leurs valeurs.
 Le but étant d’accumuler le plus de valeur en moins de temps.

 Chronométrer le temps de la première fonction livrée.

 Chronométrer le temps total.

 Calculer la somme rapportée (valeur des pièces).

 Product Backlog / Sprint Backlog
42

 2 Backlogs :
 Product backlog : liste les briques fonctionnelles exprimées avec
le format des user stories.
 Sprint backlog : détaille le contenu de la brique fonctionnelle en
cours de réalisation sous forme de tâches.

 Les backlogs :
 Peuvent être utilisés partout, comme ToDo list améliorée.
 Sont gérés / tenus par le Client.
 Doivent être parlant.
 Contiennent des expressions simples.
 Modèle pour une user story
43

 Une User Story contient :

 Elle se limite à la description d’une fonctionnalité unitaire.
 Elle doit décrire avec précision le contenu de cette
fonctionnalité à développer.
 Elle est rédigée par l’utilisateur.

 Elle doit être sous forme d'une phrase simple dans le langage de
l'utilisateur ( éviter UML car très formaliste  ).
 Elle exprime les règles de gestion, exigences, cas particuliers.

 Elle est associée à une priorité métier (identifiée par un numéro

unique).
 Elle doit être évaluée par un chiffre indiquant la complexité
technique de réalisation.
 Modèle pour une user story
44

 Une user story doit être exprimée de la manière suivante :

En tant que Qui

je veux Quoi

afin de Pourquoi
 Modèle pour une user story
45

 Le qui indique :
 L'acteur ou l'utilisateur qui exprime la fonctionnalité et qui en
est l'usager.
 Le quoi indique :
 Une description de la fonctionnalité avec le comportement
attendu de la part du système (résultat, sortie, ..)
 Le pourquoi indique :
 L'objectif ou l'intérêt de la fonctionnalité du point de vue de
l'utilisateur, ce qui permet d'évaluer la priorité par rapport
aux autres user stories.
 Modèle pour une user story
46

 Exemples :
En tant que <client de la plateforme de vente en ligne>,
je veux <ajouter des articles à mon panier>,
afin de <pouvoir passer une commande>.

En tant que <client de la plateforme de vente en ligne>,

je veux <être informé de la date de livraison prévue>,
afin de <pouvoir réceptionner ma commande>.

En tant que <client de la plateforme de vente en ligne>,

je veux <enregistrer mon adresse>,
afin de <recevoir toutes mes commandes à cette adresse>.
 Modèle pour une user story
47

 Une User Story peut aussi contenir :

 Les cas de test métier, donnés avant le développement, avec :
◼ les données de test.
◼ les résultats attendus.

 qui mieux que le métier peut spécifier les tests métier.

 On peut y trouver aussi :
 l’estimation du temps restant.
 optionnel : l’estimation du temps de réalisation.
 Atelier Offing the off-site Customer
Présence du client dans le processus
48

 Équipes :
 Des équipes de 2 ou 3 personnes.
 Il faut avoir un nombre d’équipes pair.

 La moitié des équipes joue le rôle de client.

 L’autre moitié représente chacune une start-up qui s'efforce de
s'implanter sur le marché.
 Matériel :
 Des feuilles blanches pour chaque équipe (start-up).
 Au moins 2 crayons par équipe (start-up).

 Des spécifications graphiques distribuées aux clients.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Atelier Offing the off-site Customer
Présence du client dans le processus
49

 1ère partie (Off-site customer) :

 Chaque 2 équipes simulent la création d'un produit logiciel en
utilisant une approche traditionnelle.
 La communication avec le client se fait de manière écrite, telle
que des exigences écrites.
 Le client dispose de 10 minutes pour rédiger (uniquement avec
des mots) une description des spécifications graphiques qu’il a
reçu.
 La start-up dispose ensuite de 10 minutes pour représenter sur un
papier blanc les spécifications écrites fournies.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Atelier Offing the off-site Customer
Présence du client dans le processus
50

 2ième partie (On-site customer) :

 Les deux équipes client et start-up travaillent ensembles.
 L’équipe start-up dispose de 10 minutes pour implémenter le
produit à l’aide des consignes de l’équipe client.
 L’équipe start-up n’a pas le droit de voir les spécifications
graphiques.
 Seul le client peut voir les spécifications graphiques durant les 10
minutes du jeu.
 La communication ne peut être que verbale.

 Aucune limite n’est imposée pour la quantité et la nature de la

communication verbale.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Atelier Offing the off-site Customer
Présence du client dans le processus
51

 Autre variante (Analyste d’affaire intermédiaire) :

 Dans ce scénario, un analyste métier agit en tant qu'intermédiaire
entre le client et le programmeur.
 Le programmeur s’installe d'un côté de la pièce et le client de
l'autre.
 L'analyste d’affaire se déplace entre le programmeur et le client
en relayant les informations.
 Le programmeur et le client sont tenus de rester de leur côté de la
pièce et ne peuvent pas parler directement les uns aux autres.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Atelier Offing the off-site Customer
Présence du client dans le processus
52

 Analyse des résultats :

 Les métaphores :
Réalité Métaphore
Équipe avec "programmeur", "client" Une start-up essayant d'amener un
et éventuellement "analyste nouveau produit sur le marché
d'affaires"
Diagramme abstrait que seul le client La vision produit du client de ce dont le
est autorisé à regarder marché a besoin, basée sur son
expérience et ses études de marché

Copie dessinée à la main de la vision L'implémentation du produit par le

du produit programmeur.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Atelier Offing the off-site Customer
Présence du client dans le processus
53

 Analyse des résultats :

 Les métaphores :
Réalité Métaphore
Figures en ligne droite dans le Les exigences de base du marché. Sans
diagramme de vision du produit cela, le produit sera rejeté et la société
échouera. Un chiffre est très compliqué:
satisfaire les besoins du marché n'est pas
facile.
Figures courbes dans le diagramme Une nouvelle torsion unique sur les
de vision du produit exigences du produit. Avec ceux-ci, le
produit sera une "application de tueur" et
l'entreprise dominera son marché.
Présentateur comparant les Libérer les produits sur le marché et voir
«produits» à la «vision du produit» ce qui se passe.
© 2005 Titanium I.T. LLC http://www.jamesshore.com
 Atelier Offing the off-site Customer
Présence du client dans le processus
54

 Analyse des résultats :

 Échec :
◼ Si une équipe ne copie pas exactement les trois éléments linéaires, leur
produit est un échec. Leur entreprise a fait faillite.
◼ Cela n'a pas d'importance si les éléments de la ligne courbe sont
corrects, les éléments linéaires sont une condition préalable au succès.
 Survie :
◼ Si une équipe copie exactement les trois éléments linéaires, leur
entreprise a survécu.
◼ Ils ont réussi à donner au marché ce qu'il veut, mais ils n'ont pas innové.
◼ L'un des éléments linéaires est très difficile à copier: donner au marché
ce qu'il veut n'est pas facile.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Atelier Offing the off-site Customer
Présence du client dans le processus
55

 Analyse des résultats :

 Dominance :
◼ Si une équipe copie exactement la totalité de la vision du produit, leur
entreprise domine le marché pendant plusieurs années.
◼ Les éléments courbes représentent de nouvelles innovations.
◼ En copiant exactement les cinq éléments, l'équipe a donné au marché
exactement ce qu'il voulait et a continué à produire plusieurs
innovations que le marché voulait mais qu'il ne savait pas qu'il voulait.
◼ L'un des éléments de ligne courbes est facile et l'un d'eux est très
difficile : les deux doivent être parfaits pour obtenir une position
dominante sur le marché.

© 2005 Titanium I.T. LLC http://www.jamesshore.com

 Phase de préparation (Sprint 0)
56

 Préparer le Product Backlog :

 Le métier recense toutes les user stories, les décrit, et
indique une priorité.
 En parallèle, les développeurs posent des questions sur
chaque user story, pour affiner les descriptions, et
recherchent les meilleures solutions techniques répondant
aux besoins exprimés.
 Les développeurs définissent la complexité de la User Story
en utilisant par exemple la technique du planning poker.
 Phase de préparation (Sprint 0)
57

 Préparer une feuille de route (Roadmap) du Produit, avec

les releases identifiées :
 On répartit chaque user story dans les différentes itérations
et releases en plaçant toujours les plus grandes priorités en
premier.
 Cette étape définit un planning global.
 Elle permet aussi d’estimer le budget.
 Phase de préparation (Sprint 0)
58

 Préparer l’Environnement Technique :

 Que faut-il pour commencer la première itération dans de
bonnes conditions ?
 Exemples : Mise en place des serveurs de développement et
de qualification, de l’intégration continue, et l’automatisation
de toutes les tâches possibles.
 On définit les modes de communication, la durée d’une
itération, etc.
 Quelques chiffres ...
59

 Sur 23 000 projets :

 25 % des projets sont réalisés dans les délais et budgets
initialement définis.

 27 % des projets sont arrêtés avant d’être mis en production.

 48 % des projets ont abouti, mais hors délai, hors budget, ou

sans respecter les exigences initiales.

 53 % de ces projets coutent 200% des estimations initiales.

Source : Chaos Report du Standish Group

 Quelques chiffres ...
60

Utilisation moyenne des

fonctionnalités d'applications
Toujours Souvent
7% 13%

Jamais
Parfois
45%
16%
Rarement
19%

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

 L’agilité - pour en finir avec ...
61

 L’utopie des spécifications complètes et immuables au

début du projet.
 Le désastreux effet tunnel.
 Les équipes compartimentées :
 Beaucoup d’intervenants.
 Communication peu aisée, régentée par Word et le courriel.

 Des objectifs multiples, pas toujours communs.

 Les planifications figées.

 Un certain nombre de gaspillages.
 => Un coût du changement très élevé.
 Travailler par cycles courts itératifs
62

On passe d’un mode prédictif …

Effet tunnel
… à un mode adaptif
Idées

itération
 Atelier Open-ended specifications
63

 Équipes :
 Deux équipes de taille égale.
 Matériel :
 Une feuille blanche pour chaque membre des 2 équipes.
 Des crayons de couleur pour chaque membre des 2 équipes.

 Des spécifications écrites au nombre des personnes dans

chaque groupe.
 Atelier Open-ended specifications
64

 Déroulement :
 Chaque personne reçoit une spécification écrite.
 Chaque personne dispose de 60 secondes pour représenter les
spécifications par un dessin.
 Discussion !
 Le planning poker
65

 Déroulement du planning poker

 Chaque participant reçoit un jeu de cartes.
 Sur chaque carte il y a une valeur possible pour l’estimation de la
complexité d’une story.
 Le Product Owner présente la story.
 Les membres de l’équipe posent des questions pour bien la comprendre
et débattent brièvement.
 Tous les participants présentent en même temps la carte choisie pour
l’estimation de la complexité.
 Le groupe discute des différences éventuelles.
 On recommence jusqu’à arriver à une convergence des estimations pour
la story, puis on passe à la suivante.
 Le planning poker
66

 Comme il est plus facile de faire des

estimations sur une échelle
prédéfinie plutôt que d’avoir à sa
disposition tous les entiers :
 La suite de Fibonacci est
généralement utilisée : 1, 2, 3, 5, 8,
13.
 La suite de Fibonacci est complétée :
 avec 0 et ½ pour les petites stories
 20, 40 et 100 pour les grandes
 La complexité
67

 La complexité est une note indiquant la complexité technique sur

une échelle de valeur relative qui utilise la suite de Fibonacci :

1 2 3 5 8 13 20 40 100
facile -> simple -> normal -> difficile -> très dur -> délirant

 Déterminée par l’équipe (démocratiquement) pendant une séance

de planning poker, et non par une métrique mécanique.
 N’est possible que sur un scope fonctionnel limité donc mieux
maitrisé :
Donne une évaluation plus fiable.
Aide le client à faire son choix pour la répartition des user stories dans le plan
d’itérations.
 La complexité
68

https://themindstudios.com/blog/agile-story-points-vs-hours/
 Atelier Planning poker (Salade de fruits)
69

 Équipes :
 Deux équipes de taille égale.
 Chaque équipe fera son propre planning poker.
 Matériel :
 Application ScrumCard installée sur les téléphones des participants.
 Product backlog de la salade de fruits.
 Déroulement :
 Chaque équipe doit estimer la complexité à découper les fruits définis dans le
Product Backlog.
 Tous les participants d’une équipe doivent se mettre d’accord sur l’estimation
de la complexité d’un item pour pouvoir passer au suivant.
 Atelier Planning poker (Salade de fruits)
70

 Product Backlog :

Id Item Priorité Complexité

1 Kaki

2 Clémentine

3 Noix

4 Pomme

5 Noix de coco
 Le tableau des tâches
71
 Le tableau des tâches sur Jira
72
 Le tableau des tâches en mode mural
73
Complexité des stories, complexité des tâches
74

 Pas de relation métrique d’un niveau de granularité à un autre. La somme des

complexités des taches d’une User story n’est pas égale au chiffre de la
complexité de la User story.

Release, P = 3
C = 20 Tache 1, C = 3
P = priorité métier
C : complexité technique
Release, P = 2
Tache 2, C = 13
C = 40
US 1, P=1
Release, P = 1 C=2
Tache 3, C = 20
US 2, P=2
C = 13 C=8
Tache 4, C = 8
 Conversion de la complexité en heures
75

A FAIRE EN COURS TERMINE

US 1, P=1
C=2
US 2, P=2 US 3, P=3
C=8 US 1, P=1
C=5
Durée = 7h C=2
Durée = ?h
Durée = 2h

US 4, P=4
C = 13
Durée = ?h
 La mêlée quotidienne
76

 La mêlée quotidienne appelée aussi :

 Stand-up meeting
 Daily scrum meeting

 Est défini avec un cadre pour l’optimisation du

déroulement :
 Durée limitée à 15 minutes
 Tout le monde debout
 3 questions posées à chaque membre de l'équipe :
◼ Qu’as-tu fait depuis la dernière fois ?
◼ Que prévois-tu de faire jusqu'à la prochaine réunion ?
◼ Qu'est-ce qui pourrait empêcher d'y arriver ?
 La mêlée quotidienne
77

 Objectifs de la mêlée quotidienne :

 Faire un point très rapide.
 Evaluer l'avancement du travail
 Identifier les obstacles nuisant à la progression.
 Réestimer le Reste à faire pour les tâches en cours, en heures.
 Garder l'équipe concentrée sur l'objectif du sprint
 Améliorer l'esprit d'équipe
 Mettre à jour le Burndown chart.
 Caractéristiques :
 Réunion démocratique : chacun peut s’exprimer.
 Transparence : "No good or bad news, just transparency" (Ken Schwaber).
 N'EST PAS un tribunal ou un moment pour les reproches et remontrances.
 Ce n’est pas un lieu pour les conversations.
 La mêlée quotidienne
78

 Bonnes pratiques :
 On ne se réfère pas au passé (il y a 3 mois, tu as dit que ...).
 On cherche des solutions, pas des coupables.

 On arrive à l'heure aux réunions :

◼ En cas de retard :
◼ On s'excuse.
◼ On paye une "pénalité de retard".
 Si tout le monde parle en même temps, on établit un stylo de
parole.
Équipe SCRUM durant un daily scrum meeting
79
 Atelier Scrum from hell
80

 Équipes :
 Deux équipes de 6 à 8 personnes :
◼ Une équipe Scrum.
◼ Une équipe d’observateurs.

 Matériel :
 Fiches avec objectif secret.
 Déroulement :
 Un membre de l’équipe Scrum est désigné comme Scrum Master.
 Chaque membre de l’équipe Scrum tire une carte au hasard.

 Le contenu de la carte doit être gardé secret.

 Chaque membre doit appliquer les recommandations de la carte

durant la réunion de 15 minutes.
 Déroulement d’une itération
81

 Début : Planning d’Itération

 Le Client valide les user stories qui seront réalisées pendant la
prochaine itération.
 Il a pu en supprimer, en ajouter, ou changer leur contenu depuis
la feuille de route globale du produit.
 Il donne la vision, le but de l’itération.

 Les développeurs déterminent ou confirment la charge associée

aux user stories sélectionnées, et valident (ou non) qu’ils
peuvent réaliser l’itération.
 Dans le cas ou l’objectif de l’itération n’est pas compatible avec
la durée, l’équipe révise le contenu et déplace les user stories.
 Déroulement d’une itération
82

 Milieu : Analyse, développement et test

 Les user stories sont découpées en tâches et positionnées sur la
colonne à faire.
 Les tâches les plus prioritaires sont déplacées dans la colonne En
cours.
 Chaque matin, la réunion de 15 minutes permet de faire le point
et d’identifier les problèmes à résoudre au plus vite.
 Pendant cette réunion, le tableau des tâches est mis à jour. Les
tâches sont déplacées dans les colonnes A faire/En cours/
Terminé.
 Déroulement d’une itération
83

 Fin : Démo, Rétrospective & Release

 Démo : Les développeurs font une démonstration au métier
(Product owner) et valident ce qui fonctionne et ce qui doit être
modifié.
 Rétrospective : On fait un bilan du fonctionnement de l’équipe,
les échecs sont analysés afin d’apporter les améliorations
nécessaires au processus.
 Release : On met la version en production si le client le
demande.
 Tableau des tâches : Mise à jour des tâches pour la prise en
compte de qui doit être refait.
 On recommence avec l’itération suivante.
 La revue d’itération
84

 Déroulement :
 Pas de slides
 En mode démonstration
 Mise en œuvre du réel
 Sur le serveur d'intégration
 Sauf exception, est orienté "utilisateur final"
 Points essentiels à aborder :
 Que fait-on de ce qui n'est pas fini ?
 Que fait-on des modifications et des anomalies ?
 Mise à jour du « product backlog »
 La rétrospective
85

 Déroulement :
 Les membres de l’équipe se réunissent après la revue d’itération.
 Ils dressent un bilan des succès et difficultés.
 Ils préparent un plan d’action pour améliorer le fonctionnement
de l’équipe.
 Le plan d’action est appliqué dès l’itération suivante.
 Points essentiels à aborder :
 Qu’est ce qui a fonctionné ?
 Qu’est ce qui n’a pas vraiment fonctionné ?
 Qu’aimerions nous essayer durant la prochaine itération ?
 Les rôles
86

 Client (PO) :
 Représentant du métier, du client final.
 Est le responsable du contenu fonctionnel.
 Il gère :
 Les backlogs (produit & sprints), contenant :
◼ les user stories et leur évolution
◼ Les priorités des user stories
◼ Il a le droit de changer d’avis à chaque début d’itération
 Le plan d'itérations => planning global
 Il est disponible pour répondre aux questions des
développeurs.
 Participe aux « cérémonies ».
 Les rôles
87

 Coach agile / ScrumMaster :

 Garant de l'agilité
 Facilitateur, effaceur d'obstacle
 Isolateur vis-à-vis de l'extérieur
 Anime les « cérémonies »
 Met à jour :
◼ les burndowns
◼ la vélocité
◼ tout élément de reporting
 Gère :
◼ la liste des risques / obstacles
◼ la liste des actions
 Le coach peut développer, mais pas au dépend de ses tâches de coach :
◼ ses tâches sont simples
◼ en cas de blocage; il passe la main facilement
 Les changements liés à l’agilité …
88

Imposer devient Faire Confiance

Contrôler devient Faciliter

Diriger devient Accompagner

 Les rôles
89

 Equipe :
 Taille
◼ la taille idéale : 7
◼ Principe : 7, +/- 2
◼ les contributeurs apportent un service, mais ne l’imposent pas

 S'organise comme elle l'entend

 Est responsable de terminer ses tâches

 Résout ses propres conflits

 Pas de rôles spécialisés

◼ On apporte ses compétences spécifiques, mais sans porter un label "expert"
◼ On transmet ses compétences

 L'opinion de chacun est importante et sera prise en considération.

 L’équipe est la clé.
 Flexibilité de Scrum (variation des rythmes)
90

Les rythmes possibles :

⚫ Rythme unique

❑Les itérations sont des sprints de durée fixe

❑La planification en début de chaque sprint
❑Une démo et une livraison potentielle à chaque fin de
sprint
❑Une réunion rétrospective à chaque fin de sprint
 Flexibilité de Scrum (variation des rythmes)
91

Les rythmes possibles :

⚫ Trois rythmes

Nous pouvons opter pour trois rythmes différents.

1. Chaque semaine, nous livrons ce qui est prêt à être livré.
2. Toutes les deux semaines, nous avons une réunion de
planification, de mise à jour de nos priorités et des plannings de
livraison.
3. Toutes les quatre semaines, nous avons une réunion
(rétrospective) pour améliorer nos processus.
 Flexibilité de Scrum (variation des rythmes)
92

Les rythmes possibles :

⚫ Rythme essentiellement piloté par les événements

1. Nous déclenchons une réunion de planification chaque fois que nous

commençons à ne plus rien avoir à faire.
2. Nous déclenchons la livraison d’une version dès que nous disposons d’un
ensemble de MMF (“Minimum Marketable Feature” = “fonctionnalité
minimale apportant de la valeur à l’utilisateur”).
3. Nous déclenchons spontanément un cercle de qualité à chaque fois que nous
tombons sur un même problème pour la deuxième fois. Nous faisons aussi
une rétrospective plus approfondie toutes les quatre semaines.
 Est-ce que Scrum est normatif ou adaptatif ?
93

On peut comparer les outils en regardant le nombre de règles qu’ils

fournissent :
❑Normatif signifie “plus de règles à suivre”
❑Adaptatif signifie “moins de règles à suivre”

❑100% de normatif signifie que vous n'avez pas besoin d'utiliser votre
cerveau, il y a une règle pour tout.
❑100% d’adaptatif équivaut à faire n’importe quoi, il n'y a aucune règle ni
aucune contrainte.
➔Les deux extrêmes de l'échelle sont ridicules.
 Est-ce que Scrum et Kanban sont normatifs ?
94
Comparons quelques outils sur une échelle normatif vs adaptatif :

RUP est assez normatif avec plus de 30 rôles, plus de 20

activités et plus de 70 artefacts ; une énorme quantité de
choses à apprendre.

XP (eXtreme Programming) est plus normatif que Scrum.

Il inclut une majorité des règles de Scrum + un ensemble
de pratiques d’ingénierie bien spécifiques comme le
développement piloté par les tests et la programmation
en binôme.
 Kanban en bref
95

· Visualisez le workflow :
o Divisez votre travail, décrivez chaque élément sur une fiche et mettez-la au mur.
o Tracez des colonnes, donnez-leur le nom des étapes du workflow et placez y les éléments de travail.
· Limitez le TAF : fixez des limites précises indiquant combien d’éléments peuvent être placés dans
chaque étape du workflow.
· Mesurez le temps de cycle (temps moyen pour traiter complètement un élément, appelé “lead time”
en anglais), optimisez le processus pour que le temps de cycle soit aussi court et prévisible que possible.
 Comparaison entre Scrum et Kanban
96

Dans les deux cas, nous suivons la progression d’un groupe d’éléments à
travers un workflow. Nous avons défini trois états : “À faire”, “En cours”,
et “Terminé”.

Quelle différence y a-t-il entre les deux tableaux Kanban et Scrum ?

 Comparaison entre Scrum et Kanban
97

❑ La différence est le petit 2 dans la colonne du milieu sur le tableau Kanban.

❑ Ce chiffre 2 signifie que “il ne peut pas y avoir plus de 2 éléments dans cette colonne
à un instant donné”.
❑ Avec Scrum, il n'existe pas de règle empêchant l'équipe de mettre tous les éléments
dans la colonne "En cours" en même temps ! Toutefois, la limite est le périmètre du
sprint.
❑ Donc Scrum limite le TAF indirectement, alors que Kanban limite le TAF directement.
 Flexibilité de Scrum (s’imprégner d’autres méthodes)
98

• Supposons que nous avons une

équipe de 4 personnes, et que
nous décidons de commencer
par une limite de TAF à 1.
• Chaque fois que nous
commençons à travailler sur un
élément, nous ne pouvons pas
démarrer un nouvel élément tant
que le premier n’est pas Fini
 Flexibilité de Scrum (s’imprégner d’autres méthodes)
99
Alors, si un TAF de 1 est trop faible, qu’est-ce-que cela donne avec un TAF de 8?
Supposez maintenant que nous avons un problème avec le serveur d'intégration,
Puisque nous ne pouvons pas terminer les éléments D et E, nous commençons à
travailler les éléments F et G
 Flexibilité de Scrum (s’imprégner d’autres méthodes)
100

Au bout d'un moment, nous atteignons notre

limite Kanban - 8 éléments dans « En
cours »

À ce stade, nous ne pouvons plus ajouter

d'éléments.

Nous ferions mieux de régler ce problème de

serveur d'intégration !

La limite de TAF nous a invités à réagir et à

éliminer le goulet d'étranglement au lieu
d'empiler du travail non fini.

C’est pas mal ! Mais …

On peut mieux faire.

 Flexibilité de Scrum (s’imprégner d’autres méthodes)
101

Si la limite de TAF était de 4, nous aurions réagi beaucoup plus tôt, nous donnant ainsi un
meilleur temps de cycle moyen.
 De plus en plus détaillé dans les spécifications
102

Produit Ensemble des fonctionnalités

Release Une macro-fonctionnalité (ex : gestion des clients)

Thème Domaines, catégories : subdivision d’une release

Epic Subdivision d’un thème; macro User Story

User story Scénario utilisateur, unitaire

Tache de
développement
 « having things done » Jeff Sutherland
103

Obsession d’une équipe agile : avancer

Il faut donc pouvoir distinguer clairement ce qui est fait et
ce qui reste à faire.
 En début de projet, on définit les conditions d’achèvement
– d’une tâche (tests automatisés et qui passent, intégration, mais
éventuellement aussi alimentation de certains documents, description d’une
conception, de l’exploitabilité, etc)
– d’une itération, d’une release, du projet
 On renseigne l’avancement par :
– déplacement de post-it sur le mur

– le burndown chart de l’itération

C’est très motivant pour l’équipe
 Reporting : le Burndown chart
104

Un burndown produit et un par itération (par sprint).

Représente le travail à faire, par la somme des complexités de l’itération
Chaque US terminée permet de faire baisser le RAF
Très visuel. Permet de voir l’évolution de la complexité
 Analyse du Burndown chart
105

BDC Raisons
Dès le début du sprint l’équipe constate que la
complexité réelle (traitée) dépasse la
complexité estimée.
►Mauvaise estimation de la charge.
Vers la fin du sprint l’équipe constate que la
complexité réelle commence à dépasser la
complexité estimée.
►Mauvaise estimation de la charge.
Dès le démarrage du sprint, des tâches non
planifiées sont lancées et tuent le sprint.
►Ajout de fonctionnalités par le Product
Owner.
 Analyse du Burndown chart
106

BDC Raisons
Démarrage en règle, en abordant une user story,
on se rend compte que l’évaluation de la
complexité est en dessous de la réalité, d’où la
nécessité d’une réévaluation.
►Mauvaise estimation de la charge.
►Ajout d'anomalies costauds à corriger.

Au milieu du sprint, des tâches non planifiées sont

lancées et tuent le sprint.
►Ajout d'anomalies costauds à corriger.
►Ajout de fonctionnalités par le Product Owner.
 Analyse du Burndown chart
107

BDC Raisons
Le sprint démarre avec une complexité réelle
supérieure à la complexité estimée.
►Mauvaise estimation de la charge

Dès le début du sprint l’équipe constate que la

complexité réelle (traitée) est en dessous de la
complexité estimée, d’où la nécessité d’une
réévaluation.
►Mauvaise estimation de la charge.
 Analyse du Burndown chart
108

BDC Raisons

Lors de la réunion de planification de sprint,

toutes les tâches n'avaient pas été estimées
(ni même identifiées pour certaines), ça
arrive. Avant qu'elles ne le soient, les
burndown charts ressemblaient au BDC7’,
donnant l'impression qu'on finirait avant la
moitié du sprint. Après, ça a repris une allure
plus normale.
►Absence d’estimation de la charge pour
certaines tâches.
 L'agilité pour quel résultat ?
109

En 2007, l’APLN (Agile Project Leadership Network) a mené une étude sur
1700 entreprises dans 71 pays.
Les conclusions indiquent notamment :

• 90% ont constaté des gains de productivité

• 55% ont constaté des gains de productivité d’au minimum 25%
• 85% ont constaté une réduction des bogues
• 83% ont constaté une réduction significative du Time To Market
• 66% ont constaté une réduction significative des coûts

Les deux plus grands bénéfices constatés par les entreprises vis-à-vis de leur
utilisation de l’agilité concernent la meilleure gestion du changement et
l’amélioration de la productivité.

Constat : le choix « agile » obtient de meilleurs résultats.

Le risque « agile » se révèle « payant »
 Vocabulaire Scrum
110

Scrum : en anglais signifie la mêlée.

Sprint : petites itérations de durée fixe (appelées des sprints et durant habituellement de 1 à 4
semaines) se terminant par une démonstration avec un produit potentiellement livrable.

Product backlog : liste des briques fonctionnelles composants le produit.

Iteration backlog (sprint backlog) : détaille le contenu d’une brique fonctionnelle affectée à un sprint
(itération).

Planification de sprint : Sélection des backlog selon les priorités et affectation des équipes.

Daily scrum : mêlée quotidienne

Rétrospective : Réunion à la fin du sprint permettant de tirer profit du processus déroulé durant le
sprint (analyse des problèmes et des blocages).

Lead time : temps de cycle

MMF : Minimum Marketable Feature. Fonctionnalité minimale qui a de la valeur pour l’utilisateur