Introduction
Extreme Programming (XP) est une méthode légère, efficace, humaniste de développement de logiciels.
XP évite les lourdeurs des méthodes classiques. XP se situe entre l’assurance qualité traditionnelle (beaucoup de procédures, de documents) et le développement « cow boy » sans règles précises. XP n’impose pas la charge typique des mises en œuvre des procédures dans les organisations, procédures dans lesquelles les développeurs ne se reconnaissent pas toujours : document à écrire alors qu’il est visiblement inutile et vain de le maintenir, à l’inverse activités techniques, typiquement les tests, sous-évaluées, etc. XP est plus légère. XP est une discipline : certaines pratiques sont imposées et les développeurs doivent apprendre à les respecter, en particulier dans la gestion des tests.
XP est une méthode efficace. L’un des objectifs de l’Extreme Programming est de fournir au client le maximum de chaque semaine de développement. Pour cela, XP se concentre sur l’essentiel : développer un logiciel, nettoyé au mieux de ses bugs, dans des itérations (très) courtes pour plus de feed-back et donc de capacité de réaction. Les activités techniques sont réellement pilotées par les besoins des utilisateurs qu’ils ont eux-mêmes exprimés dans une forme très simple.
XP est une discipline humaniste. Les études menées sur les projets démontrent la difficulté du métier : en moyenne 80% (toute taille confondue) des projets ne respectent pas les délais et/ou le budget. A tel point que la question « comment développeriez-vous si vous aviez le temps ? » semble parfaitement déplacée, tant le phénomène de surcharge est un quotidien banal du développeur. Or, clients et développeurs sont des êtres humains et la fabrication de logiciels, dans ces conditions, ne satisfait ni les uns, ni les autres. XP s’inscrit dans ce contexte et tient compte de la dimension humaine des projets. Elle offre au développeur la capacité à accepter, accueillir les changements : dans les spécifications, dans architecture et les solutions techniques.
Cette méthode s’adresse aux équipes de développements constitués de 2 à 10 développeurs. Plus précisément, XP a été utilisée avec succès par des équipes de ces tailles. Au delà, certaines pratiques ne sont plus adaptées. Une itération de trois semaines ne semble pas réaliste pour une équipe de 100 développeurs, trois semaines étant approximativement le délai pour, tout simplement, contacter et informer l’ensemble des personnes… Le projet de gestion de la paie (le projet C3) chez Chrysler, est historiquement le point de départ de XP. Ward Cunningham et surtout Kent Beck sont à l’origine de cette méthode. Aujourd’hui, de nombreux intervenants participent à l’évolution de XP.
« Extreme Programming » ?
La méthode est très attentive à l’activité en dernière analyse essentielle dans un projet de logiciel : la programmation. Le codage produit la documentation principale : les fichiers sources. Pourquoi « extrême » programming ? Kent Beck, qui structure et présente XP, explique que les pratiques sur lesquelles est bâtie XP sont autant de boutons de contrôle… qu’il pousse au maximum. De ce point de vue, XP est la réunion cohérente de pratiques efficaces, telles que le test omniprésent, l’esprit d’équipe, le rôle prépondérant du client dans l’équipe, etc.
Parmi les (nombreux) risques inhérents à notre métier, citons en particulier :
· Planning non maîtrisés (ou bien tenus grâce aux efforts héroïques de l’équipe)
· Besoins mal identifiées, mal compris, changeants et donc valeur ajoutée faible pour le client
· Système livré mais non opérationnel, tant les bugs sont nombreux
Ces risques sont aujourd’hui théoriquement pris en compte dans les méthodes de développement. Toute la question réside dans la façon dont ils sont traités. Les démarches sont devenues itératives. Le prototypage de l’architecture est partie intégrante des cycles de vie. XP va plus loin : la durée de développement d’une release est de quelques mois au maximum, celle des itérations de trois semaines et des les tâches (que les développeurs choisissent) de trois jours tout au plus. Les besoins, exprimés par le client, sont classés par ordre de priorité. Le client fait partie intégrante de l’équipe de développement, il peut ainsi réagir immédiatement aux interrogations, incompréhensions des développeurs. Les tests systématiques, l’intégration continue, assurent que le système est constamment opérationnel : un dysfonctionnement provoqué par une évolution du source est tout de suite détecté et donc plus rapidement corrigé. Enfin, et peut-être est-ce le plus important, XP mise sur l’implication des développeurs (et leur donne les moyens) en tant que membres de l’équipe.
les valeurs de XP
XP possède quatre valeurs complémentaires qui tiennent compte des enjeux humains et commerciaux du développement d’applications :
· Communication
· Feed-back
· Simplicité
· Courage
Les pratiques de XP s’inscrivent dans le cadre de ces valeurs cardinales.
Probablement, la non-communication est la situation la plus grave qu’un projet ait à surmonter : comment un être humain peut-il réagir devant le fait accompli ? Quel est son dépit, alors que « s’il avait su… » ? Cela vaut pour tous les intervenants. Un client peut jouer sur des priorités ou le périmètre fonctionnel du système, dans la mesure où il est informé en temps utile. Un développeur peut prendre en compte un changement d’architecture futur si le client l’informe des décisions prises par un comité directeur, etc. Plusieurs pratiques dans XP ont pour finalité l’amélioration de la communication entre acteurs du projet :
· Entre développeurs (programmation à deux)
· Entre développeurs et gestionnaires (tests, évaluations)
· Entre développeurs et clients (tests, spécification des besoins)
Le feed-back est une deuxième valeur essentielle dans XP, c’est grâce au feed-back que le processus industriel du développement peut évoluer. Il devient aussi un élément de la communication. Par les tests unitaires, le développeur a un retour immédiat sur son système et plus précisément sur les modifications qu’il vient d’apporter. Les tests fonctionnels offrent au client une vision permanente de l’état du système. La planification sur des périodes courtes permet de prendre conscience plus vite de problèmes de délais. Un développeur intervient sur des tâches de trois jours maximum, ainsi, un dépassement est tout de suite détecté dans la réunion quotidienne d’avancement (le stand-up meeting). Un client s’attend à recevoir une version chaque trois semaines. Là encore, le dépassement est rapidement détecté. Le feed-back n’a de valeur que si le délai est court. Un développeur qui provoque une erreur de programmation dans un calcul retiendra plus facilement la « leçon » si le feed-back est immédiat. A l’inverse, la relation entre un mauvais choix et les problèmes qui en découlent peut être parfaitement invisible si la prise de conscience du problème intervient trop longtemps après la cause. Mettre en pratique XP passe nécessairement par l’application de ces pratiques.
Simplicité
La communication s’accommode mal de complications inutiles. XP possède une pratique essentielle : « quelle est la solution la plus simple qui pourrait fonctionner ? ». De ce point de vue, XP fait le pari suivant. La simplicité d’aujourd’hui revient moins cher et le surcoût éventuel dans le futur est compensé par le fait que, à propos de la solution compliquée, « vous n’en aurez probablement pas besoin ». Donc, en moyenne, mieux vaut faire simple.
Enfin, tout cela demande du courage. Le client doit avoir le courage de donner des priorités à ses besoins, de dire que tel besoin n’est finalement pas très clair… Le développeur doit avoir le courage de jeter du code qui sent mauvais… Le code a une odeur, quelquefois il faut le changer. Simplement, XP demande le courage de regarder le développement en face, sans tabou…
gestion de projet
Traditionnellement, les variables sur lesquelles jouent les gestionnaires sont : délais, coûts, qualité. XP propose une dimension supplémentaire : l’étendue de la release ou de l’itération. Dans la mesure où un problème de planning est détecté (et dans XP, cela se fait très tôt), quelle est la meilleure solution ? Dépasser les délais ? Diminuer la qualité ? Augmenter le coût ? Ou bien jouer sur le périmètre et conserver ce qui est le plus prioritaire ?
XP propose le « planning game » en tant que pratique de planification. Pourquoi « game » ? Car deux joueurs interviennent : le client, le développeur. Ici, « développeur » signifie « équipe de développement », gestionnaires compris. Toutefois ce sont les développeurs qui, dans XP, estiment et choisissent leurs tâches. L’objectif est de décider d’un plan global, très régulièrement mis à jour pour tenir compte de l’avancement réel du projet. La planification négociée s’inscrit dans les quatre valeurs de XP. Le planning game réunit les acteurs du projets : clients, développeurs, et donc facilite la communication. Le planning reste simple : n’est planifié que ce qui est nécessaire, sans détails inutiles (par exemple par rapport à l’unité de temps utilisée). Le planning game fait appel au courage : le développeur s’engage. Le planning game se décline en deux temps : planification des phases, planification des itérations.
Un cycle de vie XP est basé sur trois phases :
· Exploration
· Engagement
· Pilotage
Le projet est piloté par les besoins de l’utilisateur, décrits simplement sur des cartes « user story ». Ces cartes sont constituées d’un nom pour les identifier et d’un paragraphe de description de ce que l’utilisateur souhaite, sous forme de scénario. Les cartes sont au format A5 (approximativement).
L’exploration a pour but de fournir aux deux joueurs une bonne vision de ce que le système devrait faire. Pour cela, le client écrit un ensemble de user stories que le développeur estime grossièrement. L’engagement est la phase dans laquelle (par essais successifs) le client choisit l’étendue de la release, sa date de livraison ; le développeur estime les tâches associées aux user stories. Enfin, le pilotage est la phase dans laquelle, itération après itération, le planning est mis à jour, en fonction du développement. Dans cette phase, le client peut jouer sur la priorité des user stories, il peut même en remplacer. La première itération de pilotage est la création d’un prototype d’architecture. Dans cette phase, tous les développeurs participent quotidiennement au « stand-up meeting », réunion debout qui permet d’exposer la situation de chacun, les éventuelles demandes d’aide. Dans XP, un développeur ne peut pas refuser l’aide que lui demande un collègue.
Les méthodes classiques insistent aujourd’hui sur la nécessité de piloter les projets de façon itérative, en particulier par les cas d’utilisation de UML. XP va plus loin : elle recommande d’accueillir les changements, aussi bien en termes de spécifications que de conception. L’idée n’est donc pas simplement d’accepter les changements comme une fatalité avec laquelle il faut vivre. Les changements sont une opportunité d’évoluer : humainement, ils sont un prétexte de dialogue avec le client, techniquement, ils sont aussi un prétexte de dialogue avec des collègues, des spécialistes, des formateurs, etc. Pour cela, XP s’adresse à des développeurs qui aiment leur métier. Contrairement à une approche classique dans laquelle la stabilité de l’architecture est devenue une condition sinae qua non au lancement de la construction, XP admet que la conception du système va, naturellement, évoluer. Non pas que XP ne s’intéresse pas à stabiliser l’architecture mais simplement XP n’en fait pas une affaire d’état. XP s’adresse à des développeurs qui ont des talents « normaux », qui ne maîtrisent pas forcément les vingt design patterns du gang des quatre, etc.
Le client joue un rôle majeur dans le développement. XP est une méthode très attentive à cet aspect souvent sous-estimé du développement. Le client est responsable des besoins, de leur priorité, de leurs tests fonctionnels. Une lecture rapide de XP laisse croire que les besoins sont exprimés sur des cartes d’une demi-page. C’est faux. Une user story est un prétexte pour communiquer. Inévitablement, les besoins ne sont pas suffisamment précis. Le développeur est donc dans l’obligation de dialoguer avec le client pour obtenir les détails. Le client doit écrire des tests fonctionnels qui lui permettent de valider le système, fonctionnalité après fonctionnalité, cas dégradé après cas nominal, etc. De plus, le client fait partie intégrante de l’équipe. Il est donc constamment au courant de l’état réel d’avancement du projet
tests
Les tests jouent un rôle fondamental dans XP. Le client écrit les tests fonctionnels avant que les développeurs écrivent le code. Le développeur écrit le programme de test unitaire avant le code de l’application. Les répercussions de cette pratiques sont nombreuses et capitales. Développer des tests unitaires revient à concevoir le code testé. De plus, disposer des tests dès que l’on a codé permet d’obtenir très rapidement un feed-back. Imaginons un maçon qui construit un mur et qui doit ensuite inventer puis fabriquer un fil à plomb pour pouvoir le vérifier… Les tests sont aussi partie intégrante de la documentation : la programmation de conditions de tests est ainsi une indication sur la façon d’utiliser l’élément testé.
L’architecture et la conception occupent une place prépondérante dans XP. Contrairement à d’autres approches, ces activités techniques sont permanentes. Comme toujours, cet aspect du développement repose sur les quatre valeurs de XP. Communication et simplicité sont les guides des développeurs dans leurs rôles de concepteur ou d’architecte. Curieusement, l’architecture la plus simple n’est pas toujours la plus facile. Et les tests fonctionnels et unitaires sont omniprésents pour valider la conception. XP propose une démarche basée sur l’enchaînement suivant :
· Ecriture d’un test
· Conception, un peu
· Programmation, un peu
· Refactoring, un peu.
Le refactoring est la (re-)conception d’un code existant. Un « extrême développeur » consacre un peu de temps, chaque jour, au refactoring. Cela permet d’améliorer le code existant pour qu’il puisse mieux s’adapter au exigences de demain. L’une des clés de l’efficacité de XP réside dans les « petits » changements. La présence des tests permet de valider immédiatement ce petit changement.
XP utilise si nécessaire une technique d’analyse ou de conception, telle que la modélisation avec UML. Si UML permet de visualiser, spécifier, construire, documenter un système, XP reste prudente sur la documentation en UML. La majorité des diagrammes UML obtenus en analyse ou conception sont tout simplement jetés. XP a une préférence pour la technique des CRC Cards (Class Collaborators Responsabilities) qui permet plus de communication dans l’équipe. L’architecture est présentée sous forme de métaphore plutôt que dans d’interminables documents. Une métaphore a le mérite d’être plus synthétique et parlante. Comme tout dans le développement de logiciels, l’architecture changera. Le développeur XP y est préparé et accueille cela avec courage. Une étude superficielle de XP laisse à penser que la conception n’existe pas dans cette méthode. C’est faux. Simplement, c’est le code qui fait foi, il est validé par des tests automatisés, et non pas un ensemble de diagrammes et de textes.
XP préconise la programmation à deux : le « pair programming ». Toutefois, chaque développeur reste responsable de ses propres tâches. Le « pair programming » offre plusieurs avantages :
· Il améliore la communication dans l’équipe
· Les paires de programmeurs changent, chaque développeur finit par connaître l’ensemble des modules
· Le code est par définition systématiquement relu
· Les développeurs expérimentés transmettent de facto leurs savoir-faire, leurs connaissances du projet
· Pendant qu’un des programmeurs code, son équipier prend du recul sur les tâches en cours : meilleure conception, autres tests susceptibles d’échouer à effectuer par exemple.
Le développeur prépare et programme les tests du module qu’il va écrire, il écrit petit à petit, passe continuellement les tests, intègre plusieurs fois par jour. Le code ne lui appartient pas, au contraire, c’est l’équipe qui le possède. Parfois, un collègue demande la tenue d’une « quick design session ». Dans ce cas, l’extrême développeur consacre une heure ou deux à une étude par les CRC cards.
L’Extreme Programming peut être vu comme une déclinaison du Unified Process (UP), cadre général des cycles de vie itératifs, conçu par l’équipe à l’origine du langage UML. XP est piloté par les besoins des utilisateurs décrits sous forme de « user stories » et non pas de cas d’utilisation comme dans UP. L’un des avantages de cette technique est que l’utilisateur écrit vraiment ses besoins, alors que dans une approche plus classique Unified Process, le développeur retranscrit plus ou moins bien ce qu’il a compris ; le résultat est fondamentalement différent : les user stories sont vraiment une technique d’expression de besoins, les cas d’utilisation se cantonnent souvent à une translation des besoins. L’implication du client est également sans commune mesure, dans XP il est effectivement partie prenante dans le pilotage du projet, itération après itération. XP est centré sur l’architecture et plus généralement la conception, en particulier au travers du refactoring. Enfin, XP est particulièrement itérative : chaque itération dure de une à trois semaines, ce qui donne pour le moins six itérations de construction dans une perspective UP et pour un projet de quelques mois.
la documentation dans
XP
Probablement, le point de vue sur la documentation est la partie la plus délicate a priori. Là encore, il convient de ne pas rester sur une première (fausse) impression. XP n’est pas anti-documentation. Par contre, XP est très vigilante sur la pertinence des documents : combien de documents son réellement utiles dans leur totalité ? Comment ne pas s’insurger contre des documents que le développeur doit écrire alors que visiblement ils ne vont servir à rien ni à personne ? Toutefois, si le client impose la rédaction d’un document, cela devient une tâche pour un développeur, avec une estimation et donc un coût, comme pour toute autre activité. XP joue beaucoup sur la communication orale, au travers de pratiques telles que le pair programming, le « stand-up meeting », les tests fonctionnels et unitaires. Les user stories, les tests, les fichiers sources sont autant de documents sur le projet. Lorsqu’un document est demandé par l’équipe elle-même (et non plus par le client), cela devient une activité technique. XP recommande alors de bien étudier l’utilité effective du document avant de le refaire sur un deuxième projet. En tout état de cause, une documentation technique ne devrait pas excéder quelques dizaines de pages. Si la vue d’ensemble du projet ne peut pas être perçue dans chacun des fichiers source, un document qui est par définition une redondance par rapport aux fichiers impose une mise à jour souvent ignorée car trop lourde. Une solution consiste par exemple à mixer textuel, diagrammes et surtout liens vers des fichiers sources dans un document au format HTML, document d’une dizaine de pages maximum. Dans ce cadre, UML pourrait visualiser l’architecture si les métaphores ne sont pas utilisées.
adopter XP ?
XP renouvelle et enrichit le développement de logiciels. Au delà de l’adoption de XP, son étude permet de s’interroger sur notre métier de développeur d’applications. Comment développons-nous, prenons-nous plaisir à exercer ce métier dans les conditions qui sont les nôtres ? Comme dans toute méthode, adopter XP consiste avant tout à l’adapter, en retenant quelques pratiques parmi toutes celles proposées. Mais attention, si certaines d’entre elles sont optionnelles (comme le pair programming), d’autres sont obligatoires pour entrer dans le cercle des « extrême développeurs », en particulier la façon de tester le logiciel.
Toutes les équipes ne peuvent pas appliquer XP. Certaines conditions doivent être remplies :
· De 2 à 10 développeurs
· Possibilité de tester très rapidement le code
· Proximité du client ou de l’un de ses représentants
Un environnement dans lequel le résultat d’un test est obtenu au bout de plusieurs jours, voire plusieurs semaines est incompatible avec la rapidité de feed-back requise. De même, un client absent des développements ne permet pas de faire de l’XP. Les pratiques forment un tout cohérent : enlever l’un d’elles reste possible mais à condition que la cohérence soit conservée. Par exemple, XP ne préconise pas l’écriture d’un modèle de conception. Mais XP recommande – et impose – le refactoring du code et l’écriture de tests.
Probablement, le frein à l’adoption de XP (c’est aussi vrai pour Unified Process) reste la mutation qu’elle exige au niveau commercial. Le développement forfaitaire habituel (à haut risques pour tout le monde) n’est pas compatible avec ces méthodes basées sur une approche beaucoup plus industrielle du développement, les noms de phases en témoignent. Idéalement, XP suppose une souscription du client à des journées de développement.
Web
Web
www.extremeprogramming.org le site de Don Wells, une excellente introduction à XP
www.xprogramming.com le site de Ron Jeffries, l’un des concepteurs de XP, possibilité de télécharger les environnements de tests unitaires java, C++ , etc.
www.refactoring.com le site de Martin Fowler, le site consacré au refactoring
www.xp-france.org le site français consacré à l’Extreme Programming
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap le site de Ward Cunningham, partie consacrée à XP, avec un fonctionnement wiki wiki web, particulièrement agréable et une liste de projets XP sur :
http://c2.com/cgi/wiki?ExtremeProgrammingProjects
Mailing lists
La mailing-list française d’Extreme Programming: extremeprogramming-france@egroups.fr
(inscription à partir du site www.xp-france.org, ou www.egroups.fr)
Tests :
junit-functionaltests@egroups.com
Bouquins
Sur XP et ses pratiques
Kent Beck,
Addison-Wesley ISBN 201-61641-6
Martin
Fowler, Addison-Wesley ISBN 0-201-48567-2
Sur Unified Process et UML
Ivar
Jacobson, Grady Booch, James Rumbaugh,
Addison-Wesley ISBN 0-201-57169-2
(bientôt traduit en français chez Eyrolles)
Pierre-Alain
Muller, Nathalie Gaertner, Eyrolles ISBN 2-212-09122-2
"figures"
et encarts
-
cycle de vie
|
Exploration |
Engagement |
Pilotage |
|
Mieux cerner le périmètre du projet |
Planification et engagement réciproque du Client et du Développeur |
Construction de la release par des itérations de une à trois semaines |
- droits du
développeur
-
droits du client
(pour les deux cf site www.xp-france.org)
-
une user story
(on doit vous fournir un exemple manuscrit)
-
une crc card
(idem)
L’analyse ou la conception objet consistent à obtenir les classes et leurs relations, plus précisément les relations entre objets des classes. La technique des Class Responsabilities Collaborators (CRC) Cards est basée sur l’importance des responsabilités des classes et donc des objets dans le système. Les responsabilités d’une classe correspondent aux rôles que joue cet élément dans le système, aux contrats que les autres classes passent avec elle. Une classe est ainsi définie essentiellement par ses responsabilités qui se traduisent ensuite en attributs et opérations. Les collaborations correspondent aux échanges de messages entre objets, c’est l’aspect dynamique du système. La technique des CRC Cards suppose la disponibilité de cartes rigides (de dimension A5 approximativement) séparées en trois compartiments : le nom, les responsabilités, les collaborateurs de la classe. Chaque classe est représentée par une carte. Pratiquement, les développeurs sont réunis autour d’une table. Ils sont donc focalisés autour du même sujet, ce qui n’est pas la même chose que d’être regroupés autour d’un écran, les uns derrière les autres. Une user story offre un ou plusieurs scénarios. Quels sont les objets, donc les classes qui collaborent à ce scénario ? Progressivement, les cartes apparaissent, se complètent, au fur et à mesure de l’étude. Le crayon et la gomme viennent compléter le matériel indispensable. Les cartes sont physiquement disposées en fonction des collaborations. Un scribe en retrait écrit éventuellement un compte-rendu et surtout consigne la disposition des cartes sur la table pour la prochaine réunion. Ce type de travail collectif est particulièrement efficace : les fioritures mangeuses de temps que l’on connaît avec un modeleur UML n’existent pas. Techniquement, l’approche par les responsabilités permet d’obtenir de meilleures classes, plus cohérentes, moins couplées.
Copyright © 2000 - Thierry Cros
Contact par courriel