Gestion des exigences CMMI : Soyez Agile !

L’agilité renforce considérablement l’efficacité du processus de gestion des exigences dans les projets informatiques. Un processus qui est guidé par le référentiel CMMI.

L’agilité renforce considérablement l’efficacité du processus de gestion des exigences dans les projets IT. Grâce à un juste niveau de formalisme, une collaboration permanente, une forte culture du changement, le tout dans une recherche permanente de la valeur, les méthodes agiles proposent aujourd’hui des facteurs de succès indéniables.

La Gestion des exigences est avec le développement des exigences la base de ce qu'on appelle l'Ingénierie des exigences. Celles-ci sont de deux types :
- fonctionnelles (c'est-à-dire "ce que le système doit faire")
- non fonctionnelles (rassemblées autour d'attributs de qualités, par exemple fondés sur l'ISO 9126).

Dans une dynamique de processus guidée par CMMI, la "Gestion des exigences"(REQM), est un domaine de processus du Niveau de maturité 2, dont l'intention est de "gérer les exigences des produits et composants de produits du projet et d'identifier les incohérences entre ces exigences et les produits d'activité du projet".

REQM SP1 Gérer les exigences : l'unique objectif à atteindre

Un seul objectif à satisfaire mais il est de taille : les exigences sont gérées, et les incohérences avec les plans du projet et les produits développés sont identifiées. C'est l'objectif à atteindre, et l'agilité le permet largement, en particulier au travers d'un élément central : le BACKLOG DE PRODUIT (liste estimée et priorisée qui contient tous les éléments qui vont nécessiter du travail de l'équipe pour réaliser le produit)

Un processus Agile, ou plus exactement des pratiques Agile et CMMI

Il s'agit des pratiques recommandées par le modèle théorique CMMI, des pratiques auxquelles les méthodes Agiles viennent donner à un nouvel élan : une concrétisation immédiate qui respecte les préconisations.

REQM-SP1.1 Développer une compréhension commune des exigences et de leur signification avec ceux qui les ont fournies.

L'agilité se retrouve bien dans cette pratique qu'elle pourrait faire sienne. Les ateliers de travail, les échanges face à face, pour construire de manière collaborative une Vision PARTAGEE, et un Backlog de produit, ESTIME et PRIORISE vont dans ce sens. La réunion de lancement en fait partie. Les conditions de satisfaction portant sur chaque élément du Backlog de produit prolongent cet effort de compréhension commune et concourent à l'atteinte de l'objectif.

REQM-SP1.2 Obtenir des participants au projet leur engagement sur les exigences.

Engagement et responsabilisation : voilà des points forts des méthodes Agiles. 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 (et user stories). 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 : c'est le Daily Scrum.

REQM-SP1.3 Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet.

Maintien et contrôle des exigences : c'est aussi l'objectif du Backlog de produit, qui vit et évolue au fur et à mesure de l'avancée du projet. Il est actualisé à la fin de chaque Sprint (suite à la réunion de fin de sprint). Historiser les versions du Backlog est très pertinent dans un contexte CMMI.

Le changement dans les exigences peut se traduire aussi au niveau des éléments du Backlog de produit mis à jour dés que cela s'avère nécessaire.
Le burndown chart, courbe du Reste à Faire établie chaque jour, montre par la même occasion quotidiennement ce qui est réalisé, et les changement éventuels survenus.

REQM-SP1.4 Maintenir une traçabilité bidirectionnelle entre les exigences et les produits d'activité.

Le quatuor (Backlog de produit - User Stories /Use Cases - Tâches - Produit Développé) assure un système de suivi des exigences souple et performant, se concrétisant dans la démo de fin de sprint. CMMI attend une matrice de traçabilité des exigences. Les feuilles de calcul et les outils du marché gérant les Backlog de produit permettent d'atteindre cet objectif, en ajoutant des éléments de traçabilité vers la documentation ou encore vers les tests ...Le Backlog de produit est comme on le constate l'élément clé dus dispositif.

REQM-SP1.5 Identifier les incohérences entre les plans du projet et les produits d'activité d'une part et les exigences d'autre part.

Cette pratique est un vrai point fort de l'Agilité. Elle s'effectue de manière continue, dans la collaboration, durant tout le sprint avec comme clé de voute les conditions de satisfaction définis pour chaque élément du backlog de produit, mais aussi grâce aux daily scrum. La "démo" de fin de sprint est un RDV formel permettant de déterminer ce qui a été fait ou pas, ce qui est bien fait de ce qui ne l'est pas. Ce RDV qui donne lieu potentiellement à des actions correctives et à l'actualisation du Backlog de produit.