2. • Session 1 : Introduction
o Pourquoi les méthodes agiles ?
• Session 2 : Scrum
o Présentation de Scrum
o Les rôles dans Scrum
o Les artefacts de Scrum
o Les cérémonies de Scrum
• Session 3 : Introduction a l’eXtreme Programming
• Session 4 : Piloter un projet agile
o Gérer les exigences
o Estimations agiles
o Planification
• Session 5 : Sujets avancés
Agenda
www.xebia.fr
3. • Quel est votre nom et votre rôle dans l’organisation ?
• Quel est votre niveau d’expérience professionnelle ?
• Quelle expérience avez-vous des méthodes agiles ?
Introductions…
4. • Qu’attendez-vous de la formation ?
o Ecrivez un test et placez-le sur le tableau
o Par exemple :
• J’ai compris comment, en tant que développeur, je serai impacté
• Je sais comment me préparer à l’agilité
• J’ai identifié les principaux obstacles à la mise en place de
l’agilité dans mon organisation
• Je connais des méthodes permettant de lutter contre une
mauvaise communication
Objectifs de la formation
6. • Dr Winston W. Royce, Managing the development of
large software systems, 1970
Le cycle de développement classique
Cycle en V, Waterfall…
7. • Planifier le travail, travailler selon le Plan (Gantt)
• Piloter l’avancement par rapport au Plan (effort/RAF)
• Contrôle centralisé
• Contraindre le changement
• Recherche d'optima locaux
• Segmentation des responsabilités
• Fige les choix tôt, échoue tardivement
L’hypothèse de prédictibilité
8. Taux de succès des projets
Échec des projets selon la taille (CHAOS report 2004: Standish group)
Principalement par manque :
– D’implication des utilisateurs
– De support du management
– De clarté dans les objectifs métiers
29%18%
53%
Challenged
Failed
Succeeded
10. • Dépassement du budget / des délais
• Non réalisation du business case
• Faible capacité à s’adapter et évoluer
• Utilisation non optimale de ressources
• Individus découragés et non disciplinés
• Gaspillages à de multiples niveaux
• Problèmes non visibles
Symptômes
www.xebia.fr
11. • Prédictible ou production en masse
o Production d’une voiture
o Suivre une recette de cuisine
• Développement de nouveau produit
o Créer un nouveau modèle de voiture
o Créer une nouvelle recette
Deux types de projets
www.xebia.fr
Le développement logiciel est du
développement de nouveau produit
12. • Non prédictible
• Apprentissage par
l’expérimentation
• Amélioration continue
• Tolérant au changement
• Repousser les décisions irréversibles
o Garder un maximum d’options
• Des Best Practices comme point de départ
Développement de produit
www.xebia.fr
13. Prédictif vs. Agile
www.xebia.fr
`
`
Résultat
Business
Case
Minimisation
des coûts
Maximisation
de la valeur
Défensive
Offensive
Création de valeur
Gestion des
responsabilités
Partage des
responsabilités
ConfianceContractuelle
Business CasePlanning
Management LeadershipStyle d’organisation interne
Nature des interactions entres les parties
Organisation et priorisation des activités
Vue adaptativeVue prédictive
14. Méthodes de développement
www.xebia.fr
AgileEvolutionaryItératif
• Itérations multiples
• Entre 1 et 6 semaines
• Timebox : ressources et durée fixe
• Périmètre figé durant l’itération
• Impose l’apprentissage
• Recueil évolutif des besoins
• Piloté par le feedback utilisateur
• Planification, processus adaptatifs
• Tailler sur mesure : éliminer les gaspillages
• Focus sur la communication et les individus
• La qualité comme un moyen pour maintenir productivité élevée
• Satisfaction du client en livrant tôt et régulièrement du logiciel utile
15. www.xebia.fr
2001: Le Manifeste Agile
We are uncovering better ways of developing
software by doing it and helping others do it.
February 11 – 13, 2001
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
16. 16
L’ombrelle agile
Agile Methodologies
• eXtreme Programming
Kent Beck, Ward Cunningham, Ron
Jeffries
• Scrum
Ken Schwaber and Jeff Sutherland
• Crystal Methods
Alistair Cockburn
• Feature Driven Development
Jeff DeLuca
• Dynamic Systems Development
Method
DSDM Consortium
Agile Management Frameworks
• Agile Project Management
Jim Highsmith, Sanjiv Augustine
• Agile Management, KanBan
David Anderson
• eXtreme Project Management
Rob Thomsett
• Lean Software Development
Tom & Mary Poppendieck
17. • Eliminate waste
o Fonctionnalités inutiles, « churn », frontières
• Build quality in
o Discipline, règles
o Test, test, test
• Create knowledge
o Feedback, amélioration continue
• Defer commitment
o Planification continue
• Deliver fast
• Respect people
• Optimize the whole
o Value Stream Map
Lean Software Developpment
www.xebia.fr
INSPECT & ADAPT
18. • Meilleure planification
• Emphase sur le business case
• Conçu pour les changements
• Suppression des gaspillages
• Visibilité sur les obstacles
• Utilisation optimisée des ressources
• L’excellence comme ligne de conduite
• Des individus respectés, responsabilisés,
motivés
Bénéfices procurés par l’Agile
www.xebia.fr
20. Résumé
www.xebia.fr
FEEDBACK
Principes Agiles Principes Classiques
Petits Lots
Fonctionnalités développées en itérations courtes, de 2 à 4 semaines, et
mises en production aussi souvent que possible.
Large Batches
Livraisons à un rythme typique de 2 à 3 versions par an.
Accepter le changement
Accepter l’incertutude, s’adapter aussi bien aux changement externes
(marché) qu’internes, en modifiant aussi bien les plans que les approches.
Utiliser certains principes d’ingénierie pour faciliter les évolutiosn de la
base de code.
Baseline and Change Control
Typiquement, contraindre fortement voire supprimer toute possibilité
de changement significatif autre que l’abandon de certaines
fonctionnalités. Suivre le plan initial, même si celui-ci s’est révélé faux
(rétro-planning).
Itérations et amélioration continue
Les rétrospectives en fin d’itérations permettent aux équipes de
s’introspecter, d’apprendre et de s’adapter en permanence.
Leçons tirées uniquement à la Fin
Le feedback négatif est rarement voire jamais formulé. Et s’il est
formulé, c’est généralement trop tard (REX).
Equipes petites, intégrées
Des équipes de petite taille, pluridisciplinaires, qui simplifient la
communication, permettent à chacun d’avoir une vision d’ensemble et
créent les conditions d’une discipline collective.
Equipes en silo
Les équipes sont organisées par fonction et communiquent à travers
des documents.
Focus sur le “Highest Value First”
Le projet, le produit et la vision sont alignés en priorisant les
développement en fonction des besoins métier. Le développement
incrémental permet d’obtenir un ROI accéléré.
Tout ou rien
La phasage classique interdit de livrer quoi que ce soit avant que tout
soit terminé.
28. “The … ‘relay race’ approach to product
development … may conflict with the
goals of maximum speed and flexibility.
Instead a holistic or ‘rugby’ approach —
where a team tries to go the distance as
a unit, passing the ball back and forth -
may better serve today’s competitive
requirements.”
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development
Game”, Harvard Business Review,
January 1986
Origine de Scrum
29. • Équipe responsable, en auto organisation
• Avancement du produit par une série de « sprints » d’un
mois ou moins
• Exigences définies comme des éléments d’une liste
appelée « backlog du produit »
• Pas de prescription de pratiques d’ingénierie
• Utilisation de règles génériques permettant de créer un
environnement agile pour un projet
• Un des « processus agiles »
Caractéristiques de Scrum
www.xebia.fr
30. Un peu de terminologie
Scrum XP Definition
Sprint Iteration Période de durée fixe
Release Small Release Mise en production
Sprint/Release
Planning
Planning Game Réunions de planification agile
Product Owner Customer Représentant du métier
Retrospective Reflection Réunion de type “REX”
ScrumMaster Project Manager Leader de l’équipe
Daily Scrum Daily Standup Réunion quotidienne
32. • Les projets Scrum progressent par série de Sprints
• La durée d’un Sprint varie de 2 à 4 semaines
• Une durée constante permet un meilleur rythme
• Le produit (partiel) est conçu, codé, testé pendant le
sprint
Sprints
www.xebia.fr
33. • 4 volontaires, SVP !
• 1er round :
o Le premier travailleur positionne tous les dés sur 1
o Le second travailleur positionne tous les dés sur 2
o Etc.
• 2ème round
o Le premier travailleur positionne 1 dé sur 1, puis le passe au second
travailleur, puis passe au second dé
o Le second travailleur positionne le 1er dé su 2, puis le passe, etc.
• On mesure :
o Combien de temps il faut pour que le premier dé sorte du cycle
o Combien de temps il faut pour traiter tous les dés
Une petite simulation de Scrum…
38. • Scrum est un simple framework d’inspection et
d’adaptation qui définit 3 rôles, 3 cérémonies et 4
artefacts et est conçu pour livrer du logiciel fonctionnel
par itération de 30 jours maximum
• Rôles : Product Owner, ScrumMaster et Équipe
• Cérémonies : Planification de Sprint, Revue de Sprint et
Daily Scrum
• Artefacts : Product Backlog, Sprint Backlog Burndown
Chart et logiciel fonctionnel
• Facile à implémenter, dur à exécuter
Le cadre Scrum
www.xebia.fr
41. • Définit les fonctionnalités du produit
• Décide de la date et du contenu des release
• Est responsable du ROI
• Priorise les développements en fonction de la valeur
métier
• Gère les risques à moyen et long terme, coordonne les
travaux complémentaires (Anticipation)
• Peut changer les fonctionnalités et les priorités à
chaque Sprint
Le Product Owner
www.xebia.fr
42. • Responsable de la bonne application des valeurs et
pratiques de Scrum
• Facilite une coopération poussée entre tous les rôles et
fonctions
• Résout les problèmes, supprime les obstacles et gère
les risques à court terme
• Recherche des moyens d’améliorer la productivité de
l’équipe
• Protège l'équipe des interférences extérieures
Le Scrum Master
www.xebia.fr
43. • 7 membres +/- 2
• Regroupant tous les rôles, de préférence à temps plein
o Architecte, concepteur, développeur, spécialiste IHM, testeur, etc
• Se focalise sur la livraison régulière de fonctionnalités
de haute qualité
• Propose des options pour garantir l’exécution de la
vision
• Gère ses activités à l’intérieur de chaque Sprint
L’équipe
www.xebia.fr
44. Organisation de l’équipe Scrum
44
Traditional Silos Customer BA Designer DeveloperPM
Core
Team
(EXAMPLE)
BA /
Tester
BA
Tester
Product
Owner
Developer
Designer
Developer /
BA
SM
Release
Manager
Capacity
Planner
Prod.
Architect
Tech
Ops
Business
Sponsor
Risk
Assessor
Security
44
BAAnalysts
DeveloperDeveloperDeveloper
Designers Tester
La Core Team
idéalament 5 à 9
membres dédiés (7
+/- 2).
L’équipe étendue
qui contient
d’autres membres,
dont le rôle est
important mais
dont l’effort n’est
typiquement pas
dédié au projet
TesterTestersDevs
48. • Liste de fonctionnalités priorisées et estimées
o Exprimées sous forme de User Stories
• Produit en flux
Le Product Backlog
49. Product Backlog élémentaire
Priority Backlog item Acceptance Criteria Estimate
1 Allow a guest to make a
reservation
• Confirmation email is sent
• Must be made >24 hours in
advance
3
2 As a guest, I want to cancel a
reservation
• Confirmation email is sent
• Must be canceled 15 days in
advance
5
3 Guest can change reservation
dates
… 3
4 Hotel employee can see future
reservations for her hotel
… 8
5 Improve exception handling … 15
41 … … 50
52. • Sous-ensemble du Product Backlog que l’équipe
s’engage à produire durant le Sprint
o Chaque Story est découpée en tâches par l’équipe
o Les tâches sont suivies dans un Task Board
o Un Burndown Chart permet de piloter la progression
Le Sprint Backlog
53. Task Board – Jour 1
D’après Erik Kniberg, Scrum & XP from the Trenches
54. Task Board – Jour N
D’après Erik Kniberg, Scrum & XP from the Trenches
63. • L'équipe choisit les Stories qu’elle estime pouvoir
terminer
• Le backlog de sprint est créé
o Les tâches sont identifiées et estimées (1-16 heures)
o Par toute l’équipe
• La conception de haut niveau est abordée
Planification du sprint
www.xebia.fr
En tant que touriste
potentiel, je veux voir des
photos des hôtels afin de
me faire une idée des
services et facilités.
Coder la couche métier (8 heures)
Coder l'IHM (4)
Écrire les tests (4)
Refactorer la classe foo (6)
Exécuter les tests de performance
(4)
64. Périmètre
• Analyser et évaluer le backlog de
produit
• Définir le but du sprint
Plan
• Décider comment s'y prendre
(conception)
• Créer la liste des tâches à partir
des éléments du backlog de produit
• Estimer les tâches en heures
But du
sprint
Backlog
du sprint
Contexte
métier
Capacité
de l'équipe
Backlog
de produit
Technos
Produit
actuel
Planification du sprint
65. But du Sprint
• Un bref énoncé de ce sur quoi le travail va
essentiellement porter pendant le sprint
Database Application
Services financiers
Sciences de la vie
Offrir les fonctions pour les
études génétiques.
Offrir plus d'indicateurs que le
produit ABC sur les données
de streaming.
Faire tourner l'application sur
une base MySQL en plus
d'Oracle.
67. • Revue de la vélocité et de la capacité du Sprint
o Identifier tout ce qui est unique pour le Sprint à veinr (jours fériés, vacances, absence,
etc..)
• Déterminer le But du Sprint (Optionnel)
• Sélectionner les User Stories les plus prioritaires du Product
Backlog
o En prendre sensiblement plus que la capacité, en s’assurant qu’elles sont alignées
avec le But du Sprint
• Discuter des User Stories pour créer les tâches et les critères
d’acceptance
• Estimer les tâches en heure
o Limiter la taille des tâches à < 16 heures
• S’engager sur les User Stories
o A concurrence de la capacité
• Alimenter le Task Board
Exemple d’agenda pour un Sprint Planning
70. • Paramètres
o Quotidien
o Maximum 15 minutes
o Debout
• Pas fait pour résoudre les problèmes
o Tout le monde est invité
o Seuls les membres de l'équipe peuvent parler
• Permet notamment d'éviter l'organisation d'autres
réunions
Daily Scrum
www.xebia.fr
71. • Il ne s'agit pas d’un compte-rendu au ScrumMaster
o Mais d’engagements devant des pairs
3 questions
www.xebia.fr
Qu'as tu fait hier ?
1
Que vas-tu faire aujourd'hui ?
2
Rencontres-tu des obstacles ?
3
73. • L'équipe présente ce qu'elle a fait pendant le sprint
o Toute personne intéressée par le produit est invitée
• Implique une démonstration des nouvelles
fonctionnalités ou de l'architecture
• Informel
o Préparation < 2h
o Pas de slides
• Toute l'équipe participe
• Les intervenants du projets sont invités
Revue de Sprint
www.xebia.fr
75. • Réfléchir régulièrement à ce qui marche et ce qui ne
marche pas
• Conduite à la fin de chaque sprint
• Toute l'équipe participe
o ScrumMaster
o Product Owner
o Équipe
o Éventuellement d’autres intervenants
• Aboutit à un plan d’actions sur lequel l’équipe s’engage
o Le Scrum Master en assure le suivi
Rétrospective
www.xebia.fr
76. • Toute l'équipe collecte du feedback et discute sur ce
qu'elle aimerait
Start / Stop / Continue
ww.xebia.fr
Commencer à faire
Arrêter de faire
Continuer à faire
Juste une façon
parmi d'autres
de mener une
rétrospective.
77. 77
Fin de la 2ème session
Questions ?
www.xebia.fr
79. • L’autre méthodologie dont on parle beaucoup
• Comme la plupart des autres méthodes XP est
recommandé pour…
o Des équipes de tailles petites ou moyennes
o Des projets avec de nombreuses zones d’incertitude (risques)
o Lorsque les besoins sont vagues ou évoluent rapidement
• Adopte des processus issus d’autres méthodologies
o E.g. SCRUM, Crystal
• A été utilisé ou expérimenté chez…
o Daimler-Chrysler, Ford, Capital One, IBM, et beaucoup d’autres
Extreme Programming (XP)
www.xebia.fr
80. Les valeurs
www.xebia.fr
Communication leads to valuable feedback which encourages simplicity
which allows for courage to change
communication
courage
simplicité
feedback
respect
81. • Les pratiques découlent des 4 valeurs
o Communication, Simplicité, Feedback, Courage
o Considérez les comme des « des fonctions de maximisation »
• Pratique = Étude
o En musique classique, une étude est, à l’origine, une pièce destinée
à améliorer certains aspects techniques d’un élève ou d’un interprète
o Il arrive de ne pas appliquer toutes les pratiques tout le temps en
fonction des projets
o Mais l’utilisation répétée des pratiques XP améliore
incontestablement les compétences des développeurs et leur
capacité à proposer des solutions plus rapidement
• Les pratiques procurent les meilleurs résultats
lorsqu’elles sont utilisées de façon conjuguée (SYNERGIE)
Les pratiques
www.xebia.fr
82. Les « cercles de vie »
www.xebia.fr
On-site Customer
Release
Planning
Small Releases
Acceptance
Tests
Coding
Standards
Collective
Ownership
Continuous
Integration
Metaphor
Sustainable
Pace
Pair
Programming
Unit Tests
Refactoring
Simple Design
Le client L’équipe Le code L’équipe Le client
83. • Définit les besoins, les fonctionnalités, définit les
priorités et de répond aux questions des développeurs
• Une interaction quotidienne de vis-à-vis
o Réduit la quantité de documentation écrite
o Et le coût élevé de sa création et de sa maintenance
Client sur site
www.xebia.fr
84. • Où « jeu du planning »
• Le « client » XP de doit définir la valeur métier des
fonctionnalités
o User Stories
• Les développeurs (pas seulement un CP) estiment les
fonctionnalités
• A partir de ces informations, le client et les
développeurs effectuent une sélection en fonction du
ration coût / bénéfice
o Permet une priorisation optimale des fonctionnalités
Planification de Release
www.xebia.fr
85. • Mettre en production un système simple le plus
rapidement possible puis appliquer des cycles de
livraisons très courts
• Exemple
o Releaser tous les 2 ou 3 mois
o Chaque release contient plusieurs itérations
• Établir un « rythme »
o Feedback régulier pour le client et l’équipe
• Permet d’évaluer la véritable valeur du produit dans son
environnement réel
Livraisons courtes
www.xebia.fr
86. • Où « Test First », « Test Infected »
o TESTS D’ACCEPTANCE : on demande aux clients de fournir des
tests d’acceptance avant les développements (idéalement
automatisés)
o TESTS UNITAIRES : les développeurs écrivent d’abord des tests
puis créent le logiciel qui répond aux exigences capturées dans les
tests
• Automatisation, Automatisation, Automatisation, (JUnit, XUnit) [5]
o Un développement piloté par les exigences garantit que les
fonctionnalités essentielles seront fournies
TDD
www.xebia.fr
87. • Les développeurs restructurent le système sans en
modifier le comportement pour supprimer les
duplications, faciliter la communication, simplifier ou
améliorer la flexibilité
• Petites étapes
• Coder, tester, refactorer, tester, coder, refactorer
o Beck suggère [1] des cycles de (10 minutes)
• Un alignement sur un pattern de conception est un
refactoring typique
• Basé sur le travail de Martin Fowler [6,7]
Refactoring
www.xebia.fr
88. • Le code est écrit par 2 développeurs sur 1 seule
machine
o L’un la tactique, l’autre la stratégie
• Le binôme devrait être « dynamique »
o Les membres en binôme changent de rôle toutes les 30 à 60
minutes
o Et sur tous les types de tâches
• L’expérimentation montre une réelle efficacité [8]
Programmation en binôme
www.xebia.fr
89. • Les bénéfices
o Revue de code continue
o Partage continu du métier
o Amélioration continue des compétences techniques
(Java, Design Patterns, Refactoring, IDE…)
• Les développeurs on parfois plus de mal avec cette
pratique que les managers
o Tester pour voir si cela fonctionne
o Peut nécessiter un temps d’acclimatation
o Expérience du développement plus intense
Programmation en binôme
www.xebia.fr
90. • Basé sur le principe que la plus haute valeur métier
dérive du programme répondant aux besoins courants
le plus simple
• Pas d’over-engineering !
• K.I.S.S (un concept difficile à appliquer)
• 2 philosophies communes d’équipes XP
o DTSTTCPW – Do The Simpliest Thing That Could Possibly Work
o YAGNI – You Aren’t Gonna Need IT
Conception Simple
www.xebia.fr
91. • Les développeurs produisent du code en conformité
avec des règles favorisant la communication au niveau
du code
• L’objectif : produire un code auto documenté
• La raison : le langage comment est le code
• Plus que de la Javadoc; de la bonne Javadoc et des
commentaires appropriés
Standards de développement
www.xebia.fr
92. • La vision de « l’architecture » selon XP
• Guide les développements en fournissant une vision
commune et unique de la façon dont le système
fonctionne
• Définit un vocabulaire et guide l’équipe dans les
développements et la communication
Métaphore
www.xebia.fr
93. • Intégrer et construire le système aussi souvent que
possible
• Intégrer à chaque fois qu’une tâche est finie
• Permet de connaître à tout instant le « statut » du
système
Intégration Continue
www.xebia.fr
94. • Tout développeur peut modifier toute portion de code
à n’importe quel moment
• Ceci est facilité par l’utilisation de Standards de
développement, de TDD et de Pair Programming
(Synergie)
• Sécurise l’équipe en terme de vacances, congés,
maladie, turn-over
o Les progrès ne s’arrêtent pas sur un composant parce qu’un membre
de l’équipe est absent
Propriété collective
www.xebia.fr
95. • Des développeurs fatigués produisent la plupart du
temps un code de moindre qualité
• Minimiser les « heures supplémentaires » et conserver
une équipe fraîche produit un code de meilleur qualité
en moins de temps
• 40 – 45 devrait être la règle
o Selon les préférences des équipes
• Corollaire : ne jamais faire des heures supplémentaires
une seconde semaine d’affilée
o Éviter le burnout
Rythme soutenable
www.xebia.fr
98. • Extrême = continuellement
o Revue de code (pair programming)
o Tests unitaires
o Tests d’intégration
o Tests d’acceptance utilisateurs
• Pouvez vous satisfaire votre client avec du feedback, de
la communication et de la simplicité constante ?
• Le feedback procuré par les estimations, les tests, les
livraisons fréquentes
o Donne confiance aux utilisateurs
o Donne confiance à l’équipe
o Donne confiance au management
Avantages d’XP
www.xebia.fr
99. • XP n’est pas une « silver bullet » !
• XP peut ne pas fonctionner pour
o Des grosses équipes
o Des équipes distribuées
o Des systèmes trop complexes
o Des projets d’intégration avec du code existant
o Des organisations où la méthodologie est particulièrement rigide
o Des organisation ou règne la culture du burn-out
• Où la valeur d’une personne dépend du temps passé au travail
o Des ego sur dimensionnés
o Des environnements physiques inappropriés
• Mais XP peut être adapté
Limitations
www.xebia.fr
100. • Le changement culturel peut être difficile pour les
développeurs et les managers
o Mineurs : rythme soutenable, standards de développement, tests,
refactoring
o Majeurs : client sur site, jeu de planification, livraisons fréquentes,
conception simple
o Extrêmes : propriété collective, programmation en binôme, métaphore
• Requiert des développeurs expérimentés (mais pas
des gurus)
• Disposer d’un client sur site n’est pas toujours possible
o Manque de disponibilité
o Niveau de prise de décision
o En rupture avec la culture interne
Inconvénients d’XP
www.xebia.fr
104. • Ce jeu est appelé le jeu de vélocité. Y avez-vous déjà joué ?
o Changez de casquettes 3 fois
o Développeurs – estiment
o Propriétaires de produit – priorisent en fonction de la valeur métier et du temps
o Développeurs – exécutent
• Vélocité (1-6, complexité impossible)
• Trouvez la story la plus facile et donnez lui la valeur 2
o Vous devriez trouver plus simple dans le futur
• Estimez les autres stories relativement à 2
o Pensez complexité ET temps (une story simple peut prendre longtemps)
• Il y aura 3 itérations, chacune de 3 minutes
o Le temps ne sera décompté que lorsque vous exécuterez les stories.
• VOUS NE RÉALISEZ QU’UNE STORY À LA FOIS (ensemble)
XP Game
www.xebia.fr
105. 105
Fin de la 3ème session
Questions ?
www.xebia.fr
109. • Le travail est organisé par valeur, pas par couche
d’architecture
Organisation du travail
110. • Les spécifications complètes :
o Assument que tout est connaissable à
l’avance
o Sont chronophages à rédiger, pénibles à
lire
o Considèrent l’accumulation de
connaissance comme « un changement
de périmètre »
o Ne distinguent pas l’essentiel du superflu
Spécifications détaillées ?
111. • Une User Story, c’est :
o Une description de haut niveau d’un but ou d’une fonctionnalité
o Une tranche verticale du système
• Doit avoir une valeur intrinsèque
o Un point de départ pour discuter
• Pas une spécification exhaustive
Introduction aux User Stories
112. De la User Story aux tâches
User Story #023
En tant que nouvel utilisateur,
je peux saisir mes informations
personnelles
Priorité : 1
Estimation : 2
Critères d’acceptance
L’adresse est valide dans le
référentiel
Le numéro de téléphone
contient 10 chiffres
Le nom et l’adresse email sont
obligatoires
Tâches
Prototyper l’UI
Développer le code HTML/CSS
Créer les champs dans la base
Développer les contrôle métier
Ecrire les cas de test
Coder les fixtures
Tests d’acceptance
Tests ergonomiques
Rédiger l’aide en ligne
113. • En tant que <acteur>,
• je peux <fonctionnalité>
• afin de <résultat obtenu>
Modèle de User Story
Qui, Quoi, Pourquoi… que manque-t-il?
114. • Les critère de validation (acceptance) permettent
o de circonscrire le périmètre
o de préciser la définition de DONE pour une Story
• Focalisez-vous sur l’objectif, pas sur le moyen de
l’atteindre
Critères de validation
En tant qu’abonné, je peux annuler une réservation
Un abonné Premium peu annuler le jour même sans frais
Un abonné non Premium doit payer des frais de 10% pour une annulation
le jour même
Un email de confirmation est envoyé à l’abonné
L’hôtel est informé de l’annulation
115. Ce qui fait une bonne User Story
Bill Wake’s INVEST
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Ron Jeffries’ 3 Cs
Card
Conversation
Confirmation
116. • Éviter l’introduction de dépendances
o Rendent la priorisation et la planification difficiles
Indépendant
www.xebia.fr
Une entreprise
peut payer pour
une offre
d’emploi avec
une carte Visa
Une entreprise
peut payer pour
une offre
d’emploi avec
une MasterCard
Une entreprise
peut payer pour
une offre
d’emploi avec
une AmEx
117. Rendre les stories indépendantes
www.xebia.fr
Combiner
les stories
Décomposer dans des
dimensions différentes
Effectuer 2 estimations
et passer à autre chose
• Un client peut payer avec une
carte de crédit.
• Un client peut payer avec 1 type
de carte de crédit.
• Un client peut payer avec 2
autres types de cartes de crédit.
• 3 jours si initial; 1 sinon.
118. • Les stories ne sont pas
o Des contrats signés, elles peuvent changer
o Des exigences auxquelles le logiciel doit répondre
• Doivent capturer l’essence, pas les détails
• Trop de détails donnent l’impression de
o Fausse précision ou complétude
o Qu’il n’est plus utile d’en parler
• Rester flexible afin de permettre d’ajuster les parties
d’une story qui seront implémentées
o Si la story est un contrat, alors il faut l’estimer comme un contrat
Négociable
www.xebia.fr
119. Valorisable
www.xebia.fr
• Un utilisateur peut effectuer
une recherche d’emploi par
titre et plage de salaire.
• Sur l’intégralité du projet,
l’équipe de développement
produira de la
documentation appropriée
pour un audit ISO 9001.
• L’équipe de développement
produira l’application en
accord avec CMM niveau 3
• Toutes les informations de
configuration sont lues à
partir d’un emplacement
central.
Utilisateurs
Commanditaire
120. • Devraient être réécrites pour exposer leurs bénéfices
métiers
Stories identifiées par des développeurs
www.xebia.fr
Toutes les connexions
à la base doivent passer
par un pool de connexion
L’application doit supporter
jusqu’à 50 utilisateurs
simultanés avec une licence
base de données 5
utilisateurs
Toutes les erreurs sont
présentées à l’utilisateur et
loguées d’une façon
consistante.
Toute la gestion d’erreur
et de traces est effectuée
au travers un jeu de classes
communes.
121. • De nombreux projets assument à tort qu’il n’y a qu’un
seul utilisateur
o « L’utilisateur »
• Rédigent toutes les user stories d’une seule
perspective
• Assument que tous les utilisateurs ont les mêmes buts
• Vous raterez des besoins !
« Embarquez » l’utilisateur dans le backlog
www.xebia.fr
« En tant que <rôle>, je veux <action> afin
que <bénéfices> »
122. • Élargir le point de vue
• Permettre aux utilisateurs de varier
o Pourquoi ils utilisent le logiciel
o Comment ils utilisent le logiciel
o Background
o Familiarité avec les logiciels / ordinateurs
• Définition
o Un rôle utilisateur est une collection de définitions d’attributs qui
caractérisent une population d’utilisateur et leurs intentions
d’interactions avec le système
o Technique des Persona
Les rôles de l’utilisateur
www.xebia.fr
123. • Parce que les stories sont utilisées dans les plannings
• Une story peut ne pas être estimable si
Estimables
www.xebia.fr
Les développeurs
manquent de
connaissances métier
Les développeurs
manquent de
connaissances techniques
La story est trop grosse
124. • Les grosses stories (ou épiques) sont
o Difficiles à estimer
o Difficiles à planifier
• Ne rentrent pas facilement dans un unique sprint
• Story composée
o Une story qui comprend de multiples stories plus courtes
• Story complexes
o Une story qui est large et ne peut pas être désagrégée facilement
Small
www.xebia.fr
125. • Cachent souvent un grand nombre de suppositions
Stories composées
• Un CV inclut des sections
séparées pour les diplômes,
les emplois précédents,
publications,…
• Les utilisateurs peuvent
désactiver leur CV
• Les utilisateurs peuvent avoir
de multiples CV
• Les utilisateurs peuvent éditer
leurs CV
• Les utilisateurs peuvent
supprimer des CV
Un utilisateur peut
poster son CV
126. Décomposer une story composée
• Un utilisateur peut créer des CV qui
incluent diplômes, emplois précédents,
historique de salaires, publications,
présentations et un objectif
• Les utilisateurs peuvent éditer leurs CV
• Les utilisateurs peuvent supprimer des CV
• Les utilisateurs peuvent avoir de multiples
CV
• Les utilisateurs peuvent avoir des CV
actifs et d’autres inactifs
Décomposition
suivant les opérations
(CRUD)
127. Décomposer une story composée
www.xebia.fr
• Un utilisateur peut ajouter et éditer ses
diplômes sur un CV
• Un utilisateur peut ajouter et éditer ses
emplois précédents sur un CV
• Un utilisateur peut ajouter et éditer ses
historiques de salaires sur un CV
• Les utilisateurs peuvent supprimer des CV
• Les utilisateurs peuvent avoir de multiples
CV
• Les utilisateurs peuvent avoir des CV
actifs et d’autres inactifs
Décomposition
suivant les données
128. • Les tests démontrent qu’une story répond aux attentes
du propriétaire de produit
• Essayer des les automatiser à 90+%
Testable
www.xebia.fr
Un utilisateur doit trouver
le logiciel simple à utiliser
Un utilisateur débutant est
capable de terminer un
workflow courant sans
formation
Un nouvel écran est affiché
dans les 2s dans 95% des
cas
Un utilisateur ne doit jamais
avoir à attendre longtemps
avant l’apparition d’un écran
129. • Vision
o The Fantastic Food Finder (FFF) permet aux
utilisateurs d’obtenir sur leur téléphone mobile
les informations sur les restaurants à proximité,
grâce à une interface élégante et performante
• Business Case
o Les restaurants paieront une petite redevance
chaque fois qu’un utilisateur clique sur leur lien
o Ils paient également pour être mis en valeur
Exercice – Fantastic Food Finder
130. • Rédigez les Users Stories pour FFF
o Trouvez-en au moins 12
o Ecrivez les critères de validation pour au moins l’une d’entre elles
o Rappelez-vous :
• En tant que <acteur> je peux <but immédiat> afin <d’obtenir
quelque chose de valable>
• Qui sont les acteurs du système ?
• Quels sont les workflows ?
• Temps total : 20 minutes
Exercice
131. • Les User Stories ne sont pas l’unique moyen de gérer
les exigences dans un projet agile. D’autres approches :
o Essential Use Cases
o Low-fidelity prototyping
o High-fidelity prototyping
• La bonne façon de faire est souvent le résultat de
plusieurs essais…
Au-delà des User Stories
132. • Comment gérez et communiquez-vous les besoins des
utilisateurs sur vos projets?
• Quelles méthodes utilisez-vous pour gérer les
exigences ?
• Les équipes comprennent-elles généralement la valeur
de ce qu’elles développent ?
Discussion – Vos exigences
135. • 2 approches populaires
• Story Points
o Mesure strictement relative de la complexité
o La variabilité est compensée sur le nombre de stories
o Ne varie pas dans le temps
• Jour de développement Idéal
o Autour de 4-5 heures
o Lien direct avec le temps idéal
Unités d’estimation agiles
136. • Des échelles non linéaires sont généralement
préférées:
o Fibonacci: 1, 2, 3, 5, 8
o Doubles: 1/2, 1, 2, 4, 8
o “T-Shirt Sizes:” S, M, L, XL
• Permet d’être exact sans être trop précis
Echelles d’estimations
137. Exercice – Temps de consommation
Fruit à consommer Complexité relative
Pomme
Banane
Grappe de raisin
Melon
Mûre
Mangue
Framboise
Ananas
Lychee
Pêche
138. • Planning Poker est issu d’une technique d’estimation
appelée « Wideband Delphi »
• Déroulement :
o Chaque estimateur (personne qui devra éventuellement faire le
boulot) reçoit un jeu de carte, chaque carte stipulant un poids
o Le Product Owner lit la story ; on en discute brièvement
o Chaque estimateur choisit un carte (face cachée)
o Toutes les cartes sont retournées simultanément
o Les différences sont argumentées (extrêmes)
o Ré-estimer jusqu’à ce que les estimations convergent (ou
abandonner !)
Le planning poker
139. Planning Poker - Exemple
5
55Bill
52Ann
58Vijay
33Susan
Round 2Round 1Estimateur
141. • « Plans are nothing, planning is everything »
• Connaître la contrainte et asservir les décisions à cette
contrainte
• Utiliser des techniques d'estimation honnêtes
o Précision vs exactitude
o Fiabilité vs quantité
Planifier vs. Suivre un plan
149. • Description
o Session de planning initiale, permettant de passer en revue le
backlog initial, et de déterminer les dates des release
• Durée
o 2-4 heures
• Participants
o Team, Product Owner, ScrumMaster
Release Planning - Aperçu
Goals
Features
Stories
Tasks
150. Utiliser les Story Maps
Workflow Sequence
Priority
Access
record
Review
history
Provide
Nurse ID
Provide
Patient ID
Update
record
View
history
Add
comment
Enter
updates
Search
records
Sort
records
Filter
records
Search
history
Reference
validation
Notify of
updatesRELEASE 1
RELEASE 2
• Choisir des groupes
cohérents de
fonctionnalités couvrant
toutes les activités des
utilisateurs
• Implémenter idéalement
toutes les activités dès la
première release
• Améliorer la couverture
de chacune des activités
dans les releases
suivantes
151. • Une road map permet de communiquer clairement les
objectifs business de chacune des releases
o Une road map doit être respectée
o Utiliser des buffers pour piloter la road map
• Buffer de fonctionnalités (70% - 30%)
• Buffer de temps (50%)
Road Map
PB
400
500
161. Tests – Cas idéal
www.xebia.fr
Sprint 1 Sprint 2
v1.0.0 v1.1.0
Temps
Les tests sont réalisés
pendant l’itération !
L’objectif est de prévenir
l’apparition de défauts
162. Tests – Alternative commune
www.xebia.fr
Sprint 1 Sprint 2
v1.0.1 v1.1.0
Temps
Tests de la 1.0
v1.0.1
Équipe de tests
v1.0.0
Bug!
