0% ont trouvé ce document utile (0 vote)
126 vues38 pages

Chapitre 4 XP

Transféré par

hakimahamid49
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
126 vues38 pages

Chapitre 4 XP

Transféré par

hakimahamid49
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

L'eXtreme Programming (XP)

eXtreme Programming (XP)


 L'eXtreme Programming (XP) est une
méthode de développement de logiciel agile
qui se compose, comme plusieurs autres
méthodes agiles, d'une collection de valeurs,
de principes et de pratiques qui forment son
noyau.

2
eXtreme Programming (XP)
 Elle a été mise au point à la fin des années 90
par Kent Beek, Ron Jeffries et Ward
Cunningham (Beek, 1999).
 Elle est conçue pour des équipes de petite
taille de l'ordre d'une douzaine de personnes.

3
eXtreme Programming (XP)
 La méthode eXtreme Programming a été mise
en œuvre pour la première fois en 1996 sur le
projet Chrysler Comprehensive
Compensation System, qui consistait à mettre
en place un nouveau système de gestion de la
paie des dix mille salariés d'un fabricant
automobile.

4
eXtreme Programming (XP)

 Jeffries (2006) définit l'eXtreme Programming comme suit:


 « Extreme Programming is a discipline of software
development based on values of simplicity, communication,
feedback, and

 Beck décrit l'eXtreme Programming de la manière suivante:


 « XP is a lightweight methodology for small-to-medium-
sized teams developing software in the face of vague or
rapidly changing requirements. » (Beek, 1999)

5
eXtreme Programming (XP)
 XP- tel qu'il est défini sur le site
eXtremeProgramming.org - est une approche tout à
fait réfléchie et disciplinée du développement
logiciel. Âgée d'environ huit ans, elle a déjà fait ses
preuves un peu partout dans le monde dans de
nombreuses entreprises.

6
Cycle de développement XP

 L'Extreme Programming vise une réduction significative


de la durée du cycle de développement, c'est-à-dire du
temps qui s'écoule entre le moment où l'on décide
d'implémenter une fonctionnalité et celui où l'on met en
production une nouvelle version du logiciel qui intègre la
fonctionnalité en question.

7
Cycle de développement XP
 Dans un projet XP, ce temps correspond
exactement à la durée d'une itération, c'est-à-
dire typiquement deux semaines.

8
Cycle de développement XP
 L'eXtreme Programming repose sur des
cycles rapides de développement :

 Phase d'exploration
 Phase de planification
 Phase de mise en production
 Phase de maintenance

9
Cycle de développement XP
 Phase d'exploration
Phase d'exploration : permet à l'équipe
(le client et
développeurs) de déterminer ce qui doit
être implémenté au cours de l'itération. Il
établit ainsi une liste de fonctionnalités, qui
prennent en XP la forme de « scénarios
client ».

10
eXtreme Programming (XP)
 Phase d'exploration
Un scénario client décrit en quelques mots un besoin
particulier du client.

Par exemple, pour un logiciel de gestion de carnet d'adresses


le client pourrait écrire les scénarios suivants :

• "Je rentre un nom ou prénom, et le logiciel affiche la liste de


toutes les personnes qui possèdent ce nom ou ce prénom"

• "Je peux exporter mon carnet d'adresses au format HTML."

11
eXtreme Programming (XP)
 Phase de planification

Phase de planification : où l'équipe transforme


les scénarios en tâches à réaliser. A la fin de
cette phase, l'équipe dispose de la liste précise
des tâches à réaliser.

La planification est réalisée au cours d'une


réunion dédiée, qui réunit l'équipe et le client.

12
eXtreme Programming (XP)

 Phase de mise en production

Phase de mise en production : où chaque


développeur procède à la réalisation des
tâches avec un binôme.

13
eXtreme Programming (XP)
 Phase de maintenance

Enfin, on retrouve la phase de maintenance où


les tests fonctionnels sont exécutés et le
produit est livré.

Pour chaque scénario planifié, un ensemble de


tests de recette est écrit. Ces tests ont pour
but de vérifier chacune des fonctionnalités
demandées par le client.
14
Les Valeurs d’eXtreme Programming
 La méthode eXtreme Programming se base sur
quatre valeurs qui se complètent.

 Elle met l'accent sur l'élément humain et sur la


collaboration des membres de l'équipe.

15
Les Valeurs d’eXtreme Programming

 Première valeur : Communication.


La méthode XP privilégie la communication directe
plutôt que l'échange de courriels ou de documents
formels.

16
Les Valeurs d’eXtreme Programming

 Deuxième valeur : Simplicity.


 XP soutient l'idée de concevoir le système le plus simple
possible répondant

Ce processus est guidé par le principe suivant (YAGNI): «


You ain‘t, gonna need it » (n'ajouter une fonctionnalité au
programme que si elle est nécessaire) .

 Simple ≠ Simpliste

17
Les Valeurs d’eXtreme Programming

 Troisième valeur : Feed-back .

 Le feed-back permet aussi de repérer et


intégrer les changements.
 Connaître l’état du projet

18
Les Valeurs d’eXtreme Programming

 Quatrième valeur : Courage.


Le courage réside dans le fait que l'équipe de
développement accepte de changer de vision du produit
et de remettre en cause son travail pour pouvoir faire un
bon code.

 Accepter de remanier une portion de code devenue


complexe

19
Les pratiques d’XP

 XP définit des pratiques que nous classons ici en


trois grandes catégories : celles relatives à la
programmation, celles relatives au fonctionnement
interne de l’équipe et celles qui sont liées à la
planification et aux relations avec le client.

20
Les pratiques d’XP - programmation

Conception simple (simple design) : les développeurs


implémentent toujours la solution la plus simple qui puisse
fonctionner.

Refactoring : les développeurs n’hésitent pas à revenir sur le


code écrit pour le rendre plus «propre».

Développement piloté par les tests : les développeurs


implémentent des tests automatisé. Ces tests sont exécutés à
chaque intégration et après chaque refactoring du code.

21
Les pratiques d’XP - l’équipe
Programmation en binôme (pair programming) :
les développeurs travaillent systématiquement
à deux sur la même machine. Les binômes
changent au cours du projet pour permettre le
partage des connaissances.

22
Les pratiques d’XP - l’équipe
Programmation en binôme (pair programming) :
Dans leur article «The cost and benefits of pair programming»,
Alistair Cockburn et Laurie Williams: En moyenne, les binômes
complétaient leurs tâches dans un délai d’environ 40% de temps plus
court que les développeurs seuls.
Ce chiffre est cohérent avec les retours d’expérience des équipes XP
en milieu industriel, qui constatent en général que le gain de
performance des binômes compense en grande partie le surcoût lié à
la présence du copilote sur la tâche

23
Les pratiques d’XP - l’équipe
Responsabilité collective du code : chaque
développeur doit pouvoir modifier des lignes
de code si nécessaire pour ajouter des
fonctionnalités et corriger des bogues.

24
Les pratiques d’XP - l’équipe

Règles de codage (coding standards) : les


développeurs se plient à des règles de codage
définies par l’équipe elle-même, de manière à
garantir l’homogénéité de leur code avec le
reste de l’application, et ainsi à faciliter
l’intervention d’autres développeurs.

25
Les pratiques d’XP - l’équipe
Métaphore (metaphor) : les développeurs n’hésitent pas à recourir
aux métaphores pour décrire la structure interne du logiciel ou
ses enjeux fonctionnels, de façon à faciliter la communication.

 À chaque occasion, lorsqu’on parle du programme ou de sa


conception, les membres d’une équipe XP s’efforcent
consciemment de trouver des images plutôt que de parler en
termes technique.

 Exemple : « Cette partie du système fonctionne comme une


autoroute »

26
Les pratiques d’XP - l’équipe

Intégration continue (continuous integration) :


les développeurs synchronisent leurs
développements aussi souvent que possible
(au moins une fois par jour). Cela réduit la
fréquence et la gravité des problèmes
d’intégration.

27
Les pratiques d’XP - Gestion de projet
Livraisons fréquentes (frequent releases) : l’équipe
livre des versions du logiciel à un rythme régulier,
aussi élevé que possible. Cela permet à l’équipe
comme au client de s’assurer que le produit
correspond bien aux attentes de ce dernier

Planification itérative (planning game) : la planification


du projet est réalisée conjointement par le client et
l’équipe de développement, au cours de séances
dédiées, organisées régulièrement tout au long du
projet.

28
Les pratiques d’XP - Gestion de projet
Client sur site (on-site customer, whole team) : le client
est littéralement intégré à l’équipe de développement
pour arbitrer les priorités, et définir précisément ses
besoins, notamment en répondant en direct aux
questions des programmeurs et en bénéficiant du
feedback immédiat d’une application aux livraisons
fréquentes

Rythme durable (sustainable pace) : l’équipe adopte


des horaires qui lui permettent de conserver tout au
long du projet l’énergie nécessaire pour produire un
travail de qualité et mettre en œuvre efficacement les
autres pratiques.
29
Équipe et rôles XP
 Avec les pratiques, les rôles sont une des
pierres angulaires de la méthode et font
véritablement partie de la culture XP.

30
Équipe et rôles XP
Programmeur
 Pour avoir un logiciel, il faut du code
 les programmeurs sont les créateurs et artisans du code.

du code : l’écrire, le connaître, le modifier, gérer son existence,


sa sauvegarde et ses versions ..
 Encore faut-il que le code fasse vraiment ce qu’on veut. Pour
cela, il faut le tester , et c’est aussi le programmeur qui s’en
charge

31
Équipe et rôles XP
Client
 Le client a pour responsabilité de définir ce que doit
faire ce logiciel, et de quelle façon, et de
communiquer ces informations aux programmeurs.

 La communication entre le client et les


programmeurs est donc capitale, pour que les
programmeurs comprennent les besoins du client,

32
Équipe et rôles XP
Testeur

 Le testeur est le bras droit du client.


 Techniquement, le testeur est souvent un
programmeur et bricoleur, capable de combiner
différents outils pour arriver à ses fins.

 Il faut qu’il sache déceler et mettre au jour les erreurs


du logiciel sans briser l’esprit d’équipe.

33
Équipe et rôles XP
Tracker
 Au début de chaque itération, une séance de planification
( planning game ), permet de définir un plan d’itération.
 Ce plan comporte toutes les tâches que les programmeurs
devront effectuer.
 En face de chaque tâche, un nom et une estimation de la
charge sont mentionnés.
 Le rôle du tracker consiste à faire le suivi de ces tâches en
cours d’incrément.

34
Équipe et rôles XP
Manager
 Le manager est le supérieur hiérarchique des programmeurs.

 C’est le manager qui s’occupe matériellement des


programmeurs :

Il recruit des programmeurs supplémentaires ou un testeur


lorsque l’équipe en exprime le besoin.

 Il demande à l’équipe XP de faire ses preuves

 le rôle de manager peut être joué par le chef du projet global

35
Équipe et rôles XP
Coach
 il revient au coach de réunir tous les rôles
précédents et de faire en sorte que cela marche, que
la magie XP opère.

 Le coach est le véritable garant du processus lui-


même. Il s’attache à vérifier que chacun joue son
rôle, que les pratiques XP sont respectées,

36
 Un projet XP coûte-t-il
plus cherqu’un projet
traditionnel ?

37
 Le coût sur lequel se concentrent pour l’essentiel les
débats est le coût de la main-d’œuvre humaine. Les
opposants à XP mettent en exergue plusieurs points
qui contribuent selon eux à l’alourdissement des
charges : la programmation en binôme ; la présence
du client ...

38

Vous aimerez peut-être aussi