Requirements Writing Pitfalls That Sabotage Projects (and How to Fix Them)
Avoid the most common requirements writing mistakes. A practical guide covering ambiguity, vague terms, structure problems, attributes, and document formats.
L'« user story » est-elle la nouvelle exigence ?
Si vous travaillez dans un environnement agile, vous entendez sans doute tout le temps des termes comme « user story » et « exigences », mais vous êtes-vous déjà demandé ce qu’ils signifiaient vraiment ?
Les user stories et les exigences sont-elles interchangeables ?
Dans un système agile où tant d'éléments sont flexibles et où les frontières sont sans cesse floues, comment pouvons-nous vraiment faire la différence entre ces deux termes courants du secteur ?
Certains se demandent si les user stories sont en train de remplacer les spécifications, ce qui pourrait modifier le fonctionnement d'un système Azure DevOps agile. Que se passe-t-il donc exactement ?
Les user stories et les exigences sont-elles interchangeables ?
S'agit-il plutôt des deux faces d'une même médaille ?
Dans cet article, nous allons examiner les différences et les similitudes entre les user stories et les exigences, ainsi que la manière dont elles sont utilisées tant par les équipes travaillant selon la méthode en cascade que par celles adoptant une approche agile.
Voici un modèle de base pour une user story :
« En tant que _____, je souhaite ______ afin que ________. »
Imaginons que je sois un utilisateur à la recherche d'une application qui puisse m'aider à trouver un trajet en train régional.
Mon scénario utilisateur pourrait ressembler à ceci :
« En tant que voyageur, je souhaite être informé des retards en temps réel afin de pouvoir organiser mon trajet en conséquence. »
En plus de cette user story, vous constaterez peut-être qu’il existe également des « critères d’acceptation ». Ces critères correspondent en substance aux seuils de la user story (c’est-à-dire de la fonctionnalité de l’application) qui déterminent à quel moment la user story est terminée et à quel moment le logiciel répond aux attentes de l’utilisateur final.
Lorsque les testeurs agiles mettront votre produit à l'épreuve, ce sont ces critères d'acceptation qu'ils utiliseront pour tester votre logiciel.
Si, pour une raison quelconque, elle ne répond pas à ces critères, vous devrez tout reprendre depuis le début. Ces critères permettent en effet de hiérarchiser les priorités de l'user story et obligent l'équipe de développement à se mettre à la place de l'utilisateur final, en adaptant le produit si nécessaire.
Qu'est-ce qu'une exigence ?
Les spécifications définissent le fonctionnement qu'un logiciel doit avoir une fois terminé.
En matière d'exigences, l'accent est mis sur l'objectif du système et sur sa capacité à remplir la tâche qui lui est assignée. Si vous avez déjà lu un cahier des charges, vous aurez remarqué qu'il décrit de manière très détaillée le fonctionnement de certaines fonctionnalités logicielles.
Ces spécifications détaillées ont pour but de guider l'équipe afin de garantir qu'elle développe un produit conforme aux exigences rigoureuses du projet.
Les cahiers des charges sont extrêmement détaillés et contiennent des informations sur les risques liés au projet, son périmètre, des résumés analytiques, etc. Ces documents ont pour but de définir les critères de référence en matière d'expérience utilisateur et de fonctionnalités du produit final, entre autres.
En reprenant l'exemple de l'application ferroviaire évoqué précédemment, voici quelques exemples d'exigences agiles pour cette 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 en cas de retard.
– Permettre à l'utilisateur de réserver des places.
Comme vous pouvez le constater, ce document entre davantage dans les détails fonctionnels qu'une user story, en précisant les exigences spécifiques pour chacune des fonctionnalités que l'application doit posséder.
Quelle est la différence entre une user story et un besoin ?
Dans la plupart des cas, vous constaterez que les spécifications sont plus courantes dans les approches de travail de type « cascade » et structurées, tandis que les récits d'utilisateurs sont plus courants dans les approches agiles et hybrides.
Cela s'explique par le fait que la nature dynamique et fluide de l'agilité est difficile à concilier avec une longue liste d'exigences strictes, mais qu'elle s'intègre beaucoup plus facilement à une seule user story globale qui stipule que le produit doit passer du point A au point B.
Cas d'utilisation :
« En tant que voyageur, je souhaite être informé des retards en temps réel afin de pouvoir organiser mon trajet en conséquence. »
Condition :
Afficher les temps de retard estimés pour chaque train.
Les user stories constituent sans doute une méthode de travail plus moderne, laissant place à la discussion au sein de l'équipe, qui peut ainsi adapter son processus de travail en conséquence.
D'un autre côté, de nombreuses entreprises continuent d'utiliser les méthodes de travail traditionnelles de type « cascade » ou hybrides, qui tirent parti de la spécificité et de la rigueur des exigences.
Si vous avez un produit destiné à un usage très précis, le recours à des spécifications est souvent la meilleure solution.
Lorsque l'on travaille sur des cahiers des charges, il est assez rare que l'équipe de développement modifie les exigences une fois qu'elles ont été rédigées. C'est pourquoi il est essentiel que les exigences de votre projet soient rédigées par une personne qui possède une connaissance approfondie du produit en question.
De plus, les systèmes de gestion des exigences peuvent aider les équipes agiles à faire le tri parmi ces exigences ; certains de ces systèmes sont d'ailleurs développés sur Azure DevOps pour une intégration encore plus fluide.
À l'inverse, si vous utilisez le modèle des user stories, n'importe quel membre de l'équipe de développement agile peut contribuer au backlog des user stories à tout moment au cours du projet.
Cela signifie que les «exigences »en tant que telles peuvent évoluer en cours de projet. Les développeurs doivent donc adapter leur travail pour tenir compte des changements intervenus dans le backlog.
C'est pourquoi les user stories agiles sont idéales pour les projets qui laissent une certaine marge de manœuvre, permettant ainsi aux développeurs de créer un logiciel qui semble naturel et intuitif.
En résumé
Même si elles déterminent toutes deux l'orientation d'un projet, les user stories et les exigences sont deux choses très différentes.
Les équipes qui travaillent selon la méthode traditionnelle en cascade ont tendance à se baser sur des spécifications et à s'efforcer de toutes les respecter, tandis que les équipes agiles ont tendance à recourir aux user stories en raison de leur flexibilité et de leur agilité.
Selon le projet en question, une équipe peut décider d'utiliser des spécifications, des récits utilisateur ou une combinaison des deux.
Demandez une démonstration !
- Prenez rendez-vous pour une démonstration avec l'un de nos experts produits qualifiés.
- Bénéficiez d'une démonstration personnalisée qui reproduit les processus de votre équipe
- Faites appel à nos experts pour des sujets tels que les processus de travail ou les bonnes pratiques.
Réduire les efforts liés aux tests d'acceptation utilisateur
Réduction de 50 % des efforts consacrés aux tests d'acceptation utilisateur
Un gain de temps avéré
Un gain de temps de 80 % lors de la création d'analyses de traçabilité
Simplifier les procédures d'approbation
Réduction significative des délais de validation
Améliorer les performances
Amélioration de la productivité de 50 %
Réduire les retouches
Réduction de 10 fois des retouches en phase de développement
Simplifier la mise en conformité
Réduction de 40 % des efforts liés à la production de rapports de conformité
