L’informatique agile, c’est quoi ?
Indéniablement agile est le pianiste qui enchaîne les triples croches à toute vitesse dans un scherzo de Chopin. Incontestablement agile est le surfeur en équilibre précaire sur sa planche au flanc d’une déferlante. Évidemment agile est le sportif qui s’adonne à l’accrobranche en haut des arbres. Indiscutablement agile est le skateur qui fait des pirouettes sur sa planche depuis une rampe. Assurément agile est le bricoleur qui fait des miracles avec ses doigts habiles.
Mais alors, l’informaticien, qu’a-t-il d’agile vous demanderez-vous ? Par analogie avec les exemples précédents, on pourrait déduire que l’agilité en informatique qualifie le virtuose du clavier, celui qui se joue des arcanes des réseaux, des machines, des systèmes d’exploitation et des logiciels. Eh bien, non ! Désolé de vous décevoir. L’informaticien agile n’est pas un hacker. C’est tout simplement un ingénieur qui développe, en équipe, des logiciels avec une méthodologie agile.
Un peu d’histoire
Dans 80 % des projets informatiques actuels, les développements logiciels sont organisés selon une méthodologie dite « en V ». Cette approche classique a permis de livrer des logiciels depuis une quarantaine d’années avec plus ou moins de bonheur. À titre d’exemple, on peut citer les logiciels de pilotage des avions, ceux de gestion des banques, assurances, hôpitaux, entreprises, etc. On l’utilise également pour les logiciels de simulation dans l’industrie, de contrôle-commande des centrales électriques, de réservation des compagnies aériennes…
Méthodologie classique en V.
Cette démarche respecte une succession d’étapes immuables, une approche somme toute logique car les informaticiens se sont rendus compte, au fil des ans, qu’il valait mieux procéder par étapes, du début à la fin. Ainsi, comme pour la construction d’une maison, on pose les fondations en premier, on monte les murs ensuite, puis le toit et on termine par l’aménagement intérieur.
La première étape est celle des spécifications. Il s’agit d’écrire noir sur blanc les objectifs du logiciel et les fonctionnalités qu’on en attend. Une fois que les clients et les informaticiens sont bien d’accord sur ce point, on peut passer à l’étape suivante, l’analyse. Celle-ci consiste à expliquer par quels procédés on va atteindre les objectifs spécifiés. Ce travail est réalisé en partie sur papier et en partie en créant des prototypes qui valident les idées. Le codage consiste ensuite à concrétiser les procédés issus de l’analyse, en écrivant du code ou en rassemblant des logiciels préexistants. À ce stade, la moitié du travail est faite. Il reste à vérifier que ce qui a été spécifié, analysé et codé est bien conforme aux attentes des clients. C’est ce que l’on appelle les tests et la validation.
Pour finir, le déploiement des logiciels testés et validés consiste à mettre à disposition ces logiciels sur les systèmes cibles. Par exemple, on peut graver un logiciel dans une carte à puce, dans un composant électronique pour l’automobile, dans un smartphone, etc. On peut l’installer sur le serveur d’une banque, d’une entreprise industrielle ou d’une administration. On peut aussi le mettre sous la forme d’un site web ou d’une application téléchargeable, à la disposition des utilisateurs finaux.
Un besoin de souplesse
Toutefois, cette méthodologie en V a été bousculée au cours de la dernière décennie, en raison de l’extraordinaire développement du web et des terminaux fixes et mobiles, qui envahissent désormais notre environnement familier. Elle présente en effet un inconvénient notoire : elle fonctionne comme un rouleau compresseur. Une fois la méthode lancée, on doit aller jusqu’au bout sans modifier les spécifications initiales, c’est-à-dire les objectifs et les fonctionnalités attendues du logiciel. Si le projet dure deux ans et concerne un logiciel de gestion de barrage hydroélectrique, ce n’est pas gênant. Mais s’il s’agit d’un jeu vidéo sur smartphone ou d’un site d’e-commerce, cette inertie peut vite devenir insupportable pour les utilisateurs et préjudiciable pour le client qui achète ce logiciel.
C’est donc pour éviter l’effet « rouleau compresseur » que les informaticiens ont mis en place les méthodes agiles, qui permettent, dans les cas favorables, de modifier graduellement les objectifs et les spécifications des logiciels. Idéalement, les méthodes agiles livrent des logiciels qui fonctionnent immédiatement avec un jeu restreint de fonctionnalités, là où les méthodes classiques imposent que le logiciel ne soit livré qu’à la fin des développements complets. Ce jeu de fonctionnalités est ensuite enrichi régulièrement, en fonction des nouvelles demandes des utilisateurs ou de la pression concurrentielle.
Plusieurs méthodes se revendiquent du courant agile. Voici les principales, classées par ordre chronologique d’apparition :
- RAD pour Rapid Application Development (1991)
- Scrum (1996)
- XP pour eXtreme Programming (1999)
- Crystal Clear (2004)
L’agilité est une valeur montante dans le secteur de la production de logiciel. De nombreuses entreprises d’ingénierie et de service ainsi que de nombreux éditeurs de logiciels ont lancé des projets en mode agile, lorsque le contexte technique ou contractuel y était favorable.
Une manière de travailler basée sur des valeurs structurantes
On ne peut pas résumer l’agilité à un simple changement de planning. L’objectif ultime est la satisfaction des utilisateurs en termes de valeur perçue, de facilité d’utilisation et de respect des délais. Dans ce but, les premiers promoteurs des méthodes agiles ont également impulsé des valeurs nouvelles pour penser le travail. Ces valeurs tiennent en peu de mots, elles ont été écrites sous la forme d’un « Manifeste Agile » au début de la décennie 2000, qui met en avant quatre valeurs fondamentales.
Concrètement, ces valeurs se déclinent dans un catalogue de principes assez pragmatiques (repris du « Manifeste Agile »).
- Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
- Accueillons positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
- Livrons fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
- Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
- Réalisons les projets avec des personnes motivées. Fournissons-leur l’environnement et le soutien dont ils ont besoin et faisons-leur confiance pour atteindre les objectifs fixés.
- La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
- Un logiciel opérationnel est la principale mesure d’avancement.
- Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs doivent être capables de maintenir indéfiniment un rythme constant.
- Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.
- La simplicité (c’est-à-dire l’art de minimiser la quantité de travail inutile) est essentielle.
- Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
- À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
En résumé, cette méthodologie est mise en œuvre par des équipes d’ingénieurs qui travaillent selon des méthodes flexibles mais rigoureuses, afin d’apporter graduellement de la souplesse dans la production de logiciels tout en garantissant, in fine, un excellent niveau de qualité aux utilisateurs.
Méthodologie agile.
Ainsi, les méthodes agiles sont itératives, parce que les développements sont organisés selon des cycles courts, plutôt 15 jours ou un mois au lieu d’un ou deux ans dans les projets classiques. Elles sont aussi incrémentales, parce que les nouveaux développements s’ajoutent aux précédents par strates successives. Cette approche itérative et incrémentale est particulièrement adaptée aux logiciels qui mettent en œuvre une interaction homme–machine, à l’instar des applications pour smartphones, des sites web, des jeux vidéo, etc. En effet, modifier un écran, un son, ou un dispositif haptique est immédiatement perceptible par les utilisateurs. Les utilisateurs peuvent donner rapidement un feedback qui entre ainsi aisément dans la boucle vertueuse de rétroaction propre aux méthodes agiles.
En revanche, cette approche n’est pas pertinente pour les grands logiciels industriels comme les protocoles de réseau, les progiciels de gestion d’entreprise, les logiciels de contrôle-commande de machine, les logiciels embarqués (automobile, aérospatiale, etc.). En effet, tester une couche de protocoles ou modifier une couche basse d’un middleware (ou intergiciel) requiert de mettre en place un plan d’expérience qui n’est pas compatible avec la rapidité d’interaction attendue des méthodes agiles.
Qu’est-ce qui favorise un développement agile ?
Quatre critères favorisent le recours aux méthodes agiles dans le développement logiciel. Il n’est sans doute pas nécessaire de bénéficier simultanément de tous ces critères, mais il est clair que la réussite d’un projet agile est corrélative à la réunion de plusieurs d’entre eux.
Les interfaces homme-machine
Les développements logiciels concernent des interfaces homme-machine pour lesquelles l’avis des futurs utilisateurs dépend de leur bonne adoption du produit ou du service proposé. Les goûts et les couleurs, mais aussi l’ergonomie jouent un rôle clé dans l’acceptation d’une interface par les utilisateurs. En impliquant les futurs utilisateurs, les méthodes agiles augmentent la probabilité de l’adoption en douceur d’une nouvelle application. A contrario, le développement des couches plus éloignées de l’utilisateur final, comme les protocoles de réseau, ne se prêtent pas à une implication de ce type.
La « liquidité » du projet
Le projet est dit « liquide » s’il peut être découpé en incréments de taille suffisamment flexible. Plus l’architecture du projet est « liquide », plus on pourra jouer sur la planification des incréments fonctionnels en avançant ou en reculant les développements. À l’inverse, des applications lourdes incontournables et insécables rendent plus difficile l’adoption d’une méthode agile. De ce point de vue, les approches objets et les approches SOA (Service Oriented Architecture) sont propices à l’agilité. Par contre, une chaîne d’applications bancaires qui tourne depuis trente ans ne pourra pas évoluer selon une approche agile.
Le caractère exploratoire du projet
Un projet est dit exploratoire lorsque le maître d’ouvrage (ou client ou utilisateur) ne sait pas exactement ce qu’il veut car il expérimente plusieurs voies. Dans de tels cas où le prototypage fait partie de la démarche, les méthodes agiles permettent d’organiser le « bordel ambiant » (selon l’expression de Roland Moreno). Des spécifications précises jusqu’au moindre bit près ne se prêteront donc pas aux approches agiles. On n’envoie pas un satellite artificiel en orbite en développant de manière agile.
La souplesse contractuelle et juridique
Le maître d’ouvrage et client accepte une souplesse contractuelle et juridique. Si le maître d’ouvrage et le maître d’œuvre ont signé un contrat de type « assistance technique » (achat d’un volume d’homme x jour au fil de l’eau), les approches agiles permettent d’avancer au rythme souhaité par le maître d’ouvrage. En revanche, si le contrat est de type « forfait » (travail avec engagement de résultat en contrepartie d’une enveloppe financière fixée à l’avance), une approche agile sera vraisemblablement inadaptée. Or de très nombreux contrats de développement logiciel sont encore verrouillés de manière rigide par les parties prenantes.
De nouvelles approches
Au-delà de l’agilité, on a vu apparaître de nouvelles manières de travailler dans l’industrie des logiciels. Pour le développement logiciel, on peut citer par exemple Lean Software Development (2003 ) et Kanban (2010), deux approches qui proviennent du monde de l’industrie automobile et qui se sont adaptées à l’industrie des logiciels dans la mouvance de l’informatique agile.
Le Lean Software Development est l’application des principes Lean au développement logiciel pour minimiser l’effort de production tout en maximisant la satisfaction du client (ou du maître d’ouvrage ou de l’utilisateur). Dans son contexte industriel d’origine, le Lean (littéralement « maigre », « dégraissée ») consiste à produire au plus juste, sans gaspillage, afin d’améliorer en continu la productivité, la qualité et de réduire les délais et les coûts. Dans le cadre du logiciel, le Lean cherche à identifier ce qui est réellement important pour le client et à se concentrer dessus. En ne s’éparpillant pas sur des fonctions annexes mal valorisées aux yeux du client, les informaticiens Lean privilégient l’amélioration continue qui se voit et la prévention des défauts. Idéalement, les informaticiens Lean visent le « zéro défaut » du premier coup plutôt que de devoir corriger a posteriori, une correction étant toujours beaucoup plus coûteuse.
Intégrant les principes du Lean, le Kanban a été conçu dans les années 1950 dans les usines Toyota. Cette méthode permet de gérer et d’optimiser les flux et les stocks des entreprises dans une philosophie visant le « zéro défaut » du premier coup tout en minimisant les coûts matériels et humains. Fonctionnant sur le principe des flux tirés de production, le Kanban permet de minimiser les en-cours, ce qui permet de libérer de la place dans les stocks et de réaffecter la production là où elle est réellement utile. Appliquée au monde du développement de logiciel, le Kanban permet de modéliser les flux de production (par exemple les spécifications, la conception, le codage, les tests unitaires, etc.) et de chercher à optimiser ces flux en minimisant les en-cours de production. Par exemple, il ne sert à rien de spécifier dix fonctionnalités par jour si les testeurs ne peuvent en valider que cinq par jour. Grâce à une visualisation graphique, comprise de tous, de l’organisation en flux tiré, le Kanban favorise l’allocation des ressources au bon endroit et au bon moment. Il favorise également la minimisation des défauts et la flexibilité de la production, ce qui permet de répondre plus rapidement aux attentes des clients.
Au fond, ces nouvelles approches de développement logiciel participent à la quête sans fin du Graal informatique. Produire de plus en plus vite, à moindre coût et avec « zéro défaut », des logiciels qui s’insinuent partout dans nos vies quotidiennes, depuis le logiciel enterré dans une télévision ou dans une automobile jusqu’à l’application jetable pour smartphone et depuis la chaîne de facturation bancaire jusqu’au jeu vidéo destiné au grand public. Qu’il s’agisse de logiciels jetables ou d’applications au long cours, l’enjeu est de passer du stade de l’artisanat au stade industriel, dans un monde globalisé où les développeurs de logiciels sont soumis à rude concurrence.
Quelques « gourous » de l’agilité
- Scott W. Ambler
- Jim Highsmith
- François Beauregard
- Jean-Pierre Vickoff
- Claude Aubry
- Laurent Morisseau
Bibliographie
- RAD, le développement d’applications client-serveur, Jean-Pierre Vickoff, Macmillan, 1996 (ISBN 2744002224)
- Systèmes d’information et processus agiles, Jean-Pierre Vickoff, Hermes Science Publication, 2003 (ISBN 2746207028)
- L’eXtreme Programming, de Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams Eyrolles 2004 (ISBN 221211561X)
- Maîtriser les projets avec XP : Pilotage par les tests-client, Thierry Cros, Éditions Cépadues, 2004 (ISBN 2854286391)
- Méthode agile, Les meilleures pratiques, Compréhension et mise en œuvre, Jean-Pierre Vickoff, QI, 2009 (ISBN 978-2912843074)
- L’art du Lean Software Development, Mike Sullivan, Steve Jewett, Curt Hibbs, InfoPro, Dunod, 2010 (ISBN 978-2-10-054296-3)
- SCRUM, le guide de la méthode agile la plus populaire, Claude Aubry, InfoPro, Dunod, 2è édition, 2011 (ISBN 978-2-10-056320-3)
- Kanban pour l’IT, Une nouvelle méthode pour améliorer les processus de développement, Laurent Morissseau, Dunod, 2012 (ISBN 978-2-10-057867-2)
Newsletter
Le responsable de ce traitement est Inria. En saisissant votre adresse mail, vous consentez à recevoir chaque mois une sélection d'articles et à ce que vos données soient collectées et stockées comme décrit dans notre politique de confidentialité
Niveau de lecture
Aidez-nous à évaluer le niveau de lecture de ce document.
Votre choix a été pris en compte. Merci d'avoir estimé le niveau de ce document !
