ICSSEA 2001-8 Bossavit

 

Extreme Programming

 

Laurent Bossavit

 

Oza

32, rue d’Hauteville

75010 Paris, France

Tél : +33153340606 – Télécopie : +33144830468 – Mél : laurent.bossavit@oza.fr

 

Résumé : Cet article présente le point de vue d’un développeur de la « e-économie » sur la démarche de développement appelée Extreme Programming ou XP. Deux problèmes surviennent fréquemment dans ce secteur : la perte de contrôle sur les délais de réalisation des projet, avec pour conséquences habituelles de nombreuses heures supplémentaires et les effets d’épuisement qui s’ensuivent ; et une absence de maîtrise de la qualité des logiciels produits, entraînant au-delà des problèmes de délais une perte de confiance de la part des utilisateurs, des clients, et des développeurs eux-mêmes. Le modèle itératif proposé par XP, ainsi que son mode de planification exclusivement selon des critères fonctionnels, permettent d’identifier rapidement les risques de dépassement de délais. XP insiste sur l’écriture de tests automatisés comme une partie indissociable et motrice du processus de développement, pilotant à la fois la conception détaillée et la validation finale du logiciel ; la notion de qualité y occupe une place de premier plan. Ces deux caractéristiques associées font d’XP un contexte dans lequel les bénéfices des techniques du génie logiciel, et en particulier des méthodes de programmation objet, peuvent être évalués et mis en pratique.

 

Mots clés : extreme programming, gestion de projets, qualité logicielle

 

Abstract: This paper presents an approach to software engineering known as XP (Extreme Programming), from the personal perspective of a developer of the “e” variety.  I will mention two problems endemic to that community - loss of control over project schedules, usually leading to significant overtime and “burn-out”; and loss of control over software quality, with consequences such as undermined user, stakeholder and developer confidence that go well beyond impacting project schedules. The iterative development model of XP, together with its exclusively business-oriented effort metric, allow schedule problems to be identified “early and often”.  Its focus on writing automated testing code as a seamless part of the development process, to drive low-level design as well as to provide formal validation of the resulting system, brings quality to the fore.  These two characteristics combine to form a context in which the benefits of software engineering techniques - object-oriented methods in particular - may be empirically assessed and put to practical use.

 

Keywords: extreme programming, project planning, software quality

 

1. Introduction

 

Des études souvent citées – le rapport Chaos [1] du Standish Group fait référence, mais de nombreux observateurs rapportent des conclusions identiques – montrent que la plupart des projets informatiques sont terminés en retard et dépassent leurs budgets initiaux – quand ils sont terminés.

 

Ces phénomènes ne sont pas nouveaux et ne sont certainement pas limités aux projets et aux entreprises dont l’activité repose sur les « nouvelles technologies » en général et l’Internet en particulier. Dans ces secteurs peut-être plus qu’ailleurs, ils peuvent cependant se manifester de façon particulièrement sinistre – pour l’entreprise elle-même, dont la survie est liée au succès de ces projets, mais aussi par voie de conséquence sur les salariés qui y subissent des pressions importantes pour atteindre quel qu’en soit le coût personnel – heures supplémentaires, nuits blanches, ou travail le week-end – des objectifs… qui ne seront en général pas réalisés.

 

Ces mêmes études identifient plusieurs facteurs critiques comme étant à l’origine de ces échecs : les plus fréquemment mis en avant sont le manque d’implication des utilisateurs, des clients ou de l’encadrement des équipes concernées ; une analyse insuffisante ou incomplète des besoins ; ou une mauvaise planification. Curieusement, un problème pourtant bien connu des utilisateurs, des clients et des intervenants des projets informatiques y est plus rarement cité : celui de la qualité des logiciels et des systèmes.

 

En réunissant sous le terme « qualité » l’adéquation du produit livré aux besoins de ses utilisateurs, mais également les aspects plus techniques de fiabilité et d’absence d’anomalies ou bugs, il est pourtant clair que cette dimension des projets est inévitablement liée à la maîtrise des délais. Le temps consommé à réaliser une partie d’un projet qui ne correspond pas aux besoins se soustrait au temps réellement productif. Le temps nécessaire à corriger des défauts ou des anomalies  peut augmenter de façon imprévisible la durée d’un projet.

 

Les critères usuels qui permettent de juger du succès d’un projet comprennent généralement le coût, les délais, et le périmètre fonctionnel du logiciel produit. Les études mentionnées plus haut s’appuient sur des mesures quantitatives de ces différents critères – mais aucune mesure de la qualité fournie par les projets étudiés n’y est citée. Cette absence est remarquable, et soulève plusieurs questions : quelles sont les relations entre la qualité d’un projet et les autres paramètres qui le caractérisent ? Comment la définir ? Faut-il modifier notre approche des projets informatiques pour tenir compte de cet aspect ?

 

Dans le contexte d’une économie mondiale volatile, de plus en plus orientée vers les échanges d’information et dépendante de technologies en perpétuelle évolution pour traiter ces informations, on voit actuellement émerger une conception différente des projets informatiques, celles des « processus agiles », parmi lesquels Extreme Programming (ou XP) qui met particulièrement en lumière ces questions.

2. La situation dans les métiers de l’Internet

 

Le contexte économique et technique dans lequel évoluent les entreprises de la « nouvelle économie » est caractérisé – comme d’ailleurs, par le passé, le secteur du multimédia – par plusieurs facteurs qui rendent particulièrement sensibles les problèmes évoqués plus haut.

 

D’une part, les règles économiques en vigueur imposent des délais réduits pour la production des logiciels et des systèmes : l’avantage est, dit-on, au premier arrivant sur le marché – dont la clientèle doit le plus rapidement possible atteindre une masse critique de façon à se placer hors d’atteinte de la concurrence… Si les déboires récents du secteur ont mis un bémol à ces courses effrénées, il n’en reste pas moins que l’économie de l’information est celle de l’instantané : la capacité à produire plus rapidement reste un avantage.

 

Par ailleurs, même lorsque cet avantage au premier arrivant n’entre pas en ligne de compte dans la stratégie d’un projet donné, les besoins des clients et les utilisateurs concernés par le projet évoluent au rythme imposé par le secteur : leur propre environnement est changeant, par conséquent il n’est pas rare que des orientations nouvelles soient décidées en cours de projet.

 

Enfin, l’environnement technologique de ces projets est lui-même variable et parfois mal connu ; il se compose d’une véritable mosaïque de systèmes, de normes, de matériels et de langages. Des modèles commerciaux différents s’y affrontent, de l’édition classique à la diffusion Open Source en passant par la fourniture de services déportés (Application Service Providers).

 

Dans cet environnement, il s’avère difficile d’évaluer en pratique la pertinence de méthodes et de techniques qui permettraient de garantir une maîtrise, et des délais d’un projet, et de sa qualité. L’offre en ce domaine, malgré des avancées théoriques et des convergences notables au cours des dernières années, reste elle-même sinon pléthorique, du moins largement diversifiée : elle recouvre de nombreux choix différents en matière de cycle de vie du projet, de formalismes pour l’acquisition ou l’expression des besoins, de principes d’architecture ou de conception. S’assurer de l’adéquation entre ces choix méthodologiques et les environnements techniques tient du casse-tête : les techniques de conception objet sont-elles adaptées à PHP ? avec quelle notation modéliser un serveur e-business à base d’XML ?

 

Dans mon expérience, deux comportements probablement typiques sont observés en réaction à ces contraintes. Le premier consiste à évacuer le problème, en n’adoptant « par manque de temps » que les rudiments d’une démarche structurée ou des éléments dissociés de celle-ci. Le lancement d’un projet donne lieu à la rédaction d’un cahier des charges initial, rarement soumis à une analyse approfondie, et d’une planification dont les délais sont souvent dictés exclusivement par des impératifs commerciaux, et généralement trop rapprochés au regard du périmètre fonctionnel visé. Les équipes techniques sont alors chargées de la réalisation, qui s’effectue au gré des compétences et des démarches individuelles. La validation du travail fourni n’intervient généralement qu’en fin de projet, dans le meilleur des cas lors d’une période planifiée de « beta test ».

 

A l’inverse – et généralement en réaction à des résultats décevants obtenus sur un projet précédent conduit selon le premier schéma – d’autres structures de projet se voient imposer un excès de formalisme et une organisation qui cherche à reproduire les caractéristiques extérieures de méthodes perçues comme rigoureuses, indépendamment des bénéfices concrets retirés – ou pas – de ces outils. Cette attitude que Steve McConnell [2] qualifie de « Cargo Cult Software Engineering » conduit à générer une quantité considérable de documents d’analyse et de conception, de modèles excessivement détaillés en UML ou une autre notation, mais plus rarement à des résultats probants.

3. Délais et qualité

 

Quels sont les effets de ces comportements en termes de maîtrise des délais et de maîtrise de la qualité ? Sans vouloir donner une définition formelle du terme, qui est lui-même sujet à débat, il est utile de faire une distinction entre deux aspects de ce que nous regroupons intuitivement sous le terme « qualité ».[1] Les caractéristiques observables d’un logiciel ou d’un système – est-il adapté aux besoins, remplit-il toutes les fonctions auxquelles il est destiné, contient-il peu ou beaucoup d’anomalies – font certainement partie de cette notion, sans toutefois l’épuiser ; on peut parler de qualité externe.

 

Les caractéristiques intrinsèques d’un programme – plus exactement de son code source – rentrent également en ligne de compte dans notre appréciation intuitive de sa qualité. On peut parler de qualité interne pour désigner ces attributs, qui concernent plus directement les programmeurs : la lisibilité d’un programme, le fait que sa structure permette ou non de le modifier facilement, sa conformité à des principes plus abstraits tels qu’un couplage minimal et une cohésion maximale entre ses composants, voire des critères subjectifs tels que son élégance.

 

Les risques présentés par une démarche de réalisation « anarchique » concernent plus directement la qualité interne. En l’absence d’une réelle méthode de conception la structure d’un programme évolue inévitablement vers une architecture du type « Big Ball Of Mud » [3]. Les premières périodes de l’implémentation donnent un faux sentiment de rapidité : les fonctionnalités sont en apparence complétées à un rythme satisfaisant. Mais à mesure que le projet approche les étapes majeures de livraison, les efforts d’implémentation commencent à être ralentis, d’une part par la difficulté de maintenance intrinsèque à des programmes mal structurés, d’autre part par la quantité croissante d’efforts mobilisés pour la correction d’anomalies. Les aspects externes de la qualité du projet sont alors compromis, de même que le respect des délais.

 

Les risques engendrés par une démarche par trop formaliste sont différents, mais aboutissent en définitive aux mêmes effets. Une lecture au premier degré des modèles « classiques » de conduite des projets informatiques conduit en effet à découper ceux-ci en un certain nombre de phases distinctes, effectuées en séquence, et caractérisée par des activités différentes : analyse des besoins, spécifications, conception, implémentation, et tests. Si chacune de ces phases a pour objectif de produire des « livrables » qui permettent en principe de suivre l’avancement des travaux, le seul dont la qualité puisse être validée de façon concrète et objective est l’implémentation. Une organisation en phases successives retarde donc considérablement l’évaluation de la qualité externe ; par ailleurs, toute modification dans l’expression des besoins nécessite de revenir sur les résultats des phases antérieures, ce qui tend à raccourcir encore le temps restant à la phase d’implémentation.

 

Dans les deux cas, la maîtrise des projets est rendue difficile par l’absence d’une relation linéaire entre le temps consommé par un projet et la valeur produite par ce projet – la proportion fournie (et implémentée sans anomalies) du périmètre fonctionnel prévu.

4. Extreme Programming : une approche minimaliste

 

La philosophie sur laquelle est basée Extreme Programming consiste à n’intégrer dans une démarche de conduite de projets qu’un nombre réduit d’éléments – des pratiques éprouvées ou « best practices » de l’industrie du logiciel – dont l’efficacité n’est pas remise en cause par des changements fréquents dans l’expression des besoins ou par l’instabilité de l’environnement technologique, mais au contraire capables d’en tirer profit.

 

Pour Extreme Programming, les éléments critiques d’un projet sont ceux mentionnés plus haut – la maîtrise des délais et la maîtrise de la qualité. Les activités pratiquées au cours d’un projet – par les intervenants techniques mais aussi par les autres acteurs du projet, clients et encadrement – ne sont jugées utiles que dans la mesure où elle contribuent à fournir un produit logiciel ou un système capable de répondre aux besoins de l’entreprise ou de ses clients ; permettent de garantir l’adéquation de ce qui est fourni à ces besoins ; permettent d’obtenir des informations fiables sur les délais ; et permettent de réagir à des changements imprévus.

 

4.1. Maîtrise des délais : la planification itérative

 

Pour une équipe pratiquant XP, il est possible de planifier un projet sans disposer d’une expression formelle et détaillée de l’ensemble des besoins. Les intervenants techniques du projet collaborent avec le client ou son représentant pour décomposer les besoins fonctionnels en blocs atomiques appelés « user stories ». Une « user story » est analogue à un cas d’utilisation UML en ce qu’elle décrit le plus souvent une interaction avec le système, mais plusieurs différences notables sont à relever.

 

D’une part, le niveau de détail d’une « user story » est moindre que celui d’un cas d’utilisation ; elle comportera en principe un titre et une ou deux phrases décrivant de façon synthétique un scénario principal, en omettant par exemple les conditions d’erreurs et les traitements associés. D’autre part, leur granularité – la fraction d’utilité qu’elles représentent en termes fonctionnels – doit être choisie en fonction du mode de planification itératif adopté par XP : l’estimation de l’effort à fournir pour l’implémentation d’une « user story » ne doit être ni très inférieur à la durée d’une itération, ni supérieur ou sensiblement du même ordre de grandeur. Lorsqu’un besoin est formulé qui ne correspond pas à ces contraintes, il devra être morcelé si l’effort estimé est trop important – ou au contraire agrégé à d’autres besoins représentant des efforts peu significatifs.

 

Par « itération », on entend dans XP une période de durée fixe qui sert de rythme de base à la conduite d’un projet. Celle-ci est généralement de deux ou trois semaines pour des projets de taille moyenne, ou pour des projets soumis à des changements fréquents. Cette période de référence permet un calcul simple pour estimer en première approximation la durée d’un projet sans recourir à une analyse exhaustive : le nombre d’itérations prévu sera égal au total des estimations d’effort affectées à chaque « user story », divisé par la capacité de production des programmeurs pour une itération. (Pour N programmeurs travaillant en itérations de deux semaines sur un projet dont les « user stories » représentent un total de M semaines de travail, la durée est de M/2N itérations.)

 

A la fin de chaque itération, la planification d’ensemble du projet est réévaluée en fonction des résultats produits au cours de l’itération ; en comptabilisant pour chaque « user story » entièrement implémentée le nombre de semaines de travail qui lui était affectée, on obtient une mesure approximative de la productivité qu’on utilise alors pour refaire le calcul ci-dessus : pour P semaines de travail « produites » au cours de la précédente itération, et M semaines de travail restant à fournir, on prévoira une durée de M/2P itérations. On appellera P la vélocité du projet.

 

La prévision de l’effort à fournir pour implémenter une « user story » est du seul ressort des programmeurs, qui l’estimeront subjectivement, en fonction de leur expérience et de leurs compétences propres. L’imprécision de ces estimations ne constitue pas un problème : le plan d’ensemble étant réévalué dès la première itération pour tenir compte de la production réelle, les erreurs systématiques – surestimation ou sous-estimation – seront compensées ; par ailleurs, l’expérience acquise permettra aux programmeurs d’affiner leurs estimations à mesure que le projet se poursuit.

 

Les évolutions de la vélocité sont bien entendu discutés avec les intervenants non techniques du projet, clients et encadrement : l’objectif de ce mode de planification est de donner toutes les informations nécessaires pour anticiper le plus tôt possible d’éventuels dérapages et par conséquent de permettre les décisions stratégiques qui constituent le pilotage d’un projet : ces décisions peuvent impliquer l’abandon du projet afin de limiter les dégâts, l’adjonction de ressources supplémentaires, ou la limitation du périmètre fonctionnel prévu.

 

Outre l’expression de ses besoins, un autre rôle du client dans XP contribue à la maîtrise des délais : l’identification des « user stories » qui contribuent le plus à la valeur du projet. La planification du projet n’est pas déterminée par des impératifs techniques, mais avant tout par la valeur relative de chaque composante des besoins.[2] Ce principe conduit à diminuer progressivement les risques afférents aux dépassements de délais à mesure que le projet progresse : s’il est nécessaire de réduire le périmètre fonctionnel pour remplir des objectifs de délais, ce sont les fonctionnalités les moins importantes qui en feront les frais.

 

4.2. Maîtrise de la qualité externe : une validation permanente

 

Le mode de planification proposé par XP permet en principe d’identifier rapidement – aux échéances de chaque itération dans le pire des cas – les retards engendrés par une baisse de qualité ; à contrario, il permet donc d’évaluer les bénéfices concrets apportés par les techniques adoptées pour améliorer cette qualité. Encore faut-il qu’il soit accompagné d’outils permettant d’émettre des jugements objectifs en matière de qualité, tant en termes de qualité externe qu’en termes de qualité interne. Ces outils sont présent en XP sous une forme également minimale, mais des plus efficaces : les tests automatisés.

 

Par un test automatisé, on entend dans XP un script, un programme, ou toute spécification dans un langage formel interprétable par un programme, qui a pour effet de vérifier le comportement correct du logiciel ou du système produit par le projet. Ces tests doivent pouvoir être exécutés en masse, sans aucune intervention manuelle, et émettre un diagnostic binaire : OUI, ce comportement est correct, ou NON, le logiciel présente une anomalie.

 

Pour chaque « user story » concernant un élément du besoin, quelle que soit la nature de ce besoin, XP exige que l’équipe produise un test automatisé. Une « user story » n’est pas elle-même l’expression d’un besoin ; elle n’est qu’une façon de représenter le besoin au cours des activités de planification. [3] L’expression formelle du besoin se fait sous la forme du test, dont la formulation exacte est sous la responsabilité du client ou de son représentant.

 

Selon les projets, plusieurs cas de figure se présentent : les tests peuvent être exprimés dans un premier temps sous la forme d’un scénario de test classique comme peut en comporter un cahier de recette, avant d’être automatisés par les intervenants techniques de l’équipe, ou, pour apporter plus de garanties, par une équipe d’assurance qualité spécialisée. Les tests peuvent également être rédigés directement par les clients s’il est possible de le faire dans une notation formelle accessible.

 

Ces tests sont appelés tests fonctionnels ou encore tests de recette, et ont précisément le même objectif que des jeux de tests manuels habituellement formulés dans un cahier de recette : ils constituent un « régime de la preuve », le client doit pouvoir se satisfaire que si le système fourni effectue l’ensemble des tests avec succès, il correspond à ses besoins.

 

Les tests de recette sont fournis avant que ne commence le travail de réalisation concernant la fonctionnalité décrite, ou à tout le moins au cours de l’itération pendant laquelle celle-ci est planifiée. C’est là un des aspects paradoxaux d’XP, mais il est essentiel pour rendre possible la démarche de planification. A la fin de chaque itération, ne sont prises en compte dans le total produit que les « user stories » pour lesquelles un test de recette peut être effectué avec succès.

 

Cette inversion de la chronologie habituelle – les tests sont généralement effectués en fin de projet – est caractéristique de l’attitude adoptée par XP : l’automatisation des tests est connue pour être une pratique efficace pour réduire les anomalies ; les tests automatisés sont plus fiables et moins consommateurs de temps que les tests manuels ; la testabilité des logiciels produits est elle-même un critère de qualité – par conséquent, l’automatisation des tests doit occuper une place prioritaire dans la démarche de conduite du projet.

 

4.3. Maîtrise de la qualité interne : permettre une conception incrémentale

 

Aux tests de recette dont la finalité est de garantir la qualité externe du projet, XP ajoute des outils concernant la qualité interne. Conformément à la philosophie générale de la démarche, ces outils sont en nombre restreint mais leur application sans réserve permet d’obtenir des résultats significatifs. Le premier de ces outils n’est autre que l’utilisation de tests automatisés – appartenant à une catégorie distincte, ils sont appelés tests unitaires[4]. Le second est le refactoring, qui, associé à l’utilisation des tests unitaires, permet une approche incrémentale de la conception du programme.

 

De même que les tests de recette, les tests unitaires sont écrits avant le code testé, en partie pour les mêmes raisons : c’est dès le début du projet qu’une qualité insuffisante peut être néfaste et engendrer des retards ; dès lors, repousser à la fin du projet l’écriture de tests automatisés suffit à garantir qu’il ne seront pas écrits. De même, l’écriture de tests unitaires tout au long du projet garantit – par la force des choses – que la conception des programmes les rend testables.

 

De façon tout aussi importante, l’écriture de tests unitaires avant le code testé a pour effet de promouvoir une meilleure conception : elle revient à formuler des « contrats » concernant le code en question et à les exprimer de façon formelle, ce qui oblige à aborder le test unitaire à un niveau d’abstraction supérieur à celui de l’implémentation.

 

La démarche recommandée pour l’écriture des tests unitaires est simple et pratique : on commence par rédiger le test, puis on l’exécute. La fonctionnalité testée n’étant pas implémentée, le test doit échouer ; on écrit alors le code qui permet que ce test soit exécuté avec succès. Ce rythme à trois temps garantit, lorsque les tests sont exprimés à un niveau de détail suffisamment fin, une couverture presque complète du code produit : toute modification de ce code qui en modifie le comportement – y compris par effet de bord – fera en principe échouer au moins un test. A l’inverse, une modification qui préserve la fonctionnalité n’aura aucun effet sur les tests.

 

Sous ces conditions – et même lorsque cette couverture est partielle plutôt que complète – il devient possible de pratiquer l’une des activités clés dans XP, le refactoring. Cette technique est décrite par Martin Fowler, auteur de l’ouvrage de référence sur le sujet [5], comme « toute modification d’un programme permettant d’en améliorer la structure interne sans en modifier le comportement externe ». (Cette technique est largement absente de la littérature traitant des méthodes orientées objet ; on peut la considérer comme équivalente à ce que Bertrand Meyer appelle la « phase de généralisation » dans son modèle de cycle de développement par « grappes » [4].)

 

Les tests unitaires et le refactoring vont main dans la main en XP ; ils autorisent la démarche de planification pilotée exclusivement par les aspects fonctionnels du projet, en permettant aux programmeurs de ne généraliser une solution donnée que lorsque cela devient nécessaire pour l’implémentation d’une « user story ». Ils jouent également un rôle clé vis-à-vis de la qualité de la conception : par exemple, les tests unitaires permettent de déceler les problèmes de couplages inappropriés entre les modules d’un programme – une modification mineure entraîne l’échec de plusieurs tests – et le refactoring permet de remédier à cette situation, par exemple en déplaçant une méthode ou une variable d’une classe à une autre.

 

5. Conclusions

 

Les trois pratiques proposées par XP et décrites ci-dessus – la planification itérative basée sur les « user stories », la conception pilotée par les tests de recette et les tests unitaires, et le refactoring – constituent le squelette d’une stratégie permettant de maîtriser les délais et la qualité d’un projet dans un environnement sujet à des changements rapides et fréquents. Elles ne sont pas, loin s’en faut, suffisantes pour mener un projet ; XP dans son ensemble comporte au total 12 pratiques, qui complètent et renforcent les bénéfices déjà cités. Celles que j’ai décrites[5] constituent un « fil conducteur » possible pour comprendre l’intérêt de la méthode, parmi d’autres.

 

Dans le cadre fourni par XP, d’autres outils, principes ou techniques peuvent être évalués à la lumière de leur effet sur l’efficacité d’une équipe de projet, mesurée par sa vélocité. On pourra ainsi mesurer pour un projet un contexte donné les effets de l’utilisation de design patterns ou de modèles UML, de la programmation par contrats, de la constitution de bibliothèques de composants réutilisables, des outils du type AGL… La philosophie d’XP est minimaliste, mais néanmoins ouverte à tout ce qui peut contribuer au succès d’un projet.

 

Au-delà des pratiques spécifiques qui en constituent l’armature, XP cherche à tenir compte des réalités actuelles de la conduite des projets informatiques. Les valeurs fondamentales qui sous-tendent la méthode – communication, simplicité, réactivité, courage – y sont clairement explicitées ; de même l’importance des facteurs humains et psychologiques. Si XP se caractérise par le rejet de certains dogmes longtemps associés à la notion même de génie logiciel – la priorité de la documentation détaillée sur le code source, de la trace écrite sur la tradition orale et la conversation, de la conception par rapport à l’implémentation –