Discover Agile core values and principles during a captivating sessions mixing theory, workshops and games…
We love to share our values and help your team be powerful, solid and efficient.
4. C R É E Z V O T R E P R O P R E C A R T E
• Choisissez un pseudonyme
• Inscrivez-le au bas du recto de la carte
• Inscrivez au dos de la carte une information sur vous que les autres ne
connaissent pas.
5. É C H A N G E Z - V O U S L E S C A R T E S
• Quand une carte vous donne envie de poser une question, conservez-là,
sinon continuez à échanger.
6. D É C O U V R E Z U N S E C R E T
• Un volontaire pour poser une question sur l’information secrète?
7. B I E N C O M M E N C E R L A J O U R N É E !
S P E E D B O A T
8. FOR C ESA X ES D ’ A M É L IORAT IO N
D I F F I C U LT ÉS
9. A G I L I T É O R I G I N E S & P R I N C I P E S
R E T O U R A U X S O U R C E S
10. L E M A N I F E S T E A G I L E
P E R S O N N E S E T I N T E R A C T I O N SP R O C E S S U S E T O U T I L S
L O G I C I E L Q U I F O N C T I O N N ED O C U M E N TAT I O N S U P E R F L U E
C O L L A B O R AT I O N AV E C L E C L I E N T
N É G O C I AT I O N À PA RT I R D ' U N
C O N T R AT
A D A P TAT I O N A U C H A N G E M E N TS U I V I D ' U N P L A N
11. - 1 -
“Notre plus haute priorité est de satisfaire le client en livrant
rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée.”
12. - 2 -
“Accueillez positivement les changements de besoins,
même tard dans le projet.
Les processus Agiles exploitent le changement
pour donner un avantage compétitif au client.”
13. - 3 -
“Livrez fréquemment un logiciel opérationnel
avec des cycles de quelques semaines à quelques mois
et une préférence pour les plus courts.”
14. - 4 -
“Les utilisateurs ou leurs représentants et les développeurs doivent
travailler ensemble quotidiennement tout au long du projet.”
15. - 5 -
“Réalisez les projets avec des personnes motivées.
Fournissez-leur l’environnement et le soutien
dont ils ont besoin et faites-leur confiance
pour atteindre les objectifs fixés.”
16. - 6 -
“La méthode la plus simple et la plus efficace pour transmettre
de l’information à l'équipe de développement
et à l’intérieur de celle-ci est le dialogue en face à face.”
17. - 7 -
“Un logiciel opérationnel est la principale mesure d’avancement.”
18. - 8 -
“Les processus Agiles encouragent
un rythme de développement soutenable.
Ensemble, les commanditaires, les développeurs, et les utilisateurs
devraient être capables de maintenir
indéfiniment un rythme constant.”
19. - 9 -
“Une attention continue à l'excellence technique
et à une bonne conception renforce l’Agilité.”
20. - 1 0 -
“La simplicité, c’est-à-dire l’art
de minimiser la quantité de travail inutile
est essentielle.”
30. T H E S C R U M G U I D E
L A R É F É R E N C E
31. S C R U M V S . G A S P
C E Q U ’ E S T S C R U M & C E Q U E C E N ’ E S T PA S
32. U N C A D R E S I M P L E & L É G E R
Rôles
Product Owner
Scrum Master
Equipe
Cérémonies
Sprint Planning
Sprint Review
Retrospective
Daily Scrum
Artéfacts
Product Backlog
Task Board
Burndown Charts
35. L E P R O D U C T O W N E R
• Définit les fonctionnalités du produit.
• Choisit la date et le contenu de la release.
• Responsable du retour sur investissement.
• Ordonne le backlog en fonction de la “valeur métier”.
• Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire.
• Accepte ou rejette les résultats.
37. L E S C R U M M A S T E R
• Représente le management du projet.
• Responsable de faire appliquer par l’équipe les valeurs et les pratiques de
Scrum.
• Élimine les obstacles et s’assure que l'équipe est complètement
fonctionnelle et productive.
• Facilite une coopération poussée entre tous les rôles et fonctions.
• Protège l'équipe des interférences extérieures.
39. L’ É Q U I P E S C R U M
• De 5 à 10 personnes
• Regroupant tous les rôles
(Architecte, Concepteur, Développeur, Spécialiste IHM, Testeur,…)
• A plein temps sur le projet, de préférence
(Exceptions possibles - Administrateur, DBA,…)
• L’équipe s’organise par elle-même
• La composition de l’équipe ne doit pas changer pendant un Sprint
45. D A I LY S C R U M
• Les règles:
• Tous les jours
• 15 minutes maximum
• Debout
• Pas fait pour résoudre les
problèmes.
• Tout le monde est invité.
• Seuls les membres de l'équipe
peuvent parler.
• Permet d'éviter l'organisation
d'autres réunions.
46. D A I LY S C R U M
• Chacun répond à 3 questions:
• Qu'as tu fait hier ?
• Que vas-tu faire aujourd'hui ?
• Y a t-il un obstacle qui te
freine ?
• Il ne s'agit pas de compte-rendus
au Scrum Master.
• Ce sont des engagements devant
des pairs.
48. S P R I N T R E V I E W ( D É M O )
• L'équipe présente ce qu'elle a fait pendant le sprint.
• Se fait avec une démo des nouvelles fonctionnalités ou de l'architecture
• Informel - Préparation inférieure à deux heures - Pas de slides!
• Toute l'équipe participe.
• On invite du monde.
50. R É T R O S P E C T I V E
• Réfléchir régulièrement à ce qui
fonctionne bien et ce qui ne
marche pas.
• Dure en général de 15 à 30
minutes.
• Fait à la fin de chaque sprint.
• Toute l'équipe participe.
• ScrumMaster
• Product Owner
• Equipe
• Eventuellement clients et autres
intervenants
51. R É T R O S P E C T I V E
• Toute l'équipe collecte du feedback sur le déroulement du dernier Sprint
et échange sur ce qu'elle souhaiterait:
• Commencer à faire
• Arrêter de faire
• Continuer à faire
52. V I S U A L M A N A G E M E N T
M E S U R E R P O U R P I L O T E R & S ’ A M É L I O R E R
53. TA S K B O A R D ( L I S T E D E S TÂ C H E S )
• Chacun s'engage sur du travail qu'il choisit. Le travail n'est jamais attribué
par un autre
• L'estimation du reste à faire est ajustée tous les jours.
• N'importe qui peut ajouter, supprimer ou changer la liste des tâches.
• Le travail du sprint émerge progressivement. Si un travail n'est pas clair,
définir une tâche avec plus de temps et la décomposer après
• Mise à jour du travail restant quand il est mieux connu
54. TA S K B O A R D P H Y S I Q U E
S T O R I E S À FA I R E E N C O U R S T E R M I N É
Story 1 Task
Story 2
Story 3
Story 4
Story 5
Task
Task
Task
Task
Task Task
Task Task
Task Task Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
56. B U R N D O W N C H A R T
0
25
50
75
100
20/10 21/10 22/10 23/10 24/10
57. G E N E R A L LY A C C E P T E D
S C R U M P R A C T I C E S
• User Stories
• Acceptance Tests
• Story Points
• Task Hours
58. U S E R S T O R I E S
D É C R I R E L E B E S O I N …
59. P R O B L È M E S D E C O M M U N I C AT I O N ?
60.
61. U N L A N G A G E C L A I R E T U N I V E R S E L
62. S E C O M P R E N D R E , C ’ E S T I M P O R TA N T !
• Il est nécessaire de disposer d'un moyen de communication clair, universel
et compréhensible par tous les acteurs.
• Les projets ne partageant pas un langage commun et exempt de jargon
sont voués à l'échec.
64. S T O RY C A R D S
• Les user stories sont généralement écrites sur une fiche ou Post-It.
• Les fiches peuvent être enrichies par des notes, des estimations, une valeur
business, etc…
65. C O N V E R S AT I O N
• Les précisions et autres détails concernant la user story sont évoqués lors
d'une discussion avec le Product Owner.
66. VA L I D AT I O N
• Les critères de succès et exemple à l'origine des tests d'acceptance sont
garants de la validité fonctionnelle de la user story.
67. E X E M P L E S
En tant que client
je peux modifier mon
adresse postale afin
de recevoir les
couriers de Fongecif
En tant que client
je dois saisir mon
mot de passe afin de
valider ma nouvelle
adresse
68. O Ù S O N T L E S P R É C I S I O N S ?
“En tant que client je peux modifier mon adresse postale afin de recevoir les
couriers de Fongecif.“
• Est-ce que mon adresse doit être valide?
• Est-ce que je serai notifié de la prise en compte?
• Que se passe-t-il en cas d'erreur?
69. C R I T È R E S D E S U C C È S
• Les critères de succès métier viennent s'ajouter à la user story afin de
préciser le besoin.
• Ils sont formulés sous forme d'exemples concrets.
70. C R I T È R E S D E S U C C È S
• Je saisis une adresse invalide (75315 Paris) et on me propose une adresse
valide que je dois confirmer (75015 Paris).
• Si le service de changement d'adresse est indisponible je suis infomé par
le message “Votre demande n'a pas pu être prise en compte merci de
rééssayer ultérieurement”.
• Lorsque je valide ma nouvelle adresse, je suis notifié de la prise en compte
via le message “Votre demande a été prise en compte”.
71. P R É C I S I O N PA R D É C O U PA G E
En tant que client
je peux modifier mon
adresse postale afin
de recevoir les
couriers Fongecif
En tant que client
je suis invité à vérifier
que ma nouvelle
adresse est valide
En tant que client
je suis notifié de la
prise en compte de ma
demande de
changement d'adresse
En tant que client
je dois valider ma
nouvelle adresse via
Mon mot de passe
72. C O M B I N A I S O N D E S A P P R O C H E S
• Les deux méthodes ne sont pas exclusives et peuvent être combinées.
• Il est important d'identifier le bon niveau de granularité pour les user
stories.
• Lors de son évolution, chaque user story se verra attribuer des critères de
succès.
73. S T O R I E S & E P I C S
• Les epics sont de grosses user stories qui pourront être découpées en
plusieurs user stories par la suite.
74. L’ AT E L I E R D ’ E C R I T U R E
• Des experts peuvent être invités
• Il n'est pas lié aux cérémonies Scrum
• L'objectif est d'écrire rapidement les stories
• La priorisation sera faite ultérieurement
76. I . N . V. E . S . T.
• Indépendant
• Négociable
• Valeur ajoutée
• Estimable
• Suffisamment petit
• Testable
77. - F O R M A L I S M E U N I Q U E -
“En tant que < Rôle >, je souhaite < Objectif > afin de < Raison >”
78. P O U R Q U O I D E S U S E R S T O R I E S ?
• Le métier et les développeurs comprennent les user stories.
• Les personnes retiennent plus facilement les évolutions si elles sont
organisées sous forme de stories.
79. AVA N TA G E S
• Les stories sont adaptées à la priorisation et planification.
• Elles permettent de profiter des opportunités de développement.
• Le produit prend forme grâce à l'ordonnancement des user stories.
• Ce sont des éléments collaboratifs et favorables à la communication.
80. I M P O R TA N T !
• Ne pas oublier l'objectif.
• Le texte de la story écrit sur une carte est toujours moins important que les
discussions qui en découlent.
81. E X I G E N C E S N O N F O N C T I O N N E L L E S
• Elles font partie du Backlog Produit.
• Elles peuvent être exprimées sous la forme:
• De stories techniques (le rôle est l’équipe de réalisation)
• De critères d’acceptance
82. E X P R E S S I O N D E B E S O I N & S P É C I F I C AT I O N
User story
Tests d'acceptance
Besoin agile
+ Discussion
+
83. M E R C I
W W W. A G I L E G E N I U S . C O M