Limitations et extensions des méthodes agiles

Ajouter des liens
Un article de Wikipédia, l'encyclopédie libre.

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 Scrum[1]. 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[modifier | modifier le code]

Refactorisation de code[modifier | modifier le code]

La refactorisation de code (« code refactoring » en anglais) consiste à remanier le code, afin de le rendre plus clair, structuré et simple[2].

Il existe deux types de refactoring[2] :

  • 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[modifier | modifier le code]

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[2]. 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é[2].

Extension[modifier | modifier le code]

Une solution est de remplacer le refactoring par du refactoring d’équipe (« team refactoring »)[2].

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 »[2].

Documentation[modifier | modifier le code]

La documentation consiste à développer — parallèlement au code source — un ensemble de fichiers ou documents qui permet une meilleure compréhension du code et du produit et du projet[3].

Les méthodes agiles préconisent d'écrire de la documentation mais très peu, seulement le nécessaire[3]. 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 documentation[3] :

  • 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 — au cours d'un projet agile — 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[1],[3].

Dictionnaire du projet[modifier | modifier le code]

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[1]. Il existe une différence de langage entre une terminologie business de l'équipe client et une terminologie "technique" de l'équipe développeurs[3].

Pour pallier ce problème, une des solutions est la mise en place d'un dictionnaire — lexique ou glossaire — du projet[3]. 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[3].

Documentation compréhensible[modifier | modifier le code]

Dans certains projets, la documentation se doit d'être un livrable majeur et pas seulement un accessoire qui aide à la compréhension du projet[3]. 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[3]. Cette documentation est un livrable du projet difficile à fournir par les développeurs agiles qui considèrent cela contraire aux principes agiles[3].

Une solution est de conserver les méthodes agiles en interne, sans les appliquer à la partie client[3]. Il est alors possible de fournir une documentation complète au client tout en appliquant les méthodes agiles en interne[3].

Fake documentation[modifier | modifier le code]

Lorsque deux équipes, une agile, l'autre non, participent à un projet, la documentation est source de conflit[3].

Voici les principales différences entre les deux équipes[3] :

  • 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[3].

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 doit savoir déterminer[pas clair] les échéances dès le début du projet[3]. 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[3].

« Time Stamp »[modifier | modifier le code]

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[3].

Une solution est de mettre en place un wiki pour tracer les demandes de changement, c'est ce qu'on appelle un Time Stamp[3]. 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[3].

« E-Backup »[modifier | modifier le code]

À 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[modifier | modifier le code]

Le design intensif est une technique qui consiste à développer une application ou un logiciel en fonction du design de celui-ci[1],[4].

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[4].

Architecture de l'information web[modifier | modifier le code]

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[1]. 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[4].

Design Pipeline[modifier | modifier le code]

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[4].

La mise en place de cette technique implique la définition d'un sprint initial consacré au design de l'application[4].

Gestion de l'équipe[modifier | modifier le code]

Mise en place des méthodes agiles[modifier | modifier le code]

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[modifier | modifier le code]

La programmation en binôme (« pair programming » en anglais), est préconisée par les méthodes agiles. Cette méthode consiste à travailler étroitement ensemble[2] :

  • Un membre du binôme a le clavier, il s'occupe d'écrire le code.
  • Le second s'occupe de relire le code, proposer d'éventuelles améliorations ou déceler des problèmes.

Les rôles s'échangent de manière fréquente. Cette technique permet d'améliorer la connaissance collective et la communication au sein de l'équipe.

Limitations[modifier | modifier le code]

La programmation en binôme est parfois[2] peu appliquée dans certaines équipes agiles. Les développeurs travaillent seuls sur leur ordinateur, et il y a peu d'échange entre les développeurs. Pour combler ce manque, il est possible d'appliquer le pairing.

Extensions[modifier | modifier le code]

Le pairing correspond au pair programming sans la partie programmation (l'association des deux binômes)[2]. Pendant la production de l'incrément, chaque développeur choisit le sujet sur lequel il souhaite travailler et s'associe avec quelqu'un. La paire ainsi formée a la responsabilité du code relatif au sujet choisi et de sa qualité.

Quelques règles se doivent d'être respectées par la paire :

  • Toute modification de code est effectuée au nom du binôme.
  • Tout travail de design est à réaliser ensemble.
  • Ils doivent se réunir plusieurs fois par jour pour discuter des évolutions effectuées et des problèmes rencontrés.
  • Plusieurs fois par semaine, ils doivent effectuer du pair programming.
  • À la fin de la production de l'incrément, ils doivent se réunir pour revoir l'ensemble du code écrit.

En appliquant ces règles, de nombreux points sont améliorés. La qualité du design est d'un niveau supérieur, la sensation de propriété collective du code est davantage présente, et la qualité du code est forcément augmentée. Le nombre de bugs détecté est donc plus faible[2].

Auto-organisation de l’équipe[modifier | modifier le code]

L’enjeu principal de la méthode agile dans une équipe est de trouver un équilibre entre liberté et responsabilité. Elle permet aussi d'augmenter les connaissances globales ainsi que de développer des spécialités chez les développeurs[non neutre]. Il peut donc y avoir un apprentissage permanent malgré la pression de l'échéance.

Limitations[modifier | modifier le code]

Il n'est pas toujours facile de remanier une équipe et la mise en place des méthodes agiles peut être plus difficile que prévu. Un premier problème est directement lié a l'apprentissage de ces méthodes par l'équipe. En effet, il faut trouver la bonne façon d'aider l'équipe à intégrer ces méthodes. La communication avec le client doit être préservée, voire mise en place dans le cas où elle ne l'était pas. Il faut faire attention à certains points, les méthodes agiles induisent une nécessité d'apprendre constamment tout en continuant à développer le projet au rythme qui est imposé. Il est nécessaire de bien doser la charge entre l'apprentissage et la production pour que les proportions et les délais restent bons. L'apprentissage et donc la promotion de la multidisciplinarité peut risquer d'effacer les notions de spécialisation des différentes personnes qui travaillent sur le projet[non neutre]. Dans ce sens, de nouveaux rôles seront attribués et différents domaines d'expertise technique seront créés.

Extensions[modifier | modifier le code]

Dans le but de structurer la nouvelle organisation, de nouveaux rôles sont définis avec chacun un but bien précis. (Références??)

  • Le mentor - guide et encourage l'équipe aux méthodes agiles ;
  • Le coordinator - récupère toutes les demandes du client et les transmet de manière organisée à l'équipe de développement ; (N'est-ce pas le rôle du PO en Scrum?)
  • Le translator - facilite la traduction entre le domaine métier et les termes techniques ;
  • Le champion - défend la cause agile au sein de l’organisation et de la hiérarchie ;
  • Le promoter - vend l’agile au client, et s’assure de l’implication de celui-ci dans le projet ;
  • Le terminator - identifie les membres qui posent problème au sein de l’équipe.

À part le dernier rôle (qui est un de ceux du SM en Scrum, non pour exclure mais pour aplanir), un coach Agile gère souvent l'ensemble de ces rôles.

Équipes distantes[modifier | modifier le code]

Certains projets sont parfois obligés d'être composés de plusieurs équipes séparées et ne disposent donc pas de communication directe. Les éléments fondamentaux d'une méthode Agile ne sont donc plus respectés, le projet repasse en mode conventionnel.

La distance entre les équipes peut poser problème sur certains points. En effet, le pair programming peut être difficile à mettre en place, la communication entre les équipes et la mise en commun du travail difficile.

Pour pallier les limitations précédemment évoquées, il existe un grand nombre de technologies de communications appelées l'e-Collaboration[réf. nécessaire] (ou le Groupware). Elles sont fondées sur différentes méthodes. Les visioconférences, les emails, les logiciels de messagerie instantanée internes à l'entreprise ou encore le téléphone. Chacune de ces méthodes a différentes utilités, par exemple le téléphone permet de rapidement mettre des points au clair. Les emails permettent d'avoir une trace pour certaines informations devant être réutilisées dans le temps ou encore de diffuser une information rapidement à l'ensemble des collaborateurs. Les logiciels de messagerie instantanée permettent d'effectuer le même travail que le téléphone un peu moins rapidement.

Dans le but d'assurer au mieux la collaboration il est impératif d'accorder les attentes des deux équipes. Il est aussi conseillé de communiquer sur l'avancement du projet, les besoins et l'interdépendance entre les équipes.

Relation avec le client[modifier | modifier le code]

Implication du client[modifier | modifier le code]

Le client joue un grand rôle dans le développement d'un projet. Avoir une bonne relation avec celui-ci est primordial[5].

Limitations[modifier | modifier le code]

Les clients peuvent avoir du mal à s'impliquer dans un projet pour diverses raisons. Par exemple si le client ne comprend pas le principe même des méthodes agiles, il va refuser de s'investir, n'y voyant qu'une perte de temps. À l'opposé, certains clients veulent des méthodes agiles sans les comprendre. La majorité du temps ces clients ont eu des retours positifs par ouï-dire et cherchent à utiliser cette méthode pour leur propres projets. Malheureusement dans ces cas le client ne comprend pas la méthode utilisée et ne peut donc pas s'impliquer au mieux. La distance entre clients et développeurs peut amener à une perte de confiance de la part du client. Une fois qu'il perd confiance, il va petit à petit diminuer son implication et sa réactivité. Dans le cas où le client en plus de perdre confiance ne comprend pas les méthodes agiles, cela peut amener à un abandon du projet. Un dernier problème concerne les spécifications, dans le cas où elles ne sont pas assez claires ou assez précises. Cela peut amener à des ralentissements dans le développement.

Extensions[modifier | modifier le code]

Certaines solutions sont possibles pour corriger ou améliorer l'implication et la communication avec le client. Une de ces solutions est d'avoir un représentant des clients compétent. Ce représentant doit pouvoir répondre aux questions des développeurs tout en étant en accord avec les attentes du client. Une autre solution est le « story owner ». Le story owner est une personne du côté client qui sera en relation avec l'équipe de développement lors d'un sprint. Il est recommandé d'avoir un story owner par sprint dans le but d'avoir quelqu'un de compétent sur le sujet du sprint en cours. Il faut utiliser un maximum l'e-Collaboration[réf. nécessaire] (ou le Groupware) entre l'équipe de développement et le client. Toujours garder une bonne communication entre les différentes parties. L'inverse du story owner est le « Customer proxy ».Ce rôle est utilisé pour faciliter la communication. Le customer proxy est un développeur envoyé chez le client pour faire interface avec le client et l'équipe. Cette personne doit avoir un bon sens relationnel ainsi que de bonnes connaissances du domaine métier.

Le client doit définir ses priorités. L'équipe de développement ne doit pas avoir à déterminer le plus important pour le client. Il est impératif de ne pas démarrer un sprint si la spécification n’est pas complètement définie. Cela pourrait ralentir le sprint en plein milieu de celui-ci. Faire beaucoup de démos car elles sont une manière pour le client d'être rassuré de l'avancement et donc permettent de le garder impliqué. Un autre avantage est de vérifier au fur et à mesure que ce qui est produit correspond bien aux attentes du client. Cela renforce donc sa confiance et dans le cas où une différence est détectée, on peut la corriger au plus vite.

Négociation de contrat[modifier | modifier le code]

La négociation de contrat est une étape par laquelle chaque projet va passer. Il est donc primordial qu'elle se déroule dans les meilleures conditions. Pour cela il faut que les attentes du client ainsi que celles de l'équipe de développement soient comprises et respectées[6].

Limitations[modifier | modifier le code]

La négociation du contrat dans le cadre des méthodes agiles peut poser des problèmes avec le client pour plusieurs raisons. Dans la majorité des cas le client va désirer un contrat fixe, ce qui n'est pas compatible avec les méthodes agiles[1],[6]. Dans ce sens il va exiger un prix fixe, une date de livraison, et un périmètre bien défini. La majorité de ces attentes du client ne correspondent alors pas aux contraintes des méthodes agiles. Un autre point est ce qu'on appelle « Expectations Management »[7], cela signifie que le client doit lui-même prioriser ses scénarios, dans le but de pouvoir par la suite les utiliser dans des sprints.

Extensions[modifier | modifier le code]

Changer l’état d’esprit du client dans le but de lui montrer qu’il aura plus de contrôle sur son produit s'il collabore à la production des incréments plutôt que d'exiger le produit en entier[6]. Dans cette idée de contrôle on peut lui proposer des options. C'est une manière d'attirer le client, l'objectif est de lui proposer d'acheter quelques incréments avant de s’engager sur le projet complet[1],[6]. Cela lui donne donc la possibilité de quitter le projet à tout moment (les risques financiers du client sont ainsi couverts). On peut donc ainsi proposer au client lors de ces futurs achats d'incréments la possibilité de changer certains composants avant leur mise en développement dans un incrément. Il peut donc supprimer ou ajouter des composants comme il le désire.

Le « Dernier recours » est comme son nom l'indique une solution dans le cas où le client refuse de participer à la mise en place des méthodes agiles[6]. Dans ce cas, il est possible de démarrer avec un prix fixe, mais garder l’agile en interne sans en informer le client. Le « Buffering »[1] : la technique du buffering consiste en la mise en place d'une notion de temps, le « buffer », dans l’estimation du projet. Ce temps servira aux demandes possibles de changement venant du client. On ajoute donc une notion de temps variable à chaque sprint. Par exemple sur un incrément de 15 jours on peut disposer de deux jours supplémentaires en cas de problème ou de modifications à effectuer sur demande du client. Cette technique donne plus de flexibilité à l'équipe de développement. Un autre point de vue visant à donner du pouvoir au client consiste à le faire payer en fonction de ce qui a été réalisé pendant le projet[7]. Le client doit donc avoir une prévisualisation de son projet sur des environnements de démonstration. Le contrat « Time and Materials »[7] : c'est un type de contrat qui confère encore plus de flexibilité au client, notamment pendant les sprints. Cela donne la possibilité au client de modifier les incréments comme il le souhaite.

Conclusion[modifier | modifier le code]

Les méthodes agiles définissent des principes généraux à appliquer. Ces principes doivent dans certains cas s'adapter au contexte du projet ou de l'équipe[réf. nécessaire].

Dans chaque projet, une solution est proposée pour améliorer ces méthodes. Cette solution, judicieuse dans un contexte ne le sera pas forcément dans un autre[réf. nécessaire]. Les méthodes agiles doivent donc s'adapter au contexte du projet.

Références[modifier | modifier le code]

  1. ↑ a b c d e f g et h Agility in context
  2. ↑ a b c d e f g h i et j Subclassing XP: Breaking its rules the right way
  3. ↑ a b c d e f g h i j k l m n o p q r s et t How Much is Just Enough? Some Documentation Patterns on Agile Projects
  4. ↑ a b c d et e Agile Development and User Experience Design Integration as an Ongoing Achievement in Practice
  5. ↑ Agile Undercover: When customers don’t collaborate
  6. ↑ a b c d et e Negotiating Contracts for Agile Projects: A Practical Perspective
  7. ↑ a b et c Adventures in Agile Contracting: Evolving from Time and Materials to Fixed Price, Fixed Scope Contracts

Bibliographie[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Limitations_et_extensions_des_méthodes_agiles&oldid=204510828 ».