XP

Introduction quipe et rles XP Pratiques XP Processus XP Autres
considrations
Introduction leXtreme
Programming et au
dveloppement agile
Gauthier Picard
SMA/G2I/ENS Mines Saint-Etienne
gauthier.picard@emse.fr
Octobre 2009
Adapt de XP ou les bienfaits dun dveloppement agile

par Kvin Ottens, KDE Core Developer
Introduction leXtreme Programming et au 1/

dveloppement agile 76
considrations
Sommaire
1 Introduction
2 quipe et rles XP
3 Pratiques XP
4 Processus XP
5 Autres considrations

considrations
Sommaire
1 Introduction
2 quipe et rles XP
3 Pratiques XP
4 Processus XP

considrations
La prhistoire : Influences
Culture SmallTalk
198x : Kent Beck et Ward Cunningham travaillent chez Tektronix
Elements clef de cette culture :
Dveloppement en binme Intgration continue
Refactoring Dveloppement itratif
Changements rapides Tests permanents
Interaction permanente avec le
client
Episodes
1986-1996 : Kent Beck et Ward Cunningham dveloppent un ensemble de
bonnes pratiques
Support dans le language Episodes de Ward Cunningham

considrations
La prhistoire : Influences (cont.)
Refactoring
1989-1992 : William F. Opdyke, Refactoring Object-Oriented Frameworks.
PhD Thesis
1995-1996 : Kent Beck, Smalltalk Best Practices Patterns
1999 : Martin Fowler, Refactoring : Improving the Design of Existing Code
Test-Driven Development
Driv des pratiques de refactoring
Premier article publi par Kent Beck propos de SmallUnit
1997 : Cration de JUnit par Kent Beck et Erich Gamma

considrations
La prhistoire : Influences (cont.)
Design Patterns
Ide reprise de larchitecture, plus particulirement de Christopher Alexander
Kent Beck et Ward Cunningham ont appliqu le concept de patrons au
logiciel depuis 1987
1995 : Publication de Design Patterns, par
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides

considrations
Les dbuts
Projet C3 (Chrysler, 1996) : Naissance du processus

Intervention de Kent Beck pour amliorer les performances
Identification de maux plus profonds
La direction lui confie lquipe pour rcrire le logiciel
Mise au point des pratiques XP avec Ron Jeffries
Correspond la somme des influences vues prcdemment
Octobre 1998 : Article dans Distributed Computing magazine sur C3 et XP
De lutilisation du Wiki Wiki Web

Ward Cunningham a mis au point ce site collaboratif
Utilis par la communaut XP pour affiner et discuter le processus

considrations
Les dbuts (cont.)
Evolution et gain de popularit

Septembre 1999 : Extreme Programming Explained par Kent Beck
Processus presque identique celui appliqu sur C3
Intgration du processus Scrum pour la gestion de projet
Dcembre 1999 : 1e XpImmersion ObjectMentor
31 Dcembre 1999 : Cration du groupe de discussion XP sur Yahoo !
Juin 2000 : 1e confrence internationale sur XP
Septembre 2000 : Extreme Programming Installed crit entre autre par Ron
Jeffries
Juillet 2001 : Premire confrence XpUniverse

considrations
Le Manifeste Agile
Runion organise par Kent Beck en Fvrier 2001

17 personnalits, dont les crateurs de Crystal, Scrum, Adaptive Software
Development, etc.
http://www.agilemanifesto.org/
Nous cherchons de meilleures manires pour dvelopper des logiciels en aidant les
autres et en dveloppant nous mmes. travers ce travail nous en sommes venus
valoriser :
Personnes et interaction plutt que processus et outils
Logiciel fonctionnel plutt que documentation complte
Collaboration avec le client plutt que ngociation de
contrat Ragir au changement plutt que suivre un plan
En fait, bien que les lments de droite soient importants, nous pensons que les
lments de gauche le sont encore plus.

considrations
Mythe des phases
Processus squentiels
La plupart drivs du cycle en V
Variantes... intgrant parfois des sous-cycles itratifs
1
Cahier des charges
2
Document de spcifications
3
Document de conception gnrale
4
Document de conception dtaille
5
Plans de tests
6
...
7
Et lapplication ?
Introduction leXtreme Programming et au 10 /

considrations
Mythe des phases
Processus squentiels
La plupart drivs du cycle en V
Variantes... intgrant parfois des sous-cycles itratifs
1994 : Rapport CHAOS (tude sur 8000 projets)

16% finaliss dans les temps et le budget prvus
32% interrompus en cours de route
Diagnostic courant des drapages :

Spcifications ambitieuses et Conception pousse
Puis, enlisement de la construction
Remise en cause de choix initiaux
Mise mal de la conception propose
Effet Tunnel
Le processus correspond il aux besoins du projet ?
considrations
Utopie des spcifications immuables
Faits
Sources principales de problmes dans les spcifications :
Erreurs
Oublis
Changements
Dfinir un logiciel a priori est un exercice difficile, sauf dans le cas :

Dapplications extrmement simples
De rares contextes connus et maitriss
Le client a du mal imaginer ce que sera lapplication
Consquences
Remises en question des spcifications
Risques pour la conception lis au changement

considrations
Valeurs XP
Communication
Dveloppement = Effort collectif de cration
Avoir une vision commune et pouvoir se synchroniser
Qualit de la communication
Communication directe et le contact humain
Faiblesse pour la traabilit et la structuration
Augmentation de la ractivit
Communication crite prsente, en gnral par du code
Simplicit
La chose la plus simple qui puisse marcher
Simple Simpliste
Eviter la complexit inutile dans le code
Toute duplication doit tre limine
considrations
Valeurs XP (cont.)
Retour dinformation (Feedback)

Boucles de feedback pour rduire les risques
Connatre ltat du projet
Rectifier le tir si ncessaire
Facteur de qualit
Acquisition dexprience
Amlioration constante du travail
Courage
Se lancer dans un projet non entirement spcifi
Accepter de remanier une portion de code devenue complexe
Appliquer les valeurs de feedback et de communication
Accepter de montrer ses propres limites
Maintenir une transparence complte

considrations
Principes XP
Le client (matrise douvrage) pilote lui-mme le projet, et ce

de trs prs grce des cycles itratifs extrmement courts (1 ou 2
semaines)
Lquipe livre trs tt dans le projet une premire version
du logiciel, et les livraisons de nouvelles versions senchanent ensuite un
rythme soutenu pour obtenir un feedback maximal sur lavancement des
dveloppements
Lquipe sorganise elle-mme pour atteindre ses objectifs,
en favorisant une collaboration maximale entre ses membres
Lquipe met en place des tests automatiques pour toutes
les fonctionnalits quelle dveloppe, ce qui garantit au produit un
niveau de robustesse trs lev
Les dveloppeurs amliorent sans cesse la structure interne
du logiciel
pour que les volutions y restent faciles et rapides
considrations
Sommaire
1 Introduction
2 quipe et rles XP
3 Pratiques XP
4 Processus XP

considrations
Programmeur
Deux hypothses dans XP pour justifier limportance du code

En gnie logiciel, lactivit correspondant la fabrication est la compilation,
pas la programmation
Code clair, structur et simple modifi autant de fois que ncessaire pour quil
soit comprhensible et non redondant est la meilleure forme de conception
Tests et proximit du client

Tests (cf. Feedback)
Eviter les dcalages entre ce que lon veut coder et le comportement rel
Ce qui nest pas test nexiste pas (cf. Courage)

Ecouter le client (cf. Communication)
Lui seul sait comment le logiciel doit fonctionner

considrations
Programmeur (cont.)
Conception pour un codage durable
Elle est trs importante !
Elle a un but diffrent :
Pas montrer ce que lon a cod
Pas fournir des documents remplis de schmas
Garantir le long terme
Eviter ainsi :
Fragilit (modification rgression)
Rigidit (petite modification nombreuses modifications)
Immobilit (factoriser tout casser)
Interventions sur
la conception
Collectivement lors des
sances de planification
Lors de lcriture des tests
unitaires
considrations
Programmeur (cont.)
Responsabilisation
Retour du programmeur comme rle central
A la fois : codeur, testeur, concepteur et analyste
Apprentissage Qualits humaines ncessaires
XP : Ecole de lexcellence
Responsabiliss pour donner le meilleur deux mme
ex. : estimation des charges et dlais
Pratiques XP
Programmation en binme Responsabilit collective du code
Tests unitaires Rgles de codage
Conception simple Intgration continue
Remaniement Rythme durable

considrations
Client
Qui est-il ? Client sur site et feedback

Pas ncessairement le client Intgr lquipe de
contractuel dveloppement
Assistant matrise
douvrage
Plus de cahier des charges
Reprsentant des vague ou incomprhensible
utilisateurs
Plus de dmo truque
A dfaut quelquun pour agir Explique se quil souhaite aux
comme client artificiel dveloppeurs
Chef de projet Vision plus rapide du rsultat
Ingnieur charg des
Prise de conscience en cas
spcifications
derreur

considrations
Client (cont.)
Scnarios clients
Description informelle dune fonctionnalit ou dune interaction avec
lutilisateur
Le plus simple possible
Dmarrage du A chaque
projet
Des scnarios initiaux
itration...
Grce au feedback introduit (logiciel
sont dgags et fonctionnel) :
prsents Il peut revoir le contenu des
itrations
Ils sont classs par Modifier ses scnarios
priorit et rpartis en
itrations Il est garant des fonctionnalits du
logiciel

considrations
Client (cont.)
Tests de recette
But : prciser les contours des scnarios
Donnes concrtes levant les ambiguts
Preuve que le systme fait ce quil demandait
A chaque fin ditration tous les tests de recette doivent passer avec succs
Pratiques XP
Planification itrative
Rdaction des scnarios clients
Sances de planification
Tests de recette
Intgration continue
Rythme durable
considrations
Testeur
Le bras droit du client Comptences

requises
Dfinit et automatise les tests
de recette Programmeur htroclite
Conseille le client sur la (matriser loutillage de test)
testabilit dune Rigoureux et intgre
fonctionnalit
Utilisation doutils diffrents
pour scripter Pratiques XP
Garant du sentiment de russite Suivi des tests (planification
sur le projet
itrative)
Test fonctionnel russi
Progression Tests de recette
Communiquer pour motiver Intgration continue
(graphique de progression...)
Rythme durable

considrations
Tracker
Missions
Suivre les tches en cours ditration
Interroger les programmeurs
Savoir o ils en sont
Ne pas les mettre sur des charbons ardents
Attention ne pas driver en discussion technique
Dtecter les problmes avant quil ne soit trop tard

Rvlateur
Pas de prise dinitiative
Il fait en sorte que la tche de 3 jours en prenne 4 et non 6

considrations
Tracker (cont.)
Qui est-il ?
Pas un suprieur hirarchique
Quelquun a qui on peut se confier
De prfrence pas un programmeur, mais quelquun dextrieur
Pour viter les discussions techniques
A dfaut, ce rle peut tourner entre les programmeurs chaque itration
Pratiques XP
Planfication itrative

considrations
Manager
Position dans lorganisation

Suprieur hirarchique des programmeurs
Ne fait pas partie intgrante de lquipe
Chef du service auquel appartient lquipe
Chef de projet global (dans le cadre dun sous-projet)
Responsabili Pratiques
ts XP
Il soccupe matriellement de lquipe Scnarios client
Il demande des comptes (sur les Planification itrative

engagements pris) Rythme durable
Interface avec lextrieur (dans le cadre
dun sous-projet)

considrations
Coach
Garant du processus
Il runit tout les autres rles
Vrifie que chaque rle est respect
Ses buts ultimes :
Equipe autonome
Chaque programmeur est en amlioration continue
Ses qualits
Expert de la mthode XP
Expert technique
Programmeur chevronn
Architecte
Pdagogue et sensible
Sang-froid
Pratiques XP
Toutes !
considrations
Rpartitions des rles
Plusieurs rles pour une

personne
Attention aux combinaisons
possibles
Toutefois, pas de rgle absolue
Sassurer quune cumulation ne pousse pas sacrifier une composante

importante dun rle
Plusieurs personnes
pour un rle
Programmeur, le plus grand
nombre
Tracker, une seule personne...
un moment donn
Coach, une
Introduction personne
leXtreme unique
Programming et au 27 /
considrations
Compatibilit des rles
Prog Clie Prog Trac Man Coa

ram nt ram ker ager ch
meu meu
r r
Programmeur ! ! !
Client
Testeur !
Tracker ! ! !
Manager !
Coach ! !
bonne combinaison
mauvais combinaison
! combinaison envisageable mais
risque

considrations
Prcautions
Comportements contre-indiqus
Sattribuer les mrites ou rejeter la faute sur les autres
Un codeur (mme trs comptent)
faisant des choses que personne ne comprend
refusant de travailler avec quelquun de moins comptent
Chercher se rendre indispensable
Eviter la spcialisation
Tendance naturelle la constitution de sous-groupes
Avec XP, pas de consquences tant que le groupe est petit
Envisager des mcanismes de rotation pour les binmes
Cas1particulier du consultant
Le consultant est appel pour un problme prcis
2 Il travaille toujours accompagn par un programmeur
3 Lquipe souhaitera probablement refaire le travail

considrations
Sommaire
1 Introduction
2 quipe et rles XP
3 Pratiques XP
4 Processus XP

considrations
Pratiques XP
Whole
Team
Collective Coding
Ownership Standards
Test-Driven
Development
Customer Pair Planning

Programming Refactoring
Tests Game
Continuous Sustainable
Integration Simple Pace
Design
Metaphor
Small
Releases

considrations
Pratiques XP
Dveloppement pilot par les tests

Programmation Conception simple
Remaniement
Programmation en binme
Responsabilit collective du code
Collaboration Rgles de codage
Intgration continue
Client sur site

Rythme durable
Gestion de projet Livraisons frquentes

considrations
Dveloppement pilot par les tests
Automatisation
Tests dun logiciel sont gnralement automatisables
Automatisation moins de temps consacr aux tests
Temps ncessaire lautomatisation plus long, mais...
Moins de dfauts dans le code
Moins de rgressions
Ecrire les tests en premier

Position a priori paradoxale, mais...
Elimination du dilemme habituel en fin de projet
Code plus facilement testable
Moins denchevtrement Meilleure conception
Tests fonctionnels Forme de spcification

Tests unitaires Forme de conception dtaille
considrations
Dveloppement pilot par les tests (cont.)

Tests Fonctionnels
Dans le cas gnral, la recette permet de vrifier que :
Le logiciel na pas danomalie constate
Les fonctionnalits livres sont bien celles demandes
Dans le cas XP :
Tests de recettes spcifis par le client

Tests fonctionnels crits par le testeur

Livraison possible lorsque tous les tests russissent
Test Unitaires
Ecrits avant le code tester
Plusieurs rles :
Rythmer la programmation (progression dalpiniste )
Guider la conception
Documenter le code produit (cf. notion de contrat )

considrations
Dveloppement pilot par les tests (cont.)
Test Unitaires (nouvelle

implmentation)
1 Identifier une sous-partie du problme
2 Ecrire un test indiquant si le problme est rsolu
3 Excuter le test... qui doit chouer
4 Ecrire le code
5 Excuter le test pour vrifier que le code
fonctionne correctement
Test Unitaires (modification de

conception)
1
Modifier le test concern
2
Excuter le test... qui doit chouer
3
Modifier le code
4
Excuter le test pour vrifier que
le code fonctionne correctement

considrations
Conception simple
Eviter la spculation
Conception = Investissement (en temps et/ou complexit)
Identifier toutes les classes ou modules dont sera constitu le systme, hritage...
Implmenter un systme gnrique pour facilement implmenter chaque
fonctionnalit spcifique
Cet investissement peut-tre bnfique...

Mais si on a mal spcul ?
XP : Se concentrer sur une et une seule fonctionnalit

Obtenir la meilleure conception possible... ...
sans aller au-del
Do the simplest thing that could possibly work
You Arent Gonna Need It (YAGNI)
Implmenter le strict ncessaire
Compltement et correctement
Tests unitaires compris

considrations
Conception simple (cont.)
Simplicit Facilit
Le plus simple nest pas forcment le plus facile
Par exemple, dupliquer le code dune mthode pour avoir une version
lgrement modifie est facile...
Mthode ayant des anomalies Rechercher toutes les variantes pour les
corriger
Toutefois, ne pas oublier de progresser
Rgles de simplicit XP
Tous les tests doivent tre excuts avec succs
Chaque ide doit tre exprime clairement et isolment
Tout doit tre crit une fois et une seule
Le nombre de classes, de mthodes et de lignes de code doit tre minimal

considrations
Remaniement
Dfinition
Procd consistant modier un logiciel de telle faon que, sans altrer
son comportement vu de lextrieur, on en ait amlior la structure interne
Transformations de code
Martin Fowler en a rpertori plusieurs dizaines
Dcrites avec grande prcision
Prsentation proche des Design Patterns
Beaucoup peuvent tre appliqus mcaniquement
Certains IDE commencent mme en automatiser certains (i.e. Eclipse)
Exemples de rsultats
Elimination du code dupliqu
Sparation des ides
Elimination de code mort
considrations
Remaniement (cont.)
Lien avec les tests

Chaque modification apporte par une transformation est minime
Grce aux tests on peut tre certain quaucune erreur na t introduite
On peut facilement revenir en arrire
Comme dans la nature :
Chaque remaniement est une mutation isole
Les tests font office de slection naturelle
Les mutations nocives sont limines
La robustesse du code est accrue

considrations
Mtaphores
Dans un projet classique
On cherche communiquer
Sur ce que lon attend du projet
Sur ce que lon a ralis
Do un effort de rdaction non ngligeable

But : obtenir une vision commune
Souvent noye dans une documentation trop dtaille
XP se focalise sur la vue densemble

Conserver uniquement le strict ncessaire
Eviter la redondance
En gnral quelques pages suffisent
Utilisation de mtaphores
Eviter le jargon technique
Utiliser des images
considrations
Programmation en binme
Fonctionnement du binme
Toujours deux dveloppeurs devant une machine
Pilote : Ecriture du code, manipulation des outils...
Co-Pilote : Relecture continue du code, propositions...
Dialogue permanent pour raliser la tche en cours
Formation des binmes

Changement frquent des binmes (plusieurs fois par jour)
Slection libre :
On demande laide de quelquun dautre
Il ne peut refuser ou seulement temporairement
Exemples de critres de choix :

(Faire) Profiter de lexprience
Intrt pour la tche raliser
considrations
Programmation en binme (cont.)
Rpartition des tches

Chaque dveloppeur est responsable de ses tches
Alors, tout instant :
Il travaille sur une de ses tches
Il aide quelquun dautre raliser sa tche
NB : Une tche pourra tre ralise en plusieurs fois
Une pratique rentable ?

Un binme est plus rapide sur une tche donne quun programmeur seul
Amlioration de la qualit du code Rduction du cot de maintenance
Partage des connaissances, Cohsion dquipe

considrations
Programmation en binme (cont.)
Prcautions
Rester clair :
Collaboration active et continue
Pas un qui code lautre qui sur veille
Qualits humaines de lquipe dterminantes

Sassurer que le co-pilote ne dcroche pas
Grer les diffrences de niveau (pas de marginalisation)
Souvrir sur le reste du groupe en cas de problme
Rester raliste...
Il est difficile de fonctionner en binme 100% du temps
Espace de travail
Eviter le cloisonnement pour favoriser les changes
Concept de War Room
considrations
Responsabilit collective du code
Modles actuels : Responsabilit

individuelle
Chaque dveloppeur volue dans une
partie rserve
Ncessite de se mettre daccord sur les
interfaces
Limite les interfrences
Garantie une certaine autonomie
Notion de responsable souvent

entche de faute
Sparation des connaissances
Duplication de code
Pas de progression dans les comptences
Modles actuels : Absence de

responsabilit
Code appartenant toute lquipe et
Introduction leXtreme Programming et au
dveloppement agile
44 /
76
considrations
Responsabilit collective du code (cont.)
Modle XP
Chaque binme peut inter venir sur nimporte quelle partie
Mais chacun est responsable de lensemble
Par ex. un binme peut revoir une partie peu claire du code
Fonctionne bien uniquement dans un cadre XP
Tests unitaires
Intgration continue
Remaniement
Rgles de codage
La fin des
spcialistes ?
Non !
Ils doivent devenir
polyvalent
Mais agissent comme
dveloppement agile
45 /
76
consultant interne
considrations
Rgles de codage
Pourquoi ?
Homognisation ncessaire (responsabilit collective)
Prise en main plus rapide du code crit par dautres
A dfinir avant le dmarrage du projet
Parfois mal perues, mais

Adaptation assez rapide
Prise de conscience du travail en quipe
Peut sinscrire dans une dmarche qualit
Aspects couverts
Prsentation du code (indentation, espaces...)
Organisation des commentaires
Rgles de nommage (classes, mthodes, constantes...)
Systme de noms (vocabulaire commun, mtaphore...)
Idiomes de codage (parcours de liste, singletons...)
dveloppement agile
46 /
76
considrations
Intgration continue
Pourquoi viter des priodes dintgration ?

Profiter immdiatement des efforts de chacun
Cot de lintgration augmente trs vite avec lloignement dans le temps des
intgrations successives
Frquence dintgration classique : 1/semaine
Frquence XP : 1/jour n/heure
Mthode de travail : Gestion de versions

Test Unitaires = Tests de non-rgression
Processus
1 suivi :
Rcupration dune copie locale
2 Modification de la copie
3 Mise jour de la copie locale lorsquelle passe les tests
4 Correction des ventuels problmes
5 Mise en dpt de la copie locale lorsquelle passe
les tests

considrations
Client sur site

Notion dquipe
Client intgr lquipe de dveloppement
Equipe
Ensemble des dveloppeurs
Whole Team (client et programmeurs)
Avantages
Spcifications fonctionnelles gnralement floues, ici :
Client disponible pour apporter ses comptences mtier
Maitrise douvrage conserve par le client
Dfinition des tests de recette par le client
Une pratique inaccessible ?

Trs difficile de trouver quelquun de suffisamment disponible
dveloppement agile
48 /
76
considrations
Rythme durable
Maintenir un niveau optimal

Savoir travailler... mais aussi se reposer !
Beaucoup dnergie ncessaire pour :
Trouver des solutions de conception simples
Ecrire du code propre
Penser des tests unitaires
Explorer avec son binme les problmes rencontrs
On peut faire des heures supplmentaires

Sur une cour te priode de temps
Suivie dune priode de relchement
Traiter les problmes rels

Rgle : Pas dheures sup deux semaines de suite
Ne pas la respecter est le signe dun problme plus profond
Plutt le rsoudre que le masquer par un sur plus de travail
considrations
Livraisons frquentes
Rythment le projet
Livraisons rgulires comme point de synchronisation
Le client fixe ces dates, par exemple :
Pour un projet de six ou sept mois
On pourra espacer les livraisons denviron un mois et demi
La premire livraison arrivant au bout de deux mois
La premire livraison doit arriver le plus tt possible

Dissiper dventuels malentendus
Donner consistance au projet
Les livraisons doivent tre aussi proches que possible

Pilotage prcis du projet
Donner des preuves de son avancement

considrations
Livraisons frquentes (cont.)
Un feedback pour le
client
Mieux cerner ses besoins
Etre rassur sur
lavancement rel du projet
Un feedback pour
lquipe
Sentiment rgulier de
travail fini
Confrontation du produit
un environnement rel

considrations
Rythme
Environ 2 ou 3 itrations entre deux livraisons
Pour un projet de six ou sept mois
Itrations de deux semaines environ
Sances de planification ( Planning Game )

Livraisons et itrations sont des cycles imbriqus
Deux niveaux de granularit pour le pilotage
Livraisons Fonctionnalits
Itrations Tches raliser par les dveloppeurs
Exploration,
Ces1deux identifier
cycles sont le travail
dcoups enettrois
estimer son cot
phases
2 Engagement, slectionner le travail pour le cycle en cours
3 Pilotage, contrler la ralisation de ce qui est demand

considrations
Planification itrative : Livraisons
Exploration (de plusieurs jours

quelques heures)
Dfinir les scnarios client
Granularit fine (plus fine
que les Use Cases)
Doit tre testable
Gnralement nots sur
des fiches A5
Plus simples
manipuler
Estimer les
scnarios client
Attribution dun nombre
de points (jours
thoriques)
Tenir compte du codage
des
Introduction tests et
leXtreme
dveloppement agile
de la validation
Programming et au 53 /
76
En cas dinconnue
considrations
Planification itrative : Livraisons (cont.)
Engagement (quelques heures

seulement)
Trier les scnarios (9 tas)
Par priorit (client) : Indispensable,
Essentiel, Utile
Par risque (programmeurs) : Fort,
Moyen, Faible
Annoncer la vlocit de lquipe

Nombre de points que peut traiter
lquipe en une itration
Pour la premire itration le coach
fourni sa propre estimation
Rpartir les scnarios parmi les livraisons

venir
Le client achte les scnarios en
fonction de la vlocit
dveloppement
Cration du plan de livraison
agile 76
considrations
Planification itrative : Livraisons (cont.)
Pilotage (jusqu la date de

livraison)
Suivre les tests de recette
Nombre de tests raliss par le client et les testeurs

Nombre de tests valids
Grer les dfauts Scnarios supplmentaires
1 Intgrer au mcanisme gnral de planification
2 Priorit absolue
Et ensuite ?
Livrer sans dlai Reporter les scnarios manquants
Clbrer lvnement et prendre du recul
Repas hors du lieu de travail par exemple
Bonne occasion pour se dtendre
Dmarrage dun nouveau cycle

Amlioration de la fiabilit des estimations
considrations
Planification itrative : Itrations
Exploration
Analyser les scnarios pour les scinder en tches
Activit de conception (mme superficielle)
Questions au client et discussion en sa prsence
Tche : ralisable par un binme en une ou deux journes
Engagement
Choisir et estimer des tches
Equilibrage des choix dans lquipe
Fusion/Scission de tches (si ncessaire)
Avancement/Report de scnarios (si ncessaire)
Production du plan ditration
considrations
Planification itrative : Itrations (cont.)
Pilotage
Ralisation des tches (mise jour du plan ditration)
Tourne du Tracker (au moins deux fois par semaine)
Dceler tout drapage au plus tt
Prendre des mesures correctives (allger une charge...)
Stand-up meetings
Chaque matin un point sur la situation ou les difficults
Pas une runion technique ni un suivi des tches
Permet dorganiser la journe (binmes...)
Et ensuite ?
Petite livraison informelle au client de lquipe
Mise jour des cots des scnarios raliss
Clbrer lvnement...
Un pot pour repartir sur de bonnes bases
considrations
Sommaire
1 Introduction
2 quipe et rles XP
3 Pratiques XP
4 Processus XP

considrations
Cycle de vie XP
User
Test S
ce narios
Stori Re
q ui
es re New User Story,
me
nt Project Velocity Bugs
s
Architectural Releas Release Latest Acceptance Customer Sma
System Iterati
Spik Metaphor e Plan ll
Releas
on Version Tests
e Planning e
Next Approval
Iteration
Uncertain Confident
Estimates
Estimates
Spik
e
Exploration Planning Iterations to Release Productionizing

Phase Phase Phase Phase
Maintenance Phase
http://www.extremeprogramming.org/

considrations
Cycle de vie XP
User
Test S
ce narios
Stori Re
q ui
es re New User Story,
me
nt Project Velocity Bugs
s
Architectural Releas Release Latest Sma
Iterati Acceptance Customer
System
Spik Metaphor e Plan Version ll
Releas
on Tests
e Planning e
Next Iteration Approval
Uncertain Confident
Estimates
Estimates
Spik
e
Exploration Planning Iterations to Release Productionizing

Phase Phase Phase Phase
Maintenance Phase

considrations
Itration
New User
Story,
Project
Velocity
Releas
e Learn and
Plan Us
S to e r Communicate
rie
s New
Unfinished Tasks
Projet Functionnality
Next Velocity Iterati Lates
Developme
Iterati on Iteration t
nt
on Planni Plan Versio
led Bug Fixes
F ai Tes
ts ng n
ce
ta n
cep
Ac Day by Day
Bug
s

considrations
Itration
New User
Story,
Project
Velocity
Releas
e Learn and
Plan Us
S to e r Communicate
rie
s New
Unfinished Tasks
Projet Functionnality
Next Velocity Iterati Lates
Developme
Iterati on Iteration t
nt
on Planni Plan Versio
led Bug Fixes
F ai Tes
ts ng n
ce
ta n
cep
Ac Day by Day
Bug
s

considrations
Dveloppement
Unfinish Learn and

ed
Tasks Communica
te
Pair Programming
Iterati Too Much a re Refactor Merciless
on To Do Sh Move People Around
Plan CRC Cards New
Ta Functional
s ks
nit ity
%U
10 0 d
P a ss e
s
Stand Next Task or Collective Test
Up Failed Acceptance Test Code
Meetin Ownership
Ac
il ed tsg
s ce
p ta
Fa Te Te
st P n
n ce c
as s e
ta
c ep ed
Day Ac
Bug
by
Fixes
Day

considrations
Dveloppement
Unfinish Learn and

ed
Tasks Communica
te
Pair Programming
Iterati Too Much a re Refactor Merciless
on To Do Sh Move People Around
Plan CRC Cards New
Ta Functional
s ks
nit ity
%U
10 0 d
P a ss e
s
Stand Next Task or Collective Test
Up Failed Acceptance Test Code
Meetin Ownership
Ac
il ed tsg
s ce
p ta
Fa Te Te
st P n
n ce c
as s e
ta
c ep ed
Day Ac
Bug
by
Fixes
Day

considrations
Le code appartient tous
CRC Move 100%

Card People Unit
s Around Test
Passed
Simple
Complex Change We Need Run All
Problem Pair Help Unit Tests
Design
Failed New Unit

Unit Test Tests
Next Task or Run Failed
Pair Continuo
Failed Pair Create Acceptance
Programmi us
Acceptance Test
Up Unit Passed ng New Integrati
Test
Test Unit Test Functionality on
Simple Complex
Code Code
Refacto Acceptan
r ce Test
Mercile Passed
ss

considrations
Feedback
Release Plan
Months
Iteration Plan
Weeks
Accepta
nce
Test
Stand
Days
Up
Meeting
One Day
Pair
Negotiation
Hours
Unit
Test
Minutes
Pair
Programming
Seconds
Code
considrations
Sommaire
1 Introduction
2 quipe et rles XP
3 Pratiques XP
4 Processus XP

considrations
XP et la modlisation
Can you use UML with XP ?

Yes. You can apply the artifacts of the UML activity diagrams, class diagrams,
collaboration diagrams, component diagrams, deployment diagrams, sequence
diagrams, statechart diagrams, and use case diagrams when you are taking an
XP approach to development.
How do you use UML with XP ?

Minimally you should apply Agile Modelling and use UML artifacts on your XP
project only where appropriate. Ideally you should apply all of the principles and
practices of Agile Modelling when doing so.

considrations
XP et la documentation
Au centre des dbats

On ncrit pas de documentation dans XP : Faux !
XP tend liminer la paperasse... mais restons nuancs
Documentation utilisateur
Manuel utilisateur, Procdure dinstallation...
Ils doivent tre crits, mais planifis comme les tches techniques
Documents lis au projet

Comptes rendus, Plannings...
Le client tant prsent dans lquipe, limportance de ces documents est
rduite

considrations
XP et la documentation (cont.)
Documentation technique
Document de conception, Diagrammes...
Tests fonctionnels Spcification
Tests unitaires Conception dtaille
Remaniement Modification aise de la conception
Le code est de la documentation (gnration automatique ?)
Autour du programmeur
Code source comme principale production du projet
Programmeur comme acteur essentiel
Contrairement certaines autres mthodes
Il nest pas un simple excutant
Il dispose de pratiques pour tre plus
efficace
Il accde une certaine reconnaissance
considrations
Principaux facteurs de succs
Sur le plan Humain

Prsence dun coach potentiel
Quelques dveloppeurs expriments... et ouverts
Une quipe capable de travailler... en quipe
Sur le plan Organisationnel

Environnement de travail adapt ( War Room )
Hirarchie consentante
Culture dentreprise adapte
Pas de mrite bas sur les heures supplmentaires
Pas de jeu politique (gagnant-gagnant)
Pas dattachement aux mthodes linaires, ou aux tonnes de documents comme
reflet de la qualit

considrations
Principaux facteurs de succs (cont.)
Sur le plan Technique

Possibilit de travailler sur des portions rduites de lapplication
Valable dans le cas dune reprise dun gros projet
Redcouper le logiciel dans un tel cas
Langage de programmation permettant des mcanismes dabstraction et de

factorisation
La plupart des langages objets entrent dans cette catgorie
Disposer dun outil de gestion de versions efficace

considrations
Le problme du contrat...
Aujourdhui en France...
Mise en uvre dXP encore peu prsente en entreprise
Parfois pour des dveloppements internes
Contrats forfaitaires
Un fournisseur sengage un rsultat donn, dans un dlai donn pour un
prix fix
Limites du modle
Primtre fonctionnel rarement clair
Rapports conflictuels
Tout le monde perd
Fige un maximum de paramtres (cahier des charges...)
Difficile de pratiquer XP dans ces conditions
Sauf pour deux entreprises ayant une relation partenariale
Impose lutilisation davenants au contrat
considrations
Le problme du contrat... (cont.)
Contrats dassistance technique ( rgie )

Un fournisseur met disposition du personnel comptent
Le client assure matrise douvrage et matrise duvre
Le fournisseur facture au client le temps pass
Limites du modle
Repousse simplement la question de la matrise duvre
Quelle est lexprience du client dans ce domaine ?
Motivation des collaborateurs mis disposition peut tre un problme
La possibilit dappliquer XP dpendra donc du client

Sil est capable de le faire en interne
Sinon une intervention extrieure peut permettre la transition vers XP

considrations
Le problme du contrat... (cont.)
Contrats dassistance forfaite

Combinaison des deux modles
Facturation au temps pass
Mais le fournisseur reste matre duvre
Gnralement difficile faire accepter au client

Ncessite une relation de confiance entre les deux parties
Difficults spcifiques la France

Culture institutionnelle franaise
XP est une mthode privilgiant les ralits du terrain
En France, les dcisions partent du management pour se rpercuter sur les
oprationnels
Directions financires attaches au contrat forfaitaire

Budget prvisionnel dans un primtre bien dfini
Besoins rels de lutilisateur financirement inexistants
considrations
Avoir lil critique
Critiques possibles lencontre dXP

Trop anarchique
Pas assez de documentation
Trop extrme...
Culte du super programmeur
Une utopie ?
Mthode profondment humaniste (cf. manifeste agile)
Tout le monde est-il honnte ?
Matriser XP...
... cest savoir quand ne pas utiliser XP
... cest savoir adapter XP aux besoins courants
considrations
Autres mthodes agiles
Methodolog Summarizing Phrase

y
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
http://www.devx.com/architect/Article/32836

considrations
Autres mthodes agiles (cont.)
XP Scr Le FD AU Cry DS
um an D P sta DM
Condition l
Small Team -
Highly Volatile Requirements - -
Distributed Teams
High Ceremony Culture - - -
High Criticality Systems - - - -
Multiple Customers / Stakeholders - - -
The table illustrates which conditions favor (), discourage (), or are neutral
(-)
http://www.devx.com/architect/Article/32836

considrations
Pour plus dinformations sur XP
LeXtreme Programming
J.L. Bnard, L. Bossavit, R. Mdina, D. Williams
Editions Eyrolles
Extreme Programming Explained
Kent Beck, Cynthia Andres
XProgramming.com
http://xprogramming.com/
Extreme Programming : A gentle

introduction
eXtreme Programming France

http://xp-france.net/
Design Up
http://www.design-up.com/

XP

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

XP

Загружено:

Авторское право:

Доступные форматы

Introduction quipe et rles XP Pratiques XP Processus XP Autres

SMA/G2I/ENS Mines Saint-Etienne

Adapt de XP ou les bienfaits dun dveloppement agile

Introduction leXtreme Programming et au 1/

Introduction leXtreme Programming et au 2/

Introduction leXtreme Programming et au 3/

Introduction leXtreme Programming et au 4/

La prhistoire : Influences (cont.)

Introduction leXtreme Programming et au 5/

La prhistoire : Influences (cont.)

Introduction leXtreme Programming et au 6/

Projet C3 (Chrysler, 1996) : Naissance du processus

De lutilisation du Wiki Wiki Web

Introduction leXtreme Programming et au 7/

Les dbuts (cont.)

Evolution et gain de popularit

Introduction leXtreme Programming et au 8/

Runion organise par Kent Beck en Fvrier 2001

Introduction leXtreme Programming et au 9/

Mythe des phases

Introduction leXtreme Programming et au 10 /

Mythe des phases

1994 : Rapport CHAOS (tude sur 8000 projets)

Diagnostic courant des drapages :

Mise mal de la conception propose

Utopie des spcifications immuables

Dfinir un logiciel a priori est un exercice difficile, sauf dans le cas :

Le client a du mal imaginer ce que sera lapplication

Introduction leXtreme Programming et au 11 /

Communication crite prsente, en gnral par du code

Retour dinformation (Feedback)

Introduction leXtreme Programming et au 13 /

Le client (matrise douvrage) pilote lui-mme le projet, et ce

Introduction leXtreme Programming et au 15 /

Deux hypothses dans XP pour justifier limportance du code

Tests et proximit du client

Ce qui nest pas test nexiste pas (cf. Courage)

Introduction leXtreme Programming et au 16 /

Tests unitaires Rgles de codage

Conception simple Intgration continue

Remaniement Rythme durable

Introduction leXtreme Programming et au 18 /

Qui est-il ? Client sur site et feedback

Introduction leXtreme Programming et au 19 /

Introduction leXtreme Programming et au 20 /

Le bras droit du client Comptences

Introduction leXtreme Programming et au 22 /

Dtecter les problmes avant quil ne soit trop tard

Il fait en sorte que la tche de 3 jours en prenne 4 et non 6

Introduction leXtreme Programming et au 23 /

Introduction leXtreme Programming et au 24 /

Position dans lorganisation

Il demande des comptes (sur les Planification itrative

Introduction leXtreme Programming et au 25 /

Rpartitions des rles

Plusieurs rles pour une

Sassurer quune cumulation ne pousse pas sacrifier une composante

Compatibilit des rles

Prog Clie Prog Trac Man Coa

Introduction leXtreme Programming et au 28 /

Chercher se rendre indispensable

Introduction leXtreme Programming et au 29 /

Introduction leXtreme Programming et au 30 /