Agile : c'est beau, c'est chaud, mais qu'est-ce que c'est ?

Apr 7, 2011 − Si vous n'avez pas déjà entendu parler des méthodes Agiles, c'est que vous devez vivre dans une grotte depuis quelques moments déjà. On en entend parler partout, elles sont vendues comme étant la réponse à tous les maux, mais qu'est-ce que le terme Agile signifie exactement ? Pourquoi vous devriez vous y intéresser et comment faire comprendre à votre client que c'est actuellement la méthode la plus efficace pour mener un projet informatique à bien ?

Si vous n'avez pas déjà entendu parler des méthodes Agiles, c'est que vous devez vivre dans une grotte depuis quelques moments déjà. On en entend parler partout, elles sont vendues comme étant la réponse à tous les maux, mais qu'est-ce que le terme Agile signifie exactement ? Pourquoi vous devriez vous y intéresser et comment faire comprendre à votre client que c'est actuellement la méthode la plus efficace pour mener un projet informatique à bien ?

Voici quelques réflexions sur le sujet.

Ce qu'on lit partout

On entend parler du manifeste agile, de l'importance des interactions entre personnes plutôt que l'utilisation d'outils, du fait qu'un logiciel qui marche vaut plus que toute documentation, ...

Trêve de blabla, trêve de blabla. Même si tout ceci est vrai, je pense qu'il faut d'abord comprendre la vision globale de l'agilité avant de rentrer dans les détails de sa mise en œuvre.

Comment je le résume

Travailler de manière agile, c'est adapter un projet et (surtout) ses acteurs à la réalité. En effet, adapter la réalité au projet marche rarement, même si c'est ce que beaucoup essaient de faire tous les jours.

• Développeur : On ne sera jamais prêt à temps pour la deadline
• Chef de projet : Bidouillez un truc ou deux ça se verra pas et ça ira plus vite
• Développeur : Si on rogne sur la qualité, les bugs vont s'accumuler et ça sera encore pire
• CP : Oui mais on ne peut changer ni la date ni les fonctionnalités, alors débrouillez vous, travaillez le Week-End s'il faut !

Et 3 mois plus tard :

• Développeur : rien n'est utilisable dans l'état on ne peut pas livrer. Et en plus, on est à bout.
• CP : Bah on est bien tintin !

La réalité rattrape toujours le management "par le miracle". Alors autant prendre en compte la réalité des projets informatiques dès le début, et apprendre à composer avec.

Réalité des projets informatiques

Si vous avez eu l'occasion de gérer quelques projets informatiques, où tout du moins eu l'occasion d'y participer, vous devriez être conscient des choses suivantes :

• il est impossible de réunir toutes les spécifications d'un projet dès le début
• quelques soient les spécifications que l'on est capable de recueillir, elles seront amenées à changer dans le temps
• il y aura toujours plus de choses à faire que d'argent et de temps pour les réaliser

Il faut vous mettre ça dans la tête, une bonne fois pour toute. Si si, relisez ces 3 vérités encore une fois. C'est peut être difficile à accepter pour certains "décideurs", mais c'est la réalité. Et on n'échappe pas à la réalité (par contre, on peut se la cacher, c'est un autre problème) ;-)

La question maintenant est : c'est bien beau de ne rien savoir à l'avance, mais mon budget et mon cahier des charges, j'en fais quoi, moi ?

Vous allez devoir faire face à la bête noire des informaticiens : la communication avec le client. Pardi. Le quoi ? Mais oui vous savez le client, celui qui vous paye votre salaire à la fin du mois. Le vrai gens qui va utiliser votre vrai/faux logiciel !

La communication avec le client

Une fois que vous serez convaincu par la réalité des projets informatiques, il faudra convaincre votre client de cette réalité. Et croyez moi ce n'est pas si difficile que ça (encore faut-il essayer). Des projets informatiques hors délais, hors coûts, avec des devis supplémentaires pour les nouvelles fonctionnalités, il a déjà dû en connaître. Dire à votre client que vous êtes conscient de la réalité et que vous, vous allez mettre quelque chose en place pour tourner cette réalité à votre avantage, c'est plutôt bien perçu.

Et comment vous la tournerez à votre avantage cette réalité (un peu galère il faut le dire) ? En réalisant un logiciel fonctionnel pour une date donnée et un prix donné. Ça ressemble à de la science fiction quand on parle de projet informatique, et pourtant c'est réalisable.

Flexibilité et changement

Mais il n'y a pas de miracle, pour que tout ce que je viens de vous dire puisse fonctionner il faudra être flexible (et donc agile !), aussi bien vous que votre client. Vous devrez autoriser le client à changer d'avis, prendre en compte ses nouvelles fonctionnalités et globalement accepter le fait que toutes les 2 semaines, les choses peuvent changer.

Une fois que votre client aura été sensibilisé à la réalité des projets informatiques, il faudra lui faire comprendre que ce qui est important pour lui, c'est d'avoir un logiciel fonctionnel qui apporte la plus grande valeur ajoutée finale à l'utilisateur. Ce qui est important ce n'est pas le nombre de fonctionnalités implémentées, c'est la vraie valeur ajoutée qu'apportent celles qui sont implémentées.

La règle des 20/80 s'applique aussi ici : 20% des fonctionnalités représentent 80% de la valeur ajoutée du logiciel. Le client peut avoir une bonne raison de vouloir toutes les fonctionnalités "absolument", mais la réalité le rattrapera aussi et c'est à vous de le sensibiliser à ça. Je ne dis pas que c'est facile, mais sans un certain talent en communication votre projet bat déjà de l'aile, avant même d'avoir commencé.

Pour que vous vous puissiez tenir le délai (et donc le budget) il faudra qu'il accepte d'adapter les fonctionnalités (vous vous rappelez la 3 ème réalité des projets informatiques ?). On a toujours les yeux plus gros que le ventre (ou que le budget si vous préférez). Pour qu'il ait un logiciel 100% fonctionnel pour ses utilisateurs, il faudra que vous acceptiez de changer de priorité et de développer des fonctionnalités non prévues au départ. C'est donnant donnant.

Si le client ne veut rien lâcher, ni sur le temps (la date de livraison), ni sur l'argent, ni sur les fonctionnalités je vois deux possibilités :

• vous n'êtes pas encore prêt à vendre de l'agile, et il faut encore vous entraîner un peu et parfaire votre discours
• vous faites bien de ne pas travailler avec ce client : le projet aurait été un fiasco pour vous deux de toute façon. Autant que ça soit quelqu'un d'autre qui se plante avec ce client. Mais au moins, vous, vous l'aurez prévenu.

Ça ne convient pas à tout le monde

Il faut garder quelque chose à l'esprit. Toute cette communication, que ce soit au début du projet ou tout au long de celui-ci engendre une transparence assez peu habituelle. Même s'il est toujours bon de soulever les problèmes tôt que trop tard, tout le monde n'est pas prêt à entendre et à accepter ça.

Dire à quelqu'un "attention là vous allez dans le mur", ou "attention, ce que vous demandez ne sert à rien, et vous coûtera de l'argent pour pas grand chose" ce n'est pas toujours chose aisée, et tout le monde n'est pas prêt à l'entendre. Assurez-vous en dès le début du projet, pour éviter les mauvaises surprises et prises de tête ensuite.

Le mot de la fin

Oui on peut vendre un projet agile à budget fixe et à date de livraison fixe. Il vous faudra juste pour cela faire comprendre à votre client que le logiciel n'aura pas toutes les fonctionnalités auxquelles il avait pensé. En revanche il en aura peut être d'autres (auxquelles il n'avait pas pensé), et celles qu'il aura marcheront et serviront à quelque chose (elles apporteront la plus value attendue du produit final).

J'espère que vous avez une idée un peu plus précise de ce qui fait la qualité et la difficulté des méthodes agiles après la lecture de ce post. Vous pourrez ensuite les mettre en œuvre avec Scrum ou autre, peu importe. Ce qui importe c'est votre état d'esprit, et le temps et la communication que vous êtes prêt à partager avec le client : ça vaut toutes les spécifications au monde.

Si vous cherchez un livre qui prêche cette bonne parole, je vous conseille grandement The Agile Samurai, c'est un vrai bonheur.