GAMP 5 Compliance Guide: What is It and How Modern Requirements Helps
Check out what GAMP 5 compliance is, why is it important and how a requirements management tool like Modern Requirement can help with this compliance.
L’histoire utilisateur est-elle la nouvelle exigence?
Si vous travaillez dans un environnement agile, vous entendez probablement des termes comme « user story » et « exigences » souvent évoqués, mais avez-vous déjà pris le temps de réfléchir à ce qu’ils signifient vraiment?
Les histoires d’utilisateur et les exigences sont-elles interchangeables?
Dans un système agile où tant de choses sont flexibles et où tant de frontières sont constamment floues, comment peut-on vraiment distinguer ces deux termes courants de l’industrie?
Certaines personnes se demandent si les histoires utilisateurs ne deviennent pas les nouvelles exigences, ce qui pourrait changer la façon dont un système DevOps Azure agile est censé fonctionner. Alors, qu’est-ce qui se passe exactement?
Les histoires utilisateur et les exigences sont-elles interchangeables?
Sont-ils plutôt les deux faces d’une même pièce?
Dans cet article, nous allons examiner les différences et similitudes entre les user stories et les exigences, ainsi que la façon dont elles sont utilisées à la fois par les équipes en cascade et agile.
Voici un modèle de base pour une histoire utilisateur :
« En tant que _____, je veux ______ pour que ________. »
Disons que je suis un utilisateur qui cherche une solution logicielle qui peut m’aider à prendre un trajet dans les trains locaux.
Mon histoire utilisateur pourrait ressembler à ceci :
« En tant que passager de train, je veux être informé en temps réel des retards afin de pouvoir planifier mon voyage en conséquence. »
Maintenant, en plus de cette histoire d’utilisateur, vous pourriez aussi constater qu’il existe des « critères d’acceptation ». Ces critères sont essentiellement les seuils de l’histoire utilisateur (c’est-à-dire la fonctionnalité de l’application) qui décident quand l’histoire utilisateur est terminée et quand le logiciel répond aux demandes de l’utilisateur final.
Lorsque les testeurs agiles mettent votre produit à l’épreuve, ces critères d’acceptation sont ceux qu’ils utiliseront pour tester votre logiciel.
Si elle est insuffisante pour une raison quelconque, tu vas être renvoyé à zéro. Ces critères classent efficacement les priorités de l’histoire utilisateur et forcent l’équipe de développement à voir les choses à travers les yeux de l’utilisateur final, en modifiant leur produit au besoin.
Qu’est-ce qu’une exigence?
Les exigences dictent comment un logiciel doit fonctionner une fois terminé.
Avec les exigences, l’accent est mis sur l’intention du système et sur la qualité de son accomplissement de la tâche requise. Si vous avez déjà lu un document d’exigences, vous verrez qu’ils détaillent très en détail le fonctionnement de certaines fonctionnalités logicielles.
Ces exigences approfondies sont censées guider l’équipe, s’assurant qu’elle développe un produit qui répond à ces exigences strictes du projet.
Les documents d’exigences sont excessivement détaillés, contenant des informations sur les risques du projet, leur portée, des résumés exécutifs et plus encore. Les documents sont conçus pour fixer la barre en matière d’expérience utilisateur et de fonctionnalité du produit final, entre autres facteurs.
En reprenant le même exemple d’application de train qu’auparavant, voici un exemple de quelques exigences agiles pour l’application :
– Afficher l’heure d’arrivée de chaque train.
– Afficher l’heure de départ de chaque train.
– Mettre à jour les horaires des trains pour les services retardés.
– Permettre à l’utilisateur de réserver des places.
Comme vous pouvez le voir, cela entre dans plus de détails fonctionnels qu’une histoire utilisateur, avec des exigences spécifiques pour chaque fonction que l’application doit avoir.
Quelle est la différence entre une histoire utilisateur et une exigence?
Dans la plupart des cas, vous constaterez que les exigences sont plus courantes avec les approches de travail en cascade et structurées, tandis que les histoires utilisateurs sont plus courantes avec les approches agiles et hybrides.
Cela s’explique par le fait que la nature dynamique et fluide de l’agile est difficile à intégrer avec une longue liste d’exigences strictes, et beaucoup plus facile à intégrer avec une seule histoire utilisateur globale qui stipule que le produit doit aller du point A au point B.
Histoire utilisateur :
« En tant que passager de train, je veux être informé en temps réel des retards afin de pouvoir planifier mon voyage en conséquence. »
Exigence :
Affichez les temps de retard estimés de chaque train.
Les histoires d’utilisateurs sont sans doute une façon de travailler plus moderne, laissant place à la discussion au sein de l’équipe, qui peut adapter son flux de travail en conséquence.
D’un autre côté, de nombreuses entreprises utilisent encore les méthodes traditionnelles de travail en cascade ou hybrides, qui bénéficient de la spécificité et de la rigueur des exigences.
Si vous avez un produit qui a un objectif très précis, alors les exigences sont souvent la meilleure option.
Si vous travaillez avec des documents d’exigences, il est assez rare que l’équipe de développement modifie les exigences après qu’elles aient été rédigées. Pour cette raison, il est essentiel que vos exigences de projet soient rédigées par une personne ayant une connaissance approfondie du produit en question.
De plus, les systèmes de gestion des exigences peuvent aider les équipes agiles à trier ces exigences, certains systèmes étant construits sur Azure DevOps pour une fluidité accrue.
Inversement, si vous travaillez avec le modèle d’histoire utilisateur, alors toute personne de l’équipe de développement agile peut contribuer à l’arrière-plan de l’histoire utilisateur à tout moment du projet.
Cela signifie que les « exigences » en tant que telles peuvent changer en cours de projet. Cela signifie que les développeurs doivent ajuster leur travail pour compenser les changements dans le retard.
Cela rend les user stories agiles excellentes pour les projets qui ont une certaine marge de manœuvre, permettant aux développeurs de créer un logiciel organique et intuitif.
En fin de compte
Bien qu’elles dictent toutes deux l’orientation d’un projet, les user stories et les exigences sont des bêtes très différentes.
Les équipes en cascade traditionnelles ont tendance à utiliser les exigences et à les satisfaire minutieusement, tandis que les configurations agiles utilisent généralement des user stories en raison de leur flexibilité et de leur agilité.
Selon le projet en question, une équipe peut décider d’utiliser des exigences, une histoire utilisateur ou un hybride des deux.
Demandez une démonstration!
- Planifiez une démonstration avec l’un de nos experts produits formés.
- Recevez une démo personnalisée qui imite le processus de votre équipe
- Engagez nos experts sur des sujets tels que le flux de travail ou les meilleures pratiques.
Réduire les efforts de l’UAT
Réduction de 50% des efforts de l’UAT
Économie de temps éprouvée
80% de gain de temps sur la création d’une analyse de traces
Approbations simplifiées
Réduction significative des délais d’approbation
Augmenter la performance
50% des besoins d’amélioration de la productivité
Réduction de la refonte
Réduction de 10 fois dans la refonte du développement
Simplifier la conformité
Réduction de 40% des efforts de rapport sur la conformité