Comment gérez-vous les histoires dépendantes dans la mêlée?

Dans l'entreprise sur laquelle je travaille actuellement, nous avons remarqué que parfois, certaines histoires sont liées les unes aux autres (comme trop couplées). Cela peut être dû au fait qu'ils appartiennent à la même fonctionnalité globale, ou qu'il s'agit de fonctionnalités différentes, mais il y en a certaines qui doivent être terminées en premier afin de continuer avec les suivantes, etc.

Comment gérez-vous ces cas, sans arrêter le flux de travail de l'itération? Faisons-nous quelque chose de mal?

c'est une excellente question. La théorie dit que les histoires d'utilisateurs devraient être indépendantes, mais je n'ai jamais pu y parvenir pleinement.

À mon avis, le plus important est de communiquer la dépendance afin que l'équipe et le propriétaire du produit en soient conscients. Cela obligera le propriétaire du produit à redéfinir les user stories afin que la dépendance soit supprimée (par exemple en fusionnant les user stories) ou à définir la priorité métier en conséquence afin que la user story principale soit mise en œuvre en premier.

Sur la base de la décision de priorité et de bon de commande, vous implémenterez les deux dans le même sprint ou celui dépendant sera implémenté plus tard sans aucun problème car le principal sera déjà fait.

Le pire des cas est si A dépend de B et B dépend de A. Dans ce cas, les user stories sont très probablement mal définies et devraient probablement être réécrites en A et B (principalement indépendantes ou avec une seule dépendance) et C dépendant de A et B.

Planifiez-les en conséquence.

Mettez-les dans le même sprint, et puisque les user stories sont également priorisées dans un backlog de sprint, vous n'aurez aucun problème.

Puisque votre équipe y participe, elle est consciente des dépendances, il n'y a donc rien à craindre. Ce sont des adultes et si vous leur expliquez les dépendances (généralement ils vous l'expliqueront), tout se passera bien.

Dans Agile, comme dans Waterfall, vous ne pouvez faire qu'une seule chose à la fois. Et vous faites habituellement A avant B si B a besoin de A. C'est du bon sens.

Les dépendances peuvent être une odeur que vous coupez vos histoires horizontalement au lieu de verticalement à travers le système. Le développement d'une fonctionnalité particulière doit impliquer tout, de la modification de la conception de la base de données jusqu'à l'interface utilisateur. Si vous constatez que vous dépensez tous vos efforts sur une user story à un niveau inférieur de la structure du système, comme, par exemple, l'écriture de routines de gestionnaire pour les recherches de base de données, alors vous êtes plus susceptible de créer des dépendances entre les stories. Et, vous écrivez probablement mal vos histoires d'utilisateurs.

Votre meilleur pari est de diviser vos histoires d'utilisateurs dépendantes en petits morceaux qui peuvent devenir aussi indépendants que possible. Vous devez d'abord aborder les histoires dont vous dépendez le plus (comme vous l'avez dit: celles qui doivent être terminées en premier pour continuer les autres). Créez quelque chose comme un indice de dépendance: si l'histoire 3 a plus de dépendants que l'histoire 1, vous devez d'abord aborder l'histoire3.

Si vos dépendances provoquent trop d'arrêts, il peut être judicieux d'arrêter complètement le travail (oui en plein milieu de votre sprint actuel) et de réévaluer vos user stories prioritaires et d'aborder celles-ci