Formation "Initiation Scrum" (sur 1 ou 2 jours)
- comprendre les principes agile
- découverte de SCRUM (les rôles, les livrables, les évènements)
- expérimenter par la pratique
3. • Cochez la bonne
réponse
• Relisez cette page à
la fin de la journée.
Vos réponses sont
elles toujours les
mêmes ?
Vrai Faux
Les équipes agiles font peu de planning
L’agilité n’est pas adaptée pour un projet à budget fixe
Les développeurs n’ont pas les compétences humaines
nécessaire pour parler avec les clients
Déplacer des personnes entre les projets aide à diffuser
l’expertise et améliore l’organisation
Les équipes agiles n’écrivent pas de documentation
Certaines personnes ont besoin d’être dirigées
Les équipes agiles n’ont pas besoin de spécifications
Ceci est un
exercice 2 min
4. • Qui a déjà utilisé L’agilité ?
• Qui a déjà travaillé en équipe auto-organisée
(sans chef) ?
• Qui a déjà conduit un projet, dirigé une équipe ?
• Qui connait SCRUM ?
• Prenez un post-it et marquez 1 chose que vous
voulez apprendre dans ce stage
5. - nom
1. La capacité de répondre rapidement à une demande
changeante tout en contrôlant le risque
2. Flexibilité, la capacité à s’adapter rapidement,
efficacement et de manière délibérée
Le courage d’être assez honnête pour admettre qu’écrire
des logiciels sur mesure est complexe et ne peut pas être
parfaitement planifié car le besoin change inévitablement
7. 10 % 10 %
Prix total = 110%
Valeur = 90%
Périmètre contractuel
1 - Cycle en V
imprévus
inutiles
Prix total = 100%
Valeur = 100%
Périmètre initial
2 - Agile
10 %
imprévus
10 %
inutiles
gaspillage
avenant (v1.1)
Expérience : en moyenne 20% d’écart à la fin
8. 1 - Cycle en V
2 - Agile
Expérience : plus un bug est corrigé tard, plus il coûte cher
Coût des
bugs
Fonctionalités
Bugs
Imprévus
Fonctionalités
Bugs
Imprévus
Inutile
Temps passé
Temps passé
10. Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation
exhaustive
La collaboration avec les clients plus que la négociation
contractuelle
L’adaptation au changement plus que le suivi d’un plan
Source : http://agilemanifesto.org/
importantEssentiel
Nous reconnaissons la valeur des éléments de droite,
mais privilégions ceux de gauche !!
11. Transparence
Toute méthode empirique nécessite de la transparence pour ses ajustements successifs
Courage
Affronter les vrais problèmes, oser des solutions innovantes nécessite du courage
Respect
Le respect de chacun est essentiel pour que le groupe collabore efficacement
Responsabilité
Faire sa part de travail et savoir reconnaitre ses torts
Engagement
Une valeur essentielle si on souhaite réussir un projet quel qu’il soit
Humilité
C’est une valeur utile pour éviter de s’acharner sur des choses qui, visiblement, ne fonctionnent
pas bien.
Confiance
La confiance dans les autres est nécessaire à la bonne collaboration
(de toute façon, on a prévu des moyens de s’adapter si des choses ne fonctionnent pas bien)
Ouverture
L’ouverture d’esprit est nécessaire pour profiter des tous les points de vue
16. L’intelligence collective émerge de principe simples
mais souvent contre-intuitifs :
• Fail fast and enjoy the fun !
• YAGNI (You Ain't Gonna Need It)
• KISS (Keep It Simple and Stupide)
• If it hurts, do it more often !
• Simplicity (the art of maximizing the amount of work not
done) is essential
• DRY (Don’t Repeat Yourself)
• Perfection is when nothing can be removed,
(not when you cannot add something more!)
• It’s important ? : Do it always ; It’s not ? : do it never !
17. Equipe projet (Scrum team) = PO + Scum Master + DEV team
Product Owner
• Pilote le projet, à l’aide du Product Backlog
• Optimise la valeur métier du produit fini
Scrum Master
• Garant de la méthode et de l’ambiance de travail
• Protège l’équipe des perturbations externes
• Aide l’équipe à s’auto-organiser et aide le PO à tenir son rôle
Equipe de réalisation
(DEV team)
• Elle s’auto-organise
• Livre des incréments terminés (potentiellement livrables)
• Regroupe toutes les compétences nécessaires au projet
18. « Chaque Sprint, vous
pouvez nous donner
quelque chose de
nouveau à faire »
Equipe de réalisation
« Chaque Sprint, nous
vous laissons travailler
sur nos besoins les plus
importants »
Clients
FLEXIBILITÉ STABILITÉ
21. ID Catégorie Module Titre Description Risque
Business
Value
Points
Charge
ROI
estimé
1.1 Back-Office éditorial Accueil Période d'essai 5 2 2,5
1.2 Back-Office éditorial Accueil Authentification ! 3 4 0,8
3Back-Office éditorial Parution PDF à destination d'un imprimeur 1 4 0,3
6.1 Application de lecture Publication Gestion des parutions (CRUD) 3 4 0,8
6.2
Application de lecture Kiosque Visualisation des publications
abonné !! 4 2 2
6.3 Application de lecture Authentification Limitation du nombre d'appareils 1 3 0,3
23Back-Office éditorial Page de couverture Informations en surimpression 2 4 0,5
25Back-Office éditorial Article Multimédia / Publicité 2 4 0,5
27Back-Office éditorial Article Chapeau de l'article 2 3 0,7
28Back-Office éditorial Article Héritage d'article 3 4 0,8
8.2 Back-Office commercial Abonnement Souscription !!! 4 2 2
8.4 Back-Office commercial Abonnement Interfaçage WS ADV 2 4 0,5
31Back-Office commercial Ayants droits Imports de fichiers plats (csv / txt) 1 3 0,3
43Back-Office commercial Abonnement Upload des documents 3 3 1
44Back-Office Administration Contenu illicite Notification ! 1 2 0,5
45Back-Office Administration Contenu illicite Workflow état notification 1 2 0,5
47Back-Office Administration Divers Archivage / suppression 2 3 0,7
priorité
22. exigence
exigence
0-6 mois 6-12 mois 12+ mois Futur
Si rien ne
change,
alors …
Idée
vague
Idée
Idée
exigence
exigence
exigence
exigence
exigence
exigence
Sprint 1
Sprint 2+3
Sprint ≥ 4
23. Analyse, évaluation et sélection
des items du Product Backlog
Définition de l’objectif et
du périmètre du sprint
Décomposition en plan d’action
sous forme de tâches
Sprint Backlog
Standards
Conventions
Normes
Définition de
terminé
Equipe de réalisation
Capacité + Vélocité
Product Backlog
priorisé et estimé
Durée : 6h pour un sprint de 3 semaines
24. Analyse, évaluation et sélection
des items du Product Backlog
Définition de l’objectif et
du périmètre du sprint
Décomposition en plan d’action
sous forme de tâches
Sprint Backlog
Standards
Conventions
Normes
Définition de
terminé
Equipe de réalisation
Capacité + Vélocité
Product Backlog
priorisé et estimé
Durée : 6h pour un sprint de 3 semaines
Erreurs à éviter
• Les items du backlog ne sont
pas prêts pour la réalisation
• Les items sont non chiffrés
• Pas de critères d’acceptances
• L’équipe ne connait pas sa
capacité de production
25. • Tous les jours
• 15 min
• Même lieu, même heure
• Suivi du Reste à Faire (ex. BurnDown chart)
• Synchronisation de l’équipe et du travail en cours :
• Qu’as-tu terminé hier ?
• As-tu des problèmes ?
• Que vas-tu faire aujourd’hui ?
Scrum Master +
Equipe de réalisation
• Planning pour la journée
• Pb ou questions à traiter hors séance
• Reste à faire réévalué
26. • Tous les jours
• 15 min
• Même lieu, même heure
• Suivi du Reste à Faire (ex. BurnDown chart)
• Synchronisation de l’équipe et du travail en cours :
• Qu’as-tu terminé hier ?
• As-tu des problèmes ?
• Que vas-tu faire aujourd’hui ?
Scrum Master +
Equipe de réalisation
• Planning pour la journée
• Pb ou questions à traiter hors séance
• Reste à faire réévalué
Erreurs à éviter
• Parler en même temps
• Tenter de résoudre un pb
en séance
• Se moquer / Juger
• Avoir des réactions non
productives
27. • Daily Scrum : Un plan pour chaque journée !
• Propriété collective du code :
Quick Design Session
Pas de « chasse gardée »
• Intégration continue
• Tests automatisés
Tests unitaires
Tests fonctionnels (Critères d’acceptance)
• Qualité industrielle :
Respect conventions + Bonnes pratiques
Modules fonctionnels (AB testing, Design for failure…)
Relecture de code (Pair programming, Sonar…)
• Documentation (Wiki + Quick Doc Sessions)
28. Présentation de l’état du projet
et de l’incrément (démonstration)
Recherche du feedback
Mise en place d’une stratégie
pour la suite du projet
Product Backlog + Road Map à jour
Contexte
projet
Product
Backlog
Sprint Backlog Incrément
Tâches
Comité de
pilotage
Durée : 3h pour un sprint de 3 semaines
29. Présentation de l’état du projet
et de l’incrément (démonstration)
Recherche du feedback
Mise en place d’une stratégie
pour la suite du projet
Product Backlog + Road Map à jour
Contexte
projet
Product
Backlog
Sprint Backlog Incrément
Tâches
Erreurs à éviter
• Démo de plus d’une heure
• La démo n’est pas une recette
• Pas de critères d’acceptance
• Le contexte projet n’est pas
pris en compte
• Pas de vision stratégique à
plus d’un sprint
Comité de
pilotage
Durée : 3h pour un sprint de 3 semaines
30. Etablir une vision partagée de
l’efficacité actuelle de l’équipe
Identifier 1 ou 2 leviers d’amélioration
Identifier et choisir 1 ou 2 actions
réalisables durant le prochain sprint
Plan d’action pour s’améliorer
Bilan de la
dernière Rétro
Bilan de la Revue
Durée : 2h15 pour un sprint de 3 semaines
31. Etablir une vision partagée de
l’efficacité actuelle de l’équipe
Identifier 1 ou 2 leviers d’amélioration
Identifier et choisir 1 ou 2 actions
réalisables durant le prochain sprint
Plan d’action pour s’améliorer
Bilan de la
dernière Rétro
Bilan de la Revue
Durée : 2h15 pour un sprint de 3 semaines
Erreurs à éviter
• Parler tous en même temps
• Régler ses comptes
• Cacher les problèmes
• Essayer de résoudre les pb
en séance
• Etablir un plan d’action top
ambitieux
32. • Exploiter au maximum chaque
opportunité
• Se débarrasser du monolithe
• Une meilleure qualité
• Une véritable réactivité au service du
métier
• Des personnes plus heureuses avec un
travail qui a du sens
• Un flot continue de haute valeur ajoutée
L’Espoir La triste réalité
• Une dette technique importante
• Des mauvaises habitudes de codage
• Pas de temps dédié pour les tests
• Le micro-management des managers qui
empêche l’auto-organisation
• Des clients finaux qui ne peuvent avoir des
livraisons que tous les 15 mois car elles sont
trop ambitieuses, trop chères, trop risquées,
et prennent tellement de temps à être
implémentées
Scrum c’est léger, simple, facile à comprendre,
mais généralement difficile à maîtriser.
Soyez préparés !
33. 1. Y a-t-il un Product Owner identifié, pilotant le projet ?
2. Y a-t-il une équipe de réalisation de 3 à 9 membres ?
3. Y a-t-il un Scrum Master nommé ?
4. Y a-t-il un Product Backlog ordonné et priorisé ?
5. Y a-t-il un Sprint Backlog montrant le reste à faire pour le sprint en cours ?
6. Chaque sprint dure entre 1 et 4 semaines ?
7. Le logiciel produit est-il potentiellement livrable à la fin de chaque Sprint ?
8. Est-ce que l’équipe créé un plan pour le Sprint durant une réunion de Sprint
Planning ?
9. Est-ce que l’équipe créé un plan pour chaque journée durant le Daily Scrum ?
10.Est-ce que l’incrément est inspecté par les « stakeholders » (direction,
utilisateurs…) durant la Revue de Sprint ?
11.Est-ce que l’équipe projet (ou Scrum Team = DEV + PO + SM) effectue une
Rétrospective à la fin de chaque Sprint ?
35. Exigences :
• Une ville verte, belle et agréable à vivre
• Les logement individuels et collectifs
• Une ville à la pointe de la technologie
• Faible impact environnemental
• Des transports en communs performants
• Des facilités pour les commerces et les entreprises
• Des bâtiments pour les services administratifs
• Des équipements collectifs :
• Loisirs
• Education
• Santé
• Une ville facile à identifier
• Des voies de communication : rues, routes et ponts
36. 1. Identifier les items et créer le Product Backlog
2. Evaluer et prioriser les items du Product Backlog
3. Estimer l’effort à fournir pour la réalisation
4. Etablir une road map
5. Faire le sprint planning du 1er sprint
37. 1. Identifier des items permettant de répondre aux exigences
2. Créez 1 post-it par item
• Vous devriez avoir entre 10 et 15 items
15 min
Ne cherchez pas la perfection, faites au mieux !
38. Votre équipe à 300 balles de ping-pong à dépenser
1. Donnez une valeur (nb de balles) à chaque item
2. Deux items ne peuvent pas avoir la même valeur
3. Ecrivez cette valeur relative sur chaque post-it
4. Triez
15 min
39. 1. Choisissez un item d’une taille moyenne et donner lui la valeur « 5 »
2. Chacun prend un set de carte de planning poker jusqu’à 20
3. Votez pour donner une valeur d’effort (de réalisation) pour chaque item
note : cet effort est relatif
• Si les votes sont proches, choisissez la valeur la plus haute
• Si les votes sont trop différents : argumentez
4. Ecrivez l’effort sur chaque post-it
5. Faites la somme de l’effort total
15 min
40. priorité
20 min
1. Répartissez les items sur une carte en 2D
2. Tracer des lignes pour déterminer le périmètre des 4 premier sprints
thèmes
catégories
items
fonctionnalités
important, nécessaire
accessoire, de l’ordre du confort
Sprint 2
Sprint 1
Sprint 3
Backlog
41. 10 min
1. Pour le sprint 1 et 2, décomposez les items en post-it avec
une charge de travail relative ≤ 3
2. Pour les sprint 3 et 4 décomposez les items en post-it avec
une charge de travail relative ≤ 8
42. 150 min
6 sprints de 25 min :
• 5 min Planning
• 10 min Réalisation
• 5 min Revue
• 5 min Rétrospective
43. 10 min
J’ai passé une journée très intéressante à apprendre tout ces
trucs de SCRUM. Mais quand je vais retourner à mon poste je
vais toujours devoir livrer toutes les fonctionnalités du périmètre
commandé en tenant les délais et les coûts.
Quel est le rapport de tout ceci avec ma mission au quotidien ?
44. • Lisez le SCRUM Guide :
http://scrumguides.org/
• Evaluez cette formation :
http://tinyurl.com/kc-satisfaction-scrum
READ
THE GUIDE