L'Extreme Programming

L'histoire du développement de logiciels est intimement liée à l'histoire de l'industrie informatique. Je vais donc présenter les deux à la fois.

Le transistor a été inventé en 1948, et l'ordinateur sous sa forme actuelle existe depuis les années '50. Ce n'est cependant que pendant les années '60 que l'informatique commerciale est apparue, alors que le coût des ordinateurs a grandement diminué et que des langages de programmation comme Fortran et Cobol ont permis de produire des applications pour le milieu des affaires. À partir de ce moment, le rythme n'a cessé d'augmenter, tant au point de vue machine que logiciel.

Les années '70 ont vu l'apparition des langages C, Pascal et Basic, de Unix, du circuit intégré, de Apple, Intel et Microsoft, et des premiers micro-ordinateurs. Le PC, le Mac et l'interface graphique ont suivi quelques années plus tard, et une révolution importante s'est produite : un individu pouvait désormais programmer avec un langage comme dBase ou Basic, sans aucune formation et avec un minimum de ressources, et produire un logiciel utile et immédiatement disponible. La qualité était souvent mauvaise, et les règles établies depuis les années '60 ont été oubliées au profit de cette nouvelle vague d'outils de développement. L'avènement en masse de la réseautique a amplifié le problème, puisque les défauts d'un logiciel n'étaient plus isolés au seul ordinateur où il était exécuté.

Le développement de logiciels a été pendant longtemps entièrement libre de directives ou de contraintes, et il n'y avait aucune méthode pour analyser les besoins, produire une solution, ou même évaluer le succès. En 1968, une conférence de l'OTAN a introduit le terme « génie logiciel » et suggéré d'utiliser les méthodes rigoureuses et éprouvées du génie civil au chaos du développement de logiciels. L'idée était louable, mais une différence majeure existe : contrairement à la physique et aux mathématiques, l'informatique ne repose sur aucune loi et ne peut être vérifiée scientifiquement.

Des méthodologies de développement sont apparues à différents moments durant la révolution informatique. Le modèle en cascade, inventé par la US Navy, est sans aucun doute le modèle qui a eu le plus d'influence, et cette influence peut encore être ressentie aujourd'hui. Le modèle est très strict : les étapes de concept, analyse, design, programmation et test doivent être exécutées dans l'ordre, et le retour en arrière n'est pas permis. La notion que le coût du changement augmente à mesure que le projet progresse est dérivée de ce modèle. L'emphase sur la documentation est très importante, et chaque étape doit être approuvée avant que l'étape suivante débute. Très bureaucratique, très lourd, mais un grand bond dans la bonne direction.

Le modèle en cascade a donné naissance à de nombreuses autres méthodologies : prototypage, modèle en spirale, implantation en étape, et même RAD (Rapid Application Development). Ces méthodologies sont des variations de l'original, où des possibilités de retour-arrière à différents points ont été ajoutées. Au milieu des années '90, l'industrie informatique utilisait le terme RAD à toutes les sauces, et promettait des résultats fantastiques. Les fabricants de langages de programmation, dont Borland et Microsoft, ont lancé des produits de développement qui ont effectivement accéléré le processus de programmation, mais n'avaient rien à voir avec une méthodologie de travail. En fait, dans la grande majorité des cas, les outils contribuaient à diminuer la qualité.

D'autres modèles sont apparus et ont connu un succès limité, possiblement à cause de leur manque de flexibilité. L'analyse orientée-objet (basée sur la programmation orientée-objet) est apparue à la fin des années ‘80, et est encore utilisée aujourd'hui pour le développement de systèmes de grande taille. Rational Unified Process (processus basé sur UML) est le modèle de Rational Software, et requiert l'utilisation de logiciels spécifiques. La méthode P-Plus, de DMR (maintenant Fujitsu Consulting), qui a connu son heure de gloire dans les années '80, commençait par la fin : le livre d'instructions du produit fini était écrit, puis présenté au client pour approbation ; le développement du logiciel commençait ensuite.

À travers toutes ces méthodes et tous ces modèles, de nombreuses bonnes idées sont apparues. Malheureusement, elles sont souvent mal utilisées, ou perdues au cœur de la rigueur et de la paperasse générée par le modèle. Un mouvement est apparu au milieu des années '90 qui avait pour but de rendre le processus de développement plus efficace, en utilisant des concepts très simples et reconnus. Ce mouvement s'appelle Agile Modeling. Il n'est directement relié à aucune méthodologie, mais propose une série de recommandations, valeurs, et principes qui sont appliqués dans d'autres méthodes. C'est de là que Extreme Programming est né.

Extreme Programming, ou XP, est basé sur des principes très simples, mais souvent ignorés par l'industrie. Une des idées révolutionnaires est que le coût du changement n'est pas variable, mais plutôt constant ; XP accepte donc le changement comme une réalité et l'intègre dans le processus de développement. Aussi, la programmation en paire, où deux programmeurs travaillent ensemble sur le même ordinateur, permet d'augmenter la qualité à des niveaux encore jamais vus. Une autre idée consiste à mettre l'emphase sur la communication constante entre l'équipe de développement et le client, par le biais de boucles rapides développement-test-feedback. Certaines de ces idées ne sont pas nouvelles, mais elles sont assemblées dans XP pour former une méthodologie efficace et qui présente des résultats concrets, plutôt que des résultats sur papier.

Les cours de génie logiciel, la littérature, et presque toutes les méthodologies de développement jusqu'au milieu des années ‘90 suggéraient que le coût relié à des changements dans les spécifications d'un problème ou le design d'une solution augmente de façon exponentielle à mesure que le projet avance. D'innombrables références et études sont disponibles dans des livres et articles, et l'idée est une notion acquise pour plusieurs générations de gestionnaires de projet. En fait, certaines méthodologies basées sur le modèle en cascade reposent entièrement sur cette prémisse et ignorent complètement les requêtes de changement, ou encore imposent des processus très stricts pour gérer ces requêtes (possiblement dans le but de les éliminer).

Dans la réalité, quelqu'un a-t-il déjà travaillé sur un projet d'informatique (ou n'importe quel projet) où il n'y a pas eu de changement ? Est-ce même possible ? Peu importe la taille du projet, peu importe le contexte, peu importe l'industrie, le changement est inévitable. Depuis qu'il y a des projets d'informatique, il y a des requêtes de changement ; pourquoi les ignorer ? Pourquoi supposer que ce projet sera différent ?

Le court cycle de développement utilisé dans XP règle le rythme du projet, et a un effet direct sur la qualité du produit fini. En ayant des mises en production fréquentes, les éléments les plus importants sont produits en premier ; les mises en production suivantes permettent d'ajouter des fonctionnalités tout en testant le résultat à chaque nouvelle étape.

Le graphique présente le coût du changement d'après XP. On peut voir que le coût du changement augmente légèrement durant les premières étapes, alors que le design devient plus complexe et que l'effet d'un changement a de plus en plus de répercussions. Après un certain point, cependant, le coût atteint un plateau et diminue légèrement ; ceci est causé par la « factorisation » du programme (expression pompeuse pour dire « simplification »).

Une des grandes forces de XP est d'accepter le changement comme une réalité, et de l'inclure comme partie intégrante du processus de développement. Les boucles rapides de développement-test-feedback permettent d'intégrer le changement de façon contrôlée, sans avoir à “revenir en arrière”. En permettant au changement de prendre place à tout moment, il est possible de prédire le temps et le coût associé, et de rapidement présenter au client la conséquence de ce changement. Le coût du changement devient donc une constante plutôt qu'une variable.

Bien entendu, une requête qui aurait des conséquences profondes sur le design d'une base de données ou d'une architecture devra être évaluée sérieusement, et le client sera informé rapidement du coût en temps et ressources ; il est possible qu'une requête de changement soit rejetée. De la même manière, il serait naïf de complètement ignorer les réalités économiques du projet, et d'accepter d'implanter des changements de toutes sortes, n'importe quand, tout en continuant de viser une date de livraison fixe. Le gestionnaire du projet garde le doigt sur le pouls des variables : temps, étendue (scope), ressources, qualité ; son intervention permet de garder le projet à un niveau réaliste tout en fournissant au client un maximum de résultats pour son investissement.

La programmation en paire est tranquillement en train de prendre sa place dans l'industrie. C'est une méthode efficace et reconnue d'augmenter la qualité et la vitesse du processus de développement. La technique peut être appliquée à n'importe quelle méthodologie, et plusieurs universités et même IEEE se sont intéressés au sujet et ont conduit des études. Dans l'article « Strengthening the Case for Pair-Programming », les résultats d'études conduites dans deux universités sont présentés, et démontrent la grande efficacité de la technique avec des étudiants. Le site http://www.pairprogramming.com/ est entièrement dédié à la programmation en paire.

L'idée de base de la programmation en paire est très simple. Tout développeur est familier avec cette scène : un individu est au clavier et tape du code, un autre est assis à côté et pointe les erreurs de syntaxe. Vu de l'extérieur, ça donne l'impression d'être une blague : « combien de programmeurs ça prend pour écrire 10 lignes de code ? » C'est d'ailleurs une réaction normale, ça semble être un exemple criant de perte de temps et de mauvaise utilisation des ressources.

Mais quand on porte attention on voit que le travail avance à un rythme régulier et que les erreurs sont attrapées plus rapidement. De plus, la communication ouverte entre les deux programmeurs permet d'échanger des idées et d'identifier des solutions qui n'auraient autrement pas été considérées ; il s'agit ni plus ni moins d'une session de brainstorming permanente. Il est reconnu que des programmeurs sont plus efficaces lorsqu'ils communiquent et comparent leurs idées, comparativement à un programmeur travaillant seul.

Générer des idées, isoler un problème, tester une solution, modifier une architecture, toutes ces activités sont hautement complexes et détaillées, et par conséquent susceptibles à l'erreur. Même le plus discipliné et méthodique des programmeurs fera des erreurs, pour une raison ou une autre ; certaines de ces erreurs seront reliées à la syntaxe, d'autres à la sémantique, d'autres à l'interaction avec d'autres parties du programme. Une paire de programmeurs a l'avantage de deux paires d'yeux pour voir les erreurs, en plus d'un « cerveau à deux niveaux »: focus sur le code, et focus sur la solution entière. De plus, la possibilité de discussion avec une autre personne permet d'explorer les possibilités ou de voir à l'avance les limitations d'une solution, plutôt que d'en faire la découverte après avoir écrit le code. Ces avantages résultent en un produit de meilleure qualité.

Comme c'est le cas pour la majorité des gens, et en particulier pour les gestionnaires, l'idée d'utiliser deux ressources pour faire le travail qui pourrait être accompli par une seule paraît absurde. Après tout, les programmeurs ont toujours travaillé seul, et ça a fonctionné jusqu'ici, pourquoi changer ?

La nature du développement informatique est très propice au travail solitaire, mais le travail solitaire est lui-même très propice à l'erreur. Un programmeur solitaire a tendance à développer des habitudes qui lui permettent d'aller plus rapidement, mais qui sont nuisibles à la qualité et réduisent sa créativité. Une paire de programmeurs travaillant sur le même problème sera beaucoup plus productive, produira un travail de meilleure qualité, et sera beaucoup plus confiante dans le résultat. Les individus gagnent en expérience en étant exposés aux connaissances de l'autre, et l'organisation (employeur, projet, agence) y gagne en réduction des pertes de temps, meilleure qualité du travail, et dissémination des connaissances.

D'un point de vue purement monétaire, le coût de développer une solution en utilisant la programmation en paire est d'environ 20 % supérieur au coût de développer la même solution en utilisant un seul programmeur. Cependant, les coûts engendrés par la correction d'erreurs après la mise en production font rapidement changer la balance, et la programmation en paire est en fait un bien meilleur investissement. Il peut être difficile de justifier le coût plus élevé au client, qui demandera inévitablement un programme sans erreur au moindre coût possible, mais un gestionnaire de projet expérimenté arrivera à présenter les avantages et convaincre le client qu'il s'agit en fait d'un investissement dans la qualité plutôt qu'une dépense additionnelle.

Les résultats d'études sont clairs : programmer en paire diminue le nombre d'erreurs (source : « Strengthening the Case for Pair-Programming »)

Pour un gestionnaire de haut niveau (VP Informatique, VP Systèmes d'information, VP Technologie, CIO, CTO), il y a quelques autres aspects à prendre en compte. Des programmeurs qui travaillent en paires deviennent rapidement plus qualifiés (via le partage de connaissances avec d'autres programmeurs), et sont plus satisfaits par leur travail. Par conséquent, ces programmeurs sont capables de travailler sur des problèmes plus complexes et de produire une plus grande valeur pour la compagnie. Un autre avantage non négligeable est que le taux de rétention de ces employés sera plus élevé.

J'ai personnellement essayé la programmation en paire, et l'expérience a été entièrement positive. Il s'agissait d'un projet de data warehousing pour lequel un contracteur a été engagé pour aider à produire le résultat plus rapidement. Le contracteur avait peu d'expérience avec le data warehousing, mais était expert en VB et de niveau moyen avec SQL. Ma grande force est le SQL et le design de systèmes de data warehousing ; je ne connais rien au VB.

Nous avons commencé la programmation en paire de façon impromptue, puis avons décidé de le faire de façon rigoureuse. La première moitié de la journée était consacrée à de l'administration, documentation et au polissage du code écrit la veille, individuellement ; la seconde moitié était passée à travailler sur un problème, identifier des solutions, implanter et tester, en équipe. Les tâches de design, programmation, test et implantation étaient toutes faites en équipe.

Le niveau de productivité atteint sur ce projet ne peut être comparé à aucun autre projet sur lequel j'ai travaillé ; les problèmes complexes devenaient simples, les possibilités étaient plus nombreuses, les solutions plus complètes. Il y a toujours quelqu'un avec qui célébrer un succès, affronter un problème difficile, ou éviter de succomber à la tentation de lire son email…

Les étapes indépendantes et ordonnées du modèle en cascade sont confortables et faciles à comprendre, mais présentent un inconvénient majeur : le délai entre le design de la solution et sa mise en production est trop long. Ce délai entraîne deux conséquences importantes :

1. Les différences entre les besoins du client et la solution finale n'apparaissent qu'au moment où le programme est mis en production avec les utilisateurs ;
2. Le feedback du client et des utilisateurs n'est pas pris en compte durant le design de la solution, au moment où ce feedback aurait un maximum d'impact.

En présentant régulièrement au client la solution la plus courante, en acceptant les ajustements demandés par le client, et en incluant ces changements dans la prochaine itération, ces deux problèmes sont éliminés. Les différences entre la solution présentée et les besoins du client sont immédiatement visibles, et le client peut faire des ajustements ou préciser le besoin avant que d'autres fonctionnalités soient implantées.

Le paragraphe Gestion du changement présente en détail la façon dont le changement est inclus dans le processus de développement sous XP. Pour généraliser l'approche, le feedback du client et les ajustements faits pour corriger une erreur seront appelés « changement », bien qu'il s'agisse vraiment de « mise au point » des spécifications du problème ou de la solution.

En plus de permettre de faire des ajustements et d'assurer que la solution soit le plus près possible des besoins du client, des mises en production régulières présentent au client un retour rapide sur son investissement. À chaque itération, il est possible de voir un résultat concret, et de mesurer la valeur de ce résultat comparativement à l'effort et aux ressources qui ont été investis. Le gestionnaire du projet pourra aider le client à déterminer l'ordre dans lequel les différentes itérations seront complétées, de façon à créer un maximum de valeur.

Le concept de valeur n'est pas toujours facile à saisir pour une entreprise. Peu importe la taille de l'entreprise ou l'importance d'un projet, il y a de nombreuses variables à considérer. En voici les aspects les plus importants :

• les coûts d'un projet incluent le matériel, les logiciels, les honoraires des consultants externes, le coût des experts internes, et la formation, pour ne nommer que les plus communs. À long terme, il faut également inclure les coûts des licences pour les logiciels, et les coûts de maintenance de logiciels et infrastructure ;
• en règle générale, la mesure de succès d'un projet d'informatique sera le revenu additionnel ou la réduction de la dépense qu'il aura générée. Bien des facteurs influencent ce calcul : réduction des pertes (temps, inventaire, livraison), augmentation de la productivité, meilleure qualité de l'information, intégration de départements (pour diminuer la redondance), et toute autre mesure spécifique à l'entreprise ;
• un aspect encore plus difficile à saisir est la perception de ce projet par l'entreprise. Si le projet ne semble pas créer de valeur pour l'entreprise, ou semble être redondant avec une fonction existante, il sera difficile de changer cette perception sans des chiffres concrets.

Une erreur commune sur de trop nombreux projets est de démarrer en douce, sous le radar, sans annonce ni support officiels. Un tel projet sera au mieux accueilli avec curiosité. Si le projet semble trop long (la durée est également une question de perception), l'intérêt diminuera et la valeur de ce projet pour l'entreprise sera de moins en moins évidente. Une façon facile d'éviter cette situation est de faire l'analyse coûts-bénéfices du projet, puis de présenter dans une annonce officielle le projet et sa raison d'être. Inutile ici de sortir la fanfare à chaque projet qui démarre, mais communiquer à toute l'organisation l'existence du projet et sa progression est essentiel à son succès.

Pour les développeurs, un court cycle de développement augmente la flexibilité, permet de corriger la solution, et de présenter rapidement le résultat au client. Mais qu'advient-il de la structure du programme ? Dans le but d'augmenter la flexibilité, il semblerait que le design « apparaît » au travers des itérations du cycle, plutôt que d'être solidement établi à l'avance. Si tel est le cas, la qualité et la solidité de la solution finale sera au mieux douteuse.

Une étape importante de design a lieu durant la première itération, où tous les développeurs, le client et le gestionnaire du projet participent à l'élaboration d'un squelette de solution. La première itération est donc plus longue que les autres, principalement à cause de l'exercice de design, mais aussi parce que la mise en place d'un certain nombre de composantes du programme doit être complétée avant que quoi que ce soit puisse être livré. Une fois la structure mise en place, les itérations de développement peuvent être aussi courtes que quelques jours si nécessaire, et les mises en production de nouvelles fonctionnalités aussi fréquentes que l'équipe le désire.