METHODES AGILES
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 1
SOMMAIRE
1. DEFINITION
2. XP ET L’AGILITE
3. CYCLE DE DEVELOPPEMENT
4. PILOTAGE DU PROJET
5. LES PRATIQUES DE XP
6. LES VALEURS DE XP
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 2
DEFINITION
XP est l'un des principaux représentants d'une famille émergente de processus : les
processus dits "agiles", qui se démarquent des démarches traditionnelles en mettant
l'accent sur le travail d'équipe et la réactivité. L'heure est à l'économie et à l'efficacité :
« Quelles activités pouvons nous abandonner tout en produisant des logiciels de qualité ? ».
Ou encore : « Comment mieux travailler avec le client pour nous focaliser sur ses besoins
les plus prioritaires et être aussi réactifs que possible ? »
XP propose une réponse originale à ces questions, avec un ensemble de pratiques
organisées autour des principes suivants :
Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des
cycles itératifs extrêmement courts (1 ou 2 semaines).
L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de
nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback
maximal sur l'avancement des développements.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 3
DEFINITION
L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une
collaboration maximale entre ses membres.
L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle
développe, ce qui garantit au produit un niveau de robustesse très élevé.
Les développeurs améliorent sans cesse la structure interne du logiciel pour que les
évolutions y restent faciles et rapides.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 4
XP ET L’AGILITE
Les démarches traditionnelles, basées sur la fameuse séquence « spécification >
conception > réalisation > validation », concentrent la plupart des décisions en début de
projet.
L'objectif de cette approche est louable : le client veut des garanties sur ce qu'il
obtiendra en fin de projet, et le chef de projet souhaite disposer des informations
nécessaires à l'organisation de son équipe.
Malheureusement, les équipes qui évoluent dans un environnement changeant ou
complexe savent à quel point il est difficile de s'en tenir aux décisions initiales. Le client
réalise que ses besoins ont changé, ou bien l'équipe découvre en phase
d'implémentation des erreurs de spécification qui compromettent les plans de
développement.
Le changement s'impose donc tôt ou tard : cette organisation suppose l'absence de
changement, et celui-ci se révèle bien vite très coûteux - suffisamment parfois pour
compromettre la rentabilité du projet.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 5
XP ET L’AGILITE
Les créateurs d'XP ont trouvé une réponse à ces questions en découvrant que certaines
pratiques d'organisation d'équipe et de programmation, appliquées ensemble,
permettent de rendre le logiciel extrêmement malléable - à tel point qu'il devient plus
avantageux de le faire évoluer progressivement que de chercher à le spécifier et le
concevoir complètement dès le départ. Partant de ce constat, ils ont conçu une
démarche qui diffuse le processus de décision tout au long du projet grâce à
l'enchaînement de cycles itératifs très courts :
Le client jouit d'une très grande visibilité sur l'avancement des développements.
Le client utilise le logiciel lui-même comme support de réflexion pour le choix des
fonctionnalités à implémenter - il peut en particulier intégrer très tôt les retours des
utilisateurs pour orienter les développements en conséquence.
La première mise en production du logiciel intervient très tôt dans le projet, ce qui
avance d'autant le moment à partir duquel le client peut en tirer des bénéfices.
L'ordre d'implémentation des fonctionnalités n'est pas guidée par des contraintes
techniques, mais par les demandes du client.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 6
LE 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.
Dans un projet XP, ce temps correspond exactement à la durée d'une itération, c'est-à-
dire typiquement deux semaines. Chaque itération reprend la structure suivante :
Le premier jour de l'itération est consacré à la réunion de planification, au cours de
laquelle le client et l'équipe conviennent de ce qui doit être implémenté au cours de
l'itération. A la fin de cette journée, l'équipe dispose de la liste précise des tâches à
réaliser.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 7
LE CYCLE DE DÉVELOPPEMENT XP
Ensuite, l'équipe s'organise pour réaliser les tâches en question. Elle prend en charge
le suivi des tâches, ainsi que les activités d'analyse du besoin, de conception,
d'implémentation et de test correspondantes. Il est important de noter qu'il n'y a pas
de changement de cap intermédiaire : l'équipe se focalise sur son objectif sans
interruption jusqu'à la fin de l'itération.
Au terme des deux semaines, l'équipe met une nouvelle version du logiciel à
disposition du client. Ce logiciel est robuste, testé, et sa structure interne est laissée
aussi propre que possible pour que les prochaines évolutions y restent peu coûteuses.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 8
PILOTAGE DU PROJET
EQUIPE ET RÔLES
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 9
PILOTAGE DU PROJET
RÔLES et PRATIQUE XP : LE CLIENT
Le pilotage du projet est assuré par un membre spécifique de l'équipe projet : le «
client ». Le client détermine les fonctionnalités du logiciel, gère les priorités, définit les
spécifications précises du produit - en somme, ce rôle correspond à ce que nous
nommons la maîtrise d'ouvrage du projet. Dans un projet XP, ce représentant de la
maîtrise d'ouvrage rejoint le projet à plein temps.
Planification itérative
Rédaction des scénarios clients
Séances de planification
Tests de recette
Intégration continue
Rythme durable
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 10
PILOTAGE DU PROJET
RÔLES et PRATIQUE XP : Programmeur & Développeur
Programmation en binôme Responsabilité collective du code
Tests unitaires Règles de codage
Conception simple Intégration continue
Remaniement Rythme durable
RÔLES et PRATIQUE XP : Testeur
Définit et automatise les tests de recette, Suivi des tests (planification itérative)
Utilisation d’outils différents pour scripter. Tests de recette
Garant du sentiment de réussite sur le projet Intégration continue
Test fonctionnel réussi→ Progression. Rythme durable
Conseille le client sur la testabilité d’une Fonctionnalité.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 11
PILOTAGE DU PROJET
RÔLES et PRATIQUE XP : Manager
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)
RÔLES et PRATIQUE XP : Coach, le chef de projet
Il réunit tout les autres rôles
Vérifie que chaque rôle est respecté
Ses buts ultimes :
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 12
PILOTAGE DU PROJET : LES PHASES
La phase initiale d'exploration
Le projet démarre par une phase d'exploration volontairement très courte (typiquement
un mois maximum), qui a pour triple objectif de définir le contenu fonctionnel de
l'application, établir un premier plan de développement pour le projet, et produire la toute
première version du logiciel.
Au cours de cette phase, le client explore et définit le contenu fonctionnel qu'il souhaite
voir implémenté dans le produit. Il établit ainsi une liste de fonctionnalités, qui prennent
en XP la forme de « scénarios client ».
Les scénarios sont rédigés dans le langage du client, et décrivent des fonctionnalités dont
l'implémentation paraît assez rapide. Si un scénario paraît trop vague ou trop complexe, il
est décomposé en scénarios plus simples. A l'inverse, des scénarios trop courts peuvent
être regroupés en un seul pour obtenir la granularité souhaitée.
Au cours de la phase d'exploration, le client et l'équipe se forgent ainsi une idée assez
précise du périmètre fonctionnel souhaité de l'outil. Ils établissent alors le premier plan
de développement du projet.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 13
PILOTAGE DU PROJET : LES PHASES
Planification du projet
La planification est réalisée au cours d'une réunion dédiée, qui réunit l'équipe et le client
et se déroule comme suit :
1. Le client présente les différents scénarios à l'équipe, qui tente de se faire une idée de la
charge de travail de chacun d'entre eux.
2. L'équipe donne pour chaque scénario une estimation de son coût d'implémentation, en «
points » abstraits : tel scénario coûte 3 points, tel autre 1 point, etc.
3. L'équipe donne au client une estimation de sa « vélocité », c'est-à-dire du nombre de points
de scénarios qu'elle s'estime capable de traiter en une itération - par exemple 10 points.
Au tout début du projet cette vélocité est seulement estimée, mais après les premières
itérations elle est réajustée en adoptant la règle suivante : la vélocité estimée pour une
itération donnée correspond exactement au nombre de points effectivement traités à
l'itération précédente.
4. Le client établit lui-même le plan de développement en affectant les différents scénarios
aux itérations à venir, de sorte qu'à chaque itération la somme du nombre de points des
scénarios choisis soit égale à la vélocité annoncée.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 14
PILOTAGE DU PROJET : LES PHASES
Première mise en production
Comme nous l'avons évoqué plus haut, la phase d'exploration se termine par la première
livraison du logiciel.
Cette première mise en production intervient aussi tôt que possible dans le projet : il faut
trouver le contenu fonctionnel minimal qui commence à avoir un sens pour les
utilisateurs, quitte à faire preuve d'imagination en amenant par exemple le nouveau
logiciel en complément d'un système existant dans le cadre d'une fonctionnalité bien
précise.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 15
PILOTAGE DU PROJET : LES PHASES
Livraisons suivantes
Les mises en production s'enchaînent ensuite à un rythme régulier, toujours fixé par le
client. L'objectif est d'obtenir un feedback très rapide sur le développement - en pratique
toutes les une à six itérations selon la complexité de déploiement du produit.
Le plan de développement est continuellement mis à jour si nécessaire pour tenir compte
des événements suivants :
L'équipe de développement progresse à une vitesse différente de celle prévue (dans le
bon ou le mauvais sens)
Le client décide de changer le contenu des itérations restantes. Il peut ainsi permuter
des scénarios en fonction de nouvelles priorités, ou encore remplacer certains
scénarios du plan par de nouveaux.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 16
PILOTAGE DU PROJET : LES PHASES
Suivi du projet
Le suivi « haut niveau » du projet peut par exemple s'appuyer sur des graphes inspirés de
celui représenté ci-dessous, dans lequel on note le nombre de points de scénarios restant
à implémenter.
Tous les scénarios imaginés par le client ne sont pas nécessairement représentés dans
ce graphe. Seuls y figurent ceux qui ont été retenus pour la prochaine grande échéance -
typiquement la prochaine version majeure du produit, ou encore la fin du projet pour un
développement de type forfait.
Cette courbe permet par projection d'estimer si les objectifs du projet seront tenus, et elle
permet aussi d'identifier certains « patterns » dans le fonctionnement de l'équipe (1) - par
exemple une tendance à la sur- ou sous-estimation des tâches.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 17
PILOTAGE DU PROJET : LES PHASES
Tests de recette automatiques
Pour chaque scénario planifié, un ensemble de tests de recette est écrit. Ces tests ont
pour but de vérifier de manière automatique (c'est-à-dire sans intervention ou
interprétation humaine) chacune des fonctionnalités demandées par le client. Le client
définit ces tests et participe éventuellement à leur implémentation, assisté pour cela d'un
certain nombre de testeurs.
Ces tests peuvent prendre plusieurs formes. Il peut s'agir de jeux de données, sous forme
par exemple de feuilles de tableur ou de fichiers XML, qui définissent une transformation
effectuée par le logiciel : « pour telle entrée, le logiciel doit produire tel résultat ». Il peut
s'agir également de scripts pour les cas plus complexes, ces scripts décrivant par exemple
des séquences d'interactions de l'utilisateur avec l'interface graphique du produit.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 18
LES PRATIQUES DE L’XP
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 19
LES VALEURS DE L’XP
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 20
LES VALEURS DE L’XP
Plus généralement, les pratiques XP sont sous-tendues par les quatre valeurs suivantes :
Communication : XP favorise le contact humain, la communication directe, plutôt que
le cloisonnement des activités et les échanges de courriers électroniques ou de
documents formels. Les développeurs travaillent directement avec la maîtrise
d'ouvrage, les testeurs sont intégrés à l'équipe de développement, etc.
Feedback : qu'il s'agisse d'itérations courtes, de livraisons fréquentes, de travail en
binômes ou de tests automatiques éxécutés en permanence, la plupart des 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. En particulier, les points de début d'itération
offrent à l'équipe le moyen de prendre du recul sur son fonctionnement et de
l'améliorer sans cesse au fil des itérations.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 21
LES VALEURS DE L’XP
Simplicité : comme nous l'indiquions au début de ce dossier, XP relève le défi suivant :
« que pouvons-nous arrêter de faire tout en continuant à créer efficacement un
logiciel qui réponde aux besoins réels du client ? ». Cette recherche de simplification
touche le processus lui-même, mais aussi l'outil fabriqué (la mécanique de
planification incite le client à focaliser les efforts sur les fonctions prioritaires) ou
encore la conception de l'application (guidée par un principe de « You ain't gonna need
it »).
Courage : il s'agit principalement du courage d'honorer les autres valeurs - celui de
maintenir une communication franche et ouverte, ou encore d'accepter et de traiter
de front les mauvaises nouvelles.
C'est en définitive sur ces critères qu'une équipe XP juge de sa maturité et trouve les
principaux axes de son amélioration.
Chapitre
02
3iAC
CS2I 4 M. ONDAPHE CHRISTIAN ARTHUR 22
