Agile pure et dure ou un pas vers l'agilité ? ...

Je vous entends me dire : "Il va encore nous parler encore d'une autre tendance à la mode, la saveur du moment, un buzzword, ...". Peut-être ... Toutefois, essayons de comprendre ce qui se cache sous cette méthode Agile (ou technique pour les puristes de méthodologie) qui dérange dans le monde des TI.

L'encyclopédie Wikipédia définit les méthodes Agiles comme étant des procédures de conception logicielle qui se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du besoin du client, et non des termes du contrat de développement. Comme dans toute chose, il n'y a pas une seule vision de ce qu'est la méthode Agile puisque qu'ils existent plusieurs implémentations : Rapid Application Development (RAD), Extreme Programming (XP), Scrum, etc. Mon intention n'est pas de vous vendre l'une ou l'autre de ces méthodes, ni de vous entretenir sur ce qu'elles sont. Mon intention est plutôt de vous exposer qu'est-ce qui fait défaut dans la réalisation des projets actuels en TI et l'urgence de modifier nos manières de faire.

Je n'invente rien, les échecs dans les projets en TI sont monnaie courante. L'échec prend différentes formes : insatisfaction du client et des utilisateurs parce ses besoins ne sont pas bien couverts, dépassement des coûts et retard dans la livraison, frustration de l'équipe de développement face à des spécifications incomplètes et un échéancier trop serré et nommez-les ! J'ai l'impression que dans mon domaine, un projet qui réussit est uniquement un projet livré dans les temps avec des profits avantageux pour une organisation. Le reste est accessoire. Cette approche nombriliste de certains chargés de projet me laisse perplexe et me fait douter de la capacité des méthodes de gestion de projet dites traditionnelles à mener à bien un projet informatique. Pourquoi ?

Un projet informatique, ce n'est pas :

• un processus linéaire;
• composé d'un groupe de ressources (terme largement utilisé et très péjoratif à mon avis) triées sur le volet que vous pouvez interchanger ou en ajouter à tout moment pour pallier à toute urgence;
• une livraison d'une solution qui ne convient pas, mais livrée dans les délais en respectant les coûts;
• une chose qui se fait toujours de la même manière et qu'on pourra toujours réaliser en utilisant les mêmes principes peu importe ce qu'il arrive.

Un projet informatique, c'est plutôt :

• une suite d'impondérables;
• composé d'une équipe de collaborateurs humains possèdant certaines qualités et défauts;
• une livraison d'une solution qui s'ajuste à l'évolution des besoins du client et qui lui donne entière satisfaction;
• une chose qui se déroule jamais de la même manière et qui demande d'être flexible.

Les méthodes Agiles visent justement à améliorer ces points et offre des techniques pour l'atteindre. Alors faut-il jeter nos bonnes vieilles méthodes ? Non !

En fait, c'est impossible pour une organisation de se convertir du jour au lendemain et de jeter tout ce qu'elle a utilisé pendant des années. Il faut faire un pas vers l'agilité, s'inspirer des techniques utilisées pour améliorer le déroulement interne d'un projet, mais aussi pour améliorer sa relation avec son client et lui livrer une solution satisfaisante.

Il faut minimalement :

• repenser le rôle du chargé de projet;
• restructurer nos équipes de développement;
• donner plus de latitude à votre équipe et leur faire confiance (auto-gestion);
• faire preuve de flexibilité et savoir s'adapter rapidement;
• accorder une place importante aux clients et aux utilisateurs.

Je vous invite à lire et prendre connaissance de chacune des méthodes dites Agile, d'aller chercher les meilleurs éléments et de les expérimenter. Arrêtons cette guerre de tranchées entre puristes. L'important n'est pas de se définir comme une organisation agile pure et dure, mais de bien réaliser notre travail. Être agile, c'est d'abord reconnaître qu'il faut être agile dans l'application de la méthode elle-même. Faisons preuve de gros bon sens !