SlideShare une entreprise Scribd logo
Sommaire :

1- Historique
2-Définition
3-Les valeurs d'eXtreme Programming
4-Les principales pratique
5-Projet XP
6-Cycle de vie
7-Membre d’équipe et rôles
8-Forces et faiblesses
1-Historique:


L'Extreme Programming a été inventée
par Kent Beck, Ward Cunningham et Ron
Jeffries pendant leur travail sur un projet
« C3 » de calcul des rémunérations chez
Chrysler. Kent Beck, chef de projet en mars
1996 commença à affiner la méthode de
développement utilisée sur le projet. Celle-ci
est née officiellement en octobre 1999 avec
le livre «Extreme Programming
Explained »de Kent Beck.
2-Définition :


XP est l’une des méthodes agiles qui se
base dans la suppression des risques
existants dans un projet qui contient des
besoins changeants, elle pousse a
l’extrême des principes simples.



Les pères de la méthode, Ward
Cunningham et Kent Beck définissent
eXtreme Programming comme "une
méthode basée sur des pratiques qui sont
autant de boutons de contrôle poussés au
maximum".
3-Les valeurs d'eXtreme
Programming
Les valeurs du l’eXtreme
Programming sont :
Communication
 Simplicité
 Feedback
 Courage
 Respect

Communication :
L'absence de communication est certainement l'un des
défauts les plus graves qui mettent en péril un projet.
Diverses pratiques XP tendent à rendre la
communication omniprésente entre tous les
intervenants :
 entre développeurs (programmation en binôme)
 entre développeurs et managers (tests, estimations)
 entre développeurs et clients (tests, spécifications).
Simplicité :




Cette valeur de simplicité repose sur le pari
qu'il coûte moins cher de développer un
système simple aujourd'hui quitte à devoir
engager de nouveaux frais plus tard pour
rajouter des fonctionnalités supplémentaires
plutôt que de concevoir dès le départ un
système très compliqué dont on risque de
n'avoir plus besoin dans un avenir proche.
XP encourage donc à toujours s'orienter
vers la solution la plus simple qui puisse
satisfaire les besoins du client.
Feedback :
Le retour est immédiat pour les développeurs grâce
aux tests unitaires. Pour les clients, le retour se fait
à l'échelle de quelques jours grâce aux tests
fonctionnels qui leur permettent d'avoir une vision
permanente de l'état du système.

Un feedback permanent est positif pour :
 le client qui a une bonne vision du projet, peut
détecter tout écart par rapport au planning et à ses
attentes de manière à les corriger rapidement.
 les développeurs, il lui permet de repérer et de
corriger les erreurs beaucoup plus facilement.
Courage :
Du courage est nécessaire aussi bien chez le client que chez les
développeurs.
Pour mener à bien un projet XP, le client doit avoir le courage de :
 donner un ordre de priorité à ses exigences.
 reconnaître que certains de ses besoins ne sont pas toujours très
clairs.
le développeur doit avoir le courage de :
 modifier l'architecture même si le développement est déjà bien
avancé.
 jeter du code existant et d'accepter qu'il est parfois plus rapide et
efficace de réécrire une portion de code à partir de zéro plutôt que
de bricoler du code existant.


Les relations entre
l’équipe de
développement et le
client et même entre
eux doivent êtres
baser sur le respect
mutuel.
4-Les principales pratique
Les principales pratique de l’XP
sont :













Planning game
Petites releases
Utilisation de métaphores
Conception simple
Tests (unitaires et fonctionnels)
Refactoring du code
Programmation en binôme
Appropriation collective du code
Intégration continue
Pas de surcharge de travail
Client sur site
Standards de code
Planning game :
Cette pratique a pour but de planifier uniquement les releases. La
planification se fait sous forme de jeu auquel participent les
développeurs et le client . Cette pratique est constituée de
trois phases :


première phase dite d'exploration, le client exprime ses
besoins en termes de fonctionnalités. Pour cela, il les écrit
sous forme de "user stories" .



deuxième phase dite d'engagement, les user stories sont
triées en fonction de la valeur qu'elles apportent au client et
des risques encourus lors de leur développement. Ceci permet
d'aboutir à les classer par ordre de priorité.



Troisième phase dite de direction permet de mettre à jour le
planning de la prochaine release.
User stories
Petites releases :


Pour une bonne gestion des risques, la sortie
des releases doit intervenir le plus souvent
possible.



D'une version à l'autre, l'évolution doit être la
plus petite possible, tout en s'efforçant
d'apporter le plus de valeur ajoutée et des
fonctionnalités dans leur intégralité.
Utilisation de métaphores :


XP recommande d'utiliser des métaphores
pour décrire l'architecture du système. De
telles images permettent à tout le monde
d'avoir une vision globale du système et d'en
comprendre les éléments principaux ainsi
que leurs interactions.
Conception simple :
La simplicité est une des valeurs fondamentales d'XP. Il
faut toujours développer la solution la plus simple
possible et éviter de développer plus que ce dont on
a besoin.
les exigences sont :
 satisfaire tous les tests.
 ne jamais dupliquer une logique
 utiliser le moins possible de classes et de méthodes.

Ceux qui pratiquent XP résument cela sous la phrase
YAGNI ("You ain't gonna need it", « vous n’en aurez
pas besoin »).
Tests (unitaires et fonctionnels) :
Les tests unitaires sont écrits et effectués par
les développeurs pour vérifier le bon
fonctionnement et la non régression des
méthodes ou des constructeurs.
 Les tests fonctionnels sont conçus par le client
et lui permettent de :


 vérifier le fonctionnement global du système.
 contrôler l'évolution du projet.

 affiner l'expression de ses besoins.
Pour une qualité de code encore meilleure, il est
recommandé d'écrire les tests avant le code de
l'application.
Refactoring du code :
Le but de cette pratique est de simplifier le
code, tout en faisant en sorte que tous les
tests soient satisfaits.
 D'un point de vue purement fonctionnel, cette
simplification n'est pas nécessaire.
 le refactoring du code a pour but de :


 assurer que l'ajout de fonctionnalités

supplémentaires sera facilité.
 tendre à produire un code mieux pensé, plus
modulaire, sans duplications de code et donc plus
facile à maintenir.
Programmation en binôme :
Toute l'écriture du code se fait à deux
personnes sur une même machine, avec une
seule souris et un seul clavier.
 On distingue deux rôles :


○ le pilote ("driver"), celui qui a le clavier, cherche la

meilleure approche sur une portion de code bien
précise.
○ le "partner" peut observer avec beaucoup plus de
recul et ainsi suggérer d'autres solutions ou
soulever des problèmes d'ordre plus général.
Appropriation collective du code :


Toute l'équipe est sensée connaître la totalité
du code.



Cela implique que tout le monde peut
intervenir pour faire des ajouts ou des
modifications sur une portion de code qu'il n'a
pas écrit lui même si cela s'avère nécessaire.
Intégration continue :


Après chaque fin de tâche le code
nouvellement écrit doit être intégré à
l'existant de manière à avoir à tout
moment un existant fonctionnel qui
passe avec succès tous les tests.
Pas de surcharge de travail :
L'objectif est de ne pas dépasser 40
heures de travail par semaine pour les
développeurs.
 Il ne s'agit pas de chercher à travailler
peu, mais les spécialistes d' eXtreme
Programming ont pris conscience du fait
que la surcharge de travail, en plus
d'être désagréable, est néfaste.

Client sur site :


le client est intégré à l’équipe pour définir
précisément les besoins, arbitrer sur les
priorités et visualiser « en direct » le résultat
des développements.



Pour une meilleure communication, le client
et les développeurs travaillent dans le même
espace autant que possible.
Standards de code :


Il est nécessaire de disposer de normes de
nommage et de programmation pour que
chacun puisse lire et comprendre facilement
le code produit par les autres.
5-Projet XP
Projet XP :
Itération :
Développement :
Appropriation collective du code
:
6-Cycle de vie
Cycle de vie :
7-Membre d’équipe et rôles
Membre d’équipe et rôles :
Développeur :
Il est l'élément principal d'un projet XP. Son rôle est
d’écrire des lignes de code, rajouter des
fonctionnalités, simplifier et optimiser son code mais
aussi d’avoir la qualité de communiquer et du courage.


Client :
Le client est l'autre moitié du duo essentiel dans
l'approche eXtreme Programming. Le développeur sait
comment programmer et le client sait quoi
programmer.

Testeur :
Étant donné que les tests unitaires sont à la
charge des développeurs, le testeur a pour
rôle d'aider le client à choisir et à écrire ses
tests fonctionnels.


Tracker :
C'est un peu la conscience de l'équipe. Son rôle
est d'aider l'équipe à mieux estimer le temps
nécessaire à l'implémentation de chaque user
story et de garder un œil sur le planning en
relation avec l'avancement réel du projet.

Coach :
Le coach a la responsabilité globale de tout le
processus. Son rôle est de recadrer le projet,
d'ajuster les procédures. Toute la difficulté de
sa tâche réside dans le fait qu'il se doit
d'intervenir de la manière la moins intrusive
possible.
 Consultant :
Le rôle d'un consultant est d'apporter à l'équipe
les connaissances nécessaires pour qu'ils
résolvent eux mêmes leur problème et non de
leur apporter une solution toute faite.



Big Boss :

Le Big Boss apporte à l'équipe courage et
confiance.
8-Forces et faiblesses


Forces :
 Extreme Programming apparaît comme la plus

radicale des méthodes agiles.
 XP se révèle particulièrement efficace dans le

cadre de petits projets.
 XP réalise des applications de qualité grâce à la

rigueur imposée sur les tests, qui plus est collent
au désirs du client puisque celui-ci est intégré au
projet de A à Z.


Faiblesses :
 XP n'est pas applicable dans tous les cas.
 Le cas d'une équipe supérieure à une douzaine de

personnes est un autre exemple où XP est
difficilement adaptable car le nombre risque de
ralentir, d'alourdir les procédures et de rendre la
communication plus difficile et moins efficace.
 En ce qui concerne les développeurs, la pratique

de la programmation en binôme n'est pas
forcément très bien ressentie par tous.
Question ?
Merci pour votre attention

Contenu connexe

Tendances

Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agilesguesta206aa87
 
Etude des Frameworks PHP
Etude des Frameworks PHPEtude des Frameworks PHP
Etude des Frameworks PHP
JEAN-GUILLAUME DUJARDIN
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
Mohammed Amine Mostefai
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
Nicolas Perriault
 
Methodes agiles
Methodes agilesMethodes agiles
Methodes agiles
Khalid Nafil
 
Introduction à l'agilité
Introduction à l'agilitéIntroduction à l'agilité
Introduction à l'agilité
Jonas Vonlanthen
 
Maintenance logicielle
Maintenance logicielleMaintenance logicielle
Maintenance logicielle
Nicolas Anquetil
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
Ghodhbane Mohamed Amine
 
Convergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XPConvergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XP
Agile Tour Genève
 
Modèle en v
 Modèle en v Modèle en v
Modèle en v
bouye2209
 
Scrum
ScrumScrum
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
Scrum - Une méthode agile sous la loupe ...
Scrum  - Une méthode agile sous la loupe ...Scrum  - Une méthode agile sous la loupe ...
Scrum - Une méthode agile sous la loupe ...
Bilel McSam
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
Pierre
 
Psp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 FrPsp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 Fr
Frederick Lussier
 
Méthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XPMéthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XP
Mohammed Amine Mostefai
 
Scrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du Code
Scrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du CodeScrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du Code
Scrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du Code
Fabrice Aimetti
 

Tendances (20)

Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agiles
 
Etude des Frameworks PHP
Etude des Frameworks PHPEtude des Frameworks PHP
Etude des Frameworks PHP
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
 
Methodes agiles
Methodes agilesMethodes agiles
Methodes agiles
 
Introduction à l'agilité
Introduction à l'agilitéIntroduction à l'agilité
Introduction à l'agilité
 
Maintenance logicielle
Maintenance logicielleMaintenance logicielle
Maintenance logicielle
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
Présentation kanban
Présentation kanbanPrésentation kanban
Présentation kanban
 
Convergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XPConvergences entre CMMI et SCRUM / XP
Convergences entre CMMI et SCRUM / XP
 
Modèle en v
 Modèle en v Modèle en v
Modèle en v
 
Scrum
ScrumScrum
Scrum
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Scrum - Une méthode agile sous la loupe ...
Scrum  - Une méthode agile sous la loupe ...Scrum  - Une méthode agile sous la loupe ...
Scrum - Une méthode agile sous la loupe ...
 
Initiation à l'agile
Initiation à l'agileInitiation à l'agile
Initiation à l'agile
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
 
Psp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 FrPsp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 Fr
 
Méthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XPMéthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XP
 
Scrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du Code
Scrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du CodeScrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du Code
Scrum et CMMI Niveau 5 - La Potion Magique pour les Guerriers du Code
 

En vedette

Scrum vs XP
Scrum vs XPScrum vs XP
Scrum vs XP
Sebastien Tanguy
 
Modele Avec Des Images Fortes (Our Copil Projet Id Zone)
Modele Avec Des Images Fortes (Our Copil Projet Id Zone)Modele Avec Des Images Fortes (Our Copil Projet Id Zone)
Modele Avec Des Images Fortes (Our Copil Projet Id Zone)shudyka
 
Scrum/XP : Témoignage de 2 développeurs
Scrum/XP : Témoignage de 2 développeursScrum/XP : Témoignage de 2 développeurs
Scrum/XP : Témoignage de 2 développeurs
chapurlatn
 
Up1
Up1Up1
Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322
Jean-Luc MAZE
 
Conduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & OutilsConduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & Outils
stephanie vincent
 
Les différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisationLes différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisation
Communauté d'agglomération du Pays de Grasse
 
AgileTour Toulouse 2012 : quel chemin vers l’agilité
AgileTour Toulouse 2012 : quel chemin vers l’agilitéAgileTour Toulouse 2012 : quel chemin vers l’agilité
AgileTour Toulouse 2012 : quel chemin vers l’agilitéAgile Toulouse
 
Enr idees recues-cler-hespul-rac_juillet-2014
Enr idees recues-cler-hespul-rac_juillet-2014Enr idees recues-cler-hespul-rac_juillet-2014
Enr idees recues-cler-hespul-rac_juillet-2014
RAC-F
 
Programme de 16 Jours
Programme de 16 JoursProgramme de 16 Jours
Programme de 16 Jours
Ideotour Vietnam
 
Ingenierie pedagogique
Ingenierie pedagogiqueIngenierie pedagogique
Ingenierie pedagogiqueYahya Ahmedo
 
Book illustration-florence gendre
Book illustration-florence gendreBook illustration-florence gendre
Book illustration-florence gendre
Florence GENDRE
 
Information metier hotellerie restauration café, bar brasserie www.hotellerie...
Information metier hotellerie restauration café, bar brasserie www.hotellerie...Information metier hotellerie restauration café, bar brasserie www.hotellerie...
Information metier hotellerie restauration café, bar brasserie www.hotellerie...
Emploi Hotellerie Restauration
 
Rechercher des entreprises d'accueil pour réaliser un projet en BTS TC
Rechercher des entreprises d'accueil pour réaliser un projet en BTS TCRechercher des entreprises d'accueil pour réaliser un projet en BTS TC
Rechercher des entreprises d'accueil pour réaliser un projet en BTS TC
szarzynski
 
Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...
Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...
Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...
Pape MBAYE
 
Présentation neuchatel sep2012 revue rpa
Présentation neuchatel sep2012 revue rpa Présentation neuchatel sep2012 revue rpa
Présentation neuchatel sep2012 revue rpa
SYZBank
 
LE SENS DE L’ENGAGEMENT ET DU RÉSULTAT
LE SENS DE L’ENGAGEMENT ET DU RÉSULTATLE SENS DE L’ENGAGEMENT ET DU RÉSULTAT
LE SENS DE L’ENGAGEMENT ET DU RÉSULTAT
Cursus Management
 

En vedette (19)

Scrum vs XP
Scrum vs XPScrum vs XP
Scrum vs XP
 
Modele Avec Des Images Fortes (Our Copil Projet Id Zone)
Modele Avec Des Images Fortes (Our Copil Projet Id Zone)Modele Avec Des Images Fortes (Our Copil Projet Id Zone)
Modele Avec Des Images Fortes (Our Copil Projet Id Zone)
 
Scrum/XP : Témoignage de 2 développeurs
Scrum/XP : Témoignage de 2 développeursScrum/XP : Témoignage de 2 développeurs
Scrum/XP : Témoignage de 2 développeurs
 
Up1
Up1Up1
Up1
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322
 
Conduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & OutilsConduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & Outils
 
Les différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisationLes différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisation
 
AgileTour Toulouse 2012 : quel chemin vers l’agilité
AgileTour Toulouse 2012 : quel chemin vers l’agilitéAgileTour Toulouse 2012 : quel chemin vers l’agilité
AgileTour Toulouse 2012 : quel chemin vers l’agilité
 
Enr idees recues-cler-hespul-rac_juillet-2014
Enr idees recues-cler-hespul-rac_juillet-2014Enr idees recues-cler-hespul-rac_juillet-2014
Enr idees recues-cler-hespul-rac_juillet-2014
 
Programme de 16 Jours
Programme de 16 JoursProgramme de 16 Jours
Programme de 16 Jours
 
Ingenierie pedagogique
Ingenierie pedagogiqueIngenierie pedagogique
Ingenierie pedagogique
 
Book illustration-florence gendre
Book illustration-florence gendreBook illustration-florence gendre
Book illustration-florence gendre
 
Information metier hotellerie restauration café, bar brasserie www.hotellerie...
Information metier hotellerie restauration café, bar brasserie www.hotellerie...Information metier hotellerie restauration café, bar brasserie www.hotellerie...
Information metier hotellerie restauration café, bar brasserie www.hotellerie...
 
Prueba I
Prueba IPrueba I
Prueba I
 
Rechercher des entreprises d'accueil pour réaliser un projet en BTS TC
Rechercher des entreprises d'accueil pour réaliser un projet en BTS TCRechercher des entreprises d'accueil pour réaliser un projet en BTS TC
Rechercher des entreprises d'accueil pour réaliser un projet en BTS TC
 
Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...
Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...
Présentation après visite de l'Association Togolaise pour le Bien Etre Fami...
 
Présentation neuchatel sep2012 revue rpa
Présentation neuchatel sep2012 revue rpa Présentation neuchatel sep2012 revue rpa
Présentation neuchatel sep2012 revue rpa
 
LE SENS DE L’ENGAGEMENT ET DU RÉSULTAT
LE SENS DE L’ENGAGEMENT ET DU RÉSULTATLE SENS DE L’ENGAGEMENT ET DU RÉSULTAT
LE SENS DE L’ENGAGEMENT ET DU RÉSULTAT
 

Similaire à Xtreme Programming

12 agile
12 agile12 agile
12 agile
MiisterSifdin1
 
Test driven development v0.2 20121221
Test driven development v0.2 20121221Test driven development v0.2 20121221
Test driven development v0.2 20121221
Frédéric Delorme
 
4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel
lauraty3204
 
CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?
CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?
CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?
florentpellet
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
Tremeur Balbous
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
testuser715939
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
Frederic Hardy
 
Article de référence de Winston Royce
Article de référence de Winston RoyceArticle de référence de Winston Royce
Article de référence de Winston Royce
Fabrice Aimetti
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
Sany_M
 
L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
Michel Bruchet
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
NoamHaythem
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
agnes_crepet
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1DIALLO Boubacar
 
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
qualimétrie logiciel -  Entreprise Software Analytic - nov 2015qualimétrie logiciel -  Entreprise Software Analytic - nov 2015
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
Julien Vq
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
Jean Michel
 
Intégration continue transco
Intégration continue transcoIntégration continue transco
Intégration continue transcolaurent_opnworks
 
Le métier de Product Owner
Le métier de Product OwnerLe métier de Product Owner
Le métier de Product Owner
Florent Boyer
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdf
imenhamada17
 

Similaire à Xtreme Programming (20)

12 agile
12 agile12 agile
12 agile
 
Test driven development v0.2 20121221
Test driven development v0.2 20121221Test driven development v0.2 20121221
Test driven development v0.2 20121221
 
4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel
 
CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?
CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?
CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Article de référence de Winston Royce
Article de référence de Winston RoyceArticle de référence de Winston Royce
Article de référence de Winston Royce
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
 
L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Les pratiques Scrum
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1
 
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
qualimétrie logiciel -  Entreprise Software Analytic - nov 2015qualimétrie logiciel -  Entreprise Software Analytic - nov 2015
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
 
Intégration continue transco
Intégration continue transcoIntégration continue transco
Intégration continue transco
 
Le métier de Product Owner
Le métier de Product OwnerLe métier de Product Owner
Le métier de Product Owner
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdf
 

Dernier

Iris van Herpen. pptx
Iris         van         Herpen.      pptxIris         van         Herpen.      pptx
Iris van Herpen. pptx
Txaruka
 
Textes de famille concernant les guerres V2.pdf
Textes de famille concernant les guerres V2.pdfTextes de famille concernant les guerres V2.pdf
Textes de famille concernant les guerres V2.pdf
Michel Bruley
 
Iris van Herpen. pptx
Iris         van        Herpen.      pptxIris         van        Herpen.      pptx
Iris van Herpen. pptx
Txaruka
 
Veille Audocdi 90 - mois de juin 2024.pdf
Veille Audocdi 90 - mois de juin 2024.pdfVeille Audocdi 90 - mois de juin 2024.pdf
Veille Audocdi 90 - mois de juin 2024.pdf
frizzole
 
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
M2i Formation
 
Bibliothèque de L'Union - Bilan de l'année 2023
Bibliothèque de L'Union - Bilan de l'année 2023Bibliothèque de L'Union - Bilan de l'année 2023
Bibliothèque de L'Union - Bilan de l'année 2023
Bibliothèque de L'Union
 
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
BenotGeorges3
 

Dernier (7)

Iris van Herpen. pptx
Iris         van         Herpen.      pptxIris         van         Herpen.      pptx
Iris van Herpen. pptx
 
Textes de famille concernant les guerres V2.pdf
Textes de famille concernant les guerres V2.pdfTextes de famille concernant les guerres V2.pdf
Textes de famille concernant les guerres V2.pdf
 
Iris van Herpen. pptx
Iris         van        Herpen.      pptxIris         van        Herpen.      pptx
Iris van Herpen. pptx
 
Veille Audocdi 90 - mois de juin 2024.pdf
Veille Audocdi 90 - mois de juin 2024.pdfVeille Audocdi 90 - mois de juin 2024.pdf
Veille Audocdi 90 - mois de juin 2024.pdf
 
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
 
Bibliothèque de L'Union - Bilan de l'année 2023
Bibliothèque de L'Union - Bilan de l'année 2023Bibliothèque de L'Union - Bilan de l'année 2023
Bibliothèque de L'Union - Bilan de l'année 2023
 
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
 

Xtreme Programming

  • 1.
  • 2.
  • 3. Sommaire : 1- Historique 2-Définition 3-Les valeurs d'eXtreme Programming 4-Les principales pratique 5-Projet XP 6-Cycle de vie 7-Membre d’équipe et rôles 8-Forces et faiblesses
  • 5.  L'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant leur travail sur un projet « C3 » de calcul des rémunérations chez Chrysler. Kent Beck, chef de projet en mars 1996 commença à affiner la méthode de développement utilisée sur le projet. Celle-ci est née officiellement en octobre 1999 avec le livre «Extreme Programming Explained »de Kent Beck.
  • 7.  XP est l’une des méthodes agiles qui se base dans la suppression des risques existants dans un projet qui contient des besoins changeants, elle pousse a l’extrême des principes simples.  Les pères de la méthode, Ward Cunningham et Kent Beck définissent eXtreme Programming comme "une méthode basée sur des pratiques qui sont autant de boutons de contrôle poussés au maximum".
  • 9. Les valeurs du l’eXtreme Programming sont : Communication  Simplicité  Feedback  Courage  Respect 
  • 10. Communication : L'absence de communication est certainement l'un des défauts les plus graves qui mettent en péril un projet. Diverses pratiques XP tendent à rendre la communication omniprésente entre tous les intervenants :  entre développeurs (programmation en binôme)  entre développeurs et managers (tests, estimations)  entre développeurs et clients (tests, spécifications).
  • 11. Simplicité :   Cette valeur de simplicité repose sur le pari qu'il coûte moins cher de développer un système simple aujourd'hui quitte à devoir engager de nouveaux frais plus tard pour rajouter des fonctionnalités supplémentaires plutôt que de concevoir dès le départ un système très compliqué dont on risque de n'avoir plus besoin dans un avenir proche. XP encourage donc à toujours s'orienter vers la solution la plus simple qui puisse satisfaire les besoins du client.
  • 12. Feedback : Le retour est immédiat pour les développeurs grâce aux tests unitaires. Pour les clients, le retour se fait à l'échelle de quelques jours grâce aux tests fonctionnels qui leur permettent d'avoir une vision permanente de l'état du système. Un feedback permanent est positif pour :  le client qui a une bonne vision du projet, peut détecter tout écart par rapport au planning et à ses attentes de manière à les corriger rapidement.  les développeurs, il lui permet de repérer et de corriger les erreurs beaucoup plus facilement.
  • 13. Courage : Du courage est nécessaire aussi bien chez le client que chez les développeurs. Pour mener à bien un projet XP, le client doit avoir le courage de :  donner un ordre de priorité à ses exigences.  reconnaître que certains de ses besoins ne sont pas toujours très clairs. le développeur doit avoir le courage de :  modifier l'architecture même si le développement est déjà bien avancé.  jeter du code existant et d'accepter qu'il est parfois plus rapide et efficace de réécrire une portion de code à partir de zéro plutôt que de bricoler du code existant.
  • 14.  Les relations entre l’équipe de développement et le client et même entre eux doivent êtres baser sur le respect mutuel.
  • 16. Les principales pratique de l’XP sont :             Planning game Petites releases Utilisation de métaphores Conception simple Tests (unitaires et fonctionnels) Refactoring du code Programmation en binôme Appropriation collective du code Intégration continue Pas de surcharge de travail Client sur site Standards de code
  • 17. Planning game : Cette pratique a pour but de planifier uniquement les releases. La planification se fait sous forme de jeu auquel participent les développeurs et le client . Cette pratique est constituée de trois phases :  première phase dite d'exploration, le client exprime ses besoins en termes de fonctionnalités. Pour cela, il les écrit sous forme de "user stories" .  deuxième phase dite d'engagement, les user stories sont triées en fonction de la valeur qu'elles apportent au client et des risques encourus lors de leur développement. Ceci permet d'aboutir à les classer par ordre de priorité.  Troisième phase dite de direction permet de mettre à jour le planning de la prochaine release.
  • 18.
  • 20.
  • 21. Petites releases :  Pour une bonne gestion des risques, la sortie des releases doit intervenir le plus souvent possible.  D'une version à l'autre, l'évolution doit être la plus petite possible, tout en s'efforçant d'apporter le plus de valeur ajoutée et des fonctionnalités dans leur intégralité.
  • 22. Utilisation de métaphores :  XP recommande d'utiliser des métaphores pour décrire l'architecture du système. De telles images permettent à tout le monde d'avoir une vision globale du système et d'en comprendre les éléments principaux ainsi que leurs interactions.
  • 23. Conception simple : La simplicité est une des valeurs fondamentales d'XP. Il faut toujours développer la solution la plus simple possible et éviter de développer plus que ce dont on a besoin. les exigences sont :  satisfaire tous les tests.  ne jamais dupliquer une logique  utiliser le moins possible de classes et de méthodes. Ceux qui pratiquent XP résument cela sous la phrase YAGNI ("You ain't gonna need it", « vous n’en aurez pas besoin »).
  • 24. Tests (unitaires et fonctionnels) : Les tests unitaires sont écrits et effectués par les développeurs pour vérifier le bon fonctionnement et la non régression des méthodes ou des constructeurs.  Les tests fonctionnels sont conçus par le client et lui permettent de :   vérifier le fonctionnement global du système.  contrôler l'évolution du projet.  affiner l'expression de ses besoins.
  • 25. Pour une qualité de code encore meilleure, il est recommandé d'écrire les tests avant le code de l'application.
  • 26. Refactoring du code : Le but de cette pratique est de simplifier le code, tout en faisant en sorte que tous les tests soient satisfaits.  D'un point de vue purement fonctionnel, cette simplification n'est pas nécessaire.  le refactoring du code a pour but de :   assurer que l'ajout de fonctionnalités supplémentaires sera facilité.  tendre à produire un code mieux pensé, plus modulaire, sans duplications de code et donc plus facile à maintenir.
  • 27. Programmation en binôme : Toute l'écriture du code se fait à deux personnes sur une même machine, avec une seule souris et un seul clavier.  On distingue deux rôles :  ○ le pilote ("driver"), celui qui a le clavier, cherche la meilleure approche sur une portion de code bien précise. ○ le "partner" peut observer avec beaucoup plus de recul et ainsi suggérer d'autres solutions ou soulever des problèmes d'ordre plus général.
  • 28.
  • 29. Appropriation collective du code :  Toute l'équipe est sensée connaître la totalité du code.  Cela implique que tout le monde peut intervenir pour faire des ajouts ou des modifications sur une portion de code qu'il n'a pas écrit lui même si cela s'avère nécessaire.
  • 30.
  • 31.
  • 32.
  • 33. Intégration continue :  Après chaque fin de tâche le code nouvellement écrit doit être intégré à l'existant de manière à avoir à tout moment un existant fonctionnel qui passe avec succès tous les tests.
  • 34. Pas de surcharge de travail : L'objectif est de ne pas dépasser 40 heures de travail par semaine pour les développeurs.  Il ne s'agit pas de chercher à travailler peu, mais les spécialistes d' eXtreme Programming ont pris conscience du fait que la surcharge de travail, en plus d'être désagréable, est néfaste. 
  • 35. Client sur site :  le client est intégré à l’équipe pour définir précisément les besoins, arbitrer sur les priorités et visualiser « en direct » le résultat des développements.  Pour une meilleure communication, le client et les développeurs travaillent dans le même espace autant que possible.
  • 36.
  • 37. Standards de code :  Il est nécessaire de disposer de normes de nommage et de programmation pour que chacun puisse lire et comprendre facilement le code produit par les autres.
  • 46. Membre d’équipe et rôles : Développeur : Il est l'élément principal d'un projet XP. Son rôle est d’écrire des lignes de code, rajouter des fonctionnalités, simplifier et optimiser son code mais aussi d’avoir la qualité de communiquer et du courage.  Client : Le client est l'autre moitié du duo essentiel dans l'approche eXtreme Programming. Le développeur sait comment programmer et le client sait quoi programmer. 
  • 47. Testeur : Étant donné que les tests unitaires sont à la charge des développeurs, le testeur a pour rôle d'aider le client à choisir et à écrire ses tests fonctionnels.  Tracker : C'est un peu la conscience de l'équipe. Son rôle est d'aider l'équipe à mieux estimer le temps nécessaire à l'implémentation de chaque user story et de garder un œil sur le planning en relation avec l'avancement réel du projet. 
  • 48. Coach : Le coach a la responsabilité globale de tout le processus. Son rôle est de recadrer le projet, d'ajuster les procédures. Toute la difficulté de sa tâche réside dans le fait qu'il se doit d'intervenir de la manière la moins intrusive possible.  Consultant : Le rôle d'un consultant est d'apporter à l'équipe les connaissances nécessaires pour qu'ils résolvent eux mêmes leur problème et non de leur apporter une solution toute faite. 
  • 49.  Big Boss : Le Big Boss apporte à l'équipe courage et confiance.
  • 51.  Forces :  Extreme Programming apparaît comme la plus radicale des méthodes agiles.  XP se révèle particulièrement efficace dans le cadre de petits projets.  XP réalise des applications de qualité grâce à la rigueur imposée sur les tests, qui plus est collent au désirs du client puisque celui-ci est intégré au projet de A à Z.
  • 52.  Faiblesses :  XP n'est pas applicable dans tous les cas.  Le cas d'une équipe supérieure à une douzaine de personnes est un autre exemple où XP est difficilement adaptable car le nombre risque de ralentir, d'alourdir les procédures et de rendre la communication plus difficile et moins efficace.  En ce qui concerne les développeurs, la pratique de la programmation en binôme n'est pas forcément très bien ressentie par tous.
  • 54. Merci pour votre attention