• Arnaud Mauduit

L'Histoire de l'agilité


L’agilité a vu le jour dans les années 1990 dans le milieu de la construction et des travaux publics.


A cette époque plusieurs personnes font un triple constat, notamment le chercheur finlandais Lauri Koskela :


  1. Les grands projets de construction échouent généralement à réaliser leurs objectifs dans les délais prévus, ils ne tiennent pas leurs budgets, et même très souvent le résultat final ne satisfait pas le client. Les dépassements budgétaires sont donc très courant.

  2. Second constat, l’incertitude beaucoup plus que les aléas est la cause de ces dérives : Contrairement à ce que l’on peut penser, ce ne sont pas les petits écarts par rapport à ce qui est prévu (les aléas) qui mettent les projets à rude épreuve : un grand chantier ne sera pas en retard parce qu’un lot de fenêtre va arriver avec un tout petit délai ou que la pluie va arrêter momentanément le chantier ! Ce qui est la cause de ces dérives c’est qu’au début du projet on ne sait pas tout, il y a beaucoup d’incertitudes, et surtout on refuse de l’admettre.

  3. Troisième élément du constat : au milieu de ces chantiers, les chercheurs repèrent que quelques personnes ont des résultats très nettement supérieur à la moyenne, et que, en regardant de près, ces gars ont des pratiques tout à fait atypiques, ils privilégient le collectif et l’équipe, la proximité avec le client et la flexibilité.


Après quelques temps, l’agilité va migrer de la construction à l’informatique qui souffre des mêmes mots. En 2001 (une dizaine d’année après les chantiers), des informaticiens se réunissent et sortent au bout de quelques jours ce qu’on appellera le manifeste agile et qui signe la seconde date officielle de l’agilité.


Très simplement l’agilité repose sur trois grands principes :


  1. Accepter et même accueillir l’incertitude, plutôt que dans les méthodes classiques qui cherchent à réduire tout ce qui est incertain en voulant maitriser tous les aléas, il faut plutôt faire comme le judoka qui se sert de la vitesse de son adversaire comme une arme et prendre l’incertitude véritablement comme une opportunité.

  2. Le deuxième principe est de mettre les clients au cœur du projet et au cœur du développement. Toute l’équipe sans exception doit littéralement être obsédée par les clients.

  3. Le troisième principe proclame que la réussite ne peut être que collective, que seul des équipes et des collectifs soudés vont réussir à surmonter l’ensemble des difficultés du projet. Il est donc essentiel que la direction du projet mais aussi le management de l’entreprise fassent confiance à la capacité des collectifs de développement à s’organiser, ils possèdent en eux des capacités absolument extraordinaires et insoupçonnées dont il faut savoir se servir.


Ces trois principes : accueillir l’incertitude, être obsédé par le client et donner la primauté au collectif, lorsqu’ils sont correctement appliqués, ont une efficacité redoutable et permettent de développer des produits qui n’existent pas.


Toutefois, cette activité est très difficile et au même temps très gratifiante.


Difficile parce que travailler dans l’incertitude est compliqué, cela génère beaucoup de doute, beaucoup de questions et de frustrations. Il est souvent plus tranquille de préférer la certitude des procédures pré-établies.


Mais au même temps, c’est très gratifiant parce que lorsque l’équipe voit les premiers clients acheter le produit qu’on vient de développer et en ayant le sourire, il se crée un sentiment de fierté et de satisfaction absolument irremplaçable.

Les quatre graphes ci-dessous illustrent la différence entre un développement Agile et un développement classique en cascade selon 4 axes d’analyse (Visibilité, Adaptabilité, Business Value, Risque).


La visibilité :


Dans une méthode classique, la visibilité est forte présente au début du projet, c’est-à-dire lors des spécifications. On la perd au fur et à mesure que le projet (les développements) avance.


Cette visibilité on la récupère quand la fin du projet approche (lors de la recette où l’on procède à des ajustements pour aligner le besoin métier avec les livrables).


Dans la méthode agile le client est impliqué dès le début du projet jusqu’à la fin, pas de spécifications en masse (on parle plutôt de User Story), on procède par des livraisons incrémentales à la fin de chaque sprint.


Du coup la visibilité maintient une allure presque stable, le but est d’éviter l’effet tunnel et de livrer progressivement des briques utilisables du produit final.


L’adaptabilité :


Les méthodes classiques souffrent de cet aspect d’adaptabilité, dès que les spécifications sont figées, les développeurs attaquent leurs développements à l’aveugle. Toute modification tardive coûtera plus cher car l’impact peut être énorme (on parlera d’évolution).


Contrairement aux méthodes agiles, les développements sont réalisés en briques, toute brique est testée et réalisée séparément. Au besoin, on peut modifier une composante lors d’un second sprint.


Certes il y aura des dépendances dans certaines briques qui lors des modifications impacteront d’autres. Malgré cela, la courbe d’adaptabilité des méthodes agiles reste plus avantageuse que celle des méthodes en cascade.


Business Value :


Du fait que l’on procède par des livraisons incrémentales, le produit verra le jour assez rapidement et commencera à être utilisé malgré que toutes les fonctionnalités ne sont pas encore achevées (on parle de MVP). Ceci augmentera la curiosité du client qui s’impliquera naturellement plus qu’il l’aurait fait si il devait attendre la livraison jusqu’à la fin du projet comme dans la méthode en cascade.






Risque :


Toujours grâce à l’aspect incrémentale des livraisons, le projet aura moins de risque à aboutir à ses fins car il a été revu plusieurs fois à la fin de chaque sprint. Si pour une raison donnée une brique ne répond pas au besoin du client, l’équipe peut se rattraper rapidement lors du prochain sprint avant de s’enfoncer plus dans l’erreur.


Le plus grand inconvénient de la méthode en cascade c’est le risque, car tout est à découvrir vers la fin du projet quand tout sera livré, en ce moment les surprises font apparition et les débats budgétaires deviennent sujets d’actualité.

49 vues

Posts récents

Voir tout