Qu'en pensez-vous ?

J'aime que cette dernière tâche incombe à un développeur choisit aléatoirement dans l'équipe de développement

Un défaut de cette pratique est qu'il est difficile de faire une planification précise de ce qui sera livré en fin de sprint car le backlog évolue constamment. S'il est nécessaire de savoir exactement le périmètre livré après un sprint alors il faut décaler les corrections de bugs des fonctionnalités "hors du sprint actuel" à un sprint ultérieur et les traiter de la même façon que les US.

Un bug créé par un testeur est assigné au PO qui prendra soin de le placer dans le sprint backlog à la hauteur qu'il souhaite : est-ce plus ou moins prioritaire qu'une des fonctionnalités de ce sprint. Une fois la priorisation faite, le bug est assigné à un développeur senior qui découpera en tâche sa correction et affectera celles-ci aux autres développeurs. 

plan de tests

Au quotidien les développeurs vont prendre (passage au statut "active") les tâches qui leurs sont assignées du haut du sprint backlog vers le bas : du plus prioritaire au moins prioritaire. Une fois une tâche développée, une PR est créée (passage de la tâche au status "suspended"  puis validée (passage de la tâche au status "closed" pour finalement être intégrée directement sur la branche principale.

Bien sûr cela ne nous empêche pas de faire évoluer ces affectations pendant le déroulé du sprint si cela est nécessaire.

Si les réponses ne peuvent être données et rédigées en live j'ai pour habitude de créer et placer un tag "Attente spécifications" sur les US incriminées. Une seconde relecture permettra de l'en enlever une fois tous les doutes levés.

Est-il possible de réaliser cela ? Est-ce que je comprends bien tous les termes employés : ne JAMAIS laisser une ambiguïté potentielle subsister. Est-ce que tous les cas possibles sont décrits dans l'US ? Est-ce cohérent avec les développements déjà mis en place ? Est-ce cohérent avec les autres US que j'ai pu déjà lire ? Y a t'il un risque technique potentiel à exprimer au PO : performance, qualité, disponibilité du service... ?

L'attendu fonctionnel : qu'est ce que l'on attends du produit / de la plateforme. Les utilisateurs habilités pour effectuer l'action considérée. L'emplacement de cette fonctionnalité et son contexte d'utilisation. Une maquette (ou un wireframe à défaut). --> Il est donc bien sûr nécessaire d'anticiper ce besoin et de créer les maquettes avec notre designer préféré à l'avance. Un descriptif des champs : format, taille min, taille max, valeurs autorisées et refusées.  Souvent oublié : la gestion des cas d'erreur. Est-ce que si un problème survient, cela bloque l'intégralité du processus ou on se contente de le logger techniquement ? Comment afficher le message d'erreur à l'utilisateur ?

Ce backlog doit à tout moment être priorisé par le PO (et uniquement le PO) : les US les plus importantes sont en haut, les moins importantes sont en bas et tout lecteur du backlog sait quelle fonctionnalité est plus importante qu'une autre. Cette priorisation évolue avec le temps et il est tout à fait possible de changer la priorité d'une US par rapport à une autre dans le backlog général

Personne du projet

Personne du projet

sur les US sont aussi rédigés sur les US.