INVESTISSEZ dans vos user stories
Pourquoi tant d’entre nous ont-ils du mal à écrire de bonnes histoires ?
Je vois souvent des gens qui ont du mal à couper et à rogner les user stories. « Est-ce trop gros », « Où dois-je le partager ? », « Est-ce que cela peut être inclus dans l’historique de cet utilisateur dans le cadre du même parcours utilisateur » sont les questions auxquelles je suis confrontée chaque jour. Et bien sûr ainsi. Beaucoup d’entre nous viennent de processus qui ont fonctionné dans l’autre sens. Autrement dit, à cette époque, il n’était pas nécessaire de tant réfléchir à la valeur d’une demande, car nous ne verrons probablement ce changement mis en œuvre qu’après deux ans. Si ce n’est pas ce dont nous avons besoin, nous déposerons une demande de modification.
Utilisez d’abord les roues d’exercice
Heureusement, dans les méthodes Agiles, nous pensons à la valeur que l’histoire que nous pensons apportera au client. Si nous sommes assez chanceux, nous faisons équipe avec le client pour obtenir bon nombre des hypothèses de cette question précieuse. Mais beaucoup n’ont pas ce luxe et ont besoin d’un ensemble de rouages pratiques tout en apprenant à écrire de bonnes user stories.
INVESTISSEMENT Critères d’antécédents sains
Lorsque je forme des jeunes en Agile sur les pratiques d’écriture de user story, je suis content lorsqu’ils sont satisfaits des critères INVEST pour une bonne écriture de story. Plongeons dans le sens.
I – Indépendant : Nous devons être capables de changer les histoires rapidement sans provoquer d’effet d’entraînement de la replanification. Les histoires doivent être libres de toute séquence, afin qu’elles puissent être classées par ordre de priorité individuellement.
N – Négociable : les histoires sont un rappel pour avoir des conversations et ne doivent pas être considérées comme un contrat signé. Le résultat réel d’une user story est la collection de conversations qui ont eu lieu pendant le sprint entre le client (ou le propriétaire du produit), le développeur et au moins le testeur. Rappelez-vous toujours que l’objectif est de répondre aux besoins du client et non de développer chaque histoire d’utilisateur de police. Si vous préférez ce dernier, retournez à la cascade.
V – Valide : chaque histoire doit valoriser soit un client, soit un processus interne en tant qu’exigences non fonctionnelles. Si cela n’ajoute pas de valeur, cela ne devrait pas être fait. Point final.
E – Noté : Une histoire doit être volumineuse pour être planifiée. Si c’est inestimable, alors c’est probablement trop grand ou il y a trop d’inconnues. Démêlez plus et faites quelques hypothèses si vous ne pouvez pas comprendre toutes les ambiguïtés.
S – Petit : Une histoire doit être aussi petite que possible, mais toujours donner de la valeur. Le fait d’avoir un flux constant de lots de travaux de même taille dans le système améliore notre prévisibilité et réduit les écarts. Faites la chose la plus simple et puis arrêtez. Abandonnez l’or à tout prix.
T – Testable : Si nous ne pouvons pas tester une histoire, alors nous devons reconsidérer si c’est une histoire d’utilisateur du tout. Sinon, à quoi cela ressemblerait-il si nous ne pouvions pas le mesurer avec les critères d’admission établis ? Les critères d’acceptation définis à l’avance prouvent que l’historique de l’utilisateur est testable et encourage la collaboration autour de l’historique dès le plus jeune âge.
Tout mettre en pratique
La preuve est dans le pudding. Pour votre prochain atelier sur l’historique des utilisateurs / session de raffinement des fichiers restants, entraînez-vous à écrire des histoires d’utilisateurs en pensant à INVEST. En cas de doute, demandez « comment saurai-je que cela a été fait ».
Articles similaires:
