7. janvier 2025 de Sarah Kluge
Quand l’agilité rencontre l’ingénierie des exigences
Dans l'ingénierie des exigences traditionnelle (Requirements Engineering, RE), les exigences sont identifiées, documentées et validées en détail dès le début d'un projet ou avant le lancement d’un logiciel. Dans de nombreux projets classiques, cette approche fonctionne plutôt bien. Toutefois, force est de constater qu’elle atteint ses limites avec les méthodes agiles comme Scrum ou Kanban. L'ingénierie des exigences dans les projets agiles nécessite une approche plus dynamique et adaptable, conçue pour évoluer en permanence et pour recevoir le feedback de l'équipe et des parties prenantes.
Les méthodes agiles reposent sur des cycles de développement itératifs et sur une collaboration étroite entre l'équipe et les parties prenantes. Elles définissent souvent les exigences de manière moins détaillée que les projets classiques. Au lieu de créer des exigences complètes, l'ingénierie des exigences se concentre ici sur la collecte et la priorisation de « User Stories » ou expériences utilisateurs. Par conséquent, dans les projets agiles, on ne retrouve plus le RE uniquement en amont du processus. Il devient une activité continue qui se déroule parallèlement au processus de développement.
Bonnes pratiques et défis
1.
Toujours garder une vue d'ensemble : l'un des principaux défis de l'ingénierie des exigences agile est l'absence de document précisant les exigences détaillées sur le long terme. Dans un projet classique, un cahier des charges détaillé sert de référence, tandis que dans un environnement agile, les exigences sont « live » et peuvent changer régulièrement. C'est un réel défi de ne pas perdre de vue l’ensemble, « the big picture », lors de la spécification d'exigences complexes. Dans ce contexte, certaines techniques des plus utiles ici sont par exemple : la définition d'une vision du produit ainsi que la structuration des exigences en EPIC, en stories et la visualisation des dépendances et des relations entre les exigences.
2.
Engagement des parties prenantes : un projet agile nécessite une communication continue avec les parties prenantes. Cela implique des réunions régulières, comme des « Sprint Reviews », au cours desquelles l'équipe reçoit un feedback sur les fonctionnalités développées et où les exigences peuvent être adaptées sur la base des dernières découvertes.
3.
Priorisation et itération : les exigences sont collectées sous forme d'expériences utilisateurs (user stories) et classées par ordre de priorité en fonction de leur importance ou de leur valeur. Des méthodes telles que le principe MoSCoW (Must have, Should have, Could have, Won't have) permettent de développer en premier les fonctions les plus importantes, approche cruciale dans les itérations agiles.
4.
User Stories et critères d'acceptation : l'utilisation de User Stories avec des critères clairement définis est une méthode éprouvée pour formuler les exigences d'une manière qui répond à la fois aux besoins des parties prenantes et aux exigences pratiques de mise en œuvre. Le défi consiste à préparer les exigences avec un niveau de détail approprié et de manière compréhensible au moment requis.
5.
Backlog Refinement : un « Backlog Refinement » régulier permet de s'assurer que le Product Backlog est toujours conforme aux exigences actuelles, qu’elles soeint claires, bien hiérarchisées et prêtes pour les prochains sprints. Ce processus d'adaptation continue permet d'éviter que le projet ne se heurte à des exigences obsolètes. Toutefois, seules les exigences qui offrent la plus grande valeur ajoutée et qui ont donc une priorité élevée sont élaborées en détail. Étant donné que la spécification des exigences est également un processus d'intégration, les exigences de moindre valeur sont généralement délibérément laissées à l'état de « grandes lignes directrices » jusqu'à ce que leur mise en œuvre se rapproche et que davantage de détails deviennent utiles et pertinents.
6.
Réagir de manière flexible aux changements : grâce à la gestion continue des exigences dans les projets agiles, réagir de manière flexible aux changements est également un élément important. Au lieu de passer par un processus de changement, comme dans les projets classiques, les projets agiles permettent de réagir de manière flexible et rapide à un changement. Dans ce cas, le champ d'application est parfois modifié pendant un sprint actif et le sprint est replanifié afin d'intégrer le changement le plus rapidement possible.
Comment les quatre activités de base d'une ingénierie des exigences sont-elles vécues dans les projets agiles ?
Dans le RE classique, on parle des quatre activités suivantes : identification, documentation, validation et gestion des exigences. Elles constituent la base d'une gestion réussie des exigences complexes. Dans les projets agiles, les caractéristiques de ces activités diffèrent toutefois des approches classiques, car elles nécessitent aussi une adaptation vers la méthode de travail itérative et flexible.
- Identification des exigences
Dans les projets agiles, l'identification des exigences se fait de manière continue et itérative. Au lieu d'ateliers ou d'entretiens approfondis au début du projet, les exigences sont souvent identifiées lors de réunions régulières comme les « Sprint Plannings », les « Backlog Refinement » ou par des échanges directs avec les parties prenantes. De plus, l’ajout de produits et les « Sprint Reviews » permettent également un feedback rapide et peuvent fournir de nouvelles idées pour le Product Backlog. Cette activité met l'accent sur la collecte de « user stories » qui peuvent être complétées ou adaptées de manière flexible pour tenir compte des dernières informations.
- Documentation des exigences
Au lieu d'un cahier des charges ou spécifications fonctionnelles détaillées, les projets agiles misent sur des formes de documentation minimalistes et facilement personnalisables. Les User Stories, les EPIC et les critères d'acceptation servent de principaux outils de description des exigences. Des outils comme Jira aident à maintenir la documentation à jour et accessible à toutes les personnes concernées. L'accent est mis sur le fait que la documentation doit être aussi allégée que possible tout en étant suffisamment précise. En travaillant par sprints, il est par ailleurs important de découper les exigences de manière à ce qu'un cas d'utilisation ne contienne pas plus que ce qui peut être réalisé en un sprint. Donc si nécessaire, elle doit être divisée en plus petites parties.
- Validation des exigences
Dans les projets agiles, la validation des exigences se fait de manière itérative et en étroite collaboration avec l’équipe de développement. Les « Sprints Reviews » et les tests automatisés (notamment les tests d'acceptation) jouent un rôle central pour garantir que les exigences soient correctement et entièrement mises en œuvre. Le feedback des parties prenantes est essentiel pour procéder à des ajustements rapides, le cas échéant, et pour s'assurer que les fonctionnalités développées répondent aux besoins réels.
- Gestion des exigences
Dans les projets agiles, la gestion des exigences se réfère principalement à la gestion du Backlog. Il s'agit d'une activité continue consistant à gérer et assurer la mise à jour régulière du Product Backlog. Il en va de même pour le Sprint Backlog, puisqu'il doit refléter l'état réel des travaux du sprint en cours. Cependant, contrairement au Product Backlog, dont le Product Owner est responsable, la responsabilité du Sprint Backlog incombe à l'équipe elle-même.
Un autre élément de la gestion des exigences, aussi bien dans les projets classiques que dans les projets agiles, est la gestion des attributs. Les exigences sont enrichies d'informations supplémentaires, comme le statut, les estimations, les priorités et les responsabilités. Les liens avec des exigences contradictoires ou dépendantes sont également documentés afin d'identifier les conflits à un stade précoce et pour les résoudre efficacement. Dans les projets agiles, la gestion des attributs favorise la traçabilité et facilite l'adaptation dynamique des exigences au cours du développement.
Dans un contexte agile, l'ingénierie des exigences nécessite une approche plus flexible et plus itérative que dans les projets traditionnels. En se concentrant sur la documentation provenant des user stories, de feedbacks réguliers et d'une étroite collaboration avec les parties prenantes, il est possible de saisir efficacement les exigences, de les prioriser et de les adapter en permanence. Malgré les défis posés par l'absence de documentation détaillée, une ingénierie des exigences bien mise en œuvre peut aider à mettre en place les projets avec succès et en respectant les délais. Il est important que tous les membres de l'équipe et les parties prenantes soient impliqués dans le processus agile afin de garantir que les exigences soient toujours en phase avec les besoins réels.
Il est toutefois important de noter qu'il reste tout à fait utile de pratiquer l'ingénierie des exigences en tant que phase préliminaire de tout projet dressant un catalogue d'exigences complet. Cela permet de mieux évaluer l'ampleur et le budget. Il n’existe pas de règle générale quant à l’approche préférable en ingénierie des exigences. Au contraire, les techniques de RE et les méthodes de travail utilisées devraient toujours être adaptées aux conditions spécifiques du projet et évaluées sur une base individuelle.