Ce document présente une formation sur le développement agile, avec un accent sur les méthodologies Scrum et Extreme Programming (XP). Il couvre les principes de l'agilité, les rôles clés dans Scrum, ainsi que les étapes de gestion de projet agile, y compris la planification et l'amélioration continue. Les avantages de l'agilité, tels que la moindre rigidité face aux changements et l'accent accru sur la collaboration, sont également abordés.

1. 1
Développement Agile
avec Scrum et XP
www.xebia.fr

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

5. 5
1ère session
Pourquoi les méthodes agiles ?

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

9. Attentes utilisateurs

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

19. Réduire le coût du changement

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é.

21. Le nouveau profil des projets IT

22. Etat de l’Art
Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
http://www.ambysoft.com/surveys/agileFebruary2008.html
Team location
Success
percentage
Co-located Team 83%
Distributed teams but
physically reachable
72%
Distributed across
geographies
60%
Average:
75% success rate
Agile Adoption Rate Survey
Feb 2008
642 respondents
State of Agile Development Survey
July 2008
3061 respondents in 80 countries
Comparison
Average project: 30% success rate
Agile project: 60-80% success rate

23. 23
Fin de la 1ère session
Questions ?
www.xebia.fr

24. 24
2ème session
Scrum

25. L'Agilité n'est pas une recette
www.xebia.fr
LeanAgile
Systémique
Philosophie
XP
Principes
Pratiques
YOU !
Scrum
Implémentation

26. 26
Présentation de Scrum

27. Scrum ?

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

31. Scrum : la production en flux

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…

34. Un peu de tout tout le temps

35. Production incrémentale
Piloter la progression
1 2 3 4 5

36. Production incrémentale
Explorer (prototypage)
1 2 3 4 5

37. Synthèse

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

39. 39
Les rôles dans Scrum

40. Scrum définit 3 rôles
www.xebia.fr
Product Owner
Équipe
ScrumMaster

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

45. Le principe de co-localisation
La Team Room

46. 46
Les artefacts de Scrum

47. Le Product Backlog

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

50. Sprint
Discussion : Définir READY et DONE
Ready
In
Process
Done

51. Le Sprint Backlog

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

55. Burndown Chart
D’après Erik Kniberg, Scrum & XP from the Trenches

56. Kan Ban et contrôle visuel
D’après Erik Kniberg, Scrum & XP from the Trenches

57. Kan Ban et contrôle visuel (2)
D’après Erik Kniberg, Scrum & XP from the Trenches

58. Task Board électronique
58
Rally Enterprise
Rally Software
Trichord
ChangeVision
Mingle
Thoughtworks
VersionOne
Enterprise
VersionOne

59. L’Incrément

60. La définition de DONE
Tests unitaires
Codage
Conception
Analyse
Intégration
Tests utilisateurs
Tests performance
Beta
Production

61. 61
Les cérémonies de Scrum

62. Le Sprint Planning

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.

66. Sprint Planning

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

68. Task Board
D’après Erik Kniberg, Scrum & XP from the Trenches

69. Le Daily Scrum

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

72. Le Sprint Review

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

74. La Rétrospective

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

78. 78
3ème session
Introduction à
eXtreme Programming

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

96. Synergie
www.xebia.fr

97. Cycles de feedback
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

101. XP mal compris
www.xebia.fr

102. Scrum & XP
Sprint
Planning
meeting
Daily Scrum
Sprint
Review
Sprint
backlog
Product
backlog
TDD
Pair
programming
Refactoring
Simple
design
Coding
standard
Sustainable
Pace
Metaphor
Continuous
Integration
Collective
ownership
Whole
team
Planning
game
Small
releases
Customer
tests
Burndown
chart
Product
owner
Team
ScrumMaster
Scrum
XP

103. Cycles de feedback
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

106. 106
4ème session
Piloter un projet Agile

107. Vue d’ensemble
Goals
Feature
Sets
Stories
Tasks
Discovery
Planning
Release
Planning
Sprint
Planning
Daily
Standup
Define
Value.
Decide when
& how to
Deliver Value.
Build
Value.

108. 108
Gestion des exigences

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

133. 133
Estimations Agiles

134. Estimations et probabilités

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

140. 140
Planification

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

142. Plusieurs niveaux de planification

143. Calculer la vélocité
SBPB
8
3
5
5
5
5
8
3
5
5
5
8
3
5
5
Vélocité
Estimée =
26
SB
5
8
3
5
5
Fin de sprintDébut de sprint
Vélocité
actuelle =
18Done!
Done!
Done!
Pas commencé
Presque Done!

144. Suivi de la vélocité
Velocity over Last Eight Sprints
0
2
4
6
8
10
12
14
16
1 2 3 4 5 6 7 8
Sprint Number
Velocity

145. Suivi de la vélocité
40
30
20
10
0
21 3 4 5 6 7 8 9
Moyenne (3 meilleures) = 37
Moyenne (8 dernières) = 33
Moyenne (3 pires) = 28

146. Planification dynamique

147. Intégration du Product backlog et du
Burndown chart

148. Release Planning

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

152. Investissement incrémental - ROI

153. 153
Fin de la 4ème session
Questions ?
www.xebia.fr

154. 154
5ème session
Sujets avancés

155. 155
Product Owner
L’homme orchestre

156. Le proxy Product Owner

157. 157
Montée en charge
Gros projets

158. Scalabilité avec un Scrum de Scrums
www.xebia.fr

159. Scrum de Scrums de Scrums
www.xebia.fr

160. 160
Stratégies de test

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!

163. 163
Merci
www.xebia.fr