Les méthodes agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets, mais se limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel). Les méthodes agiles ne sont pas apparues avec le Manifeste agile en 2001 mais celui-ci détermine leur dénominateur commun (consacre le terme d'« agile » pour les référencer). Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du client en priorité aux termes d'un contrat de développement.
Les méthodes agiles reposent sur une structure (cycle de développement) commune (itérative, incrémentale et adaptative), quatre valeurs communes déclinées en douze principes communs desquels découlent une base de pratiques, soit communes, soit complémentaires.
Parmi ces méthodes on trouve en premier lieu la méthode RAD (développement rapide d'applications) (1991), puis DSDM, la version anglaise du RAD (1995). Plusieurs autres méthodes, comme ASD ou FDD, reconnaissent leur parenté directe avec RAD. Les deux méthodes agiles désormais les plus utilisées sont : la méthode XP Extreme programming publiée en 1999 par Kent Beck et la méthode Scrum publiée en 2001 par Ken Schwaber et Mike Beedle.
Une méthode pour bénéficier de la dénomination d'agile doit se composer uniquement de techniques s'inscrivant dans la philosophie du Manifeste Agile et en respecter les 4 valeurs fondamentales qui se décomposent opérationnellement en 12 principes reconnus par l'ensemble de la communauté et publiés par l’Agile Alliance.
Les deux principales méthodes utilisées sont XP et ScrumAgility in context. XP dispose de techniques de pilotage du projet, de facilitation de la communication et de montée en compétence des équipes mais se focalise sur le développement itératif (conception émergente) et la qualité du logiciel. Scrum propose un pilotage incrémental des tâches de production.
Ces méthodes possèdent néanmoins certaines limitations et des extensions à ces pratiques peuvent y être apportées.
Techniques diverses
Refactorisation de code La refactorisation de code (« code refactoring » en anglais) consiste à remanier le code, afin de le rendre plus clair, structuré et simpleSubclassing XP: Breaking its rules the right way.
Il existe deux types de refactoring : Le refactoring pour un scénario donné : c’est en général un refactoring mineur, et de portée limitée. Le refactoring qui entraîne un changement de design, ou affecte du code d’application répartie. C’est en général un refactoring majeur, avec une grande portée.
Quelle que soit la méthode employée, il est préconisé de faire régulièrement du refactoring de code.
Limitation Dans certains projets ou certaines équipes, une seule personne de l’équipe réalise régulièrement du refactoring. Ce refactoring n’entraîne pas de bug, étant donné que les tests sont toujours valides. Cependant, ce développeur réalise ce refactoring seul, sans même communiquer avec l’équipe. Les autres membres de l’équipe, qui reviennent plus tard sur ce code ne s’y retrouvent plus, et parfois même, jugent ce refactoring inefficace ou inadapté.
Extension Une solution est de remplacer le refactoring par du refactoring d’équipe (« team refactoring »).
Les membres de l’équipe ajoutent à une liste les refactoring possibles. Il est possible d'utiliser un outil de tracking, par exemple JIRA qui permet de décrire la tâche, de préciser sa date de création et par qui elle est créée.
Lors de la définition des sprints, 75 % du temps est alloué au développement des fonctionnalités, le reste aux tâches parallèles du développeur. Lorsque la phase de développement est terminée, l’équipe se réunit et priorise les refactorings présents sur la liste. Le chef décide ensuite des refactorings à réaliser, en fonction de l’impact de ceux-ci sur le logiciel, étant donné que beaucoup modifient le design. Les refactorings sont ensuite réalisés en « pair programming ».
Documentation La documentation consiste à développer un ensemble de fichiers ou documents qui permet une meilleure compréhension du code et du produit et du projet.
Les méthodes agiles préconisent d'écrire de la documentation mais très peu, seulement le nécessaire. Il faut se focaliser sur le besoin utilisateur plutôt que la documentation.
Lors d'un projet agile, des éléments sont considérés comme de la documentationHow Much is Just Enough? Some Documentation Patterns on Agile Projects : Le code lui-même : il est censé être clair et bien écrit. Les tests unitaires et les tests d'acceptance constituent une documentation très riche.
Il est difficile de définir le niveau de documentation à fournir et quelle documentation. Ce niveau doit se définir en fonction du contexte, du besoin et des problèmes qui lui sont liés.
Dictionnaire du projet Dans une relation client-fournisseur, il est difficile pour le fournisseur de communiquer avec le client et pas seulement en raison du manque d'investissement de celui-ci. Il existe une différence de langage entre une terminologie business de l'équipe client et une terminologie "technique" de l'équipe développeurs.
Pour pallier ce problème, une des solutions est la mise en place d'un dictionnaire du projet. Ce dictionnaire est un document éditable en ligne (wiki), où le client définit l'ensemble des termes du domaine, leur signification, le contexte d'utilisation. Ce document permet aux développeurs d'établir une correspondance unique entre les termes du client et les termes qu'ils utilisent.
Documentation compréhensible Dans certains projets, la documentation se doit d'être un livrable majeur et pas seulement un accessoire qui aide à la compréhension du projet. Par exemple lors du développement de solutions pour l'aéronautique et notamment ce qui touche au cockpit des avions, une documentation très détaillée est nécessaire. Cette documentation est un livrable du projet difficile à fournir par les développeurs agiles qui considèrent cela contraire aux principes agiles.
Une solution est de conserver les méthodes agiles en interne, sans les appliquer à la partie client. Il est alors possible de fournir une documentation complète au client tout en appliquant les méthodes agiles en interne.
Fake documentation Lorsque deux équipes, une agile, l'autre non, participent à un projet, la documentation est source de conflit.
Voici les principales différences entre les deux équipes : La quantité de documentation : L'équipe agile souhaite peu de documentation. L'équipe non agile souhaite une documentation complète. La méthode de développement : L'équipe agile développe en fonction des besoins utilisateurs. L'équipe non agile se base sur une documentation complète et spécifiée dès le début pour effectuer l'ensemble de ses développements.
L'équipe agile considère la documentation comme un travail non pertinent alors que l'autre équipe ressent ce manque de documentation comme une faiblesse et s'en fait donc un avis négatif.
Pour pallier ces problèmes, l'équipe agile doit interagir avec la non agile pour déterminer la documentation minimale à réaliser et les échéances de besoin. L'équipe non agile les échéances dès le début du projet. L'équipe agile est en mesure de fournir et maintenir une documentation de manière itérative et la non agile d'avoir la documentation minimale lorsqu'elle en a besoin. Ce pattern est appelé la Fake Documentation.
« Time Stamp »
Les méthodes agiles préconisent d'accepter le changement à tout moment. Il est donc possible de demander un changement pour un client. Lorsque ce changement a été effectué, le client en est informé. À ce moment-là, le client peut dire qu'il n'a pas souhaité ce changement. L'équipe de développement n'a alors aucune trace de cette demande, et dans ce contexte, il peut y avoir un manque de documentation.
Une solution est de mettre en place un wiki pour tracer les demandes de changement, c'est ce qu'on appelle un Time Stamp. Il faut que ce wiki permette de retracer les dates de chaque modification, et par qui elle a été effectuée. Il sera alors possible de se référer à ce document en cas de conflit.
« E-Backup »
À tout moment, il est possible de perdre tout ou partie de traces écrites sur papier. Dans le cadre d'un projet agile, il est fréquent d'avoir des tâches à effectuer détaillées sur des étiquettes autocollantes. Ces étiquettes peuvent être mélangées ou perdues, notamment lors du ménage. La perte de ces données constitue dans ce cas une perte d'information ou de documentation.
Une solution à mettre en place est de conserver une photographie de l'état, en effectuant des sauvegardes en ligne (« E-Backup » en anglais). Il est conseillé de les stocker dans l'espace réservé au projet. La fréquence des sauvegardes n'est pas fixe, il suffit de se poser la question « Si je perds mes données demain, est-ce que j'aurai assez d'informations en ligne pour combler ce manque ? ». Dans certaines équipes, un membre a le rôle d'effectuer ces sauvegardes, on l'appelle le « super secrétaire », dans d'autres, la responsabilité d'effectuer ces sauvegardes est assumée à tour de rôle.
Design intensif Le design intensif est une technique qui consiste à développer une application ou un logiciel en fonction du design de celui-ciAgile Development and User Experience Design Integration as an Ongoing Achievement in Practice.
Lors du développement d'applications de ce genre, il est mis en avant que les méthodes agiles ne sont pas adaptées à ce genre de développement, mais le sont plus pour du pur développement. Il faut alors mettre en place des techniques qui permettent d'adapter les méthodes agiles à ce type de projet dirigé par le design.
Architecture de l'information web Dans un développement web, une des solutions est de mettre en place un document, qui définit l'architecture de l'information. Ce document définit l'architecture du site web mais aussi les règles associées aux éléments du document. Le développeur peut donc l'utiliser pour en déduire le fonctionnement et la logique de l'application et l'intégrateur pour définir le design.
Design Pipeline Une autre solution est de demander au client de définir le design avant chaque sprint. Cette méthode, appelée « Design Pipeline », permet au développeur de posséder le design de l'application avant d'effectuer ses développements. Il peut donc se baser sur celui-ci pour effectuer son travail. Cela permet de ne pas effectuer de développements inutiles ou d'améliorations non souhaitées par le client.
La mise en place de cette technique implique la définition d'un sprint initial consacré au design de l'application.
Gestion de l'équipe Mise en place des méthodes agiles
La mise en œuvre des méthodes agiles au sein d'une équipe apporte beaucoup de bénéfices mais peut être difficile, par exemple si les développeurs résistent. Certaines équipes l'effectuent en une seule fois après des sessions d'explications, d'autres de manière progressive, par exemple, sur les nouveaux projets puis les anciens. Une implémentation trop brusque peut entraîner des réticences de certains développeurs.
Différentes entreprises implémentent ces méthodes pour différentes raisons (croissance des équipes, augmentation des demandes des clients, projets trop lourds) et de différentes manières. La mise en place doit se faire par l'adaptation de la méthode à chaque entreprise selon ses besoins (réduction de fréquence des réunions, adaptation des sprints…). Pour effectuer un changement brusque, il est conseillé de commencer par une période d'entraînement. Les méthodes agiles ont un fort impact sur l'organisation. Il est conseillé alors d'appliquer une logique d'essai/erreur pour améliorer l'implémentation du processus. Finalement, une fois la méthode acceptée par l'équipe, on constate une amélioration progressive.
Programmation en binôme