Comment documenter les exigences non fonctionnelles dans les User Stories?
Je travaille en tant qu'analyste d'affaires dans une entreprise de développement de logiciels. Dans mon organisation précédente, le développement se faisait en cascade et nous écrivions: "Business Requirement Documents" (BRD).
Dans mon rôle actuel, l'équipe utilise Agile Scrum et JIRA pour écrire les user stories pour capturer les exigences fonctionnelles, etc.
Ma question est la suivante: comment capturer au mieux les exigences non fonctionnelles de JIRA en tant qu'histoire?
Dans un BRD, c'était assez simple, ajoutez les exigences non fonctionnelles dans sa propre section et assurez-vous que chaque exigence a un ID unique à côté.
ID: 001 Exigence: L'application web doit être compatible avec les navigateurs suivants: IE11, Firework 50 etc ...
Mais dans Agile Scrum, et surtout dans JIRA, comment les documenter?
Les exigences non fonctionnelles se présentent sous plusieurs formes, mais elles ont une chose en commun: elles ne décrivent pas le comportement fonctionnel du système mais imposent plutôt des contraintes aux choix de conception que vous pouvez faire.
Les exigences non fonctionnelles sont mal adaptées pour être exprimées sous la forme d'histoires utilisateur, car les histoires utilisateur fonctionnent mieux lorsqu'elles peuvent être mises en œuvre une fois dans un court laps de temps (par rapport à la durée de l'ensemble du projet), puis être considérées comme terminées. Une fois qu'une histoire est terminée, il ne devrait pas être nécessaire de revoir régulièrement l'histoire. Pour les exigences non fonctionnelles, cela ne fonctionne pas, car leur respect doit être maintenu sur l'ensemble du projet. Vous ne pouvez pas dire que vous ne regarderez la compatibilité du navigateur qu'une seule fois pendant le projet et l'ignorerez le reste du temps.
Pour les exigences non fonctionnelles qui affectent presque toutes les user stories (fonctionnelles), le meilleur endroit pour les documenter est dans le cadre de la définition de Terminé.
Pour les exigences non fonctionnelles qui affectent un sous-ensemble relativement petit de la fonctionnalité, vous pouvez les intégrer aux critères d'acceptation des user stories pertinentes. Si ce sous-ensemble est encore assez grand à votre goût (ou s'il pourrait croître à l'avenir et vous avez peur de manquer une exigence non fonctionnelle dans une histoire future), vous pouvez mettre les exigences non fonctionnelles dans un document de certains trier et référencer cela à partir des critères d'acceptation des histoires pertinentes.
En ce qui concerne le format des exigences elles-mêmes et un document possible pour les mettre en place, utilisez ce qui fonctionne le mieux pour vous et votre équipe.
Les "exigences non fonctionnelles" sont un peu vagues et sujettes à interprétation. En reprenant votre exemple spécifique, je dirais que ces exigences devraient être utilisées comme critères d'acceptation pour d'autres histoires.
Si vous souhaitez répéter les mêmes exigences non fonctionnelles histoire après histoire après histoire, une autre solution consisterait à regrouper toutes ces exigences dans un document (par exemple: "normes d'application") et à inclure la partie "doit respecter les normes d'application". de votre définition du fait.
Vous pouvez les incorporer dans votre "Définition de Terminé" DOD.
Les non-fonctionnels sont cependant problématiques en agile, s'ils changent, vous n'avez aucun moyen de suivre les histoires qui ont été faites en fonction de quels critères.
Je voudrais donc essayer de les énumérer comme des tests pour chaque histoire. Même si cela signifiait beaucoup de copier-coller.
Dans son livre "Essential Scrum" , Kenneth S. Rubin dit (voir p. 93):
J'écris fréquemment des exigences non fonctionnelles sous forme de récits d'utilisateurs […], mais je ne ressens aucune obligation de le faire, surtout si cela semble gênant ou plus pratique de les écrire dans un format différent [c.-à-d. ne suit pas le modèle "En tant qu'utilisateur…"].
Cela étant dit, vous pouvez simplement créer une user story dans JIRA pour documenter une exigence non fonctionnelle.
Cependant, Kenneth recommande également — comme déjà souligné par Ewan et Bart van Ingen Schena - "[…] que les équipes essaient d'inclure autant d'exigences non fonctionnelles dans leurs définitions de faire comme ils le peuvent. " Cela est dû au fait que les exigences non fonctionnelles affectent souvent de nombreuses autres histoires d'utilisateurs (fonctionnelles) et si elles ne sont pas traitées, l'histoire n'est pas terminée. Par conséquent, la définition de fait est souvent le meilleur endroit.