Affiner les témoignages d'utilisateurs
Affiner les user stories est le processus d’amélioration, de division et de clarification de chaque user story. Le détail et la clarté de chaque user story doivent être revisités. Le backlog toilettage est un terme qui fait généralement référence au processus de niveau supérieur de priorisation des user stories. Le raffinement (clarification) et le toilettage (établissement de priorités) sont des étapes importantes pour atteindre de bonnes exigences de qualité. Le premier garantit que l'utilisateur obtient ce qu'il veut et le second gère le séquençage pour répondre à la fois aux besoins de l'entreprise et à l'efficacité de l'équipe de développement. Dans cet article nous nous concentrerons ici sur le raffinement des user stories, laissant la priorisation dans un article séparé.
Objectif des user stories
Le but des user stories est de communiquer, pour garantir que les besoins de l'utilisateur sont correctement exprimés dans un langage qu'un développeur et un testeur peuvent comprendre pleinement et systématiquement. Les user stories doivent être orienté utilisateur, simple, clair, non ambigu et cohérent, avec rien manquant. En affinant vos histoires, vous éliminerez de nombreux défauts d’exigences qui ne sont souvent détectés que bien après le début des travaux de conception et de développement. Affiner les user stories avec ScopeMaster est généralement 10 à 20 fois plus rapide que de le faire manuellement.
Histoires d'utilisateurs ou exigences
Les user stories et les exigences sont-elles la même chose ? Certains puristes agiles expliqueront que les user stories sont des rappels de conversations et donc non des exigences. Nous avons cependant observé que pour la plupart des équipes, le les user stories sont traitées comme des exigences, et donc nous faisons de même. Les exigences ou les user stories sont essentiellement une expression des capacités dont les utilisateurs ont besoin du logiciel, pour assurer une communication claire et cohérente avec l’équipe. Notez que les User stories (ou exigences) n’incluent pas de tâches techniques ni de contraintes de projet. Nous utiliserons ci-après les termes exigence et Histoire de l'utilisateur de manière interchangeable.
Les défauts dans les user stories sont inévitables
La rédaction d’exigences ou de user stories est la même que pour tout autre travail de connaissances : nous commettons des erreurs au fur et à mesure. Même si nous sommes prudents, des erreurs se produiront, elles sont inévitables. De plus, nous les rédigeons généralement en anglais, une langue incroyablement subtile où chaque mot peut être compris de différentes manières par les lecteurs. Ainsi, même si nous pensons les avoir bien écrits, il est fort probable que les lecteurs parviendront à une compréhension légèrement différente. Si deux lecteurs de user story peuvent parvenir à une compréhension différente, alors vous avez un défaut. Un défaut dans une user story ou une exigence entraînera la création d’un mauvais logiciel.
Coût des défauts dans les user stories ou les exigences
Comprendre le coût de la qualité est un sujet très important car il peut nous aider à comprendre pourquoi la qualité des exigences est vraiment importante. Un défaut d'exigences qui n'est pas résolu avant le développement, entraînera un bug. C'est un fait inévitable. De nombreux problèmes d’exigences sont détectés au cours du développement. Mais pas tous. Examinons quel sera l'impact si nous ne trouvons et corrigeons cette erreur que plus tard dans le cycle de vie du développement logiciel (SDLC). Si l'erreur est détectée pendant le développement, nous devrons peut-être arrêter le développement, vérifier quelle est l'exigence correcte, puis la reconcevoir et réécrire le code. Cela prend du temps et perturbera et retardera les progrès. Selon la nature et la gravité du défaut de l'exigence, cela peut conduire à des retouches majeures (conception différente, architecture différente). Cela peut retarder les projets et entraîner des augmentations de coûts significatives.
Considérons maintenant une situation encore plus grave dans laquelle un défaut dans une exigence n'est remarqué qu'après que le code ait atteint la production. Cela peut avoir des conséquences encore plus graves. Le logiciel peut faire une mauvaise action et nuire aux utilisateurs ou à l'entreprise. Cela peut avoir un impact catastrophique.
Coût de récupération suite à des défauts dans les exigences
Si un défaut causé par de mauvaises exigences est constaté dans la production, et qu'il est grave, il existe deux catégories de coûts : internes et externes.
Coûts internes
- Le travail supplémentaire pour changer le logiciel pour qu'il fonctionne correctement
- Le travail supplémentaire pour modifier les données qui ont été mal traitées en raison de la faute
- Le coût d'opportunité lié à la réaffectation du personnel à la résolution de ce défaut plutôt qu'à d'autres travaux utiles
Coûts externes
- Coût conséquent pour les utilisateurs ou bénéficiaires du logiciel, causé par le bug
- Compensation aux utilisateurs ayant subi ce bug
- Travail supplémentaire effectué par le personnel non-logiciel pour gérer l'incident/l'impact sur les utilisateurs jusqu'à ce que le bug puisse être corrigé
- Dommage à la réputation d’une organisation
Dans la plupart des cas, les équipes de projets logiciels sous-estiment le coût d’exigences médiocres. Si vous souhaitez en savoir plus sur ce sujet, je vous recommande cet excellent livre "L'économie de la qualité des logiciels"
Assurance qualité automatisée des exigences
ScopeMaster porte le travail d'assurance qualité des exigences à un nouveau niveau. ScopeMaster aide à accélérer le travail d’amélioration de la qualité des exigences et d’affinement de la user story.
ScopeMaster automatisera la recherche et accélérera la correction de nombreux défauts d'exigences pour garantir que vos exigences ou user stories sont :
- Clair
- Concis
- Cohérent
- Complet
- Testable
- Important
- Unique
- Orienté utilisateur
- Conception gratuite
Le seul attribut important que ScopeMaster ne peut pas automatiser est de détecter si vous avez réellement besoin de l'exigence, est-elle utile ? Vous devrez résoudre ce problème vous-même, mais ScopeMaster vous libère tellement de temps que vous aurez la capacité de considérer la valeur réelle de chaque exigence.
En savoir plus sur affinement automatisé du backlog
Quelles sont les bonnes exigences ?
Nous avons établi que de mauvaises exigences sont néfastes, coûteuses, inutiles et, dans certains cas, même dangereuses. Alors, comment pouvons-nous rédiger de bonnes exigences ? Comment savoir si nos exigences sont bonnes ? Comment pouvons-nous détecter les problèmes dans les exigences ? Il existe quelques ingrédients universels aux bonnes exigences que nous allons décrire et qui vous aideront à :
Orienté utilisateur
Toutes les exigences doivent être exprimées en fonction des besoins d'un utilisateur. Elles peuvent ensuite être divisées en tâches de développeur, mais une version de l'exigence doit d'abord être exprimée par rapport au besoin de l'utilisateur afin que nous puissions être sûrs que ce qui sera développé répondra au besoin de l'utilisateur.
Clair et sans ambiguïté
Une exigence ne doit pas être facilement mal comprise par les lecteurs. C’est peut-être la dimension la plus difficile à garantir. Cela signifie qu'une exigence doit décrire clairement les fonctionnalités qu'un utilisateur doit exécuter. Deux lecteurs de la même exigence doivent parvenir à la même compréhension générale des données qui doivent être traitées dans le cadre de l'exigence.
Concis
Les exigences doivent être concises. Une exigence n’a pas besoin d’être verbeuse ni d’utiliser un langage fleuri et élégant.
Cohérent
Un ensemble d'exigences doit utiliser des termes cohérents pour les types d'utilisateurs, par exemple administrateur. Un ensemble d'exigences doit également utiliser des termes cohérents pour les types de données (types d'objets).
Complet
Une exigence doit être complète en elle-même (décrire toutes les étapes fonctionnelles nécessaires à cette capacité utilisateur). En outre, un ensemble d'exigences doit être complet, décrivant toutes les fonctionnalités nécessaires pour conserver toutes les données au sein du système. Pour cela, l’analyse CRUD est la plus utile.
Important
Si une exigence d'un utilisateur n'est pas fonctionnellement importante (c'est-à-dire mesurable en points de fonction COSMIC), alors elle manque presque certainement de qualité si l'un des autres aspects de cette liste est présent. C'est pourquoi nous considérons que la capacité de dimensionnement en CFP est un excellent test de clarté et de qualité des exigences. Nb. les tâches techniques et les exigences non fonctionnelles ne sont ainsi pas importantes. Les tâches techniques sont généralement dimensionnées en heures de travail. Le dimensionnement non fonctionnel est un problème non résolu, bien qu'il existe quelques recommandations (dans un article séparé).
Testable
Les testeurs doivent être capables de déterminer comment tester qu'une exigence a été satisfaite. L’exigence doit donc être rédigée de manière à pouvoir être testée. L’un des meilleurs moyens de garantir que cette exigence est testable est de garantir qu’elle décrit clairement l’intention fonctionnelle. (Pour cela nous recommandons le dimensionnement COSMIC)
Unique
Nous ne voulons pas qu'un ensemble d'exigences contienne du contenu ou des fonctionnalités en double. (C’est peut-être l’un des problèmes de qualité les moins importants en matière d’exigences.)
Sans conception
Les user stories ne doivent contenir aucun détail sur la manière dont une fonctionnalité doit être implémentée. Une user story n’est pas un espace réservé pour les détails de conception. Vous pouvez diviser le travail de mise en œuvre d'une user story en tâches techniques, mais ce ne sont pas des user stories.
Précieux
Chaque user story doit apporter de la valeur à l’utilisateur ou à la partie prenante, sinon elle ne doit pas être construite. La valeur doit être exprimée dans des termes que l'utilisateur (et non le développeur) reconnaîtra.
Il s'agit de notre liste recommandée de 10 attributs de bonnes histoires d'utilisateurs ou d'exigences logicielles. Cela s’applique dans toutes les situations. Certains experts en exigences diront à juste titre que cela ne va pas assez loin. C’est vrai, il existe certaines situations dans lesquelles les exigences devraient répondre à des normes encore plus élevées que celles que nous avons décrites ici. Ce que nous avons décrit est un ensemble d'attributs qui doivent s'appliquer partout, quel que soit le type de logiciel que vous développez/assemblez/déployez.
Attention à INVESTIR !
INVEST est un pneumonique inventé par les premiers agilistes pour fournir une sorte de liste de contrôle aux user stories. Ça signifie:
- Je suis indépendant (de tous les autres)
- « N » négociable (pas de contrat spécifique pour les fonctionnalités)
- "Précieux
- « E » stimable (avec une bonne approximation)
- Centre commercial « S » (de manière à s'insérer dans une itération)
- « T » estable (en principe, même s'il n'existe pas encore de test pour cela)
Nous aimons les listes de contrôle, mais nous trouvons que la liste INVEST présente trop de lacunes pour être universellement fiable pour évaluer la qualité des exigences et déconseillons son utilisation.
Ne parvient pas à garantir que les histoires sont orientées utilisateur
Si un logiciel ne fait pas quelque chose d’utile pour un utilisateur, il n’est pas utile. Si nos histoires ne sont pas orientées utilisateur, alors ce sont de simples tâches de travail. Et c’est ce que tant de user stories finissent par devenir, des tâches et non des expressions de fonctionnalités ou de capacités reconnaissables par l’utilisateur. Bref, votre expression de fait sera probablement pauvre.
Ne parvient pas à garantir la cohérence
Si vous suivez uniquement ces directives, vous risquez de vous retrouver avec des exigences qui brouillent les noms d'utilisateurs/personnes et comportent de nombreux termes différents pour les types d'objets.
Ne parvient pas à garantir une taille importante
En faisant référence à Estimable et non sizeable, cette approche ne parvient pas à garantir que chaque user story a une taille (fonctionnelle). La taille fonctionnelle n'est pas seulement précieuse pour la gestion de projet, mais constitue également un bon test de la qualité des exigences. Une exigence importante est une exigence de bonne qualité.
Ne parvient pas à garantir une conception sans conception
S'appuyer uniquement sur INVEST entraînera une confusion de vos user stories avec des tâches (et des « user stories techniques »), ce qui éloignera le travail de l'utilisateur et sa valeur pour lui.
Utiliser ScopeMaster
Moins d’une heure après la première utilisation de ScopeMaster, vous détecterez et corrigerez les défauts des exigences plus rapidement que jamais. En fonction de la qualité des exigences initiales, vous pourriez détecter et corriger jusqu'à 200 défauts par jour. Pouvez-vous penser à une autre activité qui serait aussi productive pour détecter et corriger les défauts ?
Suivez ces étapes:
- Importez vos user stories (via un fichier CSV).
- Cliquez sur « Tout analyser » (vous aurez peut-être le temps de prendre un café).
- Explorez les résultats de l'analyse de ScopeMaster
- Commencez par les plus ambigus et reformulez-les pour en faire des user stories fonctionnelles claires et orientées utilisateur
- Utilisez le dictionnaire de données généré automatiquement et le modèle de cas d'utilisation pour garantir une dénomination cohérente des utilisateurs.
- Utilisez l'analyse CRUD pour garantir une dénomination cohérente des objets
- Examinez les commentaires sur la qualité fournis par ScopeMaster pour les améliorer encore.
- Utilisez l'analyse CRUD pour vous assurer que l'ensemble des exigences est complet
