Agilité et Ingénierie des exigences

L’agilité évoque la souplesse, la réactivité, la flexibilité, …, en opposition aux approches traditionnelles prédictives et séquentielles de conduite de projet. Les méthodes agiles sont largement encouragées dans les projets IT, en adéquation avec la mentalité des nouveaux managers. Mais ces méthodes dites « agiles » sont-elles vraiment nouvelles ? Sont-elles réellement en opposition avec les pratiques de conduite de projet type CMMI ? Quels sont les points d’attention ou les limites de ces nouvelles méthodes ?

Bien des personnes associe le concept Agile à l’univers IT et au manifeste agile en 2001. Mais ce concept a commencé dès le début des années 90 dans une idée plus globale de transformation de l’entreprise. Il renvoie à la théorie du « design organisationnel » qui vise à une cohérence entre les objectifs structurant de l’organisation et la coordination des actifs stratégiques de l’entreprise. Ces principes repris par Roger N. Nagel avec lesquels le mot « agile » est apparu, datent des années 60.

Le concept Agile s’est basé sur différentes méthodes de génie logiciel comme l’eXtreme Programming, le RAD (rapid-application development), le DSDM (Dynamic systems development method) … et le SCRUM, approche plus rapide et flexible pour le développement de nouveaux produits.

SCRUM est la méthodologie actuellement la plus utilisée parmi les méthodes agiles existantes. Le principe de la méthode SCRUM, qui signifie mêlée, est celui d’une équipe qui avance ensemble, toujours prête à se réorienter au fur-et-à-mesure de sa progression, jusqu'à marquer l’essai.

Le terme "Agilité" définit une démarche qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type Cycle en V ou Waterfall (en cascade). La notion même de "gestion de projet" est remise en question au profit de "gestion de produit", de façon à raisonner davantage "produit" que "projet". Après tout l'objectif d'un projet consiste bien à donner naissance à un produit.

L’approche traditionnelle attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement.

Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre-productif. 

• Dans le cadre d'un projet, le client élabore sa vision du produit à réaliser et identifie les fonctionnalités ou les exigences de ce dernier. Cette liste permet d’avoir une estimation du budget global du projet.
• L'équipe de projet sélectionne ensuite les exigences à réaliser dans une portion de temps courte appelée itération ou sprint (2 à 4 semaines). Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c'est nécessaire, de développement et de test.
• A la fin de chacune de ces itérations, le produit « partiel » mais « utilisable » est montré au client. Le client peut alors se rendre compte rapidement du travail réalisé et de son alignement sur le besoin initial. Il peut se projeter et émettre des retours précieux pour les futures itérations. 

La visibilité sur le projet et la transparence entre les parties prenantes permet de consolider la relation client/fournisseur, d’identifier les risques éventuels et mener très tôt des actions de réduction des risques.

Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer le "time to market" s’il estime que le produit en l'état peut aller en production. Il réduit ainsi les coûts de production prévus pour les reporter sur le maintien de son système en production.

Il a également la possibilité de retarder la réalisation de fonctionnalités dont le besoin n'est pas mûr et ajouter de nouvelle fonctionnalité plus pertinente.  Cette souplesse est donc un véritable atout pour le client, notamment dans un marché en constante et rapide évolution. Le virage numérique que connaissent de nombreuses industries rend dorénavant cette volatilité plus normale qu’exceptionnelle.

Nous sommes donc clairement dans une approche de type empirique qui laisse ainsi place à l’erreur. Mais pour ce faire, il est fondamental de gérer les exigences efficacement. Lorsque celles-ci sont en constante évolution, il faut mettre en place des mécanismes d’identification et de pilotage des exigences drastiques pour limiter les effets pervers du changement. La gestion des exigences est donc centrale pour n’importe quel projet Agile. 

La première étape consiste à créer un carnet d’exigences (requirements backlog) qui regroupe notamment des scénarios utilisateurs permettant en quelques phrases simples de décrire comment l’utilisateur s’attend à ce que le produit fonctionne dans certaines circonstances.

Dans un deuxième temps, il est nécessaire de prioriser et planifier les exigences en estimant leur importance et l’effort requis pour les accomplir.

Finalement, on décompose ces exigences générales pour créer le carnet de produit (product backlog). C’est lors de cette étape que les exigences sont en quelque sorte traduites en véritables fonctionnalités et en tâches qui devront être réalisées. L’équipe de réalisation doit être fortement impliquée dans cette étape afin que chacun puisse comprendre ce qu’il doit faire et pourquoi.

On oppose souvent la méthode agile « approche produit » au cycle en V qui est une approche de « gestion de projet ». Si la méthode agile permet de limiter l’effet tunnel pour le client, elle ne permet pas de développer plus vite un « produit final » répondant à toutes les spécifications client.

La méthode agile est en théorie beaucoup plus basée sur la gestion des obstacles et rien n’empêche de le faire également de façon très réactive par un cycle en V.

Mais attention, l’agilité n’a pas pour but de livrer « tout » au plus vite mais livrer régulièrement des produits de bonne qualité, ce qui est bien différent. Elle a souvent le défaut, en particulier pour les projets IT, de mettre en second plan les aspects documentation et qualité technique pour livrer au plus vite. 

Elle pousse cependant à l’intelligence collective ce qui n’est pas du tout le cas du cycle en V. Elle convient aux nouvelles générations de manager qui apprécient plus d’être des acteurs du produit au-delà du simple développement. 

Avec la méthode agile, on ne livrera pas le produit final complet plus vite, mais on livrera le minimum acceptable bien avant le produit final attendu (en cycle en V). On pourra avoir ainsi un retour d’expérience plus rapide pour améliorer le produit.

Si la gestion des exigences est importante dans le cycle en V, l’agilité renforce considérablement l’efficacité du processus de gestion des exigences dans les projets, en particulier IT.