Chapitre - 3 - Extreme - Programming (XP)

Université Hassan 1er
Faculté des Sciences et Techniques

-Settat-
Département : Mathématiques & Informatique

Filière : Licence Génie Informatique
Module : Génie logiciel et UML
Chapitre 3 : Extreme Programming (XP)
Prof. Said El Kafhali
Département Mathématiques & Informatique

Faculté des Sciences et Techniques, Settat
Université Hassan 1er
Année Universitaire : 2018/2019

Année Universitaire : 2018/2019 1
Prof. Said El Kafhali Chapitre 3 : Extreme Programming (XP) / 53
Plan
1 Introduction
Définitions et motivations
Les quatres valeurs d’XP
2 Pratiques XP
Les pratiques de gestion de projet
Les pratiques de programmation
Les pratiques de collaboration
3 Equipe et rôles XP
Technique : programmeur
Domaine : client, testeur
Organisationnel : tracker, manager, coach
Répartitions des rôles
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Introduction Définitions et motivations
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Questions
1 Est-il possible de produire des logiciels de qualité avec des équipes

réduites ?
2 Quelles activités pouvons-nous abandonner sans diminuer la qualité ?
3 Comment collaborer avec les usagers pour mieux répondre à leurs
attentes et être aussi réactifs que possible ?

eXtremme Programming (XP)

L’eXtremme Programming (XP) est un ensemble de pratiques qui
couvrent une grande partie des activités de la réalisation d’un logiciel :
planification,
organisation de l’équipe de développement,
échanges avec le client,
et programmation.
Ces pratiques d’XP n’ont rien de révolutionnaire : il s’agit simplement
de pratiques de bon sens mises en oeuvre par des développeurs ou des
chefs de projet expérimentés.
La nouveauté introduite par XP consiste à pousser ces pratiques à
l’extrême (d’où le nom de la méthode) et à les organiser en un tout
cohérent.
En résumé, l’eXtreme Programming (XP) est une méthode de
développement légère conçue pour de petites équipes confrontées à
des environnements mal connus ou fortement changeants.
Les phases d’un cycle de développement de XP
Il y a trois moments (ou phases) dans un cycle de développement de

XP.
Chaque cycle d’une durée ne dépassant pas deux semaines produit une
release fonctionnelle (une livraison) du produit :
L’exploration : définition des besoins du moment.
L’engagement : choix des besoins qui vont être implémentés en
fonction de la valeur que leur accorde le client.
Le pilotage : implémentation des besoins et feedback immédiat des
conditions du développement, ainsi que l’impact du produit afin
d’orienter la phase d’exploration du cycle suivant.

Les variables de XP
XP considère que la satisfaction de quatre variables va contribuer au

développement efficace d’un produit fonctionnel :
Le coût : le développement se fait par petits modules.
Il est donc aisé de suivre de près les dépenses et ainsi d’agir en
conséquence pour ne pas dépasser les budgets.
Le temps : de la même manière que pour le coût, le développement par
modules permet de suivre l’évolution du développement en fonction du
temps passé.
La qualité : pour XP, la qualité doit toujours être maximum.
C’est la seule variable qui ne peut pas varier.
L’étendue : le nombre de fonctionnalité va dépendre du temps et du
budget à disposition.
C’est le client qui va décider de ce qui sera développé ou pas afin de
garder la plus grande qualité possible, en restant dans les délais et les
budgets.

Le cycle standard XP
1 Le client écrit ses besoins sous forme de scénarios.

2 Les développeurs évaluent le coût de chaque scénario, en collaboration
avec le client.
3 Le client choisit les scénarios à intégrer à la prochaine livraison.
4 Chaque développeur prend la responsabilité d’une tâche pour la
réalisation d’un scénario.
5 Le développeur choisit un partenaire.
6 Le binôme écrit les tests unitaires correspondant au scénario à
implémenter.
7 Le binôme prépare l’implémentation en réorganisant le code existant,
puis il procède à l’implémentation proprement dite.
8 Le binôme intègre ses développements à la version d’intégration.

Introduction Les quatres valeurs d’XP
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Comment mieux travailler avec le client pour nous focaliser sur ses
besoins les plus prioritaires et être aussi réactif que possible ?
Afin de satisfaire les quatre variables, Extreme Programming met en
évidence quatre valeurs essentielle au travers de la méthode :
La communication au sein de l’équipe, avec le client,
La simplicité du code, livrables ne contenant que les exigences du
client,
Le feedback : itérations rapides, permet la réactivité,
Le courage : il faut parfois faire des choix difficiles, cela est facilité par
les trois premières valeurs.
Courage pour se lancer dans un projet sans avoir tout spécifié.
Courage pour se borner à réaliser des choses simples.
Courage pour appliquer les principes de communication et de feedback.
Courage de mettre en place des méthodes nouvelles.

La communication pour une meilleure visibilité
XP favorise la communication directe, plutôt que le cloisonnement des

activités et les échanges de documents formels.
Communication orale : pour sa simplicité, pour des interactions rapides
entre les interlocuteurs, et plus personnelle.
Communication écrite : toutes les informations ayant trait à
l’implémentation et à la conception se retrouvent dans le code.
La clarté du code fait l’objet de nombreux efforts.
Les tests servent également à consigner formellement les besoins des
clients.
Projet de développement = Effort collectif de création dont le succès
dépend :
De la vision commune de ce qui doit être produit.
De la capacité à synchroniser les actions individuelles.
Ces deux conditions dépendent de la qualité de la communication.

La simplicité comme garantie de productivité
La chose la plus simple qui puisse marcher (The simplest thing that
could possibly work).
L’effort de simplicité s’applique également au client.
Il doit définir ses besoins avec une grande précision pour éviter
d’implémenter des choses inutiles.
La simplicité est également recherchée dans le choix des outils et dans
la méthode de travail elle-même.
Le code devrait être évident et contenir un minimum de commentaires
vraiment utiles!
Les commentaires sont souvent "évidents" et polluent le code.
Les commentaires peuvent être dangereux - Les développeurs modifient
les codes et laissent les commentaires devenus obsolètes.

Les commentaires
Les commentaires sont un mal nécessaire : ils pallient notre incapacité

à exprimer nos intentions par le code.
Il est courant de croire que la lisibilité d’un programme augmente avec
le nombre de lignes de commentaires. Ceci est faux en général.
La seule source d’information absolument juste est le code.
La cohérence entre commentaires et code est à l’entière responsabilité
du programmeur.
Ne pas compenser le mauvais code par des commentaires : il est
préférable de le réécrire.
S’expliquer directement dans le code plutôt que dans un commentaire :

Le feedback comme outil de réduction de risque
Les pratiques XP sont conçues pour donner un maximum de feedback

sur le déroulement du projet afin de corriger la trajectoire au plus tôt.
Permets à tout moment de savoir dans quel état se trouve le projet.
Et donc de pouvoir rectifier le tir au fur et à mesure.
La planification itérative permet de faire converger le produit vers une
solution mieux adaptée aux besoins.
Divers mécanismes de feeback interviennent dans l’activité de
programmation :
Tests unitaires.
Feeback du binôme.
Intégré à la conception.
Le feeback est un facteur de qualité, car les intervenants améliorent
sans cesse leur travail en profitant de l’expérience qu’ils accumulent.

Les activités de XP
Les activités de XP sont les étapes minimales garantissant la réussite

du développement du projet :
Il faut coder et intégrer, car à la fin de chaque itération, il doit y avoir
une nouvelle release fonctionnelle pour le client.
Il faut tester pour rendre la release réellement fonctionnelle.
Il faut écouter les besoins du client, ainsi que les changements qu’il
veut apporter.
Il faut modéliser (faire du design) afin de réaliser l’architecture la plus
simple possible.

Pratiques XP Les pratiques de gestion de projet
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Livraisons fréquentes et planification itérative
Livraisons fréquentes (frequent releases)

L’équipe livre des versions du logiciel à un rythme régulier, aussi élevé
que possible, la fréquence précise étant fixée par le client.
Cela permet à l’équipe comme au client de s’assurer que le produit
correspond bien aux attentes de ce dernier et que le projet est sur la
bonne voie.
Planification itérative (planning game)

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

Client sur site et rythme durable
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 oeuvre efficacement les autres pratiques.

Pratiques XP Les pratiques de programmation
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Conception simple et remaniement
Conception simple (simple design)

Les développeurs implémentent toujours la solution la plus simple qui
puisse fonctionner.
Conserver une conception simple est un travail difficile et demande
beaucoup de rigueur.
Remaniement (refactoring)
Les développeurs n’hésitent pas à revenir sur le code écrit pour le
rendre plus «propre»,
le débarrasser d’éventuelles parties inutilisées, et
le préparer à l’ajout de la fonctionnalité suivante.
Cette pratique propose une démarche de conception continue qui fait
émerger la structure de l’application au fur et à mesure du
développement.
Tests unitaires et tests de recette

Tests unitaires (test-first programming, unit tests, developer tests)
Les développeurs écrivent des tests automatiques pour le code qu’ils
produisent, et ce au moment même d’écrire le code en question. Cela
leur permet
d’une part de mieux cerner le problème avant d’écrire le code, et
d’autre part de constituer progressivement une batterie de tests qui les
autorise ensuite à apporter rapidement des changements dans
l’application, tout en conservant une certaine sérénité.
Tests de recette (acceptance tests, customer tests)

Le client précise très explicitement ses besoins et les objectifs des
programmeurs en participant à la rédaction de tests de recette.
Comme les tests unitaires, les tests de recette doivent être
automatiques afin de pouvoir vérifier tous les jours la non régression
du produit.
Pratiques XP Les pratiques de collaboration
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Programmation en binôme et responsabilité du code
Programmation en binôme (pair programming)

Lorsqu’ils écrivent le code de l’application, les développeurs travaillent
systématiquement à deux sur la même machine (il s’agit là d’une forme
«extrême» de relecture de code), dans laquelle les deux développeurs
collaborent activement pour résoudre les problèmes qu’ils rencontrent.
Les binômes changent fréquemment, ainsi chacun est amené à
travailler tôt ou tard avec tous les autres membres de l’équipe.
Responsabilité collective du code (collective code ownership)

Tous les développeurs de l’équipe peuvent être amenés à travailler sur
toutes les parties de l’application.
De plus, ils ont le devoir d’améliorer le code sur lequel ils
interviennent, même s’ils n’en sont pas les auteurs initiaux.
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 et
à assurer une certaine homogénéité de style dans l’ensemble de la
conception.
Nommer de manière cohérente les classes, les méthodes, les données,
les fonctions ...
Cela facilite la compréhension et la réutilisabilité du code.
Aucune connaissance technique spécifique ne doit être nécessaire à la
compréhension du code.

Règles de codage et intégration continue
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.
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, et
permet de disposer à tout moment d’une version du logiciel qui intègre
tous les développements en cours.

Equipe et rôles XP Technique : programmeur
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Programmeur
Va écrire, connaître, modifier, gérer l’existence, la sauvegarde, les
versions, la transformation en exécutable du code.
Va tester le code pour en obtenir un feedback.
Va faire preuve de courage, toute fonctionnalité qui n’a pas été
suffisamment testée doit être considérée comme n’existant pas.
Va poser des questions au client et écouter ses réponses.
C’est le client qui détient la connaissance de ce que doit faire le
système.
Va aider le client à définir ses besoins.
XP fournit un cadre méthodologique pour cela.
Est le seul à avoir la reponsabilité des délais (ni le client, ni le
manager, ni le coach ne peuvent influencer le programmeur dans ses
estimations).
Il est codeur, testeur, concepteur, analyste. Il a la volonté
d’apprendre. A donc un rôle varié.
Pratiques XP du programmeur
Si vous pensez être ou souhaitez devenir un programmeur XP, voici les

pratiques XP auxquelles vous pouvez donc vous reporter :
Programmation en binôme.
Tests unitaires.
Conception simple.
Remaniement (nettoyage de code).
Responsabilité collective du code.
Règles de codage.
Intégration continue.
Rythme durable.

Charte des droits du programmeur
Le programmeur retrouve une place centrale dans un projet XP et sa

situation est même protégée par la charte suivante :
Le programmeur a le droit :
de savoir ce qui est demandé, avec des priorités clairement déclarées.
de fournir un travail de qualité en toute occasion.
de demander et recevoir de l’aide de la part de ses pairs et du client.
d’émettre et de réviser ses propres estimations de coûts.
d’accepter des responsabilités, mais qui ne peuvent lui être imposées.
de travailler à un rythme de travail durable.

Equipe et rôles XP Domaine : client, testeur
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Client
Qui est-il ?
Pas nécessairement le client contractuel.
Assistant à maîtrise d’ouvrage.
Représentant des utilisateurs.
A défaut quelqu’un pour agir comme client «artificiel».
Chef de projet.
Ingénieur chargé des spécifications.
Client sur site et feedback

Intégré à l’équipe de développement.
Explique se qu’il souhaite aux développeurs.
Vision plus rapide du résultat.
Prise de conscience en cas d’erreur.

Client
Scénarios clients
Description informelle d’une fonctionnalité ou d’une interaction avec
l’utilisateur. Le plus simple possible.
Démarrage du projet
Des scénarios initiaux sont dégagés et présentés. Ils sont classés par
priorité et répartis en itérations.
A chaque itération...
Grâce au feedback introduit (logiciel fonctionnel) :
Il peut revoir le contenu des itérations.
Modifier ses scénarios.
Il est garant des fonctionnalités du logiciel.

Client
Tests de recette
Données concrètes levant les ambiguïtés.
Preuve que le système fait ce qu’il demandait.
A chaque fin d’itération tous les tests de recette doivent passer avec
succès.
Pratiques XP client
1 Planification itérative.
2 Rédaction des scénarios clients.
3 Séances de planification.
4 Tests de recettes.
5 Intégration continue.
6 Rythme durable.
Charte des droits du client
Le client a le droit :
a un plan d’ensemble, montrant ce qui peut être accompli, pour quand,
à quel coût.
d’obtenir le plus de valeur possible de chaque semaine de
programmation.
de voir des progrès sur une application qui marche, comme doivent le
prouver les tests répétables qu’il spécifie.
de changer d’avis, de substituer des fonctionnalités et de changer ses
priorités sans en payer un prix exorbitant.
d’être informé des modifications portées au calendrier de réalisation,
assez tôt pour avoir la possibilité de réduire le périmètre fonctionnel et
retomber ainsi sur la date de livraison initiale.
d’annuler le projet à tout moment et de disposer d’une application utile
et utilisable en contrepartie de son investissement.

Testeur
Définit et automatise les tests de recette.

Conseille le client sur la testabilité d’une fonctionnalité.
Garant du sentiment de réussite sur le projet.
Écriture des tests de recette automatiques pour valider les scénarios
clients;
Peut influer sur les choix du clients en fonction de la testatibilité des
scénarios.
Pratiques XP Testeur
1 Suivi des tests (planification itérative).
2 Tests de recette.
3 Intégration continue.
4 Rythme durable.
Equipe et rôles XP Organisationnel : tracker, manager, coach
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Tracker
Suivre le planning pour chaque itération.

Comprendre les estimations produites par les développeurs concernant
leur charges.
Interagir avec les développeurs pour le respect du planning de
l’itération courante.
Détection des éventuels retards et rectifications si besoin.
Qui est-il ?
Pas un supérieur hiérarchique.
Quelqu’un a qui on peut se confier.
De préférence pas un programmeur, mais quelqu’un d’extérieur.
Pratiques XP tracker
1 Planfication itérative.
Manager
Position dans l’organisation

Supérieur hiérarchique des programmeurs.
Ne fait pas partie intégrante de l’équipe.
Chef du service auquel appartient l’équipe.
Chef de projet global (dans le cadre d’un sous-projet).
Responsabilités
Il s’occupe matériellement de l’équipe.
Il demande des comptes (sur les engagements pris).
Interface avec l’extérieur (dans le cadre d’un sous-projet).
Pratiques XP manager
Scénarios client, Planification itérative, Rythme durable.
Coach
Responsabilités
Garant du processus.
Organise et anime les séances de planification.
Aide le client à rédiger ses premiers scénarios.
Doit avoir le courage de dire les choses telles qu’elles sont.
Il réunit tout les autres rôles.
Vérifie que chaque rôle est respecté.
Objectifs du coach : que l’équipe fonctionne bien, sans lui...
Ses qualités : Expert de la méthode XP, Expert technique,
Programmeur chevronné, Architecte, Pédagogue et sensible.
Pratiques XP coach
Toutes !
Equipe et rôles XP Répartitions des rôles
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Comment répartir les rôles
Plusieurs rôles pour une personne

Attention aux combinaisons possibles.
Toutefois, pas de règle absolue.
S’assurer qu’une cumulation ne pousse pas à sacrifier une composante
importante d’un rôle.
Plusieurs personnes pour un rôle

Programmeur, le plus grand nombre.
Tracker, une seule personne... à un moment donné.
Coach, une personne unique.
Manager, une personne unique.
Client+Testeur, d’une personne à une équipe.

Compatibilité des rôles

Responsabilités respectives des rôles XP

Cycle de vie Cycle de vie XP
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
Résumé de cycle de vie XP

Exploration et planning
Exploration
Les développeurs se penchent sur des questions techniques.
Explorer les différentes possibilités d’architecture pour le système.
Etudier par exemple les limites au niveau des performances présentées
par chacune des solutions possibles.
Le client s’habitue à exprimer ses besoins sous forme de user strories
(proches de diagrammes de cas illustrés par des diagrammes de
séquences). Les développeurs estiment les temps de développement.
Planning
Planning de la première release : uniquement les fonctionnalités
essentielles et la première release à enrichir par la suite.
Durée du planning : 1 ou 2 jours.
Première version (release) au bout de 2 à 6 mois.
Production de la première release
Itérations jusqu’à la première release

Itérations de une à quatre semaines.
Chaque itération produit un sous ensemble des fonctionnalités
principales.
Le produit de chaque itération subit des tests fonctionnels.
Itérations courtes pour identifier très tôt des déviation par rapport au
planning.
Brèves réunions quotidiennes réunissant toute l’équipe, pour mettre
chacun au courant de l’avancement du projet.

Mise en production
La mise en production produit un logiciel.

Offrant toutes les fonctionnalités indispensables.
Parfaitement fonctionnel.
Mis à disposition des utilisateurs.
Itérations très courtes.
Tests constants en parallèle du développement.
Les développeurs procèdent à des réglages affinés pour améliorer les
performances du logiciel.

Maintenance et mort
Maintenance
Continuer à faire fonctionner le système.
Adjonction de nouvelles fonctionnalités secondaires.
Pour les fonctionnalités secondaires, on recommence par une rapide
exploration.
L’ajout de fonctionnalités secondaires donne lieu à de nouvelles releases.
Mort
Quand le client ne parvient plus à spécifier de nouveaux besoins, le
projet est dit mort.
Soit que tous les besoins possibles sont remplis.
Soit que le système ne supporte plus de nouvelles modifications en
restsant rentable.

Cycle de vie XP vs RUP
Plan
1 Introduction
2 Pratiques XP
4 Cycle de vie
Cycle de vie XP
XP vs RUP
5 Références
A chacun son XP
XP n’est pas une approche dogmatique, elle se fonde sur des valeurs
et quelques principes dont la mise en oeuvre très libre appartient à
chaque équipe ;
L’industrialisation du Genie Logiciel, le mouvement pour la qualité, le
diktat du management nous avait peu à peu fait oublier qu’il n’y a pas
de logiciel sans développeurs ;
XP met l’accent sur l’importance des facteurs humains et redonne aux
développeurs la place qu’ils avaient peu à peu perdue.

Inconvénients de XP et comparaison avec RUP
Inconvénients de XP
Focalisation sur l’aspect individuel du développement, au détriment
d’une vue globale et des pratiques de management ou de formalisation.
Manquer de contrôle et de structuration, risques de dériveLe modèle
d’implémentation qui définit les composants.
Inconvénients de RUP
Fait tout, mais lourd, usine à gaz.
Parfois difficile à mettre en oeuvre de façon spécifique.
XP vs RUP
XP pour les petits projets en équipe de 12 max.
RUP pour les gros projets qui génèrent beaucoup de documentation.
Références
Références
1 Méthode AGILE Les meilleures pratiques Compréhension et mise en

oeuvre, Jean-Pierre Vickoff (Auteur), AgileAlliance.
2 P.-A. Sunier, Méthodologies de développement de logiciels de gestion,
Haute Ecole Arc, mai 2005.
3 eXtreme Programming Scrum Practices, Embrace Change, Naresh
Jain.
4 Exigences et spécifications du logiciel - c RR -LOG3410 -XPproc,
Université de Montreal, 2011.
5 Bonnes Pratiques de développement ENVOL_2010: 27 Septembre,
Véronique Baudin Violaine Louvet.


Chapitre - 3 - Extreme - Programming (XP)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre - 3 - Extreme - Programming (XP)

Transféré par

Droits d'auteur :

Formats disponibles

Université Hassan 1er

Faculté des Sciences et Techniques

Département : Mathématiques & Informatique

Chapitre 3 : Extreme Programming (XP)

Prof. Said El Kafhali

Département Mathématiques & Informatique

Année Universitaire : 2018/2019

1 Est-il possible de produire des logiciels de qualité avec des équipes

Année Universitaire : 2018/2019 4

eXtremme Programming (XP)

Les phases d’un cycle de développement de XP

Il y a trois moments (ou phases) dans un cycle de développement de

Année Universitaire : 2018/2019 6

XP considère que la satisfaction de quatre variables va contribuer au

Année Universitaire : 2018/2019 7

1 Le client écrit ses besoins sous forme de scénarios.

Année Universitaire : 2018/2019 8

Les quatres valeurs d’XP

Année Universitaire : 2018/2019 10

La communication pour une meilleure visibilité

XP favorise la communication directe, plutôt que le cloisonnement des

Année Universitaire : 2018/2019 11

La simplicité comme garantie de productivité

Année Universitaire : 2018/2019 12

Les commentaires sont un mal nécessaire : ils pallient notre incapacité

Année Universitaire : 2018/2019 13

Le feedback comme outil de réduction de risque

Les pratiques XP sont conçues pour donner un maximum de feedback

Année Universitaire : 2018/2019 14

Les activités de XP sont les étapes minimales garantissant la réussite

Année Universitaire : 2018/2019 15

Livraisons fréquentes et planification itérative

Livraisons fréquentes (frequent releases)

Planification itérative (planning game)

Année Universitaire : 2018/2019 17

Client sur site et rythme durable

Client sur site (on-site customer, whole team)

Rythme durable (sustainable pace)

Année Universitaire : 2018/2019 18

Conception simple et remaniement

Conception simple (simple design)

Tests unitaires et tests de recette

Tests de recette (acceptance tests, customer tests)

Programmation en binôme et responsabilité du code

Programmation en binôme (pair programming)

Responsabilité collective du code (collective code ownership)

Les développeurs n’hésitent pas à recourir aux métaphores pour décrire

Année Universitaire : 2018/2019 24

Règles de codage et intégration continue

Règles de codage (coding standards)

Intégration continue (continuous integration)

Année Universitaire : 2018/2019 25

Si vous pensez être ou souhaitez devenir un programmeur XP, voici les

Année Universitaire : 2018/2019 28

Charte des droits du programmeur

Le programmeur retrouve une place centrale dans un projet XP et sa

Année Universitaire : 2018/2019 29

Client sur site et feedback

Année Universitaire : 2018/2019 31

Année Universitaire : 2018/2019 32

Charte des droits du client

Année Universitaire : 2018/2019 34

Définit et automatise les tests de recette.