Nous connaissons tous les valeurs agiles promues dans le Manifeste Agile pour le développement de logiciel de 2001 (http://agilemanifesto.org/) et reprises ci-dessous :
- Les individus et leurs interactions, plus que les processus et les outils
- Des logiciels opérationnels, plus qu’une documentation exhaustive
- La collaboration avec les clients, plus que la négociation contractuelle
- L’adaptation au changement, plus que le suivi d’un plan
Les signataires de ce Manifeste ont mis en avant l’équipe, le produit, la collaboration et le changement, mais ils n’ont pas oublié de mentionner la chose suivante : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. ».
Alors que l’ingénierie des exigences est une discipline qui commence à être reconnue par les organisations qui définissent et conçoivent des systèmes complexes, nous assistons dans le même temps à la montée en puissance de la gestion de projet agile.
Dans ce nouveau contexte organisationnel, nous ne pouvons pas nous empêcher de nous poser les questions suivantes : Retrouvons-nous les quatre valeurs de l’agilité en ingénierie des exigences ? Si oui sous quelle forme les trouve-t-on ? Et comment peuvent-elles être déclinées ?
L’équipe – Les individus et leurs interactions
En ingénierie des exigences, les parties prenantes constituent la source principale des exigences. Un objectif fondamental de l’ingénierie des exigences est de comprendre les désirs et les besoins des parties prenantes et d’en extraire des exigences. Les utilisateurs d’un produit, d’un système ou d’un logiciel sont également des parties prenantes et leurs exigences représentent des conditions ou des capacités requises pour résoudre un problème ou atteindre un objectif.
Le processus qui produit les exigences est un processus itératif et incrémental. Ce processus que l’on appelle couramment « processus de développement des exigences » est un processus cognitif qui repose sur une communication intensive et sur l’action réciproque entre les parties prenantes et l’équipe en charge de la définition et de la réalisation du produit. Les processus et les outils sont importants pour manipuler le contenu souvent complexe et soutenir ce processus cognitif.
Néanmoins, cette première valeur de l’agilité insiste sur le fait que les processus et les outils ne sont pas une fin en soi ; ils doivent être introduits de façon raisonnable et avec discernement, et doivent être utilisés avec soin et pragmatisme.
Le produit – Des logiciels opérationnels
L’ingénierie des exigences est la base de la compréhension des besoins des utilisateurs et de l’appropriation par l’équipe de développement de leurs exigences, afin qu’elle puisse construire le bon produit. La valeur principale de la discipline et le facteur principal de la réussite d’un projet résident dans la connaissance des besoins des parties prenantes. L’interaction avec et entre les membres de l’équipe partageant la connaissance est une façon de préserver cette connaissance.
L’agilité met en avant le logiciel opérationnel au détriment de la documentation et considère que la documentation n’est pas une fin en soi. Contrairement aux idées reçues, cela ne veut pas dire qu’il n’y a pas de documentation dans un projet agile, mais que cette documentation sera réalisée avec parcimonie et en particulier, en fonction de la nécessité ou non de capitaliser sur la connaissance.
Par définition, une exigence est une représentation documentée d’une condition ou d’une capacité. Aussi, en agilité, la documentation des User Stories dans le Backlog du produit est déjà une première étape de la documentation des exigences. C’est le « contrat » minimal entre le Product Owner et l’équipe en charge de la réalisation du produit.
N’oublions pas que dans certains domaines spécifiques tels que le médical, l’automobile ou l’aéronautique, la conformité et les contraintes réglementaires définissent des normes sous forme de spécification, ce qui exige l’existence d’une documentation écrite par rapport aux exigences.
La collaboration – La collaboration avec les clients
Le socle des connaissances en ingénierie des exigences aborde le sujet de la collaboration avec le client dans les activités d’élucidation et de négociation des exigences. Les objectifs de ces activités couvrent des principes importants de l’agilité et les éléments utilisés dans les projets agiles, tels que la communication directe, les personas, les techniques de créativité, l’enquête contextuelle, les User Stories, … font partie des techniques et des outils de l’ingénierie des exigences.
Afin de faire adhérer l’équipe à l’idée de collaboration, il est important de disposer d’un référentiel unique de l’information. Ce référentiel devra être partagé entre toutes les équipes, unique et centralisé, organisé et structuré… Une partie de ce référentiel sera constituée d’exigences.
Avec son schéma de certification, l’IREB(*) offre un module de niveau avancé traitant de l’élucidation et de la consolidation des exigences avec les parties prenantes et les utilisateurs. Ce module de niveau avancé met l’accent sur les valeurs agiles et la collaboration entre les équipes.
Le changement – L’adaptation au changement
Les démarches agiles comme Scrum ou Kanban fournissent une réponse aux changements comme principe de base des valeurs agiles au travers de méthodes spécifiques, de techniques et de bonnes pratiques. Les modèles de cycle de vie agiles donnent des conseils sur comment et quand appliquer ces méthodes, techniques et bonnes pratiques.
Le fait de répondre au changement n’est pas une spécificité de l’agilité. A sa manière, la discipline de l’ingénierie des exigences au travers des activités de gestion des exigences (traçabilité, analyse d’impact, versionnement des exigences…) répond à cette nécessité. L’ingénierie des exigences offre également des méthodes spécifiques et des techniques qui soutiennent cette prise en compte du changement.
En conclusion, nous pouvons affirmer que l’ingénierie des exigences et la gestion de projet agile ne sont pas incompatibles. Le socle des connaissances en ingénierie des exigences est tout aussi important et pertinent dans le modèle de cycle de vie en cascade ou en V que dans l’agile. Les aspects collaboration et communication sont très présents dans l’un et l’autre, et la satisfaction des utilisateurs constitue un objectif commun. Des adaptations sont néanmoins nécessaires et se traduisent par des activités d’ingénierie menées avec des intensités variables, des techniques et des outils différents, des rôles des acteurs redéfinis.
Article inspiré du document IREB(*) « Ingénierie des exigences et développement agile ».
(*) IREB = International Requirements Engineering Board (www.ireb.org)