2009 scrum&xp
DESCRIPTION
TRANSCRIPT
1
Développement Agileavec Scrum et XP
www.xebia.fr
• 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
• 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…
• 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
5
1ère session
Pourquoi les méthodes agiles ?
• Dr Winston W. Royce, Managing the development of large software systems, 1970
Le cycle de développement classiqueCycle en V, Waterfall…
• 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é
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
Attentes utilisateurs
• 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
• 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
• 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
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
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
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.
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
• 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
• 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
Réduire le coût du changement
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é.
Le nouveau profil des projets IT
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
23
Fin de la 1ère session
Questions ?
www.xebia.fr
24
2ème session
Scrum
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
26
Présentation de Scrum
Scrum ?
“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
• É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
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
Scrum : la production en flux
• 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
• 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…
Un peu de tout tout le temps
Production incrémentalePiloter la progression
1 2 3 4 5
Production incrémentaleExplorer (prototypage)
1 2 3 4 5
Synthèse
• 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
Les rôles dans Scrum
Scrum définit 3 rôles
www.xebia.fr
Product Owner
Équipe
ScrumMaster
• 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
• 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
• 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
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
Le principe de co-localisationLa Team Room
46
Les artefacts de Scrum
Le Product Backlog
• Liste de fonctionnalités priorisées et estiméeso Exprimées sous forme de User Stories
• Produit en flux
Le Product Backlog
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
Sprint
Discussion : Définir READY et DONE
Ready
In Process
Done
Le Sprint Backlog
• 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
Task Board – Jour 1
D’après Erik Kniberg, Scrum & XP from the Trenches
Task Board – Jour N
D’après Erik Kniberg, Scrum & XP from the Trenches
Burndown Chart
D’après Erik Kniberg, Scrum & XP from the Trenches
Kan Ban et contrôle visuel
D’après Erik Kniberg, Scrum & XP from the Trenches
Kan Ban et contrôle visuel (2)
D’après Erik Kniberg, Scrum & XP from the Trenches
Task Board électronique
58
Rally EnterpriseRally Software
TrichordChangeVision
MingleThoughtworks
VersionOne EnterpriseVersionOne
L’Incrément
La définition de DONE
Tests unitaires
Codage
Conception
Analyse
Intégration
Tests utilisateurs
Tests performance
Beta
Production
61
Les cérémonies de Scrum
Le Sprint Planning
• 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)
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
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.
Sprint Planning
• 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
Task Board
D’après Erik Kniberg, Scrum & XP from the Trenches
Le Daily Scrum
• 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
• 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
Le Sprint Review
• 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
La Rétrospective
• 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
• 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.
77
Fin de la 2ème session
Questions ?
www.xebia.fr
78
3ème session
Introduction àeXtreme Programming
• 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
Les valeurs
www.xebia.fr
Communication leads to valuable feedback which encourages simplicity which allows for courage to change
communication
courage
simplicité
feedback
respect
• 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
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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
Synergie
www.xebia.fr
• 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
• 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
• 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
XP mal compris
www.xebia.fr
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
Cycles de feedback
www.xebia.fr
• 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
105
Fin de la 3ème session
Questions ?
www.xebia.fr
106
4ème session
Piloter un projet Agile
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
Gestion des exigences
• Le travail est organisé par valeur, pas par couche d’architecture
Organisation du travail
• 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 ?
• 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
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
• En tant que <acteur>,• je peux <fonctionnalité>• afin de <résultat obtenu>
Modèle de User Story
Qui, Quoi, Pourquoi… que manque-t-il?
• 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
Ce qui fait une bonne User Story
Bill Wake’s INVEST
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Ron Jeffries’ 3 Cs
Card
Conversation
Confirmation
• É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
• 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.
• 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
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
• 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.
• 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> »
• É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
• 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
• 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
• 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
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)
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
• 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
• 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
• 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
• 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
• 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
Estimations Agiles
Estimations et probabilités
• 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
• 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
Exercice – Temps de consommationFruit à consommer Complexité relative
Pomme
Banane
Grappe de raisin
Melon
Mûre
Mangue
Framboise
Ananas
Lychee
Pêche
• 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
Planning Poker - Exemple
2113
85321
55Bill
52Ann
58Vijay
33Susan
Round 2Round 1Estimateur
140
Planification
• « 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
Plusieurs niveaux de planification
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!
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
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
Planification dynamique
Intégration du Product backlog et du Burndown chart
Release Planning
• 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
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
• 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
Investissement incrémental - ROI
153
Fin de la 4ème session
Questions ?
www.xebia.fr
154
5ème session
Sujets avancés
155
Product OwnerL’homme orchestre
Le proxy Product Owner
157
Montée en charge
Gros projets
Scalabilité avec un Scrum de Scrums
www.xebia.fr
Scrum de Scrums de Scrums
www.xebia.fr
160
Stratégies de test
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
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
Merci
www.xebia.fr