Agilité et renforcement de l’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 manifeste Agile est le résultat du travail d’un ensemble de spécialistes de l’IT mais n’est pas la source du concept d’agilité. Il 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.

L’agilité repose donc sur des concepts bien plus anciens mais la création du manifeste agile a permis d’aider à la promotion de ce fort changement culturel dans les projets.

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. La réalisation pouvant durer plusieurs mois, voire plusieurs années, nous avons un effet tunnel pour le client qui peut conduire à un rejet par le client du produit réalisé. Certains projets se terminent ainsi dans la douleur :

  • Pour le client car le produit final ne correspond pas à son besoin.
  • Pour le fournisseur, notamment dans le cadre d’un contrat au forfait, car les délais et les coûts dépasseront le prévisionnel et la relation client risque d’être entachée.

Une enquête en 2008 du « Standish Group » indique un taux de réussite de 35% seulement des projets IT, dû notamment au manque d’implication du client et au changement du besoin en cours de projet. L’approche Agile peut réduire cet effet tunnel en donnant plus de visibilité au client et en l’impliquant à travers un processus itératif et incrémental sur tout le cycle de vie du projet.

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 « agile », 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 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 phase initiale du projet qui permet d’établir un référentiel des exigences partagé avec le client est essentielle. À cette étape, il n’est pas question d’établir le fonctionnement détaillé du produit final, mais plutôt de définir la « portée » du projet, ce qui permettra d’estimer sa durée et son coût prévisionnels.

Dans cette phase, il faut chercher à comprendre les objectifs stratégiques ou d’affaires et identifier les moyens pour les atteindre. Une fois que l’estimation globale des objectifs, des délais et des coûts est définie et partagée avec le client, nous pouvons passer à la mise en place d’une gestion agile des exigences.

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 ».

Dans le cycle en V, l’approche logique et séquentielle qui vise à créer le meilleur produit final possible, amène souvent à attendre la recette finale pour envisager des modifications du produit. Tout doit être prévu dans le moindre détail avec engagement sur le planning et le coût de réalisation. Il est donc très complexe de prendre en compte des changements car ceux-ci auront un impact sur toutes les phases en cours et à venir du projet, mais également sur les engagements contractuels.

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.

La méthode agile 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 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.

Pour les projets IT, elle donne un nouvel élan aux pratiques recommandées par la méthodologie CMMI, en particulier la « gestion des exigences »(REQM).

En méthode agile, le BACKLOG DE PRODUIT permet de dresser une liste estimée et priorisée de tous les éléments à réaliser. Il permet également de développer une compréhension commune des exigences et de leur signification avec le client.

La réunion de planification (à chaque début de SPRINT) est un moment où l’équipe s’engage collectivement sur la réalisation, durant le sprint, d’une partie du Backlog de produit. Chaque jour, les membres de l’équipe s’engagent sur la réalisation d’une tâche pour construire ce sur quoi elles se sont engagées (DAILY SCRUM).

Au cours du projet, le maintien et le contrôle des exigences est aussi l’objectif du Backlog de produit, qui vit et évolue au fur et à mesure de l’avancée du projet. La courbe du Reste à Faire (BURNDOWN CHART) montre quotidiennement ce qui est réalisé et les changements éventuels survenus.

Le Backlog de produit est l’élément clef du dispositif d’un management agile. La traçabilité des exigences du Backlog Produit est bien couverte par les outils du marché, avec des extensions vers les aspects documentaires et plan de tests.

En conclusion, grâce à un juste niveau de formalisme, une collaboration permanente entre les parties prenantes, une forte culture du changement, le tout dans une recherche permanente de la valeur, la méthode agile propose aujourd’hui des facteurs de succès indéniables.

Retenons 5 principes de base d’une conduite « agile » :

  • Satisfaire le client en livrant rapidement des produits de qualité.
  • Accueillir positivement les changements de besoin.
  • Maintenir une écoute permanente du client tout au long du projet.
  • Maintenir une dynamique au sein de l’équipe de projet.
  • Faire évoluer en permanence les pratiques et les moyens mis en œuvre.