Méthode agile… la méthode avant tout !

La méthode agile est de plus en plus utilisée dans le secteur de l’informatique. Mais il ne faut pas la considérer comme un procédé incontournable, car pour être efficace, elle demande beaucoup de rigueur.

Le principe de base de la méthode agile est simple : il s’agit de créer par itérations, chacune d’entre elles donnant lieu à une mise en production auprès des utilisateurs, puis à une mise à jour des spécifications de l’itération suivante, le tout grâce à la tenue de réunions de suivi régulières.

Le produit informatique étant immatériel, le coût de mise en production d’une nouvelle version est négligeable. Donc pourquoi ne pas affiner le produit directement au contact de ceux qui vont l’employer ?

L’idée est extrêmement séduisante : l’utilisateur est alors mis au centre du processus de conception, pour un résultat qui ne peut que le satisfaire. Cette méthode s’applique particulièrement à la conception d’applications personnalisées, où il est impératif que le logiciel soit en adéquation avec les besoins des utilisateurs.

La méthode agile est-elle donc incontournable ? Mon analyse est plus nuancée…

Avantages et inconvénients théoriques de la méthode agile

Inclure les utilisateurs en livrant de façon itérative est une bonne solution dans les cas suivants :

• Le métier est particulièrement complexe ou innovant, et donc, difficile à aborder : une démarche itérative évite les erreurs de conception dues aux incompréhension.
• Le volume d’utilisateurs est très faible : la coordination est très simple.
• L’ergonomie ou les fonctionnalités sont novatrices : le retour des utilisateurs est essentiel.

Par contre, il vaut mieux éviter les méthodes agiles dans les cas suivants :

• Le projet est l’implémentation directe de la stratégie de l’entreprise : la méthode agile peut faire perdre de vue l’objectif principal du projet, qui disparaît au fur et à mesure des itérations.
• Il n’y a pas de rôles clairement définis chez le client. La démarche itérative reposant sur la coordination d’acteurs ayant tous un rôle bien précis, la prise de décision est rendue très complexe par leur non définition.
• Le projet comporte une part importante de recherche. La R&D doit être confiée à la direction technique en premier lieu, la démarche de recherche étant agile par définition, mais pas agile dans le sens des méthodes agiles...

Sur le terrain, la réussite de la méthode agile demande le suivi de chacune de ses règles[1]. Or, son application s’accompagne parfois de l’oubli plus ou moins conscient de ce cadre strict, et donne lieu aux comportements suivants :

• Itération sans livraison. Ne pas passer par l’étape de la mise en contact de l’application avec les utilisateurs augmente le risque de hors sujet (règle 3).
• Itération sans rédaction de documentation ou validation technique. Le plan de l’application doit évoluer en restant lisible si on prend le projet de A à Z (règles 9 et 11).
• Itération sans recette complète. Le métier et la technique doivent collaborer pour valider un cahier de test reprenant les processus dans leur globalité, afin que l’application soit fonctionnelle, (règles 4, 7 et 12).