Présentation Scrum avec Alexis Monville lors de l'Agile Tour Bordeaux 2012

1. SCRUM by the Book
Scrum, méthode agile dédiée à la gestion de projets

2. Merci aux Sponsors
Alexis Monville – alexis@ayeba.fr
2
Philippe Launay
13/09/2010
2
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

3. Consultant Agile
Coach Agile & team Coordinator
Qui sommes nous…
Alexis Monville – alexis@ayeba.fr
3
Philippe Launay
13/09/2010
3
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

4. 5 minutes
Alexis Monville – alexis@ayeba.fr
4
Philippe Launay
13/09/2010
4
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

5. un produit
Alexis Monville – alexis@ayeba.fr
5
Philippe Launay
13/09/2010
5
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

6. TODO
DOING
DONE
réunionadapter
les1plus quotidienne
démonstration
fonctionnalités
rétrospective
planification
àordonner
collaborer
4 importantes
semaines
améliorer
Alexis Monville – alexis@ayeba.fr
6
Philippe Launay
13/09/2010
6
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

7. Méthodes agiles
Alexis Monville – alexis@ayeba.fr
7
Philippe Launay
13/09/2010
7
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

8. Scrum
 Scrum est une méthode de gestion de projet simple pour gérer des projets
complexes.
 Conçue à l’origine pour le développent de logiciels, Scrum est aussi utilisé
dans d’autres secteurs d’activités.
 Conçue pour améliorer grandement la productivité dans les équipes
auparavant paralysées par des méthodologies plus lourdes.
 Scrum ne s’occupe pas
d’ingénierie.
 Scrum veut dire « mêlée ».
 Scrum est la méthode Agile
la plus populaire.
Alexis Monville – alexis@ayeba.fr
8
Philippe Launay
13/09/2010
8
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

9. Gérer un projet c’est …
 Gérer la relation d’un client et
du ou des fournisseurs
 Gérer la réalisation de la vision
du client
Alexis Monville – alexis@ayeba.fr
9
Philippe Launay
13/09/2010
9
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

10. Le projet idéal …
 Plan
Analyse
Conception
Développement
Projet I
Tests
Documentation
Déploiement
Go live
T0
Alexis Monville – alexis@ayeba.fr
10
Philippe Launay
13/09/2010
T0 + 6 mois
10
12/10/2012
T0+12 mois
temps
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

11. Les débuts du projet
Projet sur les rails
Un contrat clair, bien détaillé
Une équipe motivée
Un client rassuré
Alexis Monville – alexis@ayeba.fr
11
Philippe Launay
13/09/2010
11
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

12. Alexis Monville – alexis@ayeba.fr
12
Philippe Launay
13/09/2010
12
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

13. Pendant ce temps là ….
L’expression des besoins n’a pas fourni les besoins réels
du client
Premier problème d’architecture
Certains pré requis ont été sous estimé
Difficulté technique a été mal évaluée
Problème de disponibilité pour couvrir
un autre projet plus urgent
Alexis Monville – alexis@ayeba.fr
13
Philippe Launay
13/09/2010
13
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

14. Pas de soucis
 Plan modifié, chevauchements pour lisser les « petits » retards
 …pour finalement déraper
Analyse
Conception
Développement
Projet I
Tests
Documentation
Déploiement
Go live
T0
Alexis Monville – alexis@ayeba.fr
14
Philippe Launay
13/09/2010
T0 + 6 mois
14
T0+12 mois
12/10/2012
temps
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

15. Pas de soucis
 Plan modifié, chevauchements pour lisser les « petits » retards
 …pour finalement déraper
Analyse
Conception
Développement
Tests
Projet I
Documentation
Déploiement
Go live
T0
Alexis Monville – alexis@ayeba.fr
15
Philippe Launay
13/09/2010
T0 + 6 mois
15
T0+12 mois
12/10/2012
temps
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

16. Alexis Monville – alexis@ayeba.fr
16
Philippe Launay
13/09/2010
16
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

17. Conclusions…
Un projet en retard permet le chevauchement des
différentes étapes
Alors pourquoi pas le faire dès le départ?
Alexis Monville – alexis@ayeba.fr
17
Philippe Launay
13/09/2010
17
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

18. Le nouveau plan … itératif
Faire un peu de tout en même temps
On garde le jalon
de fin du projet
traditionnel
Analyse
Conception
Développement
Sprint
Projet
Tests
Chaque sprint
contient un peu
de chacune des
étapes du projet
traditionnel
Documentation
Déploiement
Qualité
Livraison
intermédiaire à la
fin de chaque
sprint
Rollout & Packaging
Installation Site
Version intermédiaire
Go live Version finale
Alexis Monville – alexis@ayeba.fr
18
Philippe Launay
13/09/2010
18
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

19. SCRUM : Un cadre de gestion léger pour gérer des projets
 Des rôles
 Le responsable produit
 le facilitateur
 les membres de l’équipe
Equipe
 Des artefacts
 La liste à faire Produit / De l’itération
 Les courbes d’avancement
 La liste des obstacles
 Un processus jalonné de cérémonies
 Une planification
 Un suivi du reste à faire
Alexis Monville – alexis@ayeba.fr
19
Philippe Launay
13/09/2010
19
12/10/2012
Product Owner
Utilisateurs
Facilitateur
Stake Holders
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

20. Le processus
 Un processus itératif basé sur ce que l’on appelle un sprint – un effort
de 15 à 30 jours concentré sur des objectifs fixes, qui se répètent.
Rétrospective
Démo
24 h
Mêlée Quotidienne
Planning iteration
 Chaque itération améliore la valeur du produit, apporte de nouvelles
fonctionnalités ou des améliorations, qui peuvent être livrées au
client.
2à4
semaines
Backlog produit
Itération
Backlog Itération
Planifier
Faire
Produit
Contrôler
Agir
temps
Alexis Monville – alexis@ayeba.fr
20
Philippe Launay
13/09/2010
20
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

21. Collaboration avec le client
On organise des réunions avec le client
Enfin production, service et client dans le même bateau
Objectifs
Etablir une relation de confiance
Comprendre le besoin fonctionnel
Discuter les besoins fonctionnels
Prioriser les besoins fonctionnels
Touver un responsable produit
Alexis Monville – alexis@ayeba.fr
21
Philippe Launay
13/09/2010
21
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

22. Le product owner
Recense les besoins dans
un Product backlog
•Histoire 2
5
•Histoire 5
13
Exprime la vision pour le produit
•Histoire 10
20
•Histoire 3
3
Prend en compte la gestion
des risques
•Histoire 8
•Histoire 19
•Histoire 14
20
•Histoire 6
20
•Histoire 4
13
•Histoire 7
8
•Histoire 11
20
•Histoire 13
5
•Histoire 9
13
•Histoire 12
3
•Histoire 15
5
Product Backlog
Exprime la valeur des fonctions
Priorité
8
Haute
•Histoire 1
Basse
Priorité
Doit être priorisé de façon absolue
Alexis Monville – alexis@ayeba.fr
22
Philippe Launay
13/09/2010
22
12/10/2012
40
Sprint en
cours
Ajouts à
tout
moment
Peut être
supprimée
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

23. Chaque itération est un micro projet
 En début d’itération, l’équipe planifie et s’engage a atteindre son
objectif
 En fonction de la vélocité précédente
 En fonction de la capacité pour le sprint a venir
 Les estimations sont faite collectivement par les équipes
 Utilisation d’estimation relative (Story Points)
 Session d’estimation avec le poker card game
 L’équipe s’auto organise pour atteindre son objectif
 L’équipe fait une rétrospective à la fin de chaque itération pour
trouver les axes d’améliorations
Alexis Monville – alexis@ayeba.fr
23
Philippe Launay
13/09/2010
23
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

24. Itératif mais planifié
•Histoire 2
5
•Histoire 5
13
•Histoire 10
20
 En tenant compte du type de fin
(date, périmètre fonctionnel, etc.)
•Histoire 3
3
•Histoire 8
20
 Une réunion une fois avant le début de chaque itération
•Histoire 14
40
•Histoire 6
13
•Histoire 4
20
•Histoire 7
13
•Histoire 11
20
•Histoire 13
5
•Histoire 9
13
•Histoire 12
20
•Histoire 15
20
 Un plan de releases basé sur le backlog produit
Priorité
8
Haute
•Histoire 1
 En tenant compte de la vitesse de l’équipe
 Estimation / ré estimation
 Estimation nouvelle stories
 Adapter le plan en fonction de l’avancement
Sprint
Sprint
Release
Sprint
Version partielle
utilisable
Sprint
Sprint
Version partielle
utilisable
Version finale
Alexis Monville – alexis@ayeba.fr
24
Philippe Launay
13/09/2010
Sprint
Sprint
24
12/10/2012
Basse
Priorité
Release
Sprint
temps
Product Backlog
Version finale
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

25. Le Scrum Master
 Il dirige l’équipe, résous ou élimine les Obstacles et travaille
constamment pour s’assurer que l’équipe est dans les meilleures
circonstances pour atteindre les objectifs fixés pour le sprint.
 Il est un mélange de coach, de réparateur et de gardien.
 Il est un bouclier pour l’ équipe.
 Il doit aider l’équipe à rester concentrée sur l’objectif
Alexis Monville – alexis@ayeba.fr
25
Philippe Launay
13/09/2010
25
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

26. L’équipe
 Réalise le travail nécessaire à résoudre
les problèmes ou nécessaire pour satisfaire
les nouveaux concepts.
Equipe
 est normalement constituée de 7 personnes (+/- 2).
 Les membres décident comment faire le travail et comment
le répartir. Il n’y a pas de rôles spécifiques, tout le monde doit être
capable d’échanger une tâche avec un autre membre.
Cela n’empêche pas d’avoir tout de même des membres avec plus
d’expertises sur un sujet particulier.
Alexis Monville – alexis@ayeba.fr
26
Philippe Launay
13/09/2010
26
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

27. Suivre l’avancement du projet
 Les courbes de suivi du reste à faire
 Prévision en fonction de la vélocité et/ou de la capacité
 Suivi de l’avancement de la release, montre le reste à faire en story points, ou en
Story
heures
points
En avance
Vélocité idéale
100
En retard
Effort restant
à
faire
Sprint 1
Alexis Monville – alexis@ayeba.fr
27
Philippe Launay
13/09/2010
Sprint 2
27
Sprint 3
12/10/2012
Sprint 4
temps
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

28.  Selon les acteurs (développeur, utilisateur, testeur)
 Selon le niveau (tâche, Fonction, Itération, Release)
 Il faut une définition claire, ou une liste
d’état permettant de savoir quelle est la situation
 Utiliser cette définition comme garantie de
qualité
Alexis Monville – alexis@ayeba.fr
28
Philippe Launay
13/09/2010
28
12/10/2012
Itération
 Le point de vue peut–être différent :
• Toutes les fonctions sont finies
• Contrôles de fin d’itération faits
• Produit partiel livré
• Rétrospective faite, actions documentées
• Tests d’acceptations vérifiés
• Documentation réalisée
• Release notes réalisées
• Acceptée par le product owner
Histoire
 Importance de définir quand une fonctionnalité
est finie
• Toutes les itérations finies
• Plus de reste à faire avant le passage
en production
• Couverture du code par des Tests (Junits)
• Existence de tests automatisés
• Vérification qualité du code
• Documentation du code
Tâches
 Nécessité de connaitre le « fini »
chaque équipe doit avoir sa propre définition
Release
Définition de « Fini »
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

29. Merci de votre attention
Alexis Monville – alexis@ayeba.fr
29
Philippe Launay
13/09/2010
29
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr

30. Questions?
Alexis Monville – alexis@ayeba.fr
30
Philippe Launay
13/09/2010
30
12/10/2012
Philippe Launay philAgile@free.fr
PhilAgile@free.fr