Il est pas toujours facile de s' y retrouver, entre jargon et realite.
j' y trouve de la doc qui est plutot bien fichue , je voulais faire un point
Budget : Non défini
La forme canonique d'une User Story
Une User Story présente une vision utilisateur autour de 3 axes : rôle, besoin et valeur métier
Le langage Gherkin "GIVEN - WHEN - THEN" pour définir ses scénarios
Ce format provient du BDD (Behavior Driven Developement) qui provient des techniques de dev en projet Agile. Il a pour objectif d'intégrer une formalisation du développement pour obtenir à terme automatiquement des tests fonctionnels, en écrivant des scénarios de tests compréhensibles par des individus non techniques. Cette approche sert deux objectifs : documenter les fonctionnalités à développer d’une part, et permettre l’automatisation des tests d’autre part.
La définition d’un scénario de test en Gherkin se fait selon trois étapes clés : Given, When Then.
<Etant donné> les utilisateurs suivants : Nom/Prénom, position/fonction ou une situation de départ donnée = UN CONTEXTE
<Quand ou lorsque> j'ajoute/je supprime/je modifie cette donnée : l'utilisateur effectue une ou plusieurs ACTIONS
<et que>
<mais>
<Alors> je dois obtenir ce résultat : on doit pouvoir constater telles conséquences ou situation d'arrivée
<Et> est utilisé de manière optionnelle pour ajouter des conditions au besoin
L'idéal est de s'appuyer sur un fichier d'injection d'un jeu de données qui sont nos valeurs de tests pour que ça reste fonctionnel et cohérent à l'échelle de l'équipe entière.
Exemple Nominal :
Fonctionnalité : Authentification
Scénario : Tentative d’authentification avec un compte valide
Étant donné que je dispose d’un compte utilisateur « marie »
Quand j’accède à la page d’authentification /auth.html
Et que je saisis mon identifiant « marie » dans le champ « Login »
Et que je saisie mon mot de passe dans le champ « Password »
Et que je clique sur le bouton « Connexion » du formulaire
Alors je suis authentifié sur le site
Et je suis redirigé vers la page « Mon compte » à l’URL /mon-compte.html
Selon ce framework, une bonne user story est :
I — Indépendante : elle doit se suffire à elle-même, car les dépendances avec d’autres user stories induisent des problématiques de testabilité et de planification.
N — Négociable : elle doit amener à la discussion et peut être modifiée jusqu’à son inclusion dans une itération.
V — Valeur : elle doit apporter de la valeur à l’utilisateur final. La notion de valeur étant toujours difficile à évaluer, la user story doit être exprimée avec une vision de l’objectif recherché pour l’utilisateur.
E — Estimable : elle doit être suffisamment claire et comprise par l’équipe pour que celle-ci soit en capacité de l’estimer.
S — Small : elle doit être de taille assez petite pour prioriser de façon sûre et éviter les effets tunnels. Essayez donc au maximum de découper finement
vos user stories.
T — Testable : la user story doit raconter une histoire, dont les tests découlent de façon évidente.
Attention ! Dans la pratique, il est très compliqué d’avoir un backlog totalement INVEST.
Par exemple, il existera nécessairement des stories dépendantes entre elles que vous serez obligés de traiter les unes à la suite des autres. Cette méthode permet surtout au Product Owner de questionner son découpage et le contenu de ses user stories. C’est donc d’avantage une ligne de conduite qu’une règle immuable.
SMART est un acronyme qui va donner des règles pour créer vos demandes fonctionnelles que vous pourrez ensuite utiliser pour créer vos user-stories :
S => Specific : la demande doit être bien définie et compréhensible par tous ceux qui la lisent.
M => Measurable : la demande doit être facilement identifiable par l’équipe afin que l’équipe sache concrètement comment faire pour qu’elle passe du « todo » à « done » sans la moindre difficulté.
A => Achievable : la demande doit pouvoir être terminée par les équipes sans le moindre de doute. L’équipe doit avoir toutes les compétences requises pour traiter la demande.
R => Relevant : la demande doit être pertinente pour le produit et apporter de la valeur à celui-ci. Pourquoi créer une user-story si elle n’apporte rien au produit et aux utilisateurs clés ?
T => Timeboxe : la demande doit être estimable dans le temps ou estimable dans sa complexité. Elle ne doit pas comporter trop d’incertitudes aux yeux des développeurs.
je pense que je vais passer en brouillon ce tutoriel