Limitations et extensions des méthodes agiles

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.

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

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

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

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

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

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

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

À 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.

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

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

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

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.