Les méthodes agiles

Petit tour d'horizon sur les idées reçues des méthodes agiles.

Publié le 10 septembre 2012, catégorie boulot
Tags: agile, gestion, methodologie, projet, scrum

Les méthodes agiles, c’est quoi ?

Habituellement, on décrit les méthodes agiles par opposition aux méthodes de développement dites classiques. Alors qu’habituellement on enchaîne les différentes étapes du cycle en V les unes après les autres, la méthode agile propose un découpage du projet en taches plus ou moins indépendante, dont la particularité principale est que chacun doit être réalisable dans un délai très court (pas plus d’une journée ou deux, par exemple). Chaque tache étant plus ou moins indépendante et réalisable rapidement, on peut ainsi livrer souvent. Chacune des livraisons permet ainsi de valider l’adaptation du produit aux besoins, et on corrige ainsi les erreurs au fur et à mesure de la vie du projet.

Est-ce que la méthode agile va nous faire développer le produit plus vite ? Non. Je dirais même qu’un projet développé en agile va prendre un peu plus de temps qu’avec une méthode classique.

Est-ce qu’on va faire le projet pour moins cher ? Non plus.

Alors, quel en est l’intérêt ? La flexibilité apporté va permettre d’adapter ce qu’on produit aux besoins du client. L’intérêt principal, c’est qu’à la fin, on livre ce dont notre client a besoin, ni plus, ni moins. Si dès le début d’un projet, on sait exactement ce que l’on veut, si l’on est certain qu’il n’y aura aucun aléa, et que personne ne va changer d’avis, et que le contexte n’aura pas bougé, alors une méthode classique conviendra mieux : plus rapide, moins cher. Mais si on ne sait pas tout à fait ce qu’on veut, si l’alignement SI-stratégie est susceptible de changer en cours de route (et pour un projet de six mois, ça va changer), si on doit être réactif, alors une méthode agile conviendra mieux : avec elles, on peut s’attaquer à une cible mouvante, et réagir vite.

Les livraisons

Pierre angulaire des méthodes agiles : les livraisons fréquentes et régulières. Pour bien comprendre cet aspect, il faut définir les trois termes :

Livraison
la livraison est surtout défini par ce qu’on livre : un logiciel fonctionnel, utilisable, directement dans les mains des utilisateurs. Il ne faut par contre pas croire qu’une livraison est forcément une mise en production : il vaut mieux faire des livraisons en recette souvent à un public de testeurs, et de faire tester l’application par des utilisateurs experts. On peut très bien faire une version en recette par semaine, et de ne livrer en production que tous les six mois.
Fréquente
on doit livrer le plus souvent possible, tout dépend de la complexité du logiciel et des méthodes de livraison. Cela peut aller d’une fois par semaine à une fois par mois.
Régulière
quand on met en place un cycle de livraison, on s’y tient. Il vaut mieux ne pas livrer tout ce qu’on avait prévu, mais de livrer quand même.

L’idée derrière la livraison fréquente et régulière est de laisser les utilisateurs experts tester l’application, et faire des retours.

Par contre, chaque cycle de développement une fois défini est inaltérable. Lorsque l’on a défini ce qu’on doit livrer au prochain cycle, il est hors de question de le modifier. Tout au plus on pourra accepter de réaliser des corrections de bugs gênants. C’est le respect de cette règle, et cette règle seul, qui va permettre de déterminer si on gère un projet en mode agile, ou si on tente de gérer un gros bordel ingérable. Toute modification de contenu ou de spécification doit être reporté au cycle suivant.

La conception

J’ai souvent entendu dire que les méthodologies agiles ne sont pas compatibles avec la conception du projet (que ce soit de la macro-conception (on parle alors d’architecture), ou de micro-conception (on parle alors d’analyse)). Rien n’est plus faux.

Certe, il n’y a pas de phase spécifique pour la conception, mais il ne faut pas oublier que la méthode agile ne va pas à l’encontre du cycle en V. Bien au contraire. Le principe fondateur des méthodes agiles n’est pas de casser le cycle de développement du projet mais de le morceler en entités indépendantes et rapides. Chacune de ces entités est un cycle en V à lui seul. Ainsi, à chaque fonctionnalité, il faut effectuer une phase de conception, le développement, et les tests.

Ainsi, une demande client, une étude de cas, un besoin utilisateur, ou un scénario d’utilisation, représente une fonctionnalité à implémenter. Chaque fonctionnalité doit faire l’étude d’une conception pour déterminer ce qui doit être fait, et comment. J’ai déjà parlé de cet aspect dans l’article L’alignement de l’architecture technique et l’organisation projet.

Cette conception est à la charge de l’architecte du projet, et ne peut être conduite que s’il a auparavant décidé et formalisé les principes d’architectures retenus : le découpage en couches fonctionnelles ou techniques, les principes de séparation, les normes de codage, etc.

Ensuite, avant chaque développement, il n’est jamais inutile de réfléchir à la façon dont on va développer la fonctionnalité demandée. La première question qu’on doit se poser est « comment va-t-on tester cette fonctionnalité ? ». Si on rend une fonctionnalité testable, alors elle devient réalisable. C’est la mise en place des tests qui va alors faire office de conception.

Certaines méthodes mettent l’accent sur l’architecture émergente du projet. Le principe est de ne pas faire d’architecture, mais de laisser faire l’analyse au fur et à mesure du projet et de voir ce qui en émerge. Cela ne peut fonctionner quà plusieurs conditions qui me paraissent restrictive. En particulier, chaque ingénieur doit avoir une vision du projet suffisamment large pour savoir quand modifier un cas particulier pour en faire un module générique. Cela va l’amener à refactoriser le code d’un de ses collègues, et donc à refaire le boulot que quelqu’un d’autre a fait. En pratique, je n’ai vu que des copier/coller avec trois modifications au milieu, et advienne que pourra.

Après, on n’est pas obligé non plus de faire une architecture figée : l’architecte pourra très bien n’énoncer que des principes d’architectures généraux (le découpage en couches logicielles, les technos manipulées, les normes de codages, et la mise en place du projet), et laisser des pans entiers pour une analyse et une mise en plan ultérieure en fonction des besoins. Placer le curseur entre faire une conception initiale forte ou la laisser émerger ne peut se faire qu’au cas par cas.

Le refactoring et les tests

Au bout de quelques cycles de développement, on arrive toujours à un moment à un point délicat. On n’a pas réalisé ce qu’on prévoyait de faire, on s’aperçoit que l’architecture initiale pourrait être améliorée, qu’il y a plein de choses qu’on avait remis à plus tard. Il est temps de faire une pause dans l’avancement des fonctionnalité, et de remettre le projet sur de bons rails.

Pour commencer, il n’est jamais inutile de faire une version blanche à intervalles réguliers. Cette version ne consiste pas en l’ajout de fonctionnalité, mais simplement en refactoring de code, d’amélioration de l’architecture, de maximisation de la maintenabilité du logiciel, optimisations du code, des temps de réponse, etc. Bref, transformer un logiciel qui fait son boulot, en un logiciel bien fait qui fait son boulot. Cette version blanche peut être organisée une ou deux fois par an, selon la complexité du logiciel. Elle vise à rendre le code maintenable et performant, même si ceux qui l’ont créé ne sont plus là pour le maintenir. Bien entendu, cela n’a de sens que pour des projets qui s’étalent sur plusieurs années.

Pourquoi cela n’est-il pas fait au fil de l’eau ? Parce que les urgences, la procrastination naturelle des ingénieurs, et tout un tas de facteurs font que même si le code est bien fait, il y a encore des choses à faire et à améliorer.

Évidemment, le refactoring ne peut être tenté que si la couverture en tests unitaires et tests d’intégration est suffisante pour garantir qu’on ne va pas apporter des regressions. Déjà que les fonctionnels ne sont pas chaud pour accorder une version blanche, mais si en plus ça doit marcher moins bien qu’avant…

Corollaire : si on n’a pas une couverture suffisante par les tests, alors l’amélioration du code est impossible. Si l’amélioration est impossible, la qualité du code ne peut que regresser, et si le code devient mauvais, il n’est plus maintenable, donc plus maintenu…

Envoyer un commentaire

Les commentaires sont relus pour modération avant publication.
Le formattage HTML basic est accepté.

Nom : (requis)
E-mail : (requis, non publié)
Site Web : (optionnel)