2009 scrum&xp
description
Transcript of 2009 scrum&xp
![Page 1: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/1.jpg)
1
Développement Agileavec Scrum et XP
www.xebia.fr
![Page 2: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/2.jpg)
• Session 1 : Introductiono Pourquoi les méthodes agiles ?
• Session 2 : Scrumo Présentation de Scrumo Les rôles dans Scrumo Les artefacts de Scrumo Les cérémonies de Scrum
• Session 3 : Introduction a l’eXtreme Programming• Session 4 : Piloter un projet agile
o Gérer les exigenceso Estimations agileso Planification
• Session 5 : Sujets avancés
Agenda
www.xebia.fr
![Page 3: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/3.jpg)
• 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…
![Page 4: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/4.jpg)
• Qu’attendez-vous de la formation ?o Ecrivez un test et placez-le sur le tableauo 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
![Page 5: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/5.jpg)
5
1ère session
Pourquoi les méthodes agiles ?
![Page 6: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/6.jpg)
• Dr Winston W. Royce, Managing the development of large software systems, 1970
Le cycle de développement classiqueCycle en V, Waterfall…
![Page 7: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/7.jpg)
• 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é
![Page 8: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/8.jpg)
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
![Page 9: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/9.jpg)
Attentes utilisateurs
![Page 10: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/10.jpg)
• 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
![Page 11: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/11.jpg)
• Prédictible ou production en masseo Production d’une voitureo Suivre une recette de cuisine
• Développement de nouveau produito Créer un nouveau modèle de voitureo Créer une nouvelle recette
Deux types de projets
www.xebia.fr
Le développement logiciel est du développement de nouveau produit
![Page 12: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/12.jpg)
• 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
![Page 13: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/13.jpg)
Prédictif vs. Agile
www.xebia.fr
` `
Résultat
BusinessCase
Minimisationdes coûts
Maximisation de la valeur
Défensive
Offensive
Création de valeurGestion des
responsabilitésPartage 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
![Page 14: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/14.jpg)
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
![Page 15: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/15.jpg)
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 toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiationResponding 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.
![Page 16: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/16.jpg)
16
L’ombrelle agile
Agile Methodologies• eXtreme Programming
Kent Beck, Ward Cunningham, Ron Jeffries
• ScrumKen 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, KanBanDavid Anderson
• eXtreme Project ManagementRob Thomsett
• Lean Software DevelopmentTom & Mary Poppendieck
![Page 17: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/17.jpg)
• Eliminate wasteo Fonctionnalités inutiles, « churn », frontières
• Build quality ino Discipline, règles o Test, test, test
• Create knowledgeo Feedback, amélioration continue
• Defer commitmento Planification continue
• Deliver fast• Respect people• Optimize the whole
o Value Stream Map
Lean Software Developpment
www.xebia.fr
INSPECT & ADAPT
![Page 18: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/18.jpg)
• 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
![Page 19: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/19.jpg)
Réduire le coût du changement
![Page 20: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/20.jpg)
Résumé
www.xebia.fr
FEEDBACK
Principes Agiles Principes ClassiquesPetits LotsFonctionnalité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 changementAccepter 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 ControlTypiquement, 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 continueLes 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 FinLe 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éesDes é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 siloLes é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 rienLa phasage classique interdit de livrer quoi que ce soit avant que tout soit terminé.
![Page 21: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/21.jpg)
Le nouveau profil des projets IT
![Page 22: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/22.jpg)
Etat de l’Art
Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdfhttp://www.ambysoft.com/surveys/agileFebruary2008.html
Team locationSuccess percentage
Co-located Team 83%
Distributed teams but physically reachable 72%
Distributed across geographies 60%
Average:75% success rate
Agile Adoption Rate SurveyFeb 2008 642 respondents
State of Agile Development SurveyJuly 20083061 respondents in 80 countries
ComparisonAverage project: 30% success rateAgile project: 60-80% success rate
![Page 23: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/23.jpg)
23
Fin de la 1ère session
Questions ?
www.xebia.fr
![Page 24: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/24.jpg)
24
2ème session
Scrum
![Page 25: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/25.jpg)
L'Agilité n'est pas une recette
www.xebia.fr
LeanAgile
Systémique
Histoire Théorie des queuesPhilosophie
XP
Principes
Pratiques
YOU !
Scrum
Théorie des contraintesCritical Chain
Management
Implémentation
![Page 26: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/26.jpg)
26
Présentation de Scrum
![Page 27: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/27.jpg)
Scrum ?
![Page 28: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/28.jpg)
“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
![Page 29: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/29.jpg)
• É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
![Page 30: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/30.jpg)
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
![Page 31: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/31.jpg)
Scrum : la production en flux
![Page 32: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/32.jpg)
• 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
![Page 33: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/33.jpg)
• 4 volontaires, SVP !• 1er round :
o Le premier travailleur positionne tous les dés sur 1o Le second travailleur positionne tous les dés sur 2o Etc.
• 2ème roundo 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 cycleo Combien de temps il faut pour traiter tous les dés
Une petite simulation de Scrum…
![Page 34: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/34.jpg)
Un peu de tout tout le temps
![Page 35: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/35.jpg)
Production incrémentalePiloter la progression
1 2 3 4 5
![Page 36: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/36.jpg)
Production incrémentaleExplorer (prototypage)
1 2 3 4 5
![Page 37: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/37.jpg)
Synthèse
![Page 38: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/38.jpg)
• 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
![Page 39: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/39.jpg)
39
Les rôles dans Scrum
![Page 40: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/40.jpg)
Scrum définit 3 rôles
www.xebia.fr
Product Owner
Équipe
ScrumMaster
![Page 41: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/41.jpg)
• 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
![Page 42: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/42.jpg)
• 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
![Page 43: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/43.jpg)
• 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
![Page 44: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/44.jpg)
Organisation de l’équipe Scrum
44
Traditional Silos Customer BA Designer DeveloperPM
CoreTeam(EXAMPLE)
BA / Tester
BA
Tester
ProductOwner
Developer
Designer
Developer /BA
SM
ReleaseManager
CapacityPlanner
Prod.
Architect
TechOps
BusinessSponsor
RiskAssessor
Security
44
BAAnalysts DeveloperDeveloperDeveloperDesigners 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
![Page 45: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/45.jpg)
Le principe de co-localisationLa Team Room
![Page 46: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/46.jpg)
46
Les artefacts de Scrum
![Page 47: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/47.jpg)
Le Product Backlog
![Page 48: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/48.jpg)
• Liste de fonctionnalités priorisées et estiméeso Exprimées sous forme de User Stories
• Produit en flux
Le Product Backlog
![Page 49: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/49.jpg)
Product Backlog élémentairePriority Backlog item Acceptance Criteria Estimate
1 Allow a guest to make a reservation
• Confirmation email is sent• Must be made >24 hours in
advance3
2 As a guest, I want to cancel a reservation
• Confirmation email is sent• Must be canceled 15 days in
advance5
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
![Page 50: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/50.jpg)
Sprint
Discussion : Définir READY et DONE
Ready
In Process
Done
![Page 51: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/51.jpg)
Le Sprint Backlog
![Page 52: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/52.jpg)
• Sous-ensemble du Product Backlog que l’équipe s’engage à produire durant le Sprinto Chaque Story est découpée en tâches par l’équipeo Les tâches sont suivies dans un Task Boardo Un Burndown Chart permet de piloter la progression
Le Sprint Backlog
![Page 53: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/53.jpg)
Task Board – Jour 1
D’après Erik Kniberg, Scrum & XP from the Trenches
![Page 54: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/54.jpg)
Task Board – Jour N
D’après Erik Kniberg, Scrum & XP from the Trenches
![Page 55: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/55.jpg)
Burndown Chart
D’après Erik Kniberg, Scrum & XP from the Trenches
![Page 56: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/56.jpg)
Kan Ban et contrôle visuel
D’après Erik Kniberg, Scrum & XP from the Trenches
![Page 57: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/57.jpg)
Kan Ban et contrôle visuel (2)
D’après Erik Kniberg, Scrum & XP from the Trenches
![Page 58: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/58.jpg)
Task Board électronique
58
Rally EnterpriseRally Software
TrichordChangeVision
MingleThoughtworks
VersionOne EnterpriseVersionOne
![Page 59: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/59.jpg)
L’Incrément
![Page 60: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/60.jpg)
La définition de DONE
Tests unitaires
Codage
Conception
Analyse
Intégration
Tests utilisateurs
Tests performance
Beta
Production
![Page 61: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/61.jpg)
61
Les cérémonies de Scrum
![Page 62: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/62.jpg)
Le Sprint Planning
![Page 63: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/63.jpg)
• 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)
![Page 64: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/64.jpg)
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
Contextemétier
Capacitéde
l'équipe
Backlogde produit
Technos
Produitactuel
Planification du sprint
![Page 65: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/65.jpg)
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 vieOffrir 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.
![Page 66: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/66.jpg)
Sprint Planning
![Page 67: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/67.jpg)
• Revue de la vélocité et de la capacité du Sprinto 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
Backlogo 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 heureo Limiter la taille des tâches à < 16 heures
• S’engager sur les User Storieso A concurrence de la capacité
• Alimenter le Task Board
Exemple d’agenda pour un Sprint Planning
![Page 68: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/68.jpg)
Task Board
D’après Erik Kniberg, Scrum & XP from the Trenches
![Page 69: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/69.jpg)
Le Daily Scrum
![Page 70: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/70.jpg)
• Paramètreso Quotidieno Maximum 15 minuteso Debout
• Pas fait pour résoudre les problèmeso 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
![Page 71: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/71.jpg)
• Il ne s'agit pas d’un compte-rendu au ScrumMastero 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
![Page 72: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/72.jpg)
Le Sprint Review
![Page 73: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/73.jpg)
• L'équipe présente ce qu'elle a fait pendant le sprinto 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 < 2ho Pas de slides
• Toute l'équipe participe• Les intervenants du projets sont invités
Revue de Sprint
www.xebia.fr
![Page 74: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/74.jpg)
La Rétrospective
![Page 75: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/75.jpg)
• 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 ScrumMastero Product Ownero Équipeo Éventuellement d’autres intervenants
• Aboutit à un plan d’actions sur lequel l’équipe s’engageo Le Scrum Master en assure le suivi
Rétrospective
www.xebia.fr
![Page 76: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/76.jpg)
• Toute l'équipe collecte du feedback et discute sur ce qu'elle aimerait
Start / Stop / Continue
www.xebia.fr
Commencer à faire
Arrêter de faire
Continuer à faire
Juste une façon parmi d'autres de mener une
rétrospective.
![Page 77: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/77.jpg)
77
Fin de la 2ème session
Questions ?
www.xebia.fr
![Page 78: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/78.jpg)
78
3ème session
Introduction àeXtreme Programming
![Page 79: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/79.jpg)
• 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 moyenneso 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éthodologieso 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
![Page 80: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/80.jpg)
Les valeurs
www.xebia.fr
Communication leads to valuable feedback which encourages simplicity which allows for courage to change
communication
courage
simplicité
feedback
respect
![Page 81: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/81.jpg)
• Les pratiques découlent des 4 valeurso Communication, Simplicité, Feedback, Courageo Considérez les comme des « des fonctions de maximisation »
• Pratique = Étudeo 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èteo Il arrive de ne pas appliquer toutes les pratiques tout le temps en
fonction des projetso 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
![Page 82: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/82.jpg)
Les « cercles de vie »
www.xebia.fr
On-site Customer
ReleasePlanning
Small Releases
AcceptanceTests
CodingStandards
CollectiveOwnership
ContinuousIntegration
Metaphor
SustainablePace
Pair Programming
Unit Tests
Refactoring
Simple Design
Le client L’équipe Le code L’équipe Le client
![Page 83: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/83.jpg)
• 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 écriteo Et le coût élevé de sa création et de sa maintenance
Client sur site
www.xebia.fr
![Page 84: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/84.jpg)
• 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
![Page 85: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/85.jpg)
• 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 moiso 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
![Page 86: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/86.jpg)
• 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
![Page 87: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/87.jpg)
• 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
![Page 88: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/88.jpg)
• Le code est écrit par 2 développeurs sur 1 seule machineo 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 minuteso Et sur tous les types de tâches
• L’expérimentation montre une réelle efficacité [8]
Programmation en binôme
www.xebia.fr
![Page 89: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/89.jpg)
• Les bénéficeso Revue de code continueo 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 managerso Tester pour voir si cela fonctionneo Peut nécessiter un temps d’acclimatationo Expérience du développement plus intense
Programmation en binôme
www.xebia.fr
![Page 90: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/90.jpg)
• 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 Worko YAGNI – You Aren’t Gonna Need IT
Conception Simple
www.xebia.fr
![Page 91: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/91.jpg)
• 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
![Page 92: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/92.jpg)
• 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
![Page 93: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/93.jpg)
• 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
![Page 94: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/94.jpg)
• 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-overo 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
![Page 95: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/95.jpg)
• 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éeo Éviter le burnout
Rythme soutenable
www.xebia.fr
![Page 96: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/96.jpg)
Synergie
www.xebia.fr
![Page 98: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/98.jpg)
• Extrême = continuellemento Revue de code (pair programming)o Tests unitaireso Tests d’intégrationo 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équenteso Donne confiance aux utilisateurso Donne confiance à l’équipeo Donne confiance au management
Avantages d’XP
www.xebia.fr
![Page 99: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/99.jpg)
• XP n’est pas une « silver bullet » !• XP peut ne pas fonctionner pour
o Des grosses équipeso Des équipes distribuéeso Des systèmes trop complexeso Des projets d’intégration avec du code existanto Des organisations où la méthodologie est particulièrement rigideo Des organisation ou règne la culture du burn-out
• Où la valeur d’une personne dépend du temps passé au travailo Des ego sur dimensionnéso Des environnements physiques inappropriés
• Mais XP peut être adapté
Limitations
www.xebia.fr
![Page 100: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/100.jpg)
• Le changement culturel peut être difficile pour les développeurs et les managerso Mineurs : rythme soutenable, standards de développement, tests,
refactoringo Majeurs : client sur site, jeu de planification, livraisons fréquentes,
conception simpleo 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 possibleo Manque de disponibilitéo Niveau de prise de décisiono En rupture avec la culture interne
Inconvénients d’XP
www.xebia.fr
![Page 101: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/101.jpg)
XP mal compris
www.xebia.fr
![Page 102: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/102.jpg)
Scrum & XP
SprintPlanningmeeting
Daily Scrum
Sprint Review
Sprintbacklog
Productbacklog
TDD
Pair programming
Refactoring
Simpledesign
Coding standard
SustainablePace
Metaphor
Continuous
Integration
Collective
ownership
Whole team
Planning game
Small releases
Customer tests
Burndownchart
Productowner
Team
ScrumMaster
Scrum
XP
![Page 103: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/103.jpg)
Cycles de feedback
www.xebia.fr
![Page 104: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/104.jpg)
• Ce jeu est appelé le jeu de vélocité. Y avez-vous déjà joué ?o Changez de casquettes 3 foiso Développeurs – estimento Propriétaires de produit – priorisent en fonction de la valeur métier et du tempso 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 à 2o Pensez complexité ET temps (une story simple peut prendre longtemps)
• Il y aura 3 itérations, chacune de 3 minuteso 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
![Page 105: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/105.jpg)
105
Fin de la 3ème session
Questions ?
www.xebia.fr
![Page 106: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/106.jpg)
106
4ème session
Piloter un projet Agile
![Page 107: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/107.jpg)
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.
![Page 108: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/108.jpg)
108
Gestion des exigences
![Page 109: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/109.jpg)
• Le travail est organisé par valeur, pas par couche d’architecture
Organisation du travail
![Page 110: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/110.jpg)
• Les spécifications complètes :o Assument que tout est connaissable à
l’avanceo Sont chronophages à rédiger, pénibles à
lireo 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 ?
![Page 111: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/111.jpg)
• 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èqueo Un point de départ pour discuter
• Pas une spécification exhaustive
Introduction aux User Stories
![Page 112: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/112.jpg)
De la User Story aux tâches
User Story #023En tant que nouvel utilisateur, je peux saisir mes informations personnelles
Priorité : 1Estimation : 2
Critères d’acceptanceL’adresse est valide dans le référentielLe numéro de téléphone contient 10 chiffresLe nom et l’adresse email sont obligatoires
TâchesPrototyper l’UIDévelopper le code HTML/CSSCréer les champs dans la baseDévelopper les contrôle métierEcrire les cas de testCoder les fixturesTests d’acceptanceTests ergonomiquesRédiger l’aide en ligne
![Page 113: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/113.jpg)
• En tant que <acteur>,• je peux <fonctionnalité>• afin de <résultat obtenu>
Modèle de User Story
Qui, Quoi, Pourquoi… que manque-t-il?
![Page 114: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/114.jpg)
• 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 fraisUn abonné non Premium doit payer des frais de 10% pour une annulation le jour mêmeUn email de confirmation est envoyé à l’abonnéL’hôtel est informé de l’annulation
![Page 115: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/115.jpg)
Ce qui fait une bonne User Story
Bill Wake’s INVEST
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Ron Jeffries’ 3 Cs
Card
Conversation
Confirmation
![Page 116: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/116.jpg)
• Éviter l’introduction de dépendanceso 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
![Page 117: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/117.jpg)
• 3 jours si initial; 1 sinon
Rendre les stories indépendantes
www.xebia.fr
Combiner les stories
Décomposer dans des dimensions différentes
Effectuer 2 estimationset 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.
![Page 118: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/118.jpg)
• Les stories ne sont pas o Des contrats signés, elles peuvent changero 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étudeo 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éeso Si la story est un contrat, alors il faut l’estimer comme un contrat
Négociable
www.xebia.fr
![Page 119: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/119.jpg)
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
![Page 120: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/120.jpg)
• 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’erreuret de traces est effectuée au travers un jeu de classescommunes.
![Page 121: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/121.jpg)
• De nombreux projets assument à tort qu’il n’y a qu’un seul utilisateuro « 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> »
![Page 122: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/122.jpg)
• Élargir le point de vue• Permettre aux utilisateurs de varier
o Pourquoi ils utilisent le logicielo Comment ils utilisent le logicielo Backgroundo Familiarité avec les logiciels / ordinateurs
• Définitiono 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èmeo Technique des Persona
Les rôles de l’utilisateur
www.xebia.fr
![Page 123: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/123.jpg)
• 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
![Page 124: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/124.jpg)
• Les grosses stories (ou épiques) sonto Difficiles à estimero Difficiles à planifier
• Ne rentrent pas facilement dans un unique sprint
• Story composéeo Une story qui comprend de multiples stories plus courtes
• Story complexeso Une story qui est large et ne peut pas être désagrégée facilement
Small
www.xebia.fr
![Page 125: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/125.jpg)
• 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
![Page 126: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/126.jpg)
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)
![Page 127: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/127.jpg)
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
![Page 128: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/128.jpg)
• 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 trouverle 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 jamaisavoir à attendre longtemps avant l’apparition d’un écran
![Page 129: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/129.jpg)
• Visiono 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 Caseo Les restaurants paieront une petite redevance
chaque fois qu’un utilisateur clique sur leur lieno Ils paient également pour être mis en valeur
Exercice – Fantastic Food Finder
![Page 130: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/130.jpg)
• Rédigez les Users Stories pour FFFo Trouvez-en au moins 12o Ecrivez les critères de validation pour au moins l’une d’entre elleso 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
![Page 131: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/131.jpg)
• Les User Stories ne sont pas l’unique moyen de gérer les exigences dans un projet agile. D’autres approches :o Essential Use Caseso Low-fidelity prototypingo High-fidelity prototyping
• La bonne façon de faire est souvent le résultat de plusieurs essais…
Au-delà des User Stories
![Page 132: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/132.jpg)
• 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
![Page 133: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/133.jpg)
133
Estimations Agiles
![Page 134: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/134.jpg)
Estimations et probabilités
![Page 135: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/135.jpg)
• 2 approches populaires• Story Points
o Mesure strictement relative de la complexitéo La variabilité est compensée sur le nombre de storieso Ne varie pas dans le temps
• Jour de développement Idéalo Autour de 4-5 heureso Lien direct avec le temps idéal
Unités d’estimation agiles
![Page 136: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/136.jpg)
• Des échelles non linéaires sont généralement préférées:o Fibonacci: 1, 2, 3, 5, 8o 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
![Page 137: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/137.jpg)
Exercice – Temps de consommationFruit à consommer Complexité relative
Pomme
Banane
Grappe de raisin
Melon
Mûre
Mangue
Framboise
Ananas
Lychee
Pêche
![Page 138: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/138.jpg)
• 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 poidso Le Product Owner lit la story ; on en discute brièvemento Chaque estimateur choisit un carte (face cachée)o Toutes les cartes sont retournées simultanémento Les différences sont argumentées (extrêmes)o Ré-estimer jusqu’à ce que les estimations convergent (ou
abandonner !)
Le planning poker
![Page 139: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/139.jpg)
Planning Poker - Exemple
2113
85321
55Bill
52Ann
58Vijay
33Susan
Round 2Round 1Estimateur
![Page 140: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/140.jpg)
140
Planification
![Page 141: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/141.jpg)
• « 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 exactitudeo Fiabilité vs quantité
Planifier vs. Suivre un plan
![Page 142: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/142.jpg)
Plusieurs niveaux de planification
![Page 143: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/143.jpg)
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!
![Page 144: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/144.jpg)
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
Vel
oci
ty
![Page 145: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/145.jpg)
Suivi de la vélocité
40
30
20
10
021 3 4 5 6 7 8 9
Moyenne (3 meilleures) = 37Moyenne (8 dernières) = 33
Moyenne (3 pires) = 28
![Page 146: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/146.jpg)
Planification dynamique
![Page 147: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/147.jpg)
Intégration du Product backlog et du Burndown chart
![Page 148: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/148.jpg)
Release Planning
![Page 149: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/149.jpg)
• Descriptiono Session de planning initiale, permettant de passer en revue le
backlog initial, et de déterminer les dates des release
• Duréeo 2-4 heures
• Participantso Team, Product Owner, ScrumMaster
Release Planning - Aperçu
Goals
Features
Stories
Tasks
![Page 150: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/150.jpg)
Utiliser les Story Maps
Workflow Sequence
Prio
rity
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
![Page 151: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/151.jpg)
• Une road map permet de communiquer clairement les objectifs business de chacune des releaseso Une road map doit être respectéeo Utiliser des buffers pour piloter la road map
• Buffer de fonctionnalités (70% - 30%)• Buffer de temps (50%)
Road Map
PB
400
500
![Page 152: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/152.jpg)
Investissement incrémental - ROI
![Page 153: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/153.jpg)
153
Fin de la 4ème session
Questions ?
www.xebia.fr
![Page 154: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/154.jpg)
154
5ème session
Sujets avancés
![Page 155: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/155.jpg)
155
Product OwnerL’homme orchestre
![Page 156: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/156.jpg)
Le proxy Product Owner
![Page 157: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/157.jpg)
157
Montée en charge
Gros projets
![Page 158: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/158.jpg)
Scalabilité avec un Scrum de Scrums
www.xebia.fr
![Page 159: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/159.jpg)
Scrum de Scrums de Scrums
www.xebia.fr
![Page 160: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/160.jpg)
160
Stratégies de test
![Page 161: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/161.jpg)
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
![Page 162: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/162.jpg)
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!
![Page 163: 2009 scrum&xp](https://reader031.fdocuments.us/reader031/viewer/2022013003/5452941eaf795963148b9faa/html5/thumbnails/163.jpg)
163
Merci
www.xebia.fr