3.2 Processus et di cultés de mise au point
3.2.2 Les méthodes agiles
3.2.2.1 Philosophie
Cette famille de méthodes a été consacrée en 2001, lorsque les signataires du Manifeste pour le développement agile 3 ont dé ni les principes devant
mener à la création de processus de développement plus adaptés aux appli- cations modernes.
Ces méthodes partagent avec les méthodes évolutives la volonté de maî- triser les risques d'une découverte trop tardive des erreurs ou lacunes des premières étapes de la création d'un logiciel.
Elles ont cependant la volonté d'être plus légères et plus facilement adap- tables que le Processus Uni é. Dans le Processus Uni é, un grand nombre de livrables et d'intermédiaires sont dé nis, et il faut épurer la méthodolo- gie pour l'adapter à chaque projet particulier. Les méthodes agiles partent du principe inverse, en se basant sur la constatation sur le terrain que lors- qu'un projet prévoit de prime abord un certains nombre de livrables en plus de l'application elle-même, il est très rare que la totalité de ces livrables soit produite et mise à jour au long du projet, généralement par manque de temps : elles considèrent donc qu'aucune documentation n'est indispensable a priori, que le temps passé à rédiger de la documentation pour dialoguer avec le client est autant de temps perdu pour le développement de l'applica- tion elle même, et préconisent de ne produire des livrables supplémentaires que lorsque c'est absolument nécessaire (requis par contrat, ou indispensable pour la communication dans l'équipe).
Elles préconisent de gérer les risques liés au développement d'applications dont la maîtrise des aspects techniques est délicate ou les spéci cations impré- cises par l'adoption d'un cycle de vie itératif, comme dans la méthode RAD et le cycle en spirale. Comme dans la méthode RAD également, le client ou un de ses représentant est impliqué jusqu'au cou dans le cycle de vie du déve- loppement, et intervient à chaque itération. Un autre point commun avec la méthode RAD est que les itérations doivent être très courtes, a n de pouvoir réévaluer en permanence l'avancement du projet, et les mêmes pratiques de report de fonctionnalités sont mises en ÷uvre pour s'assurer de leur brièveté.
3.2. PROCESSUS ET DIFFICULTÉS DE MISE AU POINT 85 Là où certaines méthodes agiles dièrent de la méthode RAD, c'est qu'elle ont aussi pour but de s'adapter à de plus gros projets et à de plus grosses équipes de développement. La méthode RAD est selon nous un cas particu- lier, spéci que à un domaine d'application précis, de méthode agile.
Les cycles de vie sur lesquels reposent les méthodes agiles n'ont rien de nouveau par rapport à ce qui existait auparavant. La seule nouveauté est la constatation qu'il est plus rentable de s'appuyer sur une équipe compétente, et de lui apprendre à communiquer et à travailler e cacement, que de se reposer sur une méthodologie extrêmement rigide, jalonnée et produisant un grand nombre de livrables pour s'assurer que le projet sera mené à bien.
La plus connue de ces méthodes proclamées agiles est sans doute eXtreme Programming, présentée par Kent Beck dans [7] qui a scandaleusement fait parler d'elle lorsqu'elle a énoncé ses douze commandements, bien que la mé- thode Crystal, plus récente, plus souple et donc plus facile à mettre en ÷uvre de manière progressive dans une équipe de développement rodée à d'autres méthodes commence également à émerger [8], même si elle paraît plus adap- tée à des petits projets.
3.2.2.2 eXtreme Programming
Nous allons ici détailler un peu plus les principes généraux d'eXtreme Programming, a n de montrer comment cette méthode propose de remplir les objectifs xés par le Manifeste pour le développement agile.
Cette méthode, qui par bien des aspects est plus une discipline de dévelop- pement, s'appuie sur douze pratiques, a n d'assurer quatre valeurs centrales : la communication permanente entre le client et l'équipe de dévelop- pement : le premier fait idéalement partie intégrante de l'équipe ou est du moins à portée de main et décide des priorités des fonctionnalités à réaliser. La communication est continue également au sein de l'équipe, qui doit à tout moment avoir la même vision de l'application, et dont aucun individu ne doit être irremplaçable ;
la simplicité des éléments produits par le projet : les développeurs reviennent en permanence sur le code déjà produit pour le simpli er et le minimiser en regard des nouveaux développements (cette pratique est appelée refactoring [43]), et la production d'autres livrables est limitée
au strict nécessaire.
des retours fréquents, continuels, sur le développement du projet, à travers notamment des tests unitaires de non régression répétés, et des itérations très courtes, durant entre une et quatre semaines.
et en n, le grandiloquent courage d'admettre ce qu'on peut ou ne peut pas réaliser en temps et en heure, a n d'avoir toujours une plani cation réaliste.
Là où le Processus Uni é et la méthode RAD sont des processus de dé- veloppement guidés par la description de scénarios d'utilisation, un projet eXtreme Programming est guidé par la description des tests : le client écrit les tests de véri cation d'une fonctionnalité avant que celle-ci ne soit déve- loppée. De même, les développeurs écrivent les tests unitaires avant même de coder.
Les douze pratiques préconisées par eXtreme Programming et dé nies dans [7] sont alors les suivantes :
1. Le jeu du planning : il consiste à plani er juste après chaque itération le contenu et la durée de l'itération suivante, en tenant compte des priorités xées par le client et des estimations des di cultés techniques. 2. Petites livraisons : un exécutable est livré au client à chaque itération,
pourvu à chaque fois de nouvelles fonctionnalités.
3. Métaphores : un schéma, diagramme ou une description littéraire très brève doit permettre de représenter l'application assez simplement pour que toute l'équipe aie la même vision du développement. La métaphore utilisée doit être compréhensible par tous, nécessiter pas ou peu de maintenance au cours du déroulement du projet.
4. Conception simple : garder une conception de l'application la plus simple possible. Continuellement traquer et simpli er les aspects com- plexes.
5. Tests : le client écrit les tests pour les fonctionnalités, les développeurs écrivent les tests unitaires avant de coder, et ces tests sont eectués régulièrement pour véri er la non-régression de l'application.
6. Remaniement : utiliser régulièrement les techniques de refactoring pour enlever le code dupliqué, le code mort, et le simpli er.
7. Programmation en binôme : les programmeurs travaillent en équipe de deux, l'un écrit le code, pendant que l'autre véri e sa correction et sa li- sibilité, et les choix techniques sont eectués en commun. Cette pratique
3.2. PROCESSUS ET DIFFICULTÉS DE MISE AU POINT 87 qui semble scandaleuse et peu grati ante est très e cace pour garantir un codage homogène compréhensible par toute l'équipe et maintenable sur le long terme.
8. Propriété collective : tout le monde est capable et peut si nécessaire modi er n'importe quelle partie du code de l'application.
9. Intégration continuelle : dès qu'une tâche d'implémentation est termi- née et testée, on procède à l'intégration, même plusieurs fois par jours selon les projets.
10. Semaine de quarante heures : comme un développeur fatigué travaille moins bien, les heures supplémentaires ne sont pas autorisées deux se- maines de suite.
11. Client sur place : un client ou un représentant du client est disponible à plein temps, pour aider à concevoir le logiciel, répondre aux questions, et écrire les tests d'intégration.
12. Standards de code : les programmeurs adoptent et respectent à la lettre un standard de code. Ce standard bien respecté, il doit être impossible de distinguer qui a écrit quelle partie de l'application.
Les principaux avantages de la méthode eXtreme Programming sont qu'elle permet de fournir une application facilement maintenable car bien écrite, de manière homogène et compréhensible et également d'éviter qu'un des dé- veloppeurs ne devienne si indispensable que son départ constitue un gros risque pour le projet. Pourtant, et malgré le principe de la programmation en binôme qui peut sembler de prime abord humiliant pour un dévelop- peur expérimenté, eXtreme Programming et les autres méthodes agiles sont les processus qui donnent le plus d'importance au travail des développeurs, laissant à leur charge la qualité de l'application, les re-plani cations perma- nentes, et éliminant au maximum les livrables supplémentaires à produire au cours du projet.
Le principal inconvénient d'eXtreme Programming est qu'il est di cile d'obtenir la coopération du client, qui préfère en général avoir un contrat en béton armé dé nissant la livraison de toutes les fonctionnalités du projet qu'il a dé ni au tout début à une date donnée, et ne pas avoir à s'occuper de ce qui se passe entre la signature et la livraison.
Ces méthodes sont donc de fait plus adaptées lorsque le client, l'utilisateur nal, fait partie de la société. Dans le domaine du jeu vidéo, le game-designer peut très bien jouer le rôle du client dans le cadre de ces méthodes.