Les Exigences Non-Fonctionnelles dans les User Stories Scrum : Un Élément Essentiel pour la Réussite

Dans le cadre d’un projet de développement de produit, avez-vous déjà ressenti le besoin de revoir la conception de votre système pour améliorer ses performances, même lorsque tout semblait prêt ? Avez-vous été confronté à la situation où le système fonctionnait parfaitement dans votre environnement de test, mais dès sa mise en production, il a rencontré d’innombrables problèmes de performance et de scalabilité ? Pourquoi cela se produit-il ? Tout simplement parce que les exigences non-fonctionnelles n’ont pas été prises en compte.

Prenons l’exemple de cette User Story : « En tant qu’utilisateur, je souhaite effectuer une recherche d’emploi en utilisant des mots-clés pour trouver un emploi correspondant. » Lorsque vous créez votre backlog de sprint, prenez-vous en compte les exigences non-fonctionnelles de cette fonction de recherche ? Par exemple, est-ce que la recherche doit fournir des résultats en moins de 20 secondes ? Votre base de données peut-elle gérer jusqu’à 10 millions d’enregistrements, et les utilisateurs peuvent-ils saisir jusqu’à 3 mots-clés à la fois ?

Votre backlog de sprint diffère-t-il si vous devez mettre en œuvre cette fonction pour 10 000 enregistrements avec un temps de réponse de 2 minutes ? En travaillant uniquement sur cette User Story, pouvez-vous garantir d’atteindre les performances souhaitées ? Et si votre architecture ne stocke pas les emplois dans un format qui facilite une recherche rapide, devriez-vous également inclure la correction de cette partie dans cette User Story ?

En général, les équipes agiles axées sur la livraison de produits incrémentiels et qui se penchent sur les User Stories se heurtent fréquemment au défi de l’intégration des exigences non-fonctionnelles. Souvent, ces exigences se révèlent bien en amont dans la phase de développement du système.

Mais que faire dans de telles situations ? Faut-il élaborer une conception et une architecture préliminaires en anticipant que le système doit répondre à toutes les exigences non-fonctionnelles une fois finalisé ? Cette approche implique d’anticiper de nombreux besoins futurs du système, ce qui peut s’avérer fructueux ou non à la fin.

Malheureusement, j’ai été témoin de nombreuses situations où les équipes continuent à retravailler le système en fonction des exigences non-fonctionnelles, ce qui se traduit par une offre de faible qualité offrant peu de valeur et une durée de vie limitée.

Pour commencer, il est impératif d’identifier les exigences non-fonctionnelles bien avant de les intégrer à la phase de développement du produit. Une méthode judicieuse consiste à suivre l’approche de Newkirk et Martin (2001), qui ont introduit une pratique novatrice. Chaque User Story doit être annotée d’une mention « Contrainte » que les User Stories doivent respecter sans nécessairement les mettre en œuvre. Cette approche permet d’identifier en permanence les exigences non-fonctionnelles et de créer des tickets de contrainte pour chacune d’elles. Examinons quelques exemples :

1. Le système doit être compatible avec toutes les dernières versions d’Internet Explorer, Chrome et Firefox.
2. Le système doit être conçu pour prendre en charge jusqu’à 20 000 utilisateurs simultanés.
3. Le système doit avoir une extensibilité horizontale.
4. La base de données doit être capable de stocker jusqu’à 20 millions d’enregistrements.

Certes, l’ajout de tickets de contrainte et la garantie que les User Stories les respectent peuvent ralentir légèrement le processus de mise en œuvre. La question se pose alors : comment les prioriser ? Peuvent-elles être mises en œuvre dès le début du projet ? Si oui, cela ne va-t-il pas à l’encontre du principe « faites la chose la plus simple qui puisse fonctionner » ? Qui est responsable de la définition de ces contraintes ? Est-ce le Product Owner ?

Toutes ces questions, et bien d’autres, se posent fréquemment, et les réponses ne sont pas toujours évidentes. Il est important de noter que les contraintes peuvent varier d’un projet à l’autre. Par conséquent, chaque équipe de projet doit prévoir un moment pour l’identification des tickets de contrainte, en gardant à l’esprit que le faire à un stade ultérieur peut avoir un impact sur l’ensemble des User Stories développées.

Enfin, pourquoi ne pas imposer ces contraintes dès le début du projet ? La réponse est que certaines fonctionnalités du système peuvent nécessiter une mise en place préalable avant d’imposer des contraintes. Dans de tels cas, il est recommandé de rechercher une User Story distincte pour gérer ces conditions spécifiques et d’y appliquer les contraintes nécessaires. Il est toutefois essentiel de définir un point de non-retour dans le projet à partir duquel toutes les User Stories doivent respecter les contraintes.

À présent, vous disposez d’informations complètes sur la gestion des contraintes. Mais qui est responsable de la rédaction de ces « tickets de contrainte » ?…

Ne laissez pas les exigences non-fonctionnelles ou toute autre compétence essentielle vous prendre au dépourvu. Investissez dans votre avenir professionnel en choisissant CertiSkills. N’attendez plus, réservez votre formation 100% en ligne immédiatement et découvrez comment nous pouvons vous aider à atteindre vos objectifs. Vous pouvez également nous contacter au (+33) 6-29-37-62-76 ou à l’adresse contact@certiskills.fr pour plus d’informations.

Optez pour l’excellence en choisissant CertiSkills pour votre formation en ligne !