Les méthodes agiles

Cet article fait suite à ceux consacrés au cycle en V et au cycle itératif. Dans l'histoire des méthodes de gestion de projets informatiques, les méthodes agiles sont une évolution relativement récente qui tente de résoudre certains défauts des pratiques qui étaient en usage jusque là.

Le manifeste agile

La définition de toutes les méthodes agiles est synthétisée par le Manifeste agile, qui a été rédigé en 2001 par plusieurs acteurs de ce domaine. Il distingue 4 valeurs fondamentales et 12 principes.

Les 4 valeurs

(traduction © Wikipedia et al)

• L’interaction avec les personnes plutôt que les processus et les outils.
• Un produit opérationnel plutôt qu’une documentation pléthorique.
• La collaboration avec le client plutôt que la négociation de contrat.
• La réactivité face au changement plutôt que le suivi d'un plan.

Les 12 principes

(traduction © Wikipedia et al)

• Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
• Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
• Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
• Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.
• Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
• La méthode la plus efficace de transmettre l'information est une conversation en face à face.
• Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
• Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
• Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
• La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
• Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
• À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Application concrète

Il existe plusieurs méthodes qui suivent l'esprit du manifeste. Elles ont chacune leurs spécificités, mais de manière globale elles œuvrent toutes dans les mêmes voies.

• Le client, qu'il soit interne ou externe, est intégré au plus près du projet. Il est informé des avancements et des problèmes rencontrés. Le but est de produire un logiciel qui satisfasse le client, et non qui respecte à la lettre la spécification fonctionnelle rédigée plusieurs semaines ou mois auparavant. Il faut donc valider fréquemment que la direction prise est celle qui mène à sa satisfaction effective.
• Les équipes sont réduites, avec peu de distinction hiérarchique, et les collaborateurs peuvent se faire confiance les uns les autres. L'analogie employée est celle d'une escouade de guerilla, plus rapide et efficace qu'un énorme bataillon d'infanterie. En diminuant le nombre d'intervenants, on optimise les communications.
• Les livraisons de logiciel sont rapides. Chaque version est ainsi plus "légère" : elle est plus rapide à installer et à tester. Il est plus facile de changer d'orientation sur un projet quand chaque évolution "coûte" peu, et évite d'avoir à modifier des fonctionnalités qui ont déjà été développées.

Comme pour toute méthode de gestion de projet, le but des méthodes agiles est de réussir à sortir de meilleurs logiciels (du point de vue du client) pour un coût moindre (principalement grâce à une réalisation rapide). Pour expliquer leur fonctionnement, je dis souvent qu'il s'agit de la mise en place d'un cycle itératif sous stéroïdes. Les développement reste itératif, mais en tentant de raccourcir au maximum la durée du cycle.

Risques et écueils

Un des principaux écueils qui peuvent être rencontrés quand on décide de mettre en place ce type de méthode dans un groupe de projet, c'est que la frontière est parfois ténue entre l'application de la méthode et le "n'importe quoi" qui s'installe quand on laisse travailler une équipe sans méthode. Beaucoup de gens n'y voient qu'une structuration des plus mauvaises pratiques du monde de l'entreprise :

• La réactivité, c'est lorsque le client change sans arrêt d'avis, et qu'on s'efforce de le suivre comme une girouette.
• La mise en place d'une équipe réduite, c'est quand on n'a pas assez de développeurs et qu'on leur donne plus de travail à faire que ce dont ils sont capables.
• Les cycles de développement ultra-rapides, c'est quand on n'a pas le temps de tester correctement les nouvelles version, et qu'on est obligé de faire des versions de correction en urgence quand le client découvre des bugs.
• Sans parler des développeurs incapables d'écrire la moindre documentation technique, des chefs de projet qui ne veulent pas faire de planning, ni des outils de suivi inexistants...

Cela est assez vrai. Mettre en place une méthode agile nécessite que tous les acteurs soient impliqués dans le processus, en connaissent les avantages et acceptent de jouer le jeu. Certaines personnes n'ont pas la flexibilité d'esprit nécessaire pour y arriver et ont besoin de méthodes plus directives (cf. cycle itératif).

Mais si vous réussissez à mettre en place les outils nécessaires et à former les gens, vous pourrez focaliser l'équipe sur un but commun : la réalisation du projet. C'est une grande avancée par rapport à d'autres méthodes, qui sont basées sur l'affectation de tâches à des employés (tel des robots) et leur surveillance par leur hiérarchie. L'objectif est de réussir le travail, pas de permettre à une ou plusieurs personnes de jouer les petits chefs en faisant claquer le fouet au-dessus des têtes.