Affinement du backlog – automatisé

Affinement du carnet de commandes

Le raffinement du backlog est l'activité de préparation des éléments de travail sur lesquels votre équipe logicielle doit travailler. Votre arriéré de user stories, de tâches de développement et d'idées épiques est le file d'attente des éléments de travail potentiels à travailler dans les semaines à venir (sprints). Pour maintenir un flux de travail constant pour l'équipe, une liste d'éléments de backlog affinés doit être prête sur laquelle l'équipe peut commencer à travailler à tout moment. Il devrait y en avoir un peu plus prêt et prioritaire que ce dont l'équipe a besoin pour les prochains sprints.

Que signifie le raffinement du backlog ?

Le raffinement du backlog (ou préparation du backlog) signifie travailler sur la validité et les détails des exigences/idées/tâches afin que les questions clés reçoivent une réponse correcte, de sorte que le développeur/testeur fasse la bonne chose du premier coup. Les user stories doivent être affinées et prêtes avant le début du travail de codage et de test.

Pour raccourcir vos réunions en retard, vous souhaitez que votre contribution soit de la plus haute qualité possible. Cela signifie demander à votre analyste commercial ou propriétaire de produit d'affiner les user stories autant que possible avant la réunion. L'analyse automatisée peut vraiment vous aider, car elle vous aidera à mettre vos histoires en bon état avant la réunion de perfectionnement.

Que signifie réellement « prêt » ?

Prêt, ou définition de prêt, signifie que suffisamment de vérification, de questionnement, de reformulation, de révision et d'analyse ont été effectués AVANT le codage, afin que le travail de codage puisse être effectué correctement du premier coup. Cela signifie que les objectifs de l'utilisateur sont parfaitement compris, clairs, idéalement mesurables et certainement sans ambiguïté avant qu'une ligne de code ne soit écrite. (Le prototypage Nb est souvent un moyen utile de vérifier les exigences, mais le prototypage n'est pas nécessairement du codage).

Une user story raffinée doit être :

Simplifié

Vos user stories doivent être des déclarations fonctionnelles courtes et concises qui décrivent complètement les étapes fonctionnelles des exigences complètes d'un utilisateur. De telle sorte que le système soit dans un état stable avant et après que les étapes aient eu lieu.

Clarifié

Vos user stories doivent être claires, succinctes et sans ambiguïté. L’idéal est que plusieurs membres décrivent leur interprétation de chaque user story. Chaque interprétation est la même. Or, c’est difficile avec la langue anglaise, parfois même si toutes les parties étaient présentes lors de la conversation décrivant la user story. L'objectif est d'obtenir cette interprétation cohérente par tous les membres de l'équipe, c'est-à-dire. un compréhension partagée.

Orienté utilisateur

Nous voyons beaucoup d'histoires d'utilisateurs commencer par « en tant que développeur… ». Cela ne décrit pas l'exigence du point de vue de l'utilisateur, il s'agit plutôt d'une tâche.  Avant de créer des tâches de développeur, vous devez d'abord disposer d'une user story qui décrit ce que l'utilisateur doit réaliser et pourquoi. Alors et seulement alors, vous pourrez décomposer cela en tâches de développeur, si nécessaire.

Cohérence vérifiée

Il est essentiel que vous utilisiez des termes cohérents tout au long de vos user stories pour chaque utilisateur. Il est également essentiel que vous utilisiez des mots identiques pour chaque type d'objet. Ce problème est très courant lorsque deux personnes ou plus rédigent les user stories, mais il peut même arriver qu'une seule personne fasse le travail. Une utilisation incohérente des noms d’objets ou des personnages d’utilisateurs entraînera des interprétations incohérentes et des erreurs.

Complétude vérifiée

Votre user story est-elle complète, décrit-elle toutes les fonctionnalités nécessaires pour offrir l'expérience utilisateur ou les fonctionnalités nécessaires ? Avez-vous « enterré » les fonctionnalités réelles dans vos critères d'acceptation (c'est une erreur très courante).

Si vous conservez des données dans un système, il est courant d'effectuer une analyse CRUD et de créer une matrice CRUD. Cela vous aidera à garantir que toutes les données sont créées, lues, mises à jour et supprimées par au moins un processus. L'analyse CRUD est un moyen efficace et efficient de garantir que vos user stories sont compétitives en elles-mêmes. À terme, toutes les données doivent être entièrement conservées par un système. Effectuer une analyse CRUD tôt donnera une meilleure appréciation de la portée éventuelle de votre projet.

Dimensionné

Il est important de dimensionner chaque user story, epic ou tâche dans votre backlog. Pourquoi? Pour que vous puissiez planifier et prioriser les travaux. Bien que de nombreuses équipes utilisent l’idée de tailles de t-shirts ou de story points, celles-ci sont d’une utilité limitée car elles sont incohérentes et n’ont aucune signification absolue. Nous recommandons:

• Tâches sont dimensionnés en heures-personnes ou en jours-personnes.
• Histoires d'utilisateurs, les user stories spécifiquement fonctionnelles sont dimensionnées en COSMIC Function Points (CFP).
• Épopées peut généralement être estimé en CFP.

Nb. Les CFP d'une équipe sont généralement facilement convertibles en heures estimées. Pour en savoir plus sur les points de fonction COSMIC.

Priorisé

Les éléments du backlog doivent être priorisés. La priorité (et l’ordre des éléments de priorité similaire) doivent être déterminées en tenant compte au moins des considérations suivantes :

• Valeur de la fonctionnalité pour l'entreprise, y compris son utilisation probable
• Taille (détermine l’effort probable à fournir).
• Impact sur l'entreprise de retarder cela. Coût du retard.
• Relation technique de cette fonctionnalité avec d'autres, c'est-à-dire dépendances techniques
• Risque d'inconnues pouvant entraîner un changement significatif dans d'autres travaux effectués.

Une technique courante pour mapper certaines de ces considérations à une valeur numérique est appelée Weighted Shortest Job First (WSJF).

Colin Hammond, 2022

Affinement du backlog automatisé

D'autres articles sur ce sujet traiteront du fractionnement et de l'élaboration d'histoires. Nous considérons ces termes comme un peu vagues. Nous avons été plus précis parce que c’est important de l’être. Un mot erroné dans une exigence peut conduire à une mauvaise interprétation et potentiellement à des heures et des heures de perte, si le code doit être réécrit.

Lectures complémentaires sur des sites externes

J'ai eu du mal à trouver de nombreux articles que je puisse fortement préconiser. Je recommande ce livre Software Requirements, par Karl Wiegers et Joy Beatty

Article Digite sur le raffinement du backlog