Téléchargez l`article : « L`Extreme Programming : réduire le coût du

best practices revues et corrigées
• L’Extreme Programming : réduire
le coût du changement dans
les projets informatiques
Par Christophe Legrenzi, chercheur et consultant international,
expert associé de Best Practices Systèmes d’information
Les approches traditionnelles de développement ont montré leurs limites. Les méthodes agiles commencent
à s’imposer, notamment pour réduire les cycles de développement et mieux satisfaire les utilisateurs.
U
n facteur d’échec courant dans les projets de développement
informatique est le manque d’implication des « clients » qui
vont utiliser l’application. Les approches traditionnelles, dont
le classique modèle en cascade (le fameux « V »), consistent à
recueillir l’ensemble des besoins en début de projet, pour ensuite
développer toutes les fonctionnalités afférentes. Entre l’expression
initiale des besoins et la livraison finale, il arrive cependant que le
contexte ait changé, modifiant les exigences de départ.
Il arrive également que certains besoins aient été mal formulés
par les clients ou mal compris par les équipes chargées du projet :
les écarts en résultant sont alors identifiés au mieux en phase de
recette, voire après la livraison. Cela entraîne mécontentement
et insatisfaction chez les utilisateurs, ainsi qu’une surcharge de
travail pour les équipes projet, quand tout cela ne se traduit pas par
l’abandon pur et simple du projet. C’est pour pallier ces difficultés
que sont apparues les méthodes agiles, parmi lesquels l’Extreme
Programming, mais aussi Scrum ou la plus récente Crystal Clear,
pour ne citer que les méthodes formalisées. Depuis quelques
années, le lean management est également considéré comme
une méthodologie agile applicable aux projets informatiques.
1. Présentation de
l a Best Practice
L’Extreme Programming, XP en abrégé, est une méthode de
développement agile créée en 1996 par Kent Beck, Ward
Cunningham et Ron Jeffries, dans le cadre du projet Chrysler
Comprehensive Compensation (C3) mené par le groupe automobile
Chrysler.
Au départ, le projet faisait intervenir trois équipes différentes,
qui travaillaient dans une logique de compétition plutôt que
de coopération. Cette organisation avait ralenti le projet, les
dépassements de délais et de budget menaçant. Par ailleurs, le
code ainsi produit s’était avéré redondant et trop complexe pour
garantir la fiabilité de l’application. Kent Beck fut recruté par
Chrysler alors que le projet avait été gelé, le temps d’établir un
diagnostic. Le verdict fut sans appel, l’application telle qu’elle
avait été développée ne pouvait être mise en production. Kent
Beck fut alors rejoint par d’autres consultants et experts du
développement agile, afin de remettre le projet sur les rails.
Son idée était d’identifier les pratiques qui faisaient avancer
et celles qui freinaient le développement, afin de promouvoir
autant que possible les premières et de réduire les autres. Parmi
les avancées identifiées, le partage du référentiel de code entre
toutes les équipes fut une étape stratégique pour développer la
coopération.
Avec un seul et même référentiel pour tous, chacun pouvait
intégrer du code et en modifier à sa guise sans pour autant perdre
les versions précédentes. En outre, cela incitait chacun à écrire
des tests pour son code, afin d’être sûr que les changements
introduits par les autres n’en modifiaient pas l’exécution.
Grâce à ces bonnes pratiques, le projet rattrapa son retard et
fut finalisé dans les temps. L’expérience issue de ce projet fut
ensuite appliquée à d’autres, permettant de vérifier la pertinence
des principes de ce qui allait devenir l’Extreme Programming. La
méthode fut officialisée en 1999 avec la publication de l’ouvrage
Extreme Programming Explained de Kent Beck.
Le premier objectif de l’Extreme Programming est de réduire les
coûts du changement en introduisant de la flexibilité dans le
processus de développement. Pour cela, la méthode reprend
des règles simples, connues dans l’industrie du logiciel, mais
en les poussant à l’extrême : par exemple, la revue de code est
faite en permanence, les tests sont systématiques, la simplicité
est privilégiée à tous les niveaux et les cycles de développement
sont très rapides pour s’adapter au changement.
Les projets basés sur l'XP sont constitués de séries d’itérations
courtes, n’excédant pas quelques semaines. Ils sont gérés comme
une démarche collective, impliquant l’ensemble de l’équipe
ainsi que le client. Chaque itération débute par l’exploration
des scénarios clients, ces scénarios étant ensuite traduits en
tâches réparties entre les membres de l’équipe. Chacune des
fonctionnalités développées doit être testée avant de livrer une
version, l'XP préconisant d’ailleurs d’écrire les tests avant d’entamer
le développement proprement dit. Le projet s’achève quand les
clients ne sont plus en mesure de fournir de scénario.
Les projets basés sur l'Extreme Programming mettent en
œuvre un ensemble de bonnes pratiques :
12 décembre 2011 - N° 78 - Best Practices - Systèmes d’Information • 9
best practices revues et corrigées
• Un représentant du client doit être présent sur le site de
développement, afin de permettre un échange régulier avec
l’équipe et de répondre aux questions.
• Jeu du planning : le client crée des scénarios basés sur ce
qu’il souhaite obtenir, scénarios qui sont ensuite évalués par
l’équipe. Une fois ces estimations effectuées, le client choisit les
scénarios qui vont être implémentés en fonction de ses priorités
et du temps disponible.
• Intégration continue : dès qu’un élément est prêt, il est
immédiatement testé et intégré pour éviter d’avoir à intégrer
l’ensemble des éléments en fin de projet, avec le risque de
découvrir à ce moment-là seulement des problèmes.
• Des livraisons petites mais fréquentes. La première
livraison est généralement la plus importante.
• Rythme soutenable : dans la logique de l’Extreme
Programming, le besoin d’heures supplémentaires signale un
problème de planning. C’est donc ce dernier qu’il faut revoir,
l’efficacité des équipes décroissant si celles-ci sont fatiguées.
• Tests : les tests sont essentiels dans la démarche d’Extreme
Programming. Pour chaque nouvelle fonctionnalité, les
développeurs écrivent un test unitaire conservé tout au long du
projet. L’ensemble de ces tests sont relancés à chaque modification
pour détecter immédiatement les dysfonctionnements. Des
procédures de tests fonctionnels sont par ailleurs écrites en se
basant sur les scénarios clients. Une fois que la livraison en
cours passe l’ensemble des tests fonctionnels (recette), elle est
considérée comme terminée.
• Conception simple : plus une application reste simple, plus
elle est aisée à faire évoluer ultérieurement. Il n’est pas nécessaire
de prévoir d’autres fonctionnalités que celles nécessaires pour
les scénarios choisis.
• Utilisation de métaphores : tout membre de l’équipe
doit comprendre la logique de l’application, chacun est donc
impliqué dans sa conception et son évolution. Des analogies
et métaphores sont utilisées pour s’assurer que tout le monde
comprend aisément le système en cours de développement.
• Réingénierie du code (refactoring) : il s’agit de retravailler
régulièrement le code existant sans introduire de nouvelles
fonctionnalités, simplement dans le but d’en améliorer la
structure, la lisibilité ou les performances.
• Appropriation collective du code : tous les membres de
l’équipe ont le même niveau de responsabilité sur l’application
et les mêmes droits. Chacun peut faire des modifications du
code qu’il n’a pas développé, les tests permettant de vérifier si
tout fonctionne.
• Normes et conventions de dénomination : celles-ci sont
indispensables dès lors que chaque développeur peut intervenir
sur le code d’un autre.
• Programmation en binôme : les développeurs travaillent
par deux, l’un écrivant le code, l’autre lui suggérant des
options ou l’aidant à identifier d’éventuels problèmes. Les
binômes changent régulièrement. Ce mode de travail favorise
en outre le partage des connaissances.
Le s v ale u rs de l’E xt re me P ro g ramming
Dans certains cas, l'XP peut également favoriser une fuite en
avant, les équipes étant constamment en train de développer
de nouveaux scénarios et les versions n’étant jamais gelées. À
terme, une telle situation peut coûter plus cher que les approches
traditionnelles. Pour éviter cette dérive, il est important que le
client ait bien compris l’intérêt d’une méthode comme XP et
sache se montrer raisonnable dans les scénarios proposés.
• Communication : celle-ci est primordiale au sein de
l’équipe de développement, mais aussi avec les clients et
les responsables du projet.
• Simplicité : prévoir d’emblée l’ensemble des
fonctionnalités génère des pertes de temps. Au contraire,
privilégier la simplicité permet de créer des applications
aisées à faire évoluer.
• Retour d’information (feedback) : les tests interviennent
à tous les niveaux (unitaire, fonctionnel, intégration). Ils
permettent à chaque étape de savoir si le code produit
fonctionne.
• Courage : dans un projet, l’équipe peut parfois être
amenée à prendre des décisions difficiles, comme de
modifier l’architecture initiale ou de supprimer du code.
Le courage est nécessaire pour faire ces choix.
• Respect : un aspect essentiel dans toute démarche
collaborative.
10 • 2. Regard critique
L’Extreme Programming est une méthodologie créée pour pallier
les dysfonctionnements des approches traditionnelles. Elle ne
convient pas à tous les types de projets et un usage dans des
contextes inadaptés présente un certain nombre de risques.
Ainsi, du fait de ses itérations courtes, la méthode n’est pas
vraiment adaptée au développement des applications cœur de
métier, dont la durée de vie est d’au moins huit à douze ans. La
performance opérationnelle de l’entreprise dépendant fortement
de ces applications et celles-ci n’ayantt pas vocation à changer
fréquemment, l’XP est très rarement utilisé dans ce cadre.
De la même manière, avec l’XP, peut apparaître une tendance
à développer des fonctionnalités à faible valeur ajoutée pour
l’entreprise, en laissant trop la main aux utilisateurs : la somme
des optima individuels aux yeux des utilisateurs ne donne jamais
mathématiquement l’optimum global pour l’entreprise.
Il existe également un risque opérationnel quand les fonctions
études-développement ne sont pas clairement séparées de la
mise en production-exploitation. C’est une bonne pratique qu’il
faut respecter autant que faire se peut. Par ailleurs, la méthode
imposant de travailler en binôme et dans un cadre collectif peut
susciter des blocages culturels dans les organisations habituées
Best Practices - Systèmes d’Information - N°78 - 12 décembre 2011
best practices revues et corrigées
Métaphores du système
iè
re
ve
rs
liv
ra
is
D
Pl
an
Planification
release
er
n
de
Scénarios
utilisateur
Spécifications
io
Itération
n
on
Bugs
A
cl ppr
ie o
nt ba
ti o
Nouveau scénario
utilisateur
n
Scénarios de test
Tests
d'acceptation
Transition
architecturale
Estimations
incertaines
Estimations
confiantes
Transition
à d’autres modes de travail. Dans de tels cas, une résistance
au changement est possible. Enfin, la méthode ne met pas
forcément en avant la documentation du projet. Or une faible
documentation entraîne une dépendance forte à l’égard des
individus ayant développé l’application.
Il existe un risque réel de fragilisation du code et de
construction « d’usines à gaz » si la méthode n’est pas bien
suivie, en particulier les exigences de simplicité, les petites
releases et le refactoring. Souvent, l’XP est utilisé conjointement
avec des technologies de type Java ou autres qui ne sont pas
toujours en phase avec les enjeux de performance requis
par le métier, comme les temps de réponse, la simultanéité
des accès, etc. Pour pallier ce risque potentiel, il faut éviter
d’être « dogmatique » en matière d’environnements de
développements et ne pas oublier ce type d’exigences dans les
scénarios. C’est d’ailleurs souvent plus facile à dire qu’à faire,
surtout avec des équipes internes formées à un outil précis.
3. Que faire ?
Quelques pistes de solutions
Une fois les risques et les bénéfices d’une méthode comme l'XP
bien compris, il est possible d’identifier les cas où les entreprises
peuvent en tirer le meilleur parti.
Il va de soi que les applications amenées à changer fréquemment
sont la meilleure cible pour des projets menés selon l’XP. Cela
dit, il est plus facile de mettre en œuvre la méthode sur de
nouvelles applications que sur des applications existantes, cellesci n’ayant pas toujours été écrites d’une manière simple.
L’Extreme Programming fonctionne particulièrement bien sur
des projets de taille petite ou moyenne, avec des équipes
Prochaine
itération
Le cycle de développement de
l’Extreme Programming
proportionnées : au-delà d’une vingtaine de développeurs, il
devient en effet difficile de fonctionner de manière efficace
avec les principes décrits précédemment. Sur ces projets, il est
important de prévoir des points de contrôle en amont (expression
des besoins) et en aval (recettes) afin de prévenir les risques de
dérives liées à des besoins trop fluctuants.
En outre, les clients ne pensent pas toujours dans leurs scénarios
à exprimer certains enjeux non fonctionnels, mais importants
pour le métier, comme les temps de réponse ou le nombre
d’accès simultanés requis. Là aussi, un cadrage préalable permet
de ne pas oublier ces exigences.
La méthode peut également s’avérer précieuse pour les phases
de prototypage, permettant de montrer rapidement au client une
application fonctionnelle et d’échanger avec lui sur les différents
scénarios possibles. Dans ce cas, il faut néanmoins faire attention
à la maturité du client concernant ces méthodes, présenter une
application trop simple à des utilisateurs peu au fait de ces
approches pouvant s’avérer contre-productif.
De manière générale, un certain nombre de principes de l’Extreme
Programming peuvent être utilisés dans le cadre d’approches
plus traditionnelles, afin d’améliorer certains aspects comme la
communication, la diffusion des connaissances ou les tests. Enfin,
l’Extreme Programming peut être utilisé en complément d’autres
méthodes agiles. Geoffrey Bourne, spécialiste du développement
agile travaillant dans le secteur financier, met notamment
en avant la complémentarité de l’Extreme Programming avec
Scrum et le lean IT, chacun s’adressant à un niveau différent de
l’organisation. Le lean IT répond ainsi aux enjeux stratégiques
du management, tandis que Scrum s’adresse aux chefs de projets
en leur offrant de nombreux outils pour gérer l’organisation des
équipes. l'XP est quant à lui un outil tactique, qui trouve sa place
directement au sein des équipes de développement. •
12 décembre 2011 - N° 78 - Best Practices - Systèmes d’Information • 11