Nous avons choisi de publier, ci-dessous, un article qui nous a été adressé par Christophe Rigo de la société Abyss CAD, éditrice de logiciels professionnels, sur la méthodologie « Agile » largement utilisée dans la gestion de projets par les SSII.
Popularisées par le monde de l’informatique les méthodes "Agiles" de gestion de projet tentent de donner plus de souplesse et de réactivité à la gestion de ce type de projets.
Nous avons tous été témoins de projets qui dérapent et au final n’aboutissent pas à leurs objectifs initiaux, ne se terminent pas en temps voulu, ne respectent pas le budget initialement alloué. Pourtant tout était prévu : équipe projet, chef de projet expérimenté, planning, PERT, GANTT, chemin critique, …
Alors comment améliorer cela ?
Revenons quelques instants à la genèse d’un projet informatique. Généralement, un projet est prévu pour créer un produit ou un service nouveau, ou encore améliorer l'existant (dans la suite de l’article nous parlerons du "produit", qu’il soit matériel ou immatériel). Il faut dans tous les cas que cette action implique quelque chose de nouveau, sinon ce n’est plus un projet mais une mise en production, une procédure déjà figée. Quand la décision de lancer le projet sera prise, l’organisation va mener cette aventure en tentant de maîtriser les caractéristiques de la gestion de projet :
- le produit, résultat à atteindre,
- la contrainte de calendrier,
- la contrainte de budget,
- la contrainte de qualité.
Le produit, comme je le disais, est au départ une idée et un résultat à atteindre, on espère intéressant, mais en partie inconnu. A ce stade, là encore pour un projet informatique, on ne peut généralement pas définir précisément le produit fini dans ses moindres détails. C’est pourquoi, les résultats concrets des projets informatiques doivent être complétés au fil du temps et s'éloignent généralement des spécifications initiales.
De là découle le reste des faiblesses des méthodes de gestion de projet traditionnelles. Car sur une spécification par définition incomplète, nous allons baser le calendrier et chiffrer le budget. D'où la difficulté à apprécier de façon fiable les deux paramètres que sont les contraintes de temps et de budget.
Méthodes "Agiles" : la clef du succès ?
Les méthodes "Agiles" essaient de remettre la définition du produit au cœur du processus projet. Contrairement aux méthodes traditionnelles qui figent des spécifications au départ et les hissent au rang d’icônes intouchables, les méthodes "Agiles" vont revoir continuellement le périmètre du produit pour l’adapter aux besoins exprimés par les utilisateurs finals du produit.
"Utilisateurs finals" ? C’est la première fois que j’en parle pourtant ne sont-ils pas les principaux intéressés par le résultat auquel prétend le projet ?
L’équipe projet est en contact permanent avec le représentant des utilisateurs, que nous désignerons par ‘Product Owner’ qui lui remontera les adaptations demandées ou les nouvelles fonctionnalités désirées.
Je vois venir les critiques : si le périmètre change continuellement alors le projet sera sans fin ...
Ce n’est pas faux, et si on laisse ce processus comme tel, on peut imaginer un projet sans fin. Mais le ‘Product Owner’ ne s’arrête pas à rédiger perpétuellement sa liste de nouveautés, telle une liste au père Noël. Il doit attribuer une priorité à chaque demande et tient à jour le ‘Product Backlog’, liste priorisée de ses demandes d’évolutions. Ces demandes seront toutes examinées au cours des réunions de planification des périodes de développement entre le ‘Product Owner’ et l’équipe de développement (team). Durant cette réunion, l’équipe projet prend l’engagement de développer un périmètre donné de nouvelles demandes. Ici commence une nouvelle période de développement : ‘le Sprint’.
Et là est le deuxième secret des "méthodes Agiles". A chaque itération dans le développement du produit, l’équipe projet doit livrer un produit pleinement (si possible) fonctionnel et testé dans le périmètre choisi. Ces périodes de développement sont courtes, entre 3 et 4 semaines. Ainsi le ‘Product Owner’ et les autres utilisateurs finals peuvent suivre régulièrement les avancées du projet et les nouveautés. Ils peuvent ainsi valider ou modifier certaines fonctionnalités.
Ces paliers sont aussi l’occasion pour les donneurs d’ordres de clore un projet facilement, à chacune des étapes définies, puisque la dernière itération est fonctionnelle même si le périmètre n’est pas exactement celui prévu à l'origine. Ainsi le travail n’est pas perdu alors que si tout avait été figé dès l'origine on aboutirait à une production insatisfaisante, voire inutilisable car ne correspondant plus aux besoins réellement exprimés.
Un autre avantage des "méthodes Agiles" est la gestion des ressources humaines de l’équipe projet. L’équipe dans son ensemble est plus impliquée, car des produits sont livrés à chaque étape de façon opérationnelle, sans attendre trop longtemps le produit fini, ce qui nuit gravement avec d'autres méthodes au moral de l'équipe qui ne voit rien de concret être fourni pendant un temps trop long. La sortie régulière de livrables opérationnels permet de donner des points de passage et de contrôle réguliers qui sont l’occasion de revoir les méthodes, d’analyser les dysfonctionnements et de proposer des axes d’amélioration pour l’ensemble des processus du projet (tenue du product backlog, communication Product Owner/team, fonctionnements interne de l’équipe de développement, …).
"Méthodes Agiles" : la panacée de la gestion de projet ?
... Sans doute pas, mais elles apportent un peu de fraîcheur dans le monde de la gestion des projets informatiques.
Une des principales lacunes des "méthode Agiles" est la difficulté de prévoir le calendrier global. En effet, puisque le périmètre des itérations de développement change régulièrement, comment prévoir que telle fonctionnalité sera opérationnelle à telle date. C’est difficile et cela pose beaucoup de problème pour tenir informés les donneurs d’ordres qui n’aiment en général pas être dans le flou.
Ensuite pour que cette méthode fonctionne, il faut que le rôle de ‘Product Owner’ soit tenu par quelqu’un qui connait parfaitement l’usage du produit développé. Le ‘Product Owner’ aura une responsabilité très importante dans le succès du projet. Beaucoup d’entreprises n’ont peut-être pas encore cette culture, et se reposent exclusivement sur l’équipe projet pour atteindre les objectifs. Sans ‘Product Owner’ impliqué, l’équipe projet développera un produit comme elle le perçoit et non pas comme les utilisateurs le souhaiteraient.
En conclusion, les "méthodes Agiles" permettent de développer un produit plus proche des besoins réels des utilisateurs finals. Elles sont aussi l’occasion de revoir l’organisation interne des équipes et leurs modes de fonctionnement. Pour autant, elles ne s’appliqueront peut-être pas à tous les types de projets, ni à toutes les organisations ...
Christophe RIGO