Les méthodes agiles : agile oui mais surtout méthode!

cadavre

Le cadavre exquis, application dans l’Art de la méthode agile

Scrum, XP, DSDM, FDD… derrière ces acronymes se cache un concept de méthode de conception et de fabrication de produits informatique : la méthode agile. Le principe de base est simple : le produit informatique est immatériel, donc le coût de mise sur le marché (en production) d’une nouvelle version est négligeable par rapport à celui de n’importe quel autre secteur de l’industrie. Donc pourquoi ne pas proposer des mises en production en cours de réalisation, pour pouvoir affiner le produit directement au contact de l’utilisateur ?

En ce qui concerne la définition de la méthode, je vous propose de lire la fiche Wikipedia de description de la méthode agile, et en particulier les principes fondamentaux que je ne vais pas énoncer dans l’article. Je rappelle juste que le principe de la méthode agile est de créer le produit par itérations, chaque itération donnant lieu à une mise en production auprès des utilisateurs et à une mise à jour des spécifications de l’itération suivante, le tout suivi par des réunions et comités réguliers.

L’idée est extrêmement séduisante : l’utilisateur est alors mis au centre du processus de conception, et y participe activement pour un résultat qui ne peut que le satisfaire. Cela s’applique particulièrement au métier de la conception d’applications personnalisées, où le constat à éviter absolument lors de la mise en production de l’application est que l’orientation du produit ne soit pas en adéquation avec les besoins des utilisateurs. Vous pensez donc : « est-ce donc le design pattern idéal de Marc Lemaire et de Yoocan ? ».

Ma réponse est plus nuancée, et je vais la développer en évoquant en premier lieu le principe de la méthode, ses avantages et ses inconvénients, puis son implémentation (car non tout ne se passe pas comme dans le manuel!).

1) Avantages et inconvénients en théorie

Sur le principe 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 et difficile à aborder : une démarche itérative évite les erreurs de conception dues à une mauvaise compréhension
  • Le volume d’utilisateurs est très faible : la coordination est très simple
  • L’ergonomie ou les fonctionnalités sont très innovantes : le retour des utilisateurs est essentiel sur un fonctionnement complètement nouveau
  • Le métier de l’utilisateur est innovant pour la même raison

D’un autre côté, également sur le principe il vaut mieux éviter ce type de méthode dans les cas suivants :

  • Le projet est une V1 avec un budget ou un temps limité : la méthode itérative demande du temps et en particulier du temps de réunion, donc c’est peu adapté pour un produit dont la phase de développement doit être la plus rapide possible.
  • Le projet est l’implémentation directe de la stratégie de l’entreprise : l’itération peut faire perdre de vue l’objectif principal du projet, et l’objectif d’évolution stratégique disparaît au fur et à mesure des itérations.
  • Il n’y a pas de rôles clairement définis chez le client (notamment pas de rôle de décision) : la démarche itérative demande la coordination des acteurs, chacun ayant un rôle bien précis. La non définition de ces rôles rend la communication et la prise de décision très complexe.
  • Un projet avec une part importante de recherche : la recherche et développement doit être confiée à la direction technique en premier lieu. La démarche de recherche est agile par définition, mais pas agile dans le sens des méthodes agiles.

2) Dans la pratique : les écueils à éviter

Dans la pratique, la réussite de l’application d’une démarche agile demande le bon suivi de chacun de ses règles.

Or l’application de cette méthode s’accompagne parfois de l’oubli conscient ou non de ces règles, et donne lieu aux comportements suivants

  • Itération sans livraison : il faut dans une démarche agile que l’application soit mise au contact des utilisateurs (règle 3). Ne pas passer par cette étape et itérer sans contact en vie réelle augmente considérablement le risque de hors-sujet, plus parfois que pour un cycle en V classique.
  • Itération sans rédaction de documentation ou validation technique (règles 9 et 11) : l’application évolue et donc son plan doit évoluer en restant lisible si on prend le projet de A à Z. Si vous créez un cagibi et ajoutez les pièces pour obtenir une maison au fur et à mesure, il paraît être du bon sens de maintenir un plan complet. Ce bon sens a tendance à être oublié au quotidien dans la conception d’un produit informatique.
  • Itération sans recette complète (règles 4, 7 et 12) : ces règles utilisent le terme d’applications fonctionnelles. Cela signifie que l’application doit être complètementfonctionnelle, et donc le métier et la technique doivent collaborer pour valider (même si l’évolution ne porte que sur une part du métier) un cahier de test reprenant les processus dans leur globalité.

Pour moi le problème de la non compréhension de l’intérêt de la méthode agile réside dans son nom. Le nom d’agile convient pour exprimer la qualité de cette méthode pour stimuler la créativité technique et fonctionnelle, et obtenir des produits innovants et proches du besoin final. Mais il y a une tendance à confondre agilité et manque de rigueur.

Durant ma carrière j’ai rencontré de nombreux chefs de projets ou dirigeants qui pensent qu’implémenter une méthode agile permet de ne suivre aucun plan de développement et de ne travailler qu’au fil de l’eau, sans cadre. Or au contraire l’application d’une méthode agile demande un surcroit de rigueur dans le suivi technique et fonctionnel, et ce afin d’éviter d’aboutir à une usine à gaz impossible à maintenir.

En conclusion, si vous voulez obtenir un beau cadavre exquis, il faut que tous les dessinateurs connaissent leur métier, leur rôle et leur style. Sinon vous obtiendrez un infâme gribouillis inexploitable.

Une réflexion au sujet de « Les méthodes agiles : agile oui mais surtout méthode! »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>