L’ingénierie des exigences dans les projets agiles expliquée simplement

Scrum, l’une des méthodes agiles les plus connues, est un framework qui a fait ses preuves dans le cadre du développement de produits complexes. L’un de ses principes centraux « Inspect & Adapt » est mis en œuvre lors de différents événements et lors des cycles de feedback.

Les résultats des tâches sont inspectés à intervalles réguliers. Et, lorsqu’il est nécessaire ou sensé, des adaptations sont entreprises sur le produit ou le processus de travail. Ces derniers sont donc continuellement améliorés et adaptés en fonction des nouvelles connaissances ou d’un changement de conditions.

Donc si on veut développer avec succès des produits dont la complexité augmente sans cesse, prendre acte des exigences et les consolider continue de jouer un rôle central.

Mais comment conjuguer exactement les méthodes agiles avec l’ingénierie des exigences (« Requirements Engineering » ou RE) ? Où a-t-on besoin de l’ingénierie des exigences et comment a-t-elle lieu exactement ?

Afin de répondre à ces questions, regardons tout d’abord l’ingénierie des exigences du point de vue des modèles classiques, avant de se pencher sur le contexte agile.

L’ingénierie des exigences dans les approches classiques

Dans les modèles classiques, le processus de développement est divisé en phases clairement définies et limitées dans le temps. Le modèle prédéfinit l’ordre de déroulement de ces phases, les activités qu’elles contiennent, qui les réalisent et qui en est responsable.

L’ingénierie des exigences a généralement lieu au début du processus de développement. Avant même le début de la mise en œuvre du projet, les exigences relatives au système à construire sont entièrement déterminées et documentées. Ensuite seulement suivent les autres phases comme le design du système, l’implémentation et le test.

Cela signifie que toutes les exigences sont déjà spécifiées très en détail avant même le début de la mise en œuvre.

Découvrez également notre article : Requirements Engineering : 5 bonnes raisons de s’y mettre

L’ingénierie des exigences dans les projets agiles

Dans les projets agiles, on commence par constituer un produit minimum viable (MVP, Minimum Viable Product). Un MVP constitue la première version du produit visé et contient le minimum de fonctionnalités qui permettent de répondre à un besoin du client. Les autres exigences sont alors déterminées dans les itérations suivantes et réalisées selon des priorités fixées. Ainsi, il est possible de réagir de manière flexible et rapide à de nouveaux souhaits des clients et à des conditions fluctuantes.

Une phase dédiée à l’analyse des exigences n’est pas prévue dans un cadre de développement agile de produit.

Si l’établissement d’un concept embryonnaire peut toutefois être conseillé au début d’un projet agile, une phase dédiée à l’analyse des exigences n’est pas prévue dans un cadre de développement agile de produit.

Mais alors où et quand ont donc lieu les activités principales de l’ingénierie des exigences comme la recherche, la documentation, le contrôle, la coordination et la gestion des exigences ?

1. La recherche des exigences

Le Product Owner (PO) est responsable de la recherche des exigences. Il communique avec les parties prenantes pertinentes et recense leurs exigences. Ces dernières sont généralement enregistrées sous forme de User Stories dans le Backlog du produit. Cette recherche est une activité permanente qui s’étend tout au long du développement du produit.

Lors des Refinement Meetings, les User Stories sont discutées avec l’équipe, adaptées et affinées si nécessaire. Si une User Story reçoit une priorité suffisamment haute et prévue pour le prochain Sprint, le PO la présente à toute l’équipe lors du Sprint Panning Meeting. À cette occasion, de nouvelles exigences peuvent être identifiées ou concrétisées.

2. La documentation des exigences

La création d’une User Story dans le backlog du produit marque le début de la documentation d’une exigence. Elle sera ensuite complétée par des critères d’acceptation.

De plus, il existe des critères d’acceptation valables invariablement pour toutes les exigences et qui représentent un certain niveau de qualité de l’équipe. Ces critères sont enregistrés dans un Definition of Done (DoD) de l’équipe séparé et généralement applicable.

Selon la complexité d’une exigence, il peut s’avérer pendant un Refinement Meeting ou un Sprint Planning qu’une documentation structurée supplémentaire soit nécessaire, par exemple sous la forme de diagrammes contextuels, d’activité ou de classes …

Le backlog du produit est constitué d’exigences à un niveau d’abstraction élevé sous la forme de User Stories. Elles sont ensuite affinées et détaillées lorsqu’elles sont candidates à la prochaine itération.

La responsabilité du backlog du produit incombe au PO. Ce dernier peut cependant être épaulé par les analystes business et les développeurs de l’équipe interdisciplinaire lors de la création et de l’affinage des User Stories.

3. Le contrôle et la coordination des exigences

Le contrôle et la coordination des exigences sont importants pour atteindre une compréhension commune. Dans le cadre de l’élaboration des User Stories, une première coordination des exigences transmises a lieu avec toutes les parties prenantes pertinentes.

La même chose est faite avec l’équipe lors des Refinements et Sprint Plannings, afin de parvenir à une compréhension commune des contenus et à la clarté nécessaire à la mise en œuvre des exigences.

4. Gestion des exigences

Dans le cadre d’un projet agile, les exigences sont collectées et affinées en continu. Cela signifie aussi que le backlog du produit change en permanence. Pour le maintenir à jour, il doit donc également être constamment entretenu et géré.

Le Backlog Management est l’activité continue de mise à jour du backlog. Il en va de même pour le backlog du sprint, puisque ce dernier doit refléter l’état réel du travail au sein du sprint. Mais à l’inverse du backlog du produit, c’est l’équipe qui est responsable du backlog du sprint.

Conclusion

L’ingénierie des exigences est aussi importante dans un environnement agile que lors de l’application de modèles traditionnels de gestion de projet. Étant donné que dans un contexte agile les exigences peuvent changer à tout moment, l’ingénierie des exigences a lieu de manière itérative tout au long du processus de développement.

En lieu et place de spécifications contraignantes des exigences sous différentes formes, on trouve des formes plus légères comme des Backlogs, des User Stories ou Story Maps.

L’agilité et la flexibilité ne sont donc pas des excuses pour négliger l’ingénierie des exigences ou pour une ingénierie des exigences non systémique et ad hoc.